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

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?

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.

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.

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.