Pourquoi une adresse MAIL FROM vide peut-elle envoyer un e-mail?

Nous utilisons le système Smarter Mail. Récemment, nous avons constaté qu'un pirate avait piraté certains comptes d'utilisateurs et envoyé de nombreux spams. Nous avons un pare-feu pour limiter l'expéditeur, mais pour l'e-mail suivant, le pare-feu n'a pas pu le faire en raison de l'adresse FROM vide. Pourquoi une adresse FROM vide est considérée comme OK? En fait, dans notre MTA (surgemail), nous pouvons voir l'expéditeur dans l'en-tête de l'e-mail. Une idée?

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

Le vide MAIL FROMest utilisé pour les notifications d'état de livraison. Les serveurs de messagerie sont nécessaires pour le prendre en charge ( RFC 1123 section 5.2.9 ).

Il est utilisé principalement pour les messages de rebond, pour éviter une boucle sans fin. Lorsqu'il MAIL FROMest utilisé avec une adresse vide (représentée par <>), le serveur de réception sait ne pas générer de message de rebond si le message est envoyé à un utilisateur inexistant.

Sans cela, il pourrait être possible pour quelqu'un de vous DoS simplement en simulant un message à un utilisateur inexistant sur un autre domaine, avec une adresse de retour d'un utilisateur inexistant sur votre propre domaine, résultant en une boucle sans fin de renvoyer des messages.

Que se passerait-il si vous bloquiez les messages avec un vide MAIL FROM:?

• Vos utilisateurs ne recevraient pas de messages de rebond provenant d'autres domaines: ils ne sauraient jamais s'ils ont fait une faute de frappe lors de l'envoi de courrier à un utilisateur d'un autre domaine.

Les MAIL FROM:messages vides que vous voyez ne proviennent probablement pas d'un spammeur.

Au lieu de cela, un spammeur a truqué une adresse sur votre domaine et l'a utilisée comme adresse de retour pour un message vers un autre domaine. Disons que vous l'êtes yourdomain.comet que mon domaine l'est mydomain.net. Le spammeur envoie un message à [email protected], en simulant l'adresse de retour comme [email protected]. Comme il n'y a pas d' utilisateur johnqdans mon domaine, mon serveur de messagerie envoie un message de rebond ( MAIL FROM:<>) à l'expéditeur apparent, [email protected]. C'est probablement ce que vous voyez.

À MAIL FROMmon avis, bloquer les messages vides fera plus de mal que de bien. D'après mon expérience, les spammeurs utilisent rarement un espace vide MAIL FROM:car ils peuvent facilement truquer une adresse réelle. Lorsque le message est un spam réel, il existe de bien meilleures façons de le détecter et de le bloquer, notamment les RBL, les filtres bayésiens et SpamAssassin.

Et enfin, vous pouvez empêcher au moins certaines des contrefaçons yourdomain.comen configurant des enregistrements SPF appropriés pour votre domaine.

Mise à jour: Après avoir regardé de plus près votre journal, quelqu'un a pu AUTHutiliser un nom d'utilisateur et un mot de passe valides pour votre serveur. Cela le place dans une toute autre catégorie de problèmes. Cependant, tout ce que j'ai dit MAIL FROM:demeure. 99% du temps, cela sera le résultat de messages de rebond.

Vous pouvez rechercher l'option de votre serveur de messagerie pour limiter MAIL FROM aux e-mails des utilisateurs authentifiés. De nombreux systèmes de messagerie appliquent cette limitation.

Et donc, forcez les utilisateurs piratés à changer de mot de passe.