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

J'ai une application qui envoie un e-mail aux utilisateurs une fois qu'ils ont rempli un formulaire. Il utilise une [email protected]adresse 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 [email protected]). 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.

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.

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: [email protected]
À: [email protected]
SENDER: [email protected]

La plupart des clients de messagerie afficheront ceci comme "De [email protected] au nom de [email protected]" . 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.

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.

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".

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' [email protected]adresse et déciderais quoi faire de l'e-mail plus tard.

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, [email protected]c'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é.

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.