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
