Question Les raisons légitimes «SMIL FROM MAIL» de SMTP ne correspondent pas à «De:» en-tête dans DATA


Existe-t-il une raison légitime pour que le champ "MAIL FROM:" de SMTP ne corresponde pas au champ "De:" de la section DATA d'un message, en dehors des listes de diffusion?

De https://stackoverflow.com/questions/1750194/smtp-why-does-email-needs-envelope-and- what-does-the-envelope-mean:

«Mais, pour continuer la métaphore de votre courrier postal, la plupart des lettres professionnelles contiendront les adresses de l'expéditeur et du destinataire imprimées sur la lettre elle-même. Ces adresses ne sont pas nécessaires pour le facteur, mais sont plutôt une courtoisie envers le destinataire. Il est donc logique que le courrier électronique fonctionne de la même manière. "

Le problème de cette logique réside ici: «courtoisie envers le destinataire». Inclure l'adresse «De:» dans un courrier électronique via SMTP n'est pas une courtoisie. il est nécessaire si le destinataire doit pouvoir envoyer une réponse.

De: Comment limiter l'en-tête From pour qu'il corresponde à MAIL FROM dans postfix?:

"Mais si vous voulez vraiment assurer De: et MAIL FROM, vous devez appliquer header_checks pour que Return-Path: corresponde à partir de:"

Quelles sont les implications de faire cela? Les listes de diffusion poseraient évidemment un problème. Existe-t-il d'autres utilisations légitimes des informations d'en-tête «MAIL FROM:» et «De:» différentes?


14
2018-06-24 15:11


origine




Réponses:


Il existe de nombreuses raisons pour lesquelles les adresses d'en-tête et d'enveloppe de peuvent ne pas correspondre. La plupart concernent les processus automatisés d'envoi de courrier, où les problèmes de livraison doivent être signalés à une adresse qui n'est pas représentative de celui qui a envoyé le courrier, du destinataire ou du destinataire du courrier. Les listes de diffusion que vous avez indiquées sont un bon exemple.

La raison principale pour laquelle un message envoyé à partir du client de messagerie d'un utilisateur peut différer des adresses est le courrier transféré. Le contenu de l'e-mail doit alors être raisonnablement fidèle à l'original, mais en cas d'erreur de livraison, il doit être signalé à l'utilisateur qui a envoyé l'e-mail, et non à l'expéditeur d'origine.

Outre l'en-tête SMTP, divers programmes utilisent divers en-têtes pour tenter de distinguer l'expéditeur d'origine et l'expéditeur intermédiaire et / ou l'adresse préférée pour signaler les erreurs à .Eg Reply-To, Expéditeur, Originaire de , Errors-To, etc., etc., chacun avec une sématique différente. Certains d'entre eux prennent en charge les normes, tandis que beaucoup d'autres ne le font pas, mais peuvent être utilisés de toute façon. Le comportement de divers programmes de courrier varie considérablement dans la pratique.

Si une manière de traiter le courrier est souhaitable est une question différente de celle de savoir si elle est "légitime" comme vous le demandez. Si vous envisagez une légitimité en termes de politique de traitement du courrier indésirable potentiel, alors non, je ne pense pas que vous puissiez faire une simple distinction de cette manière.

Réfléchissez bien à la signature de courrier électronique DKIM et à l’authentification SPF des serveurs de messagerie pour les domaines de messagerie. Si vous envoyez beaucoup de courrier, il peut être important de pouvoir authentifier votre courrier de cette manière, ce qui peut avoir des conséquences sur l'adressage du courrier à partir des en-têtes, car vous ne pouvez authentifier que le courrier lié à des domaines pour lesquels vous détenez des droits. .

-

Prolongé sur demande:

Un en-tête MIME "Reply-To" demande à un MUA (agent d'utilisateur de messagerie, généralement le client de messagerie d'une personne) d'envoyer des réponses à une adresse différente, au lieu de l'adresse "De" MIME. Ceci n'est pas utilisé par un MTA (Mail Transport Agent) pour des choses comme des erreurs.

En général, un MTA utilise l'adresse «MAIL De» de l'enveloppe SMTP pour envoyer les erreurs. Le service informatique peut être surchargé avec un en-tête MIME "Errors-To", qui est une instruction MTA. Tous les MTA ne l'accepteront pas. Il est donc moins efficace de définir l'adresse d'enveloppe SMTP, mais il existe de nombreuses circonstances dans lesquelles il est possible de définir des en-têtes MIME dans un message, mais pas l'adresse d'expéditeur SMTP. Par exemple, un logiciel fonctionnant dans un environnement d'hébergement partagé peut se trouver dans cette situation.

"Envoyeur" est beaucoup plus ambigu en tant qu'instruction destinée aux agents logiciels, mais il indique qui ou quoi l'envoi du courrier électronique est différent de l'adresse de l'expéditeur, qui ressemble davantage à la personne à qui le courrier a été envoyé. Par exemple, lorsque vous remplissez un formulaire de courrier électronique en ligne avec votre politique, il serait très approprié que le courrier électronique résultant utilise votre courrier dans l'en-tête De, mais que vous ayez une adresse d'expéditeur liée à l'organisation qui l'a configuré.

"Originally-From" est utilisé par certains logiciels MUA lors du transfert de courrier, l'adresse de transfert étant utilisée pour l'en-tête "De". Les autres MUA laisseront uniquement l'adresse de destination et utiliseront un en-tête "Resent-From". Que les MUA recevant ces différents en-têtes, les e-mails les interprètent utilement, ou même les affichent, est très variable. Lorsque vous répondez à un courrier qui vous a été transmis, à qui la réponse doit-elle être adressée par défaut? Peut-être vaut-il mieux définir cet en-tête "Répondre à"?

Le comportement des MUA est variable, mal défini, même s’il semble s’améliorer avec le temps. En revanche, la sémantique de l’enveloppe est beaucoup plus définie. On a généralement affirmé que les MTA ne devraient jamais s'intéresser aux en-têtes MIME, mais comme ils sont de plus en plus tenus pour responsables du contenu du courrier (voir SPF et les normes DMARC émergentes), il existe une pression pour que la clarté de cette position soit dégradée. Des mécanismes de longue date tels que Errors-To ont également été en conflit avec la notion de MTA ne regardant pas le contenu de l'en-tête, ce qui explique en partie pourquoi ces mécanismes ont toujours été appliqués de manière incohérente. Les philosophies des auteurs de logiciels varient.

Vous trouverez peut-être utile de regarder par-dessus http://tools.ietf.org/html/rfc4021#section-2 , mais rappelez-vous que les pratiques actuelles de la multitude de logiciels de messagerie varient d’une manière qui n’est pas nécessairement une bénédiction.

Essayez de définir une philosophie claire sur la manière dont vous pensez que le courrier devrait être utilisé, mais ne vous attendez pas à ce que tous les autres fassent les choses comme vous le souhaitez.


16
2017-08-14 13:12



Il me reste du temps pour attribuer cette prime et je suis intéressé par d'autres scénarios tels que l'utilisation des en-têtes: `Répondre à, Expéditeur, Originaire de, Erreurs-À` - random65537
Merci pour les ajouts. J'espère bien comprendre ce que sont les comportements attendus du MTA, par rapport à ce qu'ils sont mis en œuvre. En outre, vous pourriez être intéressé par ce q: Je viens de poster sur Sec.StackExchange concernant la liste blanche de courrier électronique (semblable à BATV) security.stackexchange.com/q/41008/396 - random65537
+1, pourquoi seulement 4 votes? - Pacerier


Le traitement automatisé est une grande raison. Vous voulez pouvoir envoyer tous les rebonds / répliques automatiques / erreurs à traiter séparément, sinon ces messages disparaissent ou sont ignorés, ou un fichier SAP médiocre doit les parcourir. Oui, il est possible d'ajouter un en-tête X pour le traitement, mais souvent, les rebonds / etc. n'inclura pas le courrier électronique d'origine ou seulement une partie mutilée de celui-ci et vous ne pourrez pas obtenir la source.

Par exemple, disons qu'une personne s'inscrit sur votre site Web et que vous lui envoyez un courrier électronique lui disant merci de s'être inscrite. Votre MAILFROM et From pourraient ressembler à ceci:

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>

De cette façon, l'utilisateur voit le "ami de" dans le client de messagerie. Mais si l'utilisateur n'existe pas, son MTA enverra le message de renvoi à:

user-signup-123123123@bounces.example.com

et un processus automatisé peut facilement extraire l'ID utilisateur (la partie 123123123) et la partie du système qui a créé le rebond (la partie -signup-) de l'en-tête et facilement supprimer / marquer cet utilisateur comme étant désactivé.


8
2017-08-14 13:54





Le courrier de: dans la conversation smtp est conçu pour être l'endroit où les rebonds iront L'en-tête De: dans le corps du message est utilisé pour s'afficher au destinataire et comme adresse de réponse si l'en-tête Répondre à: n'est pas défini.

Les e-mails qui ne doivent pas générer de rebond doivent définir l'expéditeur vide dans l'enveloppe, par exemple. Par exemple, un accusé de réception aura généralement: mail from:<> avec le nom de l'utilisateur dans le de: en-tête.

Une autre situation est lorsqu'un serveur de messagerie utilise BATV pour rejeter les faux rebonds. Le courrier de: sera sous la forme prvs=tag-value=mailbox@example.com.


7
2017-08-14 07:56



Je pense me souvenir d'avoir vu un en-tête X pour les déclarations et les rapports de non-remise. Savez-vous quand et comment cela est utilisé? - random65537
Les en-têtes X ont été ajoutés à l'origine pour permettre aux MUA et / ou aux MTA de mettre des métadonnées personnalisées. Ils ne sont spécifiés dans aucune norme, bien que certaines deviennent des normes de facto. Vous pensez peut-être au type mime multipart / report défini dans rfc 6522 qui a été défini pour aider le logiciel à classer les messages qui sont renvoyés automatiquement. Ceux-ci seront toujours envoyés avec une enveloppe vide dans courrier de: - Richard Salts


À moins que je ne lise pas correctement les en-têtes ou la question, les e-mails de mon BlackBerry sont envoyés depuis le serveur BlackBerry et aucun des champs ne correspond. Petit pourcentage d'utilisateurs, je me rends compte. Je me suis récemment penché sur la question lors de l’évaluation de mon serveur de messagerie. Vous trouverez ci-dessous un courrier électronique anonymisé envoyé par mon BlackBerry à mon compte Gmail:

Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <recipientusername@gmail.com>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T

1
2017-08-18 20:21



Il y a une excellente raison à cela - Réécriture SPF. Si BlackBerry ne le faisait pas, le nombre d'échecs SPF envoyés par votre appareil serait beaucoup plus élevé. - MikeyB
C'est vrai, mais c'est parce que BlackBerry n'utilise pas mon serveur pour l'envoi. - Paul