When we auto-reply, we should take proper measures to avoid loops. The most commonly used method in the wild is through the use of the Precedence header. We should never auto-reply to a message that has a Precedence header with a value of 'list', 'bulk', or 'junk'. The "Precedence: list" header is not a standardised header, and RFC2076/"the draft to update it" have some warning against it. (that draft here : http://www.dsv.su.se/~jpalme/ietf/mail-headers/mail-headers.html) Still most any mailing list includes it (including the IETF mailing-lists), and make it the most robust method for mailing-list loop control. It think it could be better to insert the Precedence header in email that we send automatically in order to avoid non mailing-list related loops, but that might be a more debatable point. rfc 3834 "Recommendations for Automatic Responses to Electronic Mail" has useful indications, even if we can't implement everything it suggests : [...] For instance, if the subject message contained a Precedence header field [I4.RFC2076] with a value of "list" the responder might guess that the traffic had arrived from a mailing list, and would not respond if the response were only intended for personal messages. For similar reasons, a responder MAY ignore any subject message with a List-* field [I5.RFC2369]. [...] 3.1.8. Precedence field A response MAY include a Precedence field [I4.RFC2076] in order to discourage responses from some kinds of responders which predate this specification. [...] Note that RFC 3834 does not discourage it at all, and explicitely allows if not recommend it, which seems a lot more coherent with the actual usage than RFC 2076.
Also, when we should set the Auto-Submitted header, like "Auto-Submitted: auto-replied" according to RFC 3834. And of course avoid auto replying/forwarding of such mails.
I see this behavior as something that should be coded manually by the filter writer. (We can already filter on "Precedence" or any other header in incoming mail messages by using the Customize option in the Create New Filter dialog, and presumably the fix for bug 11034 will include the ability to set any header in the outgoing auto-reply message.) Hard-coding it in Mozilla would give spam-senders the ability to defeat the auto-reply mechanism by putting in a header that will make Mozilla refuse to send an auto-reply. In my view that is the greater danger. The right way to prevent loops is to put in help text encouraging use of the Precedence header as in the Description of this bug, and possibly to bury the auto-reply capability where casual users won't find it. Therefore I oppose this bug.
(In reply to comment #2) > I see this behavior as something that should be coded manually by the filter > writer. We don't want to depend on the user making a manual operation that most people don't know anything about. I'd agree on a hidden option to disable it. > Hard-coding it in Mozilla would give spam-senders the ability to defeat the > auto-reply mechanism by putting in a header that will make Mozilla refuse to > send an auto-reply. You really believe in fighting spam by sending a bounce ? Some abuse service see trying to do that as an abuse itself, because if you fake your ISP bounce, they are the one who will get bounces back for the false spammer adresses. Anyway that would be bug 109930, not 11034. If bug 109930 is solved, it could be through a method that doesn't take into account the Precedence and Auto-Submitted headers. You'd either select the action Reply that respects Precedence/Auto-Submitted, or the action Bounce that doesn't.
See among others at http://www.spamcop.net/fom-serve/cache/329.html a detailed explanation of the contribution of various kinds of "auto-replies" to the spam problem, and how to avoid that contribution by replacing auto-replying by better procedures. Remember that nothing is easier than using a counterfeit "From" address (I could explain you in one minute how to do it with plain-vanilla Thunderbird), and that no one uses that possibility more extensively than spammers.
Magnus, is this solved by bug 904458 ?
No, but bug 904461 would improve it (maybe for most cases even), and perhaps later we could build on it to fix this fully. The problem is that the needed headers would not be easily accessible atm.