Pourquoi est-ce une mauvaise idée d'utiliser un e-mail client comme adresse de l'expéditeur


29

J'ai une application qui envoie un e-mail aux utilisateurs une fois qu'ils ont rempli un formulaire. Il utilise une no-reply@customerdomain.comadresse de provenance. Le client souhaite qu'il utilise l'e-mail du formulaire comme adresse d'expéditeur qui pourrait être n'importe quoi. On m'a dit que c'était une mauvaise idée en raison de l'usurpation d'identité / de la liste noire et du spam.

Je me sens vraiment vague sur la raison exacte pour laquelle c'est une mauvaise idée, d'autant plus que je dois essayer de conseiller le client à ce sujet. Quelqu'un peut-il m'expliquer pourquoi c'est une mauvaise idée.

Fait intéressant, le client a utilisé un compte gmail comme adresse de départ comme démo qui fonctionne non seulement correctement mais a permis à l'application de commencer à envoyer des e-mails (il ne le ferait pas auparavant avec un e-mail qui l'était no-reply@customerdomain.com). Euh - ce qui se passe. On me dit une chose et le contraire fonctionne.

Désolé - je sais que c'est basique mais j'ai pu trouver quoi que ce soit sur une recherche Google. Je pense en grande partie parce que j'ai du mal à formuler la question.

MODIFIER

Merci à tous - bonnes réponses. Fait intéressant, le serveur qui envoie l'e-mail et la boîte aux lettres qu'il va se trouver derrière le même pare-feu, de sorte que le client se dit indifférent au spam. Tant pis.


"Il est intéressant de noter que le serveur qui envoie l'e-mail et la boîte aux lettres qui s'y trouve se trouvent tous deux derrière le même pare-feu, de sorte que le client se dit indifférent au spam." C'est bien tant que l'application se trouve également derrière le même pare-feu et n'est pas accessible par le reste d'Internet. Espérons que cette boîte aux lettres à l'intérieur du pare-feu ne soit pas non plus disponible sur Internet - cela ressemble à un relais ouvert!
afrazier

Je suis d'accord avec les autres réponses. En tant qu'utilisateur (pas administrateur d'un site Web), je serais perplexe, inquiet et irrité si je recevais un e-mail de ma part alors que je ne l'avais pas envoyé. Dans le passé, j'ai envoyé de tels e-mails à du spam sans les lire et je continuerai probablement de le faire.
Paddy Landau

Réponses:


46

C'est une mauvaise pratique pour plusieurs raisons:

  • Vous n'êtes PAS autorisé à envoyer un e-mail à partir d'un domaine que vous ne possédez pas. En tant que tel, il pourrait être conçu comme une tentative d'usurpation d'identité.
  • C'est une pratique assez courante utilisée par les spammeurs et, en tant que telle, est fréquemment marquée par des filtres anti-spam.
  • Il est assez courant que des domaines bien entretenus utilisent SPF ou DKIM pour protéger leur réputation et aider d'autres systèmes à identifier l'emprunt d'identité et le spam. De toute évidence, vous ne pourrez pas ajouter l'en-tête de courrier DKIM ou ajouter votre serveur SMTP dans l'enregistrement DNS SPF du domaine et votre courrier sera donc (à juste titre) considéré comme falsifié et rejeté.

La bonne pratique consiste à utiliser votre domaine local comme expéditeur, en utilisant éventuellement une adresse non existante comme nom d'utilisateur.


2
Très bonne réponse. Copie sans vergogne une partie de votre texte pour l'e-mail du client. Merci
Crab Bucket

3
Est-ce que l'utilisation d'une Sender:adresse ne contournerait pas ces problèmes? C'est ce que fait Gmail lorsqu'il est configuré pour envoyer des e-mails à partir d'un autre compte.
TRiG

3
Pourquoi est-ce interdit? Avez-vous une référence à un RFC ou au droit international?
Nils

3
@Nils En voici un. RFC 1855 (Netiquette). "Les contrefaçons et l'usurpation d'identité ne sont pas des comportements approuvés." Bien que cela se trouve dans une section sur les listes de diffusion et les actualités.
Kaz

3
@Kaz voir RFC 2822 de BlueRaja - c'est la bonne référence. Il est autorisé si vous définissez le SENDER sur le véritable domaine d'origine.
Nils

48

En fait, vous êtes autorisé à définir l' Fromadresse sur l'e-mail de votre client, tant que vous définissez correctement le Senderchamp sur votre propre adresse. C'est ce que Paypal ne sert à faire!

DE: customer@yourCustomer.com
À: recipient@recipient.com
SENDER: you@yourCompany.com

La plupart des clients de messagerie afficheront ceci comme "De vous@votreentreprise.com au nom de client@votreCustomer.com" . Il ne devrait y avoir aucun problème avec SPF ou DKIM sur le domaine du client.


Vous devez également probablement définir l'en- Reply-totête à l'adresse de votre client, afin que les réponses soient envoyées à l'adresse du client plutôt qu'à la vôtre.


+1 pour avoir mentionné Reply-to
Bobson

3
@Nils: RFC 2822 §3.6.2 "Champs d'expéditeur" "Le champ" De: "spécifie le ou les auteurs du message, c'est-à-dire la ou les boîtes aux lettres de la ou des personne (s) ou système (s) responsable (s) pour la rédaction du message. Le champ "Expéditeur:" spécifie la boîte aux lettres de l'agent responsable de la transmission effective du message. "
BlueRaja

1
(suite) Donc, notez que si l'utilisateur n'a pas réellement écrit le message (OP n'est pas clair sur ce point) , cela ne sera pas techniquement conforme à la RFC et Reply-Todevrait seulement être utilisé. Mais même dans ce cas, Paypal et d'autres grandes entreprises le font de toute façon, il est donc très peu probable de déclencher des filtres anti-spam. Que ce soit "une violation de la confiance de l'utilisateur" dépend du message / de l'application réelle (par exemple, je ne pense pas que Paypal abuse de ma confiance lorsqu'il envoie un message "BlueRaja vous a envoyé un paiement!" En mon nom)
BlueRaja

1
@Nils: Oups, apparemment, cela devrait être RFC 6854 , qui est une mise à jour de RFC 5322 , qui est à son tour la version mise à jour de RFC 2822. Le passage pertinent n'a cependant pas changé.
BlueRaja

2
PayPal ne fait plus cela, précisément parce que c'était une mauvaise pratique. Leurs e-mails actuels proviennent de member@paypal.coml'adresse e-mail de l'utilisateur dans l'en- Reply-Totête.
Michael Hampton

12

TL; DR:

C'est une mauvaise pratique d'utiliser l'adresse e-mail du formulaire. Utilisez plutôt une adresse e-mail spécifiquement utilisée pour cette liste de diffusion.

Version longue:

Tout d'abord, deux adresses e-mail sont utilisées. L'un est l'expéditeur de l'enveloppe, l'autre est celui indiqué sur la From:ligne dans l'e-mail.

L'expéditeur de l'enveloppe est celui utilisé par les serveurs de messagerie pour émettre des avis de non-livraison. Si vous exécutez une liste de diffusion, cette adresse sera généralement vers un script qui peut effacer les adresses non fonctionnelles de la liste de diffusion.

L' From:adresse est celle qui sera utilisée lorsque le destinataire du mail cliquera sur Répondre. Dans ce cas, il doit pointer vers quelqu'un qui peut réellement répondre à toute question avec laquelle le destinataire peut répondre (ou au moins transmettre à quelqu'un qui le peut).

Si vous utilisez la propre adresse e-mail du destinataire comme expéditeur de l'enveloppe, vous pouvez vous attendre à ce que certains / plusieurs serveurs de messagerie rejettent le courrier ou le marquent comme étant probablement du spam - car les gens ne s'envoient pas souvent de courrier à partir de leur propre adresse via un serveur extérieur.

Si vous utilisez l'adresse e-mail du destinataire en tant From:qu'expéditeur, l'utilisateur ne pourra pas répondre aux messages s'il en a besoin. Mettre un lien quelque part dans le corps du message électronique ne suffit pas; les gens utiliseront toujours le bouton Répondre dans leur client de messagerie et seront contrariés quand cela ne fonctionnera pas.


Merci pour cela, en particulier le point sur l'utilisateur répondant à lui-même. J'aimerais pouvoir donner deux réponses
Crab Bucket

3
Ce n'est pas tout à fait vrai lorsque l'utilisateur clique sur Répondre ... l'en-tête Reply-to (s'il existe) sera utilisé pour cela
JoelFan

@JoelFan Bon point sur l'en-tête Reply-To.
Jenny D dit Réintégrer Monica

8

Vous avez ici d'excellentes réponses sur les problèmes techniques. En termes de vente à votre client, il peut être utile de reformuler légèrement la question. Le client vous demande probablement une variante de "ça va marcher", à laquelle la réponse est "oui, vous pouvez envoyer des e-mails comme ça".

Une meilleure question à considérer est "est-ce qu'il" arrivera ", nos clients le verront-ils s'il est envoyé de cette façon". La réponse avec la plupart des filtres anti-spam modernes est "non, probablement pas".


4

Il y a deux problèmes auxquels je peux penser, le plus gros problème est que vous enverrez des e-mails qui pourraient très bien ne pas être livrés, et évidemment l'adresse de retour le sera également, ce qui signifiera beaucoup d'e-mails assis et en attente de temporisation . Le plus petit problème pourrait être que certains de ces e-mails se retrouvent dans le spam, car les serveurs recherchent des e-mails de certains domaines provenant de certaines machines (selon les règles DKIM).

Je créerais l' no-reply@customerdomain.comadresse et déciderais quoi faire de l'e-mail plus tard.


2

Usurper l'adresse de l'utilisateur en tant que From: est une mauvaise idée. C'est un bon moyen de s'assurer que le courrier n'atteint jamais l'utilisateur, car les filtres anti-spam peuvent le considérer comme une contrefaçon (ce qu'il est de facto !)

Il est tout à fait raisonnable et courant que le serveur SMTP pour "thisdomain" rejette une requête "MAIL From: user @ thisdomain" qui provient d'une connexion TCP en dehors de "thisdomain". (Le fait d'autoriser une telle demande de la part des hôtes locaux permet à l'utilisateur du réseau "thisdomain" de s'envoyer des courriers électroniques.)

En fait, noreply@customerdomain.comc'est aussi une mauvaise idée:

Voici un extrait de configuration de mon serveur SMTP (logiciel Exim), qui le configure pour renvoyer les messages des noreplyexpéditeurs:

deny
  message = Sorry, we do not accept SMTP traffic from "noreply" senders. \
            We believe that it is less than polite to send messages from \
            nonexistent e-mail addresses \
            which cannot be replied to! E-mail is a "two-way street". \
            If you want us to accept \
            your mail, then please accept replies.
  senders = ^noreply@.*

Les e-mails ne doivent être envoyés que par de véritables expéditeurs qui peuvent accepter des réponses.

Pourquoi devrais-je écouter tout ce que vous dites si vos oreilles sont bouchées contre tout ce que je dis?

Certaines personnes répondront quand même à ces e-mails et ils devraient être acheminés vers le compte de support client approprié.


Merci d'avoir répondu. Très intéressant sur la non réponse. Si le courrier électronique n'existait pas vraiment et que c'était juste quand dans une boîte aux lettres qui était périodiquement vidée, serait-ce mieux? Le courrier n'a pas de sens pour moi en tant qu'utilisateur car quand je les vois, je sais que personne n'écoute. Mais quand un e-mail ne veut pas de réponse, c'est au mieux du marketing direct et au pire du spam. Je pense que je me suis parlé de la non-réponse
Crab Bucket

Vieux fil mais ... Je ne peux pas m'empêcher de penser: bloquer les e-mails des expéditeurs nommés "noreply" semble inutile au mieux. Quiconque souhaite envoyer des e-mails abusifs utilise simplement un autre e-mail d'expéditeur inexistant. Si l'e-mail en question EST vraiment "en lecture seule", qu'est-ce qui pourrait être faux de rendre cela aussi évident que possible? "Voici les prévisions météo que vous avez commandées: il fera beau demain. Ne répondez pas à cet e-mail, nous en envoyons six millions chaque jour et nous ne pouvons pas traiter les différents types de réponses qu'ils génèrent inévitablement."
Culme

-1

Le client peut ne pas être préoccupé par le spam, mais le problème majeur ici est qu'il est éthiquement mauvais d'utiliser le domaine du client, comme cité par toutes les autres réponses ici.


Ce n'est pas vraiment une question éthique. Vous êtes le seul à mentionner l'éthique plutôt que des problèmes réalistes.
ceejayoz
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.