Sender Policy Framework

Autoresponders are those weird tools sending you out of office or vacation messages from strangers you've never before heard of. Those odd challenge-response systems are also auto-responders.

SPF and similarly BATV limit the backscatter to innocent bystanders by these tools to some degree, as far as they follow the rules stated in RFC 3834.

Simplified the rules boil down to behave like a delivery status or message disposition notification. Adding a bit of syntactical sugar in the form of a header field Auto-Submitted:, but that's not essential wrt unsolicited auto-responses, i.e. backscatter.

In other words, auto-responses should behave like bounces. They should use an empty envelope sender address, that's MAIL FROM <> resulting in an empty Return-Path: at the receiver, otherwise broken auto-responders could try to send auto-responses to auto-responses.

And auto-responses should go to the envelope sender address aka Return-Path: of whatever triggered the auto-response. That's where some auto-responders screw up badly, they send their crap to other addresses found in the mail header, to the From: or if given Reply-To:, and it wouldn't surprise me if some even try to send auto-responses to the PRA in a misguided attempt to pervert Sender ID.

Mailing lists are one of many points where auto-responders not following the rules cause harm. As soon as somebody posts an article these broken auto-responsers will try to inform the author that their master is out of office or in some other situation.

On some lists like the IETF general list, the RFC-ignorant list, or the SPF Help list it's possible that authors get five auto-responses as soon as they post for the first time in a period defined by the auto-responder. Of course the list moderators would unsubscribe these users immediately, with a friendly and never come back in the case of the RFC-ignorant list.

But the auto-responses are sent to the posters, so that would require to inform the moderator including to find out who that is, because the standard list-owner address typically doesn't work as expected.

My recipe to address this problem is to report these auto-responses manually as spam via spamcop. Manual reports unlike quick reports allow to add an explanation, and I've written a script to copy the following text to the clipboard:

 Erroneous bounce to the From-address of a list member
 instead of the envelope sender address, for details see
 RFC 3834 http://tools.ietf.org/html/rfc3834#section-4

Before copying this recipe read also the Spamcop FAQ entry, it's a border case.

RFC 3834

Just in case, here's the famous part of section 4:

4.  Where to send automatic responses (and where not to send them)
   In general, automatic responses SHOULD be sent to the Return-Path
   field if generated after delivery.  If the response is generated
   prior to delivery, the response SHOULD be sent to the reverse-path
   from the SMTP MAIL FROM command, or (in a non-SMTP system) to the
   envelope return address which serves as the destination for non-
   delivery reports.
   If the response is to be generated after delivery, and there is no
   Return-Path field in the subject message, there is an implementation
   or configuration error in the SMTP server that delivered the message
   or gatewayed the message outside of SMTP.  A Personal or Group
   responder SHOULD NOT deliver a response to any address other than
   that in the Return-Path field, even if the Return-Path field is
   missing.  It is better to fix the problem with the mail delivery
   system than to rely on heuristics to guess the appropriate
   destination of the response.  Such heuristics have been known to
   cause problems in the past.

RFC 3834 was written by Keith Moore, see also his email submission recommendations.