Perhaps the wiki should also reference the sieve vacation draft as well as RFC3834 (which is also referenced by the vacation draft), and state how it does or does not conform to it.
Good idea...
- The envelope sender and envelope recipient are the same
Where does that rule come from, I wonder? I don't think that is reasonable, as it would often prevent one from testing one's own vacation responder, and I don't know what it would gain anyway.
Maybe the idea was to prevent an endless loop - but that shouldn't be an issue since only one response per sender per [x] day[s] is allowed...
- The envelope sender and envelope recipient are the same
- The envelope recipient is not found in the message To:, Cc: or Bcc: fields.
add:
- There is a "Sender:" header containing one of the tokens listed above.
Hmm, I dunno about that.
Wouldn't this just be because sender headers are easily forged?
- There is a List-Id or List-Post header
The vacation draft is more expansive than that:
Implementations SHOULD NOT respond to any message that contains a "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List- Unsubscribe", "List-Post", "List-Owner" or "List-Archive" [RFC2369] header field.
Excellent... these should all definitely be considered for inclusion in the tests...
- There is no header suggesting that this is possible spam
Maybe.. that seems like a can'o'worms.
I agree - if it gets past your spam filter/gateway, it should be considered ham by the vacation responder... unless your system is using tagging, in which case, if a message is actually tagged as spam, it should not be responded to...
Some interesting things I found while reading the draft...
1 (add this to the list):
"Automatic responses SHOULD NOT be issued in response to any message which contains an Auto-Submitted header field (see below), where that field has any value other than "no".
2:
Personal and Group responses that are intended to notify the sender of a message of the recipient's inability to read or reply to the message (e.g., "away from my mail" or "too busy" notifications) SHOULD NOT issue the same response to the same sender more than once within a period of several days, even though that sender may have sent multiple messages. A 7-day period is RECOMMENDED as a default."
My comment: 7 days!? I thought 1 day was reasonable...
3:
"Responders are encouraged to check the destination address for validity before generating the response, to avoid generating responses that cannot be delivered or are unlikely to be useful."
So, the auto-responder *itself* should perform 'recipient validation' (I'm assuming through the designated smtp server) before actually generating the response and sending it?
4:
"3.1.7. Auto-Submitted field
The Auto-Submitted field, with a value of "auto-replied", SHOULD be
included in the message header of any automatic response. See
section 5."5:
"3.1.5. Subject field
The Subject field SHOULD contain a brief indication that the message is an automatic response, followed by contents of the Subject field (or a portion thereof) from the subject message. The prefix "Auto:" MAY be used as such an indication. If used, this prefix SHOULD be followed by an ASCII SPACE character (0x20)."
and
"However, it is still necessary to ensure that no line in the resulting Subject field that contains an encoded-word is greater than 76 ASCII characters in length (this refers to the encoded form, not the number of characters..."
and
"Also, if the responder truncates the Subject from the subject message it is necessary to avoid truncating Subject text in the middle of an encoded-word."
So, something like:
Subject: Out of office - (Re: original subject) (making sure it is less than 76 ASCII characters, and no truncation in the middle of an encoded-word)
The only one I've ever used (postfix-admin's) I've used don't include *any* of the original subject - does dovecot's?
6: (should be considered for inclusion):
"5. The Auto-Submitted header field" (it should add one)
Many thanks for your input...
--
Best regards,
Charles