La réécriture SRS est-elle absolument nécessaire pour un mail de transfert?
Je propose un serveur de messagerie postfix pour mon domaine, dites mydomain.com. Il agit surtout comme un serveur de messagerie de transfert: les utilisateurs reçoivent une adresse email @ mydomain.com, mais choisissent généralement de faire avancer leur adresse à une boîte de réception externe (Gmail, Yahoo, etc.). Quelques milliers d'adresses sont envoyées, le serveur gère donc un volume de trafic de courrier assez important.
Dans le passé, le serveur n'a pas utilisé de réécriture SRS. Cela signifiait bien sûr que le courrier transféré échouerait des chèques SPF, car mon adresse IP n'est pas techniquement autorisée à envoyer un courrier électronique 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 d'utilisateurs comme Gmail, Yahoo, etc. semble être suffisamment intelligente pour ignorer les défaillances du SPF et transmettre les messages de toute façon.
Dans cet esprit, est-il vraiment nécessaire d'activer la réécriture SRS? Je envisage de l'activer, mais ma principale préoccupation est que mon domaine sera sur la liste noire pour avoir envoyé du spam lorsque le spam est inévitablement privilégié. La réécriture ne ferait-elle pas apparaître comme si je suis l'initiateur du spam? (Au moins, c'est ma compréhension de la lecture les meilleures pratiques de Gmail pour transférer les messages de messagerie ).
Certes, je prends déjà certaines des précautions recommandées telles que l'utilisation de Spamassassin pour ajouter du "spam" à la ligne d'objet suspectée avant de transférer, sans renvoi de la confiance élevée (score de 15 ans et plus) spam, et à l'aide de la blocklist SPAMHAUS, mais ces mesures sont disponibles. 'T Perfect et Spam peut toujours glisser sans marquage.
Est-ce que la réécriture SRS en vaut la peine, s'il augmente le risque de marquer mal comme un spammeur? Ou serait-il plus sûr de le laisser tout comme et ignore les échecs du SPF?
Il me semble que ce que votre question se résume à IS " Combien de serveurs de messagerie Vérifiez que les enregistrements SPF sur l'e-mail entrant? ". 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 mes mains sur un travail académique à ce sujet. Mais depuis que je vérifie SPF sur le courrier électronique entrant, je peux dire avec certitude que certains serveurs de messagerie vérifie. N'importe lequel de vos clients qui ont votre serveur vers des comptes sur mon serveur perdront le courrier électronique envoyé des 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 de vos clients ne seront pas livrés.
Je m'excuse de marc que je ne peux pas lire l'allemand, je ne peux donc pas dire si le PDF il cite avance des arguments convaincants, mais je peux réitérer cela sans SRS, une fraction de vos clients Le courrier électronique ne sera pas livré. Je ne peux pas dire ce que cette fraction est, mais ce n'est pas zéro - et cela donné, je ne pense pas avoir une alternative mais pour diriger SRS.
Je conviens que votre serveur ne s'aidera pas lui-même en transférant le spam, mais dans mon expérience, la plupart des dommages reputionnels sont effectués à son adresse IP, et non à l'enveloppe du domaine; Cela sera fait indépendamment de l'utilisation des SRS.
La réponse plus approfondie à votre question est que, entre SPF et son (mal réfléchi et internet), DMARC, il me semble que les services de transfert de courrier ont eu leur journée. J'ai déjà nécessité tout sauf un de mes utilisateurs d'avoir une livraison finale sur mon serveur et qu'un utilisateur devra changer ou partir en 2016. De nos jours, de nombreux systèmes WebMail permettront à intégrer plusieurs boîtes aux lettres en collectant le courrier hors serveur en utilisant IMAP ou POP, et de nombreux clients de messagerie permettent de présenter plusieurs comptes IMAP ou POP à présenter en tant que boîte de réception intégrée unique, le renversement n'est pas le BOON de la lecture centralisée qu'elle était autrefois.
En bref, je dirais que vous avez besoin de SRS à court terme et un nouveau modèle d'entreprise à long terme.
Les SRS semblent être une bonne idée sur le papier, mais ne fonctionnent pas très bien dans la pratique selon les membres du support de Heinlein (ils exécutent un service de messagerie de taille moyenne avec plus de 100 000 comptes.)
Les détails sont dans leur conversation, cependant en allemand, pourquoi: https://www.heinlein-support.de/sites/default/files/spf-dkim-greylisting_froscon_2012.pdf
La principale raison est que SRS est un petit patch pour des problèmes graves de la mise en œuvre du SPF en réalité, car le SPF ne couvre pas très bien certains cas de courriels d'utilisation courants. Pour que SRS ait du sens, même si elle doit être déployée sur une large base de serveurs, ce qui est peu susceptible de se produire. 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, c'est qu'ils ont de nos jours avoir une véritable base d'utilisateurs et qu'ils mettent en œuvre de plus en plus de techniques (le successeur de la DMARC est déjà dans le pipeline), qui rend cela de plus en plus difficile pour une normale Configuration du serveur de messagerie pour envoyer des mails à un type fiable.
Si vous souhaitez que votre courrier soit mieux livré aux grands fournisseurs de messagerie tels que Gmail, Hotmail, et ainsi de suite, vous devez mettre en œuvre au moins DKIM et DMARC, mais également la définir au mieux et peut-être mettre en œuvre certains mécanismes de limitation de taux sur la livraison du courrier travaillerait des merveilles pour vous.
Ce problème avec les grands fournisseurs est la raison pour laquelle il existe des services de nos jours tels que MailChimp, Mandrill ou Retour de retour. Ces fournisseurs paient de l'argent à Google & Co. pour une meilleure qualité de livraison.
Je suis d'accord avec chaque mot de @madhatter, mais je suis important sur Google!
Si vous fournissez un service de transfert à Gmail, vous devez également fournir un accès SMTP afin que vos utilisateurs de Gmail puissent envoyer des mails 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 signale pas vos averses comme spam, même si elle échoue au chèque SPF.
Vous pouvez envoyer vos messages à vos clients à partir de [email protected]. Le message arrivera à leur boîte de réception sans aucun avertissement! (Microsoft a-all dans l'enregistrement SPF)
Vérifié et vérifié. Exemple attaché.
ce message est allé à la boîte de réception . 