15

I have a few scripts that automatically send out small email notifications when necessary. I get a small number of auto-response messages (e.g. out-of-office or vacation) back from these. Is there a header I can add to the email that will indicate to (well-behaved) auto-responders that I'm not interested in any response?

See also this related StackOverflow question.

3 Answers 3

13

Adding a "List-Id" header or a "Precedence: list" header should solve the problem for well behaved auto-responders. The behavior comes from the original vacation program for UNIX. Among other things it will not respond to an email that appears to come from a list. You would probably be better off with the List-Id header line than taking chances with the precedence setting but try both.

1
  • 1
    RFC3834: Because Precedence is not a standard header field, and its use and interpretation vary widely in the wild, no particular responder behavior in the presence of Precedence is recommended by this specification.
    – Jasen
    Feb 6, 2020 at 23:04
12

I believe Precedence: Bulk is the canonical setting, but the number of people whose autoresponders obey it is miniscule. Fact is, the vast majority of autoresponders are badly behaved.

2
  • RFC3834 Because Precedence is not a standard header field, and its use and interpretation vary widely in the wild, no particular responder behavior in the presence of Precedence is recommended by this specification.
    – Jasen
    Feb 6, 2020 at 23:03
  • 3
    Yes, that's what I said.
    – womble
    Feb 6, 2020 at 23:05
6

No, there nothing that always works.

#There's standards

sending wuth a null return path (empty envelope sender, SMTP MAIL FROM:<>) should prevent autotoresponders (https://www.rfc-editor.org/rfc/rfc5321#section-4.5.5)

Implementers of automated email processors should be careful to make sure that the various kinds of messages with a null reverse-path are handled correctly. In particular, such systems SHOULD NOT reply to messages with a null reverse-path,

setting an Auto-Submitted header should also work (https://www.rfc-editor.org/rfc/rfc3834#section-2)

Automatic responses SHOULD NOT be issued in response to any message which contains an Auto-Submitted header field

#And then there's Microsoft... section 2.2.3.2.14 in https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/e489ffaf-19ed-4285-96d9-c31c42cab17f (URL subject to expire at Microsoft's whim)[MSOXCMAIL] 2.2.3.2.14

says

#2.2.3.2.14 Suppression of Automatic Replies To set the value of the PidTagAutoResponseSuppress property (section 2.1.3.2.20) to -1, indicating that all automatic replies to the message are to be suppressed, clients SHOULD write an X-Auto-Response-Suppress header with the value "All".

...

MIME readers SHOULD<116> map individual elements of an X-Auto-Response-Suppress header to bits in the value of the PidTagAutoResponseSuppress property according to the table. If both the X-Auto-ResponseSuppress and Precedence headers are present, the PidTagAutoResponseSuppress property value SHOULD be 0xFFFFFFFF but MAY<117> be 0x00000000. If the value of the X-Auto-Response-Suppress header is other than as specified in the table in section 2.1.3.2.20, MIME readers SHOULD<118> ignore the entire header.

Those little notes are most revealing

<116> Section 2.2.3.2.14: Outlook 2010, Outlook 2013, Outlook 2016, and Outlook 2019 do not read the X-Auto-Response-Suppress header.

<117> Section 2.2.3.2.14: Exchange 2003 uses this value for the PidTagAutoResponseSuppress property ([MS-OXOMSG] section 2.2.1.77).

<118> Section 2.2.3.2.14: Exchange 2003, Office Outlook 2003, and Office Outlook 2007 ignore the X-Auto-Response-Suppress and Precedence headers.

so presubamly Exchange Server 2007 or newer want X-Auto-Response-Suppress and Outlook wants Precedence

Note that this is ignoring https://www.rfc-editor.org/rfc/rfc3834#section-2

(Because Precedence is not a standard header field, and its use and interpretation vary widely in the wild, no particular responder behavior in the presence of Precedence is recommended by this specification.)

The best move is probably to do all four, or as many of these as are possible.

4
  • Thanks for this info @Jasen - very helpful. Are there any risks you are aware of with using a null return path, in particular with regard to spam filters? I manage a booking system that issues confirmation emails. These are not bulk messages, but naturally have no use for auto-replies. Avoiding spam filters is a constant battle for us.
    – John Rix
    Feb 26, 2020 at 11:04
  • Yeah, spam filters may block or drop that especially if the domain uses SRS or other VERP on all their outbound. use a real return path, if possible one that you can monitor (so, not hosted on a rate-limited service like gmail)
    – Jasen
    Feb 26, 2020 at 20:06
  • Thanks for the advice! We do use VERP, now you mention it.
    – John Rix
    Feb 28, 2020 at 2:13
  • i mean the destination domain of the emails: The recipeint sever may decide that it looks like a forged bounce and reject it on that basis.
    – Jasen
    Feb 29, 2020 at 22:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .