La réécriture SRS est-elle absolument nécessaire pour un serveur de messagerie de transfert?


14

J'exploite un serveur de messagerie Postfix pour mon domaine, par exemple mydomain.com. Il agit principalement comme un serveur de messagerie de transfert: les utilisateurs reçoivent une adresse e-mail @ mydomain.com, mais choisissent généralement de transférer leur adresse vers une boîte de réception externe (Gmail, Yahoo, etc.). Il y a quelques milliers d'adresses en cours de transfert, de sorte que le serveur gère un volume assez important de trafic de messagerie.

Dans le passé, le serveur n'utilisait pas la réécriture SRS. Cela signifiait bien sûr que le courrier transféré échouerait aux vérifications SPF, car mon adresse IP n'est pas techniquement autorisée à envoyer des e-mails au nom du domaine de l'expéditeur d'origine. Cependant, d'après ce que je peux voir, cela ne semble pas causer de problèmes importants. Généralement, aucune plainte des utilisateurs tels que Gmail, Yahoo, etc. ne semble assez intelligente pour ignorer les échecs SPF et transmettre les messages de toute façon.

Dans cet esprit, est-il vraiment nécessaire d'activer la réécriture SRS? J'envisage de l'activer, mais ma principale préoccupation est que mon domaine soit mis sur liste noire pour l'envoi de spam lorsque le spam est inévitablement transmis. La réécriture ne donnerait-elle pas l'impression que je suis l'auteur du spam? (Au moins, c'est ce que je comprends de la lecture des meilleures pratiques de Gmail pour le transfert des serveurs de messagerie ).

Certes, je prends déjà certaines des précautions recommandées, comme utiliser SpamAssassin pour ajouter "SPAM" à la ligne d'objet de spam suspecté avant de transférer, ne pas transmettre de spam de confiance élevée (score 15+) et utiliser la liste de blocage de spamhaus, mais ces mesures ne sont pas n'est pas parfait et le spam peut toujours passer sans marque.

Est-ce que l'activation de la réécriture SRS en vaut la peine, si elle augmente le risque d'être incorrectement marqué comme spammeur? Ou serait-il plus sûr de le laisser tel quel et d'ignorer les échecs SPF?


Je sais par expérience que certains FAI au Royaume-Uni rejetteront les e-mails entrants qui prétendent provenir de leurs propres clients, mais qui n'ont pas été envoyés par leurs propres expéditeurs. La même chose peut également devenir vraie pour Gmail, Yahoo et AOL. De telles situations ne peuvent être résolues qu'en réécrivant l'adresse de l'expéditeur.
roaima

Réponses:


9

Il me semble que votre question se résume à " combien de serveurs de messagerie vérifient les enregistrements SPF sur les e-mails entrants? ". Si c'est la plupart d'entre eux, SRS est une exigence absolue pour un serveur de transfert; si ce n'est aucun d'entre eux, vous n'avez pas besoin de SRS.

Malheureusement, je ne peux pas immédiatement mettre la main sur un travail académique à ce sujet. Mais comme je vérifie SPF sur les e-mails entrants, je peux dire avec certitude que certains serveurs de messagerie le vérifient. Tous vos clients qui ont transféré votre serveur vers des comptes sur mon serveur perdront les e-mails envoyés par les expéditeurs qui annoncent un SPF qui se termine (comme ils le devraient tous) -all, sauf si vous utilisez SRS. Je peux donc dire avec certitude que sans SRS, certains des courriels de vos clients ne seront pas livrés .

Je m'excuse auprès de Marc de ne pas pouvoir lire l'allemand, donc je ne peux pas dire si le PDF qu'il cite avance des arguments convaincants, mais je peux répéter que sans SRS, une partie du courrier électronique de vos clients ne sera pas livré. Je ne peux pas dire quelle est cette fraction, mais elle n'est pas nulle - et cela étant donné, je ne pense pas que vous ayez d'autre alternative que d'exécuter SRS.

J'accepte que votre serveur ne s'aidera pas lui-même en transmettant du SPAM, mais d'après mon expérience, la plupart des dommages à la réputation sont causés à son adresse IP, pas au domaine enveloppe-de; cela se fera indépendamment de l'utilisation de SRS.

La réponse plus profonde à votre question est qu'entre SPF et son suivi DMARC (irréfléchi et révolutionnaire sur Internet), il me semble que les services de transfert de courrier ont fait leur temps. J'ai déjà demandé à tous mes utilisateurs, sauf un, d'avoir la livraison finale sur mon serveur, et cet utilisateur devra changer ou quitter en 2016. De nos jours, de nombreux systèmes de messagerie Web permettront l'intégration sur plusieurs boîtes aux lettres en collectant le courrier hors serveur à l'aide de IMAP ou POP, et de nombreux clients de messagerie permettent à plusieurs comptes IMAP ou POP de se présenter comme une seule boîte de réception intégrée, donc le transfert n'est pas la bénédiction d'une lecture centralisée qu'il était auparavant.

En bref, je dirais que vous avez besoin de SRS à court terme et d'un nouveau modèle commercial à plus long terme.


Le fait est que SRS est une solution pour résoudre les problèmes de transfert de SPF. SRS réécrit par exemple utilisateur @ A en A = utilisateur @ B et les enregistrements SPF de B sont alors en charge. Problème: B peut toujours se forger des adresses! Par conséquent, certains ajoutent des hachages de cryptage et des horodatages à l'adresse réécrite. Pour que cela fonctionne à grande échelle, il faut une adoption mondiale qui n'est pas là. Cela ne fonctionne également que si quelque chose est transmis une fois, mais pas plus. Les réponses sont également un problème. Gardez également à l'esprit que SPF est une technique pour protéger votre propre domaine d'abus, rien de plus.
Marc Stürmer

@ MarcStürmer " SRS est une solution pour résoudre les problèmes de transfert de SPF ": oui, c'est exactement ce que c'est. SPF est connu pour rompre le transfert simpliste; si vous ne pensez pas que SRS est un prix à payer, ne faites pas de publicité pour un enregistrement SPF. " Problème: B peut toujours forger des adresses ": pas vers le domaine de A, ou tout autre domaine protégé par un enregistrement SPF décent, ou le courrier sera rejeté sous SPF; mais à part ça, oui, c'est possible, et je ne vois pas cela comme un problème. " SPF est une technique pour protéger votre propre domaine d'abus, rien de plus ": je suis d'accord.
MadHatter

@ MarcStürmer: "Cela ne fonctionne également que si quelque chose est transmis une fois, mais pas plus." est faux. SRS fonctionne parfaitement sur plusieurs serveurs de transfert. Il ne souffre que s'il y a un serveur sans balisage dans la ligne. Mais c'est le même problème qu'avec n'importe quel serveur sans balisage en général, que ce soit un premier ou un saut ultérieur. Dans un monde SPF, vous n'avez pas besoin de SRS, il vous suffit de prendre la responsabilité du courrier transféré et de vous assurer que vous pouvez livrer un éventuel rebond. SRS n'est qu'une technique qui permet cela, Google utilise par exemple quelque chose de différent.
Adrian Zaugg

Le problème est que l'utilisation de SRS rompt la vérification d'alignement DMARC (c'est-à-dire l'expéditeur d'enveloppe! = From:-Header) et obligera Gmail à rejeter les messages si le domaine dans l'en- From:tête a p=rejectdans sa politique DMARC. Si vous réécrivez le From:, le courrier sera vérifié selon les règles de votre propre domaine. Mais une vérification DKIM échouera et l'expéditeur indiqué dans le client de messagerie est mutilé.
mbirth

@mbirth afaik, vous avez raison. Mais je considère personnellement DMARC comme un désastre complet, notamment parce qu'il a rompu unilatéralement les listes de diffusion et (en ma qualité d'administrateur d'une grande liste communautaire) déconseille simplement aux gens d'utiliser un FAI qui publie une p=rejectpolitique. Si SRS casse DMARC, eh bien, c'est juste dur sur DMARC.
MadHatter

9

SRS semble être une bonne idée sur le papier, mais ne fonctionne pas très bien dans la pratique selon les gens du support Heinlein (ils gèrent un service de messagerie de taille moyenne avec plus de 100 000 comptes).

Les détails sont dans leur exposé, bien qu'en allemand, pourquoi: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

La raison principale est que SRS est un petit correctif pour de sérieux problèmes d'implémentation de SPF en réalité, car SPF ne couvre pas très bien certains cas d'utilisation courants de la messagerie électronique. Pour que SRS ait un sens, il doit être déployé sur une large base de serveurs, ce qui ne se produira probablement jamais. Donc, jusqu'à ce qu'il soit déployé sur cette grande base de serveurs, cela n'a pas beaucoup de sens.

Le problème avec les grands fournisseurs de messagerie est qu'ils ont de nos jours une très grande base d'utilisateurs et qu'ils implémentent de plus en plus de techniques (le successeur de DMARC est déjà dans le pipeline), ce qui rend de plus en plus difficile pour une normale configuration du serveur de messagerie pour leur envoyer des e-mails de manière fiable.

Si vous souhaitez que votre courrier soit mieux distribué aux grands fournisseurs de messagerie tels que Gmail, Hotmail, etc., vous devez implémenter au moins DKIM et DMARC, mais également le configurer au mieux en cas de défaillance logicielle et peut-être mettre en œuvre des mécanismes de limitation de débit sur la distribution du courrier. ferait des merveilles pour vous.

Ce problème avec les grands fournisseurs est la raison pour laquelle il existe aujourd'hui des services comme Mailchimp, Mandrill ou Returnpath. Ces fournisseurs paient de l'argent à Google & Co. pour une meilleure qualité de livraison.


1
Le problème ici est SPF et non SRS. Tant que certains FAI utilisent SPF, vous devez implémenter SRS (ou quelque chose de similaire) pour que le transfert fonctionne avec chacun d'eux. Le problème avec la liste grise est différent, vous devez "décompresser" les adresses d'expéditeur marquées SRS pour la liste grise (ainsi que les courriers marqués BATV).
Adrian Zaugg

3

Je suis d'accord avec chaque mot de @MadHatter, MAIS fait important sur Google!

Si vous fournissez un service de transfert vers gmail, il y a de fortes chances que vous fournissiez également un accès SMTP pour que vos utilisateurs gmail puissent envoyer des messages de gmail au nom de l'adresse stockée par vous.

Dans ce cas, gmail sait que vous êtes un transitaire pour cet e-mail et ne marque pas vos transferts comme spam même s'il échoue à la vérification SPF.

Vous pouvez envoyer des courriels à vos clients à partir de bill@microsoft.com. Le message arrivera dans leur boîte de réception sans aucun avertissement! (Microsoft a -all dans l'enregistrement spf)

Vérifié et vérifié. Exemple ci-joint.

ce message est allé dans la boîte de réception.gmail Afficher l'original

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.