Raisons légitimes SMTP "MAIL FROM:" ne correspondra pas à l'en-tête "From:" dans DATA

Question

Y a-t-il jamais une raison légitime pour que le champ SMTP "MAIL FROM:" ne corresponde pas au champ "From:" dans la section DATA d'un message, en plus 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 votre métaphore du 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 pour le destinataire. Il est donc logique que le courrier électronique fonctionne de la même manière. "

Le problème avec cette logique réside ici: "courtoisie envers le destinataire". L'inclusion de l'adresse "De:" dans un e-mail via SMTP n'est pas une courtoisie; elle est requise pour que le destinataire puisse envoyer une réponse.

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

"Mais si vous voulez vraiment garantir From: et MAIL FROM, vous devez appliquer header_checks pour que Return-Path: corresponde à From:"

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

Answer 1

Il existe de nombreuses raisons pour lesquelles les adresses d'en-tête et d'enveloppe 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 qui a envoyé le courrier, de qui il a été envoyé au nom de ou à qui il faut répondre. Les listes de diffusion, comme vous l'avez souligné, en sont un bon exemple.

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

En plus de l'en-tête SMTP, il existe une variété d'en-têtes MIME que divers programmes utilisent pour essayer de faire la distinction entre 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, Sender, Originally-From , Errors-To, etc, etc, chacun avec une sémantique différente. Certains d'entre eux sont compatibles avec les normes, tandis que d'autres ne le sont pas, mais peuvent être utilisés de toute façon. La façon dont divers programmes de messagerie se comportent dans la pratique varie considérablement.

La question de savoir si une manière d'adresser le courrier est recommandée est différente de celle de savoir si elle est "légitime", comme vous le demandez. Si vous envisagez la légitimité ici en termes de politique de gestion du spam potentiel, alors non, je ne pense pas que vous serez en mesure de faire une distinction simple de cette manière.

Réfléchissez à la signature DKIM des e-mails 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, et cela peut avoir des implications pour l'adressage du courrier à partir des en-têtes, car vous ne pouvez authentifier que le courrier lié aux domaines pour lesquels vous avez l'autorité .

-

Prolongé sur demande:

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

Habituellement, un MTA utilise l'adresse "MAIL From" de l'enveloppe SMTP pour envoyer des erreurs. L'informatique peut être remplacée par un en-tête MIME 'Errors-To', qui est une instruction MTA. Tous les MTA ne le respecteront pas, c'est donc un mécanisme inférieur à la définition de l'adresse d'enveloppe SMTP, mais il existe de nombreuses circonstances où il peut être possible de définir des en-têtes MIME dans un message, mais pas l'adresse d'enveloppe SMTP de. Par exemple, un logiciel fonctionnant dans un environnement d'hébergement partagé peut se retrouver dans cette situation.

`` Expéditeur '' est beaucoup plus ambigu en tant qu'instruction pour les agents logiciels, mais indique qui ou quoi a envoyé l'e-mail, ce qui est distinct de l'adresse de l'expéditeur, qui ressemble plus à la personne à qui le courrier a été envoyé au nom de. Par exemple, lorsque vous remplissez un formulaire de courrier électronique en ligne, il serait très approprié que l'e-mail résultant utilise votre courrier dans l'en-tête De, mais possède une adresse d'expéditeur liée à l'organisation qui a configuré le formulaire.

"Originally-From" est utilisé par certains logiciels MUA lors du transfert de courrier, l'adresse du transitaire étant utilisée pour l'en-tête "From". Les autres MUA laisseront l'adresse From seule et utiliseront un en-tête "Resent-From". Que les MUA recevant ces e-mails de divers en-têtes interprètent les en-têtes de manière utile, ou même les affichent, est assez variable. Lorsque vous répondez à un courrier qui vous a été transmis, à qui la réponse doit-elle être envoyée par défaut? Peut-être préférable de définir cet en-tête "Répondre à"?

Le comportement des MUA est variable, mal défini, bien qu'il semble s'améliorer avec le temps. En revanche, la sémantique de l'enveloppe est beaucoup plus définie. Il y a généralement une position forte selon laquelle les MTA ne devraient jamais se préoccuper des en-têtes MIME, mais comme les MTA sont de plus en plus tenus responsables du contenu du courrier (par exemple, voir SPF et les nouvelles normes DMARC), il y a 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 selon laquelle les MTA ne regardent pas le contenu des en-têtes, ce qui explique pourquoi ces mécanismes ont toujours été appliqués de manière incohérente. Les philosophies des auteurs de logiciels varient.

Vous pourriez trouver utile de regarder par-dessus http://tools.ietf.org/html/rfc4021#section-2 , mais n'oubliez pas que les pratiques réelles de la multitude de logiciels de messagerie varient qui ne sont pas nécessairement des normes bénies.

C'est bien d'essayer de trouver une philosophie claire de la façon dont vous pensez que le courrier doit être utilisé, mais ne vous attendez pas à ce que tout le monde fasse les choses comme vous le pensez.

Answer 2

Le traitement automatisé est une grande raison. Vous voulez pouvoir envoyer tous les rebonds/réponses automatiques/erreurs à traiter séparément, sinon ces messages disparaissent, ou sont ignorés, ou une mauvaise sève doit creuser à travers eux. Oui, l'ajout d'un en-tête X pour le traitement est possible, mais la plupart du temps rebondit/etc. n'inclura pas l'e-mail d'origine ou seulement une partie tronquée de celui-ci et vous ne pourrez pas obtenir la source.

Par exemple, dites que quelqu'un s'inscrit sur votre site Web et vous lui envoyez un e-mail pour vous remercier de votre inscription. Votre MAILFROM et From pourrait ressembler à ceci:

MAIL FROM: <[email protected]>
From: Website X <[email protected]>

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

[email protected]

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 désactivé.

Answer 3

Le courrier de: dans la conversation smtp est conçu pour être l'endroit où les rebonds iront. L'en-tête From: dans le corps du message est utilisé pour s'afficher pour le destinataire et comme adresse de réponse si l'en-tête Reply-to: 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 un accusé de réception aura généralement: mail from:<> avec le nom de l'utilisateur dans l'en-tête from :.

Une autre situation est celle où un serveur de messagerie utilise BATV pour rejeter les faux rebonds. Le courrier de: sera sous la forme [email protected].

Answer 4

À moins que je ne lise pas correctement mes en-têtes ou la question, les e-mails de mon BlackBerry sont envoyés depuis le serveur BlackBerry et, fondamentalement, aucun des champs ne correspond. Petit pourcentage d'utilisateurs, je me rends compte. J'ai examiné cela récemment lors de l'évaluation de mon serveur de messagerie. Vous trouverez ci-dessous un e-mail anonyme envoyé depuis mon BlackBerry vers mon compte Gmail:

Delivered-To: [email protected]
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=[e-mail]>
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 <[email protected]>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=[e-mail] 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=[e-mail] designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=[e-mail]
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 <[email protected]>; 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 <[email protected]>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <58727559[e-mail]>
Reply-To: [email protected]
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <[email protected]>
From: [email protected]
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T