Precedence: header in email
Asked Answered
B

5

39

My web application sends email fairly often, and it sends 3 kinds of emails: initiated by user, in response to an event in the system, and in automatic response to an email received by the application.

I would like to make sure that the third type of email does not get stuck in an endless loop of auto-responders talking to each other. Currently, I use the header:

Precedence: junk

but Yahoo! mail is treating these messages as spam. This is obviously not ideal, because we would like SOMEBODY to read our auto-response and make a decision on it, just not an out-of-office reply.

What is the best way to send an email without triggering either junk filters or auto-responders?

Precedence: junk?

Precedence: bulk?

Precedence: list?

X-Priority: 2?
Broca answered 30/9, 2008 at 20:1 Comment(0)
A
18

RFC 2076 discourages the use of the precedence header. as you have noted, many clients will just filter that off (especially the precedence: junk variety). it may be better to use a null path to avoid auto responder wars:

Return-Path: <>

Ultimately you could use priority to try to get around this, but this seems like going against the spirit of the header. i'd suggest just using the return-path header for this, and avoiding precedence. in some cases you may have to write in some way to drop auto-responders in your application (to avoid getting into a responder war), but i can't remember a situation in which this happened using an appropriate return-path. (most auto responder wars i recall having to deal with were the result of very badly formed emails)

Note: the Return-Path header is, in short, the destination for notifications (bounces, delay delivery, etc...), and is described in RFC 2821 -- because it's required by SMTP. It's also one method to drop bad mail (as theoretically all good mail will set an appropriate return-path).

Agnomen answered 30/9, 2008 at 20:12 Comment(2)
Can you explain what Return-Path is used for? (I assume it's much different than the Reply-To header)Azygous
in short it's the destination for notifications (bounces, delay delivery, etc...), and is described in RFC 2821. because it's required by SMTP, it's also one method to drop bad mail (as theoretically all good mail will set an appropriate return-path)Agnomen
A
27

There is a RFC 3834 dedicated for automated email responses.

In short, it recommends:

  1. Send auto-responses only to address contained in the Return-Path header of an incoming message, if it is valid email address. Particularly "<>" (null address) in the Return-Path of the message means that auto-responses must not be sent for this message.

  2. When sending auto-response, MAIL FROM smtp command must contain "<>" (null address). This would lead to Return-Path:<> when message will be delivered.

  3. Use Auto-Submitted header with value other than "no" to explicitly indicate automated response.

One note: it is not worth to explicitly set Return-Path header in outgoing message, as this header must be rewritten by envelop address (from MAIL FROM smtp command) during delivery.

Arch answered 19/11, 2008 at 14:3 Comment(3)
I believe #3 above should be "Auto-Submitted", and it can be "no" (human mail), "auto-replied" (bounces, vacation notices) or "auto-generated" (daily status cron jobs, etc)Engineer
By checking headers, do I still need to check subject to detect auto responders?Shluh
can we rely on Auto-Submitted=auto-replied in order to filter bounced messages from normal ones? Do all mail servers/clients respect RFC 3834? at least major ones?Swetlana
A
18

RFC 2076 discourages the use of the precedence header. as you have noted, many clients will just filter that off (especially the precedence: junk variety). it may be better to use a null path to avoid auto responder wars:

Return-Path: <>

Ultimately you could use priority to try to get around this, but this seems like going against the spirit of the header. i'd suggest just using the return-path header for this, and avoiding precedence. in some cases you may have to write in some way to drop auto-responders in your application (to avoid getting into a responder war), but i can't remember a situation in which this happened using an appropriate return-path. (most auto responder wars i recall having to deal with were the result of very badly formed emails)

Note: the Return-Path header is, in short, the destination for notifications (bounces, delay delivery, etc...), and is described in RFC 2821 -- because it's required by SMTP. It's also one method to drop bad mail (as theoretically all good mail will set an appropriate return-path).

Agnomen answered 30/9, 2008 at 20:12 Comment(2)
Can you explain what Return-Path is used for? (I assume it's much different than the Reply-To header)Azygous
in short it's the destination for notifications (bounces, delay delivery, etc...), and is described in RFC 2821. because it's required by SMTP, it's also one method to drop bad mail (as theoretically all good mail will set an appropriate return-path)Agnomen
B
9

You can set these headers:

Precedence: bulk
Auto-Submitted: auto-generated

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

Boohoo answered 18/1, 2012 at 10:43 Comment(2)
RFC 2076 discourages the usage of Precedence.Jeanett
@Jeanett You say the RFC discourages the usage of Precedence. Yes, you are right. I think there are two worlds of truth: The theory and the practice. Related: github.com/jpmckinney/multi_mail/wiki/Detecting-autorespondersBoohoo
B
0

The traditional way of dealing with this is to send the email with a null envelope-sender (traditionally written as <>). This prevents the autoresponder on the other end from responding because there's no sender to respond to.

Baluster answered 30/9, 2008 at 20:8 Comment(0)
K
-5

How about configuring a white list on your email account?

I would assume that any email key words could get flagged by a junk filter.

Kesler answered 30/9, 2008 at 20:6 Comment(1)
I can't go to Yahoo! and tell them to put my application on a white list, if that's what you meant.Broca

© 2022 - 2024 — McMap. All rights reserved.