Dois-je laisser un e-mail rebondir ou l'envoyer à un trou noir?

J'ai beaucoup de comptes inutilisés (anciens, morts) sur ma machine. Beaucoup d'entre eux reçoivent des milliers d'e-mails par jour, tous des spams.

Si le compte a été utilisé par une personne, je laisse le courriel rebondir pour que toute personne essayant de la contacter sache que quelque chose ne va pas. Cependant, je ne sais pas quoi faire des centaines de comptes qui ont été utilisés à d'autres fins, tels que les comptes jetables que j'utilisais pour les sites Web qui demandaient mon adresse e-mail, ou l'adresse que j'avais l'habitude de lister sur les pages Web .

Option 1:
transférez tous les messages vers ces comptes à /dev/null. L'expéditeur ne reçoit pas de rebond.

Option 2:
laissez le courriel rebondir.

L'avantage d'envoyer l'e-mail à /dev/nullest qu'un spammeur ne peut pas m'utiliser pour générer des messages de rebond (spam de rétrodiffusion) . ie: forgez la ligne "from" pour être quelqu'un qu'ils n'aiment pas, puis utilisez-moi pour envoyer des tonnes de messages de rebond à cette personne.

L'avantage de les faire rebondir, c'est que c'est moins d'entretien pour moi. Je peux simplement supprimer l'élément de mon fichier d'alias et l'e-mail rebondira. De plus, je continue de découvrir de nouveaux pièges à spam et de les ajouter à ma liste de "trous noirs de spam", ce qui est une perte de temps.

Quels sont les avantages et les inconvénients de chaque approche?

Tant que vous renvoyez le courrier en refusant de le recevoir en premier lieu, un spammeur ne peut pas vous utiliser pour agacer quelqu'un d'innocent avec beaucoup de rebonds.

Vous pouvez soit renvoyer une erreur sur la RCPT TOcommande, ce qui se produit généralement en cas d'adresse inexistante, soit renvoyer la RCPT TOcommande avec succès mais renvoyer une erreur à la fin de DATA.

Dans les deux cas, le résultat final sera le même. Votre serveur de messagerie n'a pris aucune responsabilité pour le courrier, et le serveur de messagerie expéditeur est maintenant responsable de le renvoyer. En cas de spam, cela signifie que le spammeur devra générer des rebonds. (Et si c'est ce qu'ils voulaient faire, ils auraient pu le faire sans même essayer de vous livrer le courrier en premier lieu.)

Je ne vois aucun problème dans cette approche.

Je vois cependant un problème dans l'acceptation du courrier. Autrement dit, si votre serveur de messagerie répond avec succès tout au long de la transaction, y compris à la fin de DATA, alors il devient de la responsabilité de votre serveur de messagerie de livrer le courrier. C'est un problème, car vous n'avez pas de moyen de sortir.

• La suppression silencieuse du courrier est un problème, car si un courrier légitime a été envoyé, l'expéditeur ne peut jamais savoir qu'il n'a pas été remis.
• L'envoi de rebonds à partir de votre serveur de messagerie est un problème, car dans ce cas, le spam rebondit sur la boîte aux lettres d'une personne innocente au lieu de revenir au spammeur.

Il peut y avoir des cas où la distribution de l'adresse e-mail en premier lieu était si limitée, que vous savez qu'il ne pourrait pas y avoir de courrier légitime envoyé à l'adresse. Dans ces cas, cela fait peu de différence si vous rejetez la RCPT TOcommande ou si vous acceptez le courrier et le supprimez silencieusement. Mais je ne peux pas trouver une situation dans laquelle la suppression silencieuse du courrier est préférable à son rejet lors de la transaction SMTP.

Je vais faire cette réponse assez générique car la terminologie et les détails de configuration varieront en fonction de votre serveur de messagerie / logiciel de filtrage anti-spam spécifique.

Il existe en fait 3 approches pour un destinataire invalide:

1. Une fois que le destinataire est déterminé comme non valide, renvoyez un message non remis à l'expéditeur.

2. Fermez la connexion SMTP pendant que le message est toujours "en vol". Le serveur SMTP de l'expéditeur sera responsable de la génération du message non livrable.

3. Acceptez le message et supprimez-le en silence. L'expéditeur n'aura aucune idée si le message a été reçu ou non.

Il n'y a plus de raison d'utiliser l'approche n ° 1. Dans le cas d'une attaque de rétrodiffusion, votre serveur ressemblera au spammeur (même s'il s'agit d'une victime innocente), et vous serez celui qui sera mis sur liste noire. Il met également plus de charge sur votre serveur et charge la bande passante, car il doit envoyer le message de rebond.

L'approche n ° 2 est à peu près universellement meilleure que l'approche n ° 1. Cela réduit la possibilité que votre serveur soit mis sur liste noire ou DoSed. Cela n'élimine pas la possibilité d'une rétrodiffusion contre une adresse tierce innocente, mais au moins votre serveur n'est pas celui qui envoie les messages de rebond.

L'approche n ° 3 élimine la possibilité de rétrodiffusion. Il aide également à se prémunir contre une attaque de récolte d'annuaire . Cependant, cela signifie également que si un expéditeur externe saisit mal votre adresse, il ne le saura jamais. Cela peut également être un problème si quelqu'un quitte votre entreprise et qu'un client essaie de contacter l'ancien employé.

J'ai hérité d'un système de messagerie électronique qui utilisait l'approche n ° 3 en raison de préoccupations concernant le DHA. Cela a causé plus de problèmes que cela n'en valait la peine. Nous utilisons maintenant l'approche n ° 2. (Notez qu'il existe d'autres moyens d'atténuer le DHA.)

Si votre serveur de messagerie est correctement configuré, vous devez rejeter les e-mails vers des utilisateurs inconnus lors de la transaction SMTP.

Rejeter le courrier électronique pendant la transaction SMTP

Votre serveur doit être configuré pour rejeter les e-mails vers des utilisateurs inconnus pendant la phase de transaction SMTP. Cela renvoie un code d'erreur 550 SMTP au serveur d'envoi. Étant donné que cela se produit lors de la transaction SMTP, votre serveur n'envoie jamais de rapport de non-remise (aka rebond).

Correctement configuré, cela empêche la rétrodiffusion car le rejet est envoyé directement au serveur d'envoi et les autres en-têtes de courrier électronique sont ignorés.

Avantages

Les avantages de cette approche sont que vous rejetez très rapidement les e-mails dans le processus de transaction SMTP. Cela pourrait signifier:

• Réduction de l'utilisation des ressources sur votre serveur, surtout si tous les e-mails sont envoyés pour traitement après leur acceptation (filtrage antivirus / antivirus).
• Les expéditeurs suppriment souvent ces adresses e-mail de leurs listes pour éviter d'être mis sur liste noire.

Sachez que si vous annulez le routage du courrier électronique, le serveur d'envoi pense que le message a été remis avec succès. Il n'y a aucune raison pour eux de cesser d'envoyer des courriels à ces adresses disparues. Par conséquent, à mesure que ces anciennes adresses s'accumulent, vous avez besoin de plus en plus de ressources de serveur pour traiter l'e-mail.

Pour l'implémenter, il vous suffit de supprimer les utilisateurs du système de messagerie. Si vous avez besoin de sauvegardes des e-mails actuels, c'est bien, vous voulez simplement que votre serveur envoie la 550 user unknownréponse.