web-dev-qa-db-fra.com

Priorité: en-tête dans l'e-mail

Mon application Web envoie des e-mails assez souvent, et elle envoie 3 types d'e-mails: initiés par l'utilisateur, en réponse à un événement dans le système, et en réponse automatique à un e-mail reçu par l'application.

Je voudrais m'assurer que le troisième type de courrier électronique ne reste pas coincé dans une boucle sans fin d'auto-répondeurs qui se parlent. Actuellement, j'utilise l'en-tête:

Precedence: junk

mais Yahoo! mail traite ces messages comme du spam. Ce n'est évidemment pas l'idéal, car nous aimerions que QUELQU'UN lise notre réponse automatique et prenne une décision à ce sujet, mais pas une réponse en dehors du bureau.

Quelle est la meilleure façon d'envoyer un e-mail sans déclencher de filtres indésirables ou de répondeurs automatiques?

Precedence: junk?

Precedence: bulk?

Precedence: list?

X-Priority: 2?
emailheader
37
Jacob Krall

RFC 2076 décourage l'utilisation de l'en-tête de priorité. comme vous l'avez noté, de nombreux clients filtreront simplement cela (en particulier la priorité: variété indésirable). il peut être préférable d'utiliser un chemin nul pour éviter les guerres de répondeur automatique:

Return-Path: <>

En fin de compte, vous pouvez utiliser la priorité pour essayer de contourner cela, mais cela semble aller à l'encontre de l'esprit de l'en-tête. Je suggérerais simplement d'utiliser l'en-tête return-path pour cela et d'éviter la priorité. dans certains cas, vous devrez peut-être écrire d'une manière ou d'une autre pour supprimer les répondeurs automatiques dans votre application (pour éviter d'entrer dans une guerre de répondeurs), mais je ne me souviens pas d'une situation dans laquelle cela s'est produit en utilisant un chemin de retour approprié. (la plupart des guerres de répondeurs automatiques dont je me souviens avoir été le résultat d'e-mails très mal formés)

Noter la Return-Path en-tête est, en bref, la destination des notifications (rebonds, retard de livraison, etc ...), et est décrit dans RFC 2821 - car il est requis par SMTP. C'est aussi une méthode pour supprimer les mauvais courriers (car théoriquement tout bon courrier définira un chemin de retour approprié).

16
Owen

Il existe un RFC 3834 dédié aux réponses automatisées par e-mail.

En bref, il recommande:

  1. Envoyer des réponses automatiques uniquement à l'adresse contenue dans le Return-Path en-tête d'un message entrant, s'il s'agit d'une adresse e-mail valide. En particulier "<>" (adresse nulle) dans le Return-Path du message signifie que les réponses automatiques ne doivent pas être envoyées pour ce message.

  2. Lors de l'envoi de la réponse automatique, la commande MAIL FROM smtp doit contenir "<>" (adresse nulle). Cela conduirait à Return-Path: <> lorsque le message sera livré.

  3. Utilisez l'en-tête Auto-Submitted avec une valeur autre que "no" pour indiquer explicitement une réponse automatisée.

Une remarque: il ne vaut pas la peine de définir explicitement l'en-tête Return-Path dans le message sortant, car cet en-tête doit être réécrit par l'adresse d'enveloppe (à partir de la commande MAIL FROM smtp) lors de la livraison.

26
user38936

Vous pouvez définir ces en-têtes:

Precedence: bulk
Auto-Submitted: auto-generated

Source: http://www.redmine.org/projects/redmine/repository/revisions/2655/diff

8
guettli

La manière traditionnelle de traiter ceci est d'envoyer l'e-mail avec un expéditeur d'enveloppe nul (traditionnellement écrit comme <>). Cela empêche le répondeur automatique à l'autre extrémité de répondre car il n'y a pas d'expéditeur à qui répondre.

0
jj33