Precedence: header in email

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

You can set these headers:

Precedence: bulk
Auto-Submitted: auto-generated

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

Answer 5

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).