Notre application Web envoie des e-mails aux utilisateurs lorsque quelqu'un publie un nouveau contenu. L'expéditeur et le destinataire ont choisi de recevoir des e-mails de notre application. Lors de la préparation d'un tel message, nous définissons les en-têtes SMTP suivants:
DE: [email protected] À: [email protected] SENDER: [email protected]
Nous avons choisi d'utiliser l'adresse e-mail de l'auteur dans l'en-tête FROM afin de fournir la meilleure expérience au destinataire; lorsqu'ils voient le message dans leur client de messagerie, l'auteur est clair. Pour éviter l'apparence d'usurpation d'identité, nous avons ajouté l'en-tête SENDER (avec notre propre adresse e-mail d'entreprise) pour indiquer clairement que nous avons envoyé le message au nom de l'auteur. Après avoir lu les RFC 822 et 2822, cela semble être une utilisation prévue de l'en-tête de l'expéditeur.
La plupart des serveurs de messagerie récepteurs semblent bien gérer cela; l'e-mail est remis normalement (en supposant que la boîte aux lettres du destinataire existe, ne dépasse pas le quota, etc.). Cependant, lors de l'envoi d'un message à partir d'une adresse dans un domaine vers une adresse dans le même domaine, certains domaines de réception rejettent les messages avec une réponse comme:
571 IP incorrecte - psmtp (en réponse à la commande RCPT TO)
Je pense que cela signifie que le serveur de réception a seulement vu que l'adresse d'en-tête FROM était dans son propre domaine et que le message provenait d'un serveur qu'il ne considérait pas autorisé à envoyer des messages pour ce domaine. En d'autres termes, le serveur de réception a ignoré l'en-tête SENDER.
Nous avons une solution de contournement en place: la webapp conserve une liste de ces domaines qui semblent ignorer l'en-tête SENDER, et lorsque les en-têtes FROM et TO sont tous les deux dans un tel domaine, elle définit l'en-tête FROM à notre propre adresse e-mail. Mais cette liste nécessite une maintenance.
Existe-t-il une meilleure façon de réaliser l'expérience souhaitée? Nous aimerions être un "bon citoyen" du net, et toutes les parties concernées - expéditeurs et destinataires - souhaitent participer et recevoir ces messages. Une alternative consiste à toujours utiliser l'adresse e-mail de notre entreprise dans l'en-tête FROM et à ajouter le nom / l'adresse de l'auteur au sujet, mais cela semble un peu maladroit.
From: authorplace deFrom: [email protected]?Réponses:
Vous regardez les mauvaises choses. Ce sont les en- têtes de message . Vous devriez regarder l' enveloppe SMTP . (La manière dont l'enveloppe est spécifiée dépend de la manière dont votre application soumet le courrier au système de messagerie. Sur de nombreux systèmes, l'enveloppe est spécifiée par des arguments de ligne de commande au programme utilitaire de soumission du courrier.) Selon exactement quand dans la transaction de protocole il décide d'émettre cette réponse 571, le serveur de relais SMTP n'a peut-être même pas du tout vu les en-têtes de message.
Le texte de réponse indique que l'administrateur de ce serveur de relais SMTP particulier auquel vous parlez a restreint ce que vous pouvez mettre dans l'enveloppe SMTP. Il semble se plaindre de la partie destinataire de l'enveloppe. Mais il peut différer la validation de l'expéditeur de l'enveloppe jusqu'à la spécification du premier destinataire, il peut donc se plaindre de l'expéditeur.
Notez que l'expéditeur de l'enveloppe est l'endroit où les messages d'état de livraison sont envoyés, et vous ne voudrez pas que ceux-ci soient dirigés vers des personnes aléatoires à travers le monde. (Mis à part le fait que beaucoup de gens ne le font pas comme ça, cela n'a aucun sens pour les messages d'état de livraison pour votre courrier à retourner à tout le monde mais vous.) Vous spécifiez comme expéditeur de l' enveloppe.
Soit dit en passant, il est faux d'exiger
MXdes enregistrements de ressources. Un serveur de relais SMTP peut être localisé par des enregistrements de ressourcesAetAAAAen l'absence d'MXenregistrements de ressources. Voir RFC 5321 § 5.1.la source
Je peux me tromper, mais la cause la plus probable de l'erreur ci-dessus, en particulier dans le cas de Postini, est que les domaines où vous êtes rejeté ont une politique SPF stricte. La plupart des serveurs de messagerie avec vérification SPF vérifient uniquement l'en-tête From: ils ne se soucient pas de l'en-tête Sender.
Pour vérifier si c'est le cas, exécutez "dig + short TXT domain.com" où domain.com est ce qui vous donne le message d'erreur. Vous devriez récupérer quelque chose comme:
La partie importante est le -all. Cela signifie que le propriétaire du domaine a déclaré qu'il n'enverra jamais de courrier électronique que des serveurs qui agissent comme ses serveurs de messagerie, tous les autres messages seront rejetés.
Heureusement, si c'est le cas, vous pouvez vérifier activement avant d'envoyer l'e-mail! Demandez à la WebApp d'effectuer une vérification SPF lorsque l'utilisateur saisit son adresse e-mail. Si une politique stricte est en place, ajoutez le domaine à votre liste. Les bibliothèques ne manquent pas pour toutes les langues pouvant effectuer des vérifications SPF.
la source