[ACCEPTED]-Precedence: header in email-header
There is a RFC 3834 dedicated for automated email 16 responses.
In short, it recommends:
Send auto-responses 15 only to address contained in the
Return-Pathheader 14 of an incoming message, if it is valid email 13 address. Particularly "<>" (null 12 address) in theReturn-Pathof the message means that 11 auto-responses must not be sent for this 10 message.When sending auto-response, MAIL 9 FROM smtp command must contain "<>" (null 8 address). This would lead to Return-Path:<> when 7 message will be delivered.
Use Auto-Submitted header with 6 value other than "no" to explicitly 5 indicate automated response.
One note: it 4 is not worth to explicitly set Return-Path 3 header in outgoing message, as this header 2 must be rewritten by envelop address (from 1 MAIL FROM smtp command) during delivery.
RFC 2076 discourages the use of the precedence header. as 22 you have noted, many clients will just filter 21 that off (especially the precedence: junk 20 variety). it may be better to use a null 19 path to avoid auto responder wars:
Return-Path: <>
Ultimately 18 you could use priority to try to get around 17 this, but this seems like going against 16 the spirit of the header. i'd suggest just 15 using the return-path header for this, and 14 avoiding precedence. in some cases you may 13 have to write in some way to drop auto-responders 12 in your application (to avoid getting into 11 a responder war), but i can't remember a 10 situation in which this happened using an 9 appropriate return-path. (most auto responder 8 wars i recall having to deal with were the 7 result of very badly formed emails)
Note: the 6 Return-Path header is, in short, the destination for 5 notifications (bounces, delay delivery, etc...), and 4 is described in RFC 2821 -- because it's required 3 by SMTP. It's also one method to drop bad 2 mail (as theoretically all good mail will 1 set an appropriate return-path).
You can set these headers:
Precedence: bulk
Auto-Submitted: auto-generated
Source: http://www.redmine.org/projects/redmine/repository/revisions/2655/diff
0
The traditional way of dealing with this 5 is to send the email with a null envelope-sender 4 (traditionally written as <>). This 3 prevents the autoresponder on the other 2 end from responding because there's no sender 1 to respond to.
More Related questions
We use cookies to improve the performance of the site. By staying on our site, you agree to the terms of use of cookies.