Priorité: en-tête de courriel
Mon application web envoie un message assez souvent, et il envoie les 3 types d'e-mails: initiée 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 assurez-vous que le troisième type d'e-mail ne restez pas coincé dans une boucle sans fin des auto-répondeurs à parler les uns aux autres. Actuellement, j'utilise l'en-tête:
Precedence: junk
mais Yahoo! le courrier est le traitement de ces messages comme du spam. Ce n'est évidemment pas idéal, parce que nous aimerions QUELQU'un de lire notre auto-réponse et de prendre une décision sur elle, tout simplement pas un out-of-office de réponse.
Quelle est la meilleure façon d'envoyer un e-mail sans déclencher soit de filtres de pourriels ou de l'auto-répondeurs?
Precedence: junk?
Precedence: bulk?
Precedence: list?
X-Priority: 2?
Vous devez vous connecter pour publier un commentaire.
RFC 2076 décourage l'utilisation de la priorité d'en-tête. comme vous l'avez constaté, de nombreux clients se juste de filtre off (en particulier la priorité: junk variété). il peut être préférable d'utiliser une valeur null chemin pour éviter de répondeur automatique wars:
En fin de compte, vous pourriez utiliser la priorité à essayer de contourner cela, mais cela semble aller à l'encontre de l'esprit de l'en-tête. je vous suggère de simplement en utilisant le chemin de retour de l'en-tête pour cela, et en évitant de priorité. dans certains cas, vous pouvez avoir à écrire d'une certaine façon à déposer des auto-répondeurs dans votre application (pour éviter d'entrer dans un répondeur guerre), mais je ne me souviens pas d'une situation dans laquelle cela s'est produit en utilisant le chemin de retour. (la plupart des auto répondeur wars je me souviens d'avoir à traiter avec, ont été le résultat de très mal formé e-mails)
Remarque: le
Return-Pathen-tête est, en bref, la destination pour les notifications (rebonds, délai de livraison, etc...), et est décrite dans RFC 2821 -- parce que c'est requis par le protocole SMTP. C'est aussi une méthode pour déposer une mauvaise mail (en théorie toutes les bonnes courrier définir un chemin de retour).Il y a un RFC 3834 dédié automatisée des réponses par e-mail.
En bref, il recommande:
Envoyer des réponses automatiques uniquement à l'adresse contenue dans le
Return-Pathen-tête d'un message entrant, si c'est l'adresse de courriel valide. En particulier "<>" (adresse null) dans leReturn-Pathdu message signifie que des réponses automatiques ne doivent pas être envoyés pour ce message.Lors de l'envoi automatique de réponse, smtp MAIL from commande doit contenir "<>" (adresse null). Cela conduirait à la Voie de Retour:<> lorsque le message sera livré.
Utilisation Auto-Soumis - tête avec une valeur autre que "non" pour indiquer explicitement réponse automatique.
Une remarque: il n'est pas la peine de définir explicitement la Voie de Retour de l'en-tête de message sortant, que cet en-tête doit être réécrit par enveloppe (adresse de MESSAGERIE à PARTIR de la commande smtp) lors de la livraison.
Vous pouvez définir ces en-têtes:
Source: http://www.redmine.org/projects/redmine/repository/revisions/2655/diff
La traditionnelle façon de traiter cette question est d'envoyer l'e-mail avec une valeur null à une enveloppe de l'expéditeur (traditionnellement écrit que <>). Cela empêche l'autorépondeur sur l'autre extrémité de répondre car il n'y a pas l'expéditeur d'y répondre.
Comment sur la configuration d'une liste blanche sur votre compte de messagerie?
Je suppose que tout e-mail mots clés peuvent obtenir signalé par un filtre de courrier indésirable.