Ich weiß nicht, seit wievielen Jahren genau es als „bad practice“ gilt, Bounces zu versenden. Bounces gehen nun mal an die Adresse, die als Envelope Sender in der SMTP-Session angegeben wird – und das muss eben durchaus nicht die Adresse desjenigen sein, der die Mail tatsächlich verschickt hat. Insbesondere bei Spam ist das regelmäßig nicht der Fall, was letzten Endes heißt: Mailserver, die Mails nicht direkt in der SMTP-Session ablehnen, sondern jene erst akzeptieren und dann später bouncen, lösen damit als Antwort auf eine Welle von Spam eine Welle von Bounces aus, die dann denjenigen trifft, den der Spammer zufällig als Absender gewählt hat. Ich selbst habe im Lauf der Jahre immer mal wieder erlebt, wie plötzlich innerhalb weniger Stunden zehntausende von Bounces auf meiner Mailadresse eintrafen, die jemand als Absender von Spam verwendet hatte.
Das Ärgerliche dabei ist, dass sich sowas nur schwer filtern lässt, denn die Bounces sind ja so gesehen durchaus „legitime“ im Sinne von „gut gemeinten“ Mails; sie haben keinen strikten Aufbau, und im blödesten Fall zitieren sie auch die Originalmail nicht, so dass der Spamfilter wirklich keine Chance hat, wenn ich ihn nicht darauf trainieren will, allgemein Bounces als Spam anzusehen.
Folgerichtig haben einige RBL-Betreiber damit begonnen, nicht nur Hosts, die Spam versenden, auf ihre Listen zu setzen, sondern auch Hosts, die Bounces versenden. Dazu gehören nicht nur ganz exotische RBLs, sondern auch Größen wie z.B. SpamCop, die durchaus eine gewisse Reputation haben und das Problem in ihrer FAQ gut erläutern.
Mittlerweile sind so ziemlich alle Mailserver auf einem Entwicklungsstand, dass sie Mails, die sie dann ohnehin nicht zustellen, auch gar nicht erst annehmen. Selbst das von uns gerne eingesetzte netqmail, dem gerne – und zu Recht – vorgeworfen wird, „delayed bounces“ zu senden, setzen wir nicht ohne eine Empfängerprüfung ein, in der Regel den validrcptto.cdb-Patch.
Der Einzige, der mir legitimer- und auch erwünschterweise Bounces senden können sollte, dürfte in einer idealen Welt ausschließlich der Mailserver sein, den ich zum Relaying verwendet habe – denn der muss ja nun meine zu verschickenden Mails erstmal annehmen; er ist ja nicht der Empfänger, sondern der Postbote, der dann erstmal schauen muss, wo er eine Mail hintragen muss, und von daher regelmäßig erst später wissen kann, ob ein Empfänger existiert oder nicht.
An wem aber ist diese an sich doch recht positive Entwicklung, Mails, die man nicht haben will, direkt in der SMTP-Session abzulehnen, weitestgehend spurlos vorübergegangen? Am Über-600-Millionen-User-Netzwerk Facebook, deren Macher es als gute Idee ansehen, dass ihre User nun auch per E-Mail mit Nicht-Facebook-Mitgliedern kommunizieren können (und ich als Nicht-Facebook-Mitglied hatte das immer als Feature angesehen, dass das nicht geht – also, als Feature für mich meine ich).
Facebook-User haben offenbar die Möglichkeit, dies als Option ein- oder auszuschalten. Leider dringt das nicht bis zum Facebook-MX durch, der Mails an User, die das gar nicht wollen, problemlos annimmt:
$ dnsmx facebook.com 10 smtpin.mx.facebook.com $ telnet smtpin.mx.facebook.com 25 Trying 66.220.155.11... Connected to smtpin.mx.facebook.com. Escape character is '^]'. 220 smtpin.mx.facebook.com ESMTP HELO mainz.jonaspasche.com 250 smtpin.mx.facebook.com says HELO to 82.207.131.175:46878 MAIL FROM:<jpasche@jonaspasche.com> 250 MAIL FROM accepted RCPT TO:<SOME_USER@facebook.com> 250 RCPT TO accepted DATA 354 continue. finished with "\r\n.\r\n" Subject: Test Test . 250 OK 82/1F-27359-C29DDED4 QUIT 221 smtpin.mx.facebook.com closing connection Connection closed by foreign host.
Sekunden später trudelt die Bouncemail ein (hier der Übersicht wegen etwas gekürzt; eigentlich ist es ein multipart/report):
From: Facebook <mailer-daemon@mx.facebook.com> To: jpasche@jonaspasche.com Subject: Sorry, your message could not be delivered Date: Tue, 07 Jun 2011 00:55:25 -0700 This message was created automatically by Facebook. Based on the email preferences of the person you're trying to email, this message could not be delivered. Reporting-MTA: dns; 10.138.205.200 Arrival-Date: Tue, 07 Jun 2011 00:55:22 -0700 Status: 5.1.1 Last-Attempt-Date: Tue, 07 Jun 2011 00:55:55 -0700 Final-Recipient: rfc822; SOME-USER@facebook.com Action: failed Diagnostic-Code: smtp; 550 5.1.1 RCP-P2 http://postmaster.facebook.com/response_codes?ip=82.207.131.175#rcp Refused due to recipient preferences
„Refused due to recipient preferences“ – und das wusste man zum Zeitpunkt des RCPT TO noch nicht? Also bitte, das muss doch im Jahr 2011 besser gehen. Vor allem dann, wenn man Mail für so eine große Userbasis macht.