Précédence: en-tête dans l'email

Question

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

Je voudrais m'assurer que le troisième type d'email ne soit pas bloqué dans une boucle sans fin d'auto-répondeurs parlant les uns aux autres. Actuellement, j'utilise l'en-tête:

Precedence: junk 

mais Yahoo! Le courrier traite ces messages comme spam. Ce n'est évidemment pas idéal, parce que nous aimerions que SOMEBODY lise notre réponse automatique et prenne une décision à ce sujet, mais pas une réponse d'absence du bureau.

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

Precedence: junk? 

Precedence: bulk? 

Precedence: list? 

X-Priority: 2? 

Answer 1

RFC 2076 décourage l'utilisation de l'en-tête de précédence. Comme vous l'avez noté, de nombreux clients vont simplement filtrer 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: <> 

vous pourriez utiliser la priorité En fin de compte pour essayer de contourner ce problème, mais cela semble aller à l'encontre de l'esprit de l'en-tête. Je suggère simplement d'utiliser l'en-tête du chemin de retour 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 auto-répondeurs dans votre application (pour éviter de déclencher une guerre de répondeur), mais je ne me souviens pas d'une situation où cela se produirait. (la plupart des guerres du répondeur automatique dont je me souviens avoir été le résultat d'e-mails très mal formés)

Note: le Return-Path header est, en clair, la destination des notifications (retours, délais de livraison, etc ...), et est décrit dans RFC 2821 - parce que c'est requis par SMTP. C'est aussi une méthode pour abandonner le mauvais courrier (car théoriquement, tout bon courrier définira un chemin de retour approprié).

Answer 2

Que diriez-vous de configurer une liste blanche sur votre compte de courrier électronique?

Je suppose que tous les mots-clés de courrier électronique pourraient être signalés par un filtre indésirable.

Answer 3

La manière traditionnelle de traiter ceci est d'envoyer l'email avec un expéditeur d'enveloppe nul (traditionnellement écrit comme <>). Cela empêche l'autorépondeur à l'autre bout de répondre parce qu'il n'y a pas d'expéditeur à répondre.

Answer 4

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

En bref, il recommande:

1. Envoyer des réponses automatiques uniquement à l'adresse contenue dans l'en-tête Return-Path d'un message entrant, si elle est l'adresse e-mail valide. Particulièrement "<>" (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 d'une réponse automatique, la commande MAIL FROM smtp doit contenir "<>" (adresse nulle). Cela conduirait à Return-Path: <> quand le message sera livré.

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

Une note: il ne vaut pas d'en-tête définir explicitement Return-Path dans le message sortant, comme cet en-tête doit être réécrite par adresse envelop (de commande MAIL FROM smtp) lors de l'accouchement.

Answer 5

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