SMTP permet plusieurs adresses FROM dans le RFC. Cela a-t-il déjà été utile, pourquoi cela existe-t-il?


27

SMTP permet plusieurs adresses FROM sur le corps (pas l'enveloppe) selon les RFC.

Cette fonctionnalité a-t-elle déjà été utilisée à des fins légitimes?

Est-il sûr de supprimer les messages qui ont plusieurs adresses FROM?


Pourriez-vous citer le rfc pertinent?
AnFi

@ AndrzejA.Filip D'après ce que je me souviens, dans la série x822, il n'a jamais été explicitement autorisé ou refusé. Des révisions ultérieures l'ont mentionné, mais je vais devoir scanner chacune d'elles pour la rechercher. Notez que je parle des en-têtes, pas de l'enveloppe
goodguys_activate

FWIW, Gmail n'accepte pas les messages avec plusieurs adresses dans de, ils répondront par un "550 5.7.1 Les messages avec plusieurs adresses dans De: l'en-tête ne sont pas acceptés." Donc, même si cela peut être "autorisé" par le RFC, je pense que nous pouvons dire en toute sécurité qu'il n'est plus autorisé dans le monde réel. Et Office365 acceptera le message, mais n'affichera que la première adresse e-mail et ne répondra qu'à la première (traitée comme s'il n'y en avait qu'une).
WaldenL

Réponses:


31

La RFC 822 donne en fait un exemple de cette utilisation. Il exigeait (section 4.4) que l'en-tête Sender: soit présent lors de son utilisation.

     A.2.7.  Agent for member of a committee

             George's secretary sends out a message which was authored
        jointly by all the members of a committee.  Note that the name
        of the committee cannot be specified, since <group> names  are
        not permitted in the From field.

            From:   Jones@Host,
                    Smith@Other-Host,
                    Doe@Somewhere-Else
            Sender: Secy@SHost

La RFC 2822 , qui la rendait obsolète, a continué à autoriser explicitement cette construction particulière (section 3.6.2).

from            =       "From:" mailbox-list CRLF

mailbox-list    =       (mailbox *("," mailbox)) / obs-mbox-list

Dans la norme actuelle , RFC 5322 , cela reste inchangé et plusieurs adresses sont toujours explicitement autorisées (section 3.6.2).

   The from field consists of the field name "From" and a comma-
   separated list of one or more mailbox specifications.  If the from
   field contains more than one mailbox specification in the mailbox-
   list, then the sender field, containing the field name "Sender" and a
   single mailbox specification, MUST appear in the message.

Cela vous a-t-il été utile? Oui, et c'est toujours le cas, pour exactement le genre de scénario montré dans l'exemple ancien. Les messages avec plusieurs auteurs sont censés tous être répertoriés dans l'en-tête De:, avec l'expéditeur: défini sur la personne qui a réellement appuyé sur Envoyer dans leur programme de messagerie.

   The originator fields indicate the mailbox(es) of the source of the
   message.  The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message.  For example, if a secretary were to send a message for
   another person, the mailbox of the secretary would appear in the
   "Sender:" field and the mailbox of the actual author would appear in
   the "From:" field.  If the originator of the message can be indicated
   by a single mailbox and the author and transmitter are identical, the
   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
   appear.

Dans la pratique sur l'Internet public, les messages dans lesquels cela est fait sont rares, bien qu'ils se produisent en particulier dans les environnements d'entreprise et académiques où il est beaucoup plus courant qu'une personne envoie un e-mail au nom d'une autre ou d'un groupe.

Je n'ai jamais vu de spam qui fasse cela (et j'ai passé tous mes autres contrôles). Je considère généralement qu'il n'est pas sûr de jeter ou d'augmenter le score de spam d'un tel message.


J'ai reçu du spam qui utilise cette astuce pour essayer de masquer l'adresse réelle. Par exemple, j'ai reçu du courrier d' yahoo.comFromavait quelque chose comme user@domain.com, some fillter text <realaccount@yahoo.com>. Je suppose que Yahoo a permis à l'utilisateur de saisir user@domain.com, some fillter textson "vrai" nom.
Mikko Rantalainen

5

Je n'ai pas vu plusieurs adresses dans le champ De utilisées à des fins légitimes. Les quelques cas que j'ai vus concernaient du spam et comportaient plusieurs copies de la même adresse.

Je ne connais aucun logiciel de composition de messages qui prend en charge les listes dans ce contexte. Les cas que j'estime appropriés pourraient être relativement peu nombreux et, d'après mon expérience, ils sont traités d'une autre manière.

J'ai ajouté une règle de spam à mon système qui ajoute un score élevé aux en-têtes From avec plusieurs adresses. Pour être conforme, il ne serait pas correct de refuser du courrier sur cette seule base. S'ils réussissent d'autres vérifications de spam, vous pouvez mettre les messages en quarantaine tout en évaluant si vous en avez besoin ou si vous souhaitez accepter ces messages.

EDIT: J'ai examiné la réponse bien documentée de Michael Hampton. Il semble que si l'en-tête From contient une liste, un en-tête Sender valide est requis. Je crois qu'un tel filtre aurait attrapé le spam qui a traversé une adresse de transfert. Une liste dans l'en-tête De sans en-tête Expéditeur serait en violation de l'objectif prévu d'autoriser la liste.

J'ai effectué des tests préliminaires sur trois outils de composition de courrier courants; Microsoft Outlook, Thunderbird et GMail. Aucun de ceux-ci ne semble prendre en charge les listes dans le champ De. Seul Outlook semble prendre en charge l'envoi d'e-mails au nom d'un autre utilisateur.


4
Thunderbird fait actuellement sur la version 45.2
M Conrad
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.