Warum kann eine leere MAIL FROM-Adresse eine E-Mail versenden?

Wir verwenden das Smarter Mail-System. Kürzlich stellten wir fest, dass Hacker einige Benutzerkonten gehackt und viele Spam-Mails verschickt hatten. Wir haben eine Firewall, um den Absender einzuschränken, aber für die folgende E-Mail konnte die Firewall dies aufgrund der leeren FROM-Adresse nicht tun. Warum gilt eine leere FROM-Adresse als OK? Tatsächlich können wir in unserem MTA (Surgemail) den Absender im E-Mail-Header sehen. Irgendeine Idee?

11:17:06 [xx.xx.xx.xx][15459629] rsp: 220 mail30.server.com
11:17:06 [xx.xx.xx.xx][15459629] connected at 6/16/2010 11:17:06 AM
11:17:06 [xx.xx.xx.xx][15459629] cmd: EHLO ulix.geo.auth.gr
11:17:06 [xx.xx.xx.xx][15459629] rsp: 250-mail30.server.com Hello [xx.xx.xx.xx] 250-SIZE 31457280 250-AUTH LOGIN CRAM-MD5 250 OK
11:17:06 [xx.xx.xx.xx][15459629] cmd: AUTH LOGIN
11:17:06 [xx.xx.xx.xx][15459629] rsp: 334 VXNlcm5hbWU6
11:17:07 [xx.xx.xx.xx][15459629] rsp: 334 UGFzc3dvcmQ6
11:17:07 [xx.xx.xx.xx][15459629] rsp: 235 Authentication successful
11:17:07 [xx.xx.xx.xx][15459629] Authenticated as [email protected]
11:17:07 [xx.xx.xx.xx][15459629] cmd: MAIL FROM:
11:17:07 [xx.xx.xx.xx][15459629] rsp: 250 OK <> Sender ok
11:17:07 [xx.xx.xx.xx][15459629] cmd: RCPT TO:[email protected]
11:17:07 [xx.xx.xx.xx][15459629] rsp: 250 OK <[email protected]> Recipient ok
11:17:08 [xx.xx.xx.xx][15459629] cmd: DATA

Das Leerzeichen MAIL FROMwird für Lieferstatusbenachrichtigungen verwendet. Mail-Server sind erforderlich, um dies zu unterstützen ( RFC 1123, Abschnitt 5.2.9 ).

Es wird hauptsächlich zum Abprallen von Nachrichten verwendet, um eine Endlosschleife zu verhindern. Bei MAIL FROMVerwendung mit einer leeren Adresse (dargestellt als <>) kann der empfangende Server keine Bounce-Nachricht generieren, wenn die Nachricht an einen nicht vorhandenen Benutzer gesendet wird.

Ohne dies könnte es möglich sein, dass jemand Sie einfach durch Fälschen einer Nachricht an einen nicht vorhandenen Benutzer in einer anderen Domäne mit einer Absenderadresse eines nicht vorhandenen Benutzers in Ihrer eigenen Domäne zu DoS führt, was zu einer nie endenden Schleife von führt Nachrichten abprallen.

Was würde passieren, wenn Sie Nachrichten mit einem leeren blockieren MAIL FROM:?

• Ihre Benutzer würden keine Bounce-Nachrichten von anderen Domänen erhalten: Sie würden nie erfahren, ob sie beim Senden von E-Mails an einen Benutzer einer anderen Domäne einen Tippfehler gemacht haben.

Die leeren MAIL FROM:Nachrichten, die Sie sehen, stammen wahrscheinlich nicht von einem Spammer.

Stattdessen hat ein Spammer eine Adresse in Ihrer Domain gefälscht und diese als Absenderadresse für eine Nachricht an eine andere Domain verwendet. Angenommen, Sie sind yourdomain.comund meine Domain ist mydomain.net. Der Spammer sendet eine Nachricht an [email protected]und fälscht die Absenderadresse als [email protected]. Da es keine Benutzer johnqin meiner Domain sendet mein Mail - Server eine Bounce - Nachricht ( MAIL FROM:<>) zu dem scheinbaren Absender [email protected]. Das sehen Sie wahrscheinlich.

Das Blockieren leerer MAIL FROMNachrichten kann meiner Meinung nach mehr schaden als nützen. Nach meiner Erfahrung verwenden Spammer selten eine leere MAIL FROM:Adresse, da sie leicht eine echt aussehende Adresse fälschen können. Wenn es sich bei der Nachricht um tatsächlichen Spam handelt, gibt es weitaus bessere Möglichkeiten, sie zu erkennen und zu blockieren, einschließlich RBLs, Bayes'schen Filtern und SpamAssassin.

Und schließlich können Sie zumindest einige der Fälschungen verhindern, yourdomain.comindem Sie geeignete SPF-Einträge für Ihre Domain einrichten.

Update: Nachdem Sie sich Ihr Protokoll genauer angesehen haben, konnte jemand AUTHeinen gültigen Benutzernamen und ein gültiges Kennwort für Ihren Server verwenden. Dies bringt es in eine ganz andere Kategorie von Schwierigkeiten. Alles, worüber ich gesagt habe, MAIL FROM:steht jedoch noch. In 99% der Fälle ist dies das Ergebnis von Bounce-Nachrichten.

Sie können nach Ihrem Mailserver suchen, um MAIL FROM auf authentifizierte Benutzer-E-Mails zu beschränken. Viele Mailsysteme wenden diese Einschränkung an.

Erzwingen Sie daher, dass gehackte Benutzer das Kennwort ändern.