[Dovecot] Vacation message functionality
Hi,
Since I will soon be attempting to get this working on one of my client's systems, I posed a question on the postfix list - since they mostly dislike vacation messages - but *ardent haters* of badly configured vacation message systems - as to the quality of the dovecot vacation message function. The only response I got did seem to have a few very good suggestions for additional conditions to test for, so I'm posting the response here to see if they can be incorporated (I'm not a coder or I'd attempt it myself).
The original text (prefixed by double quote characters) in the following exchange is what I copied/pasted from the wiki, and the reply (prefixed by one quote character) is the suggested change/enhancement (this reply is from a trusted source on the postfix list):
Vacation auto-reply
The vacation replies are sent to the envelope sender. Currently this is taken from the Return-Path: header in the message.
comment: or from the command line if this is supported.
also, if the envelope sender is not available, no reply should be sent.
List of autoreplied senders is stored in .dovecot.lda-dupes file in user's home directory. When you're testing the vacation feature, it's >> easy to forget that the reply is sent only once in the number of configured days. If you've problems getting the vacation reply, try deleting this file. If that didn't help, make sure the problem isn't related to sending mails in general by trying the "reject" Sieve command.
if you support extensions, you can test using a unique sender each time: foo+12345@domain.example.
The automatic replies aren't sent if any of the following is true:
<snip>
o begins with "owner-" (case-sensitive)
replace with: o starts with "${token}-" (not case sensitive), where token is one of: owner, request, bounces
It is safer to send nothing than send a risky one.
o contains the string "-request" anywhere within it (case-sensitive)
replace with: o contains "-${token}@" (not case sensitive), where token is one of: owner, request, bounces
- 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.
- There is a List-Id or List-Post header
- There is no header suggesting that this is possible spam
Unlike delivery, safety here is to not send a reply if the message may be spam. so you don't rely on recipient preferences, and you don't fear false positives too much (the guy who receives your auto-rep may have a better filter, and besides annoying him, would find you stupid to miss an obvious spam ;-p)
The envelope sender is taken from a Return-Path: header in the message. The envelope recipient is taken from the recipient user (-d parameter with virtual user setup). A bare username without a domain gets canonicalised by the libsieve code to "<username>@unspecified-domain", which means it is highly unlikely to pass the last two tests in the list above.
note: the envelope recipient can also be retrieved in the Delivered-To header if this is available ('D' flag).
Comments appreciated...
--
Best regards,
Charles
"CM" == Charles Marcus <CMarcus@Media-Brokers.com> writes:
CM> The only response I got did seem to have a few very good
CM> suggestions for additional conditions to test for, so I'm posting
CM> the response here to see if they can be incorporated (I'm not a
CM> coder or I'd attempt it myself).These certainly do look like reasonable suggestions. I am going to be looking at exactly the vacation handling code over the next few days and already suspect that I need to make some changes. I'll certainly look at adding the suggested tests but see below.
CM> The original text (prefixed by double quote characters) in the
CM> following exchange is what I copied/pasted from the wiki, [...]Assuming the wiki text has not changed significantly it is I believe a rendering, in english, of the tests performed all the way down in the CMU Cyrus sieve code. So strictly speaking this is not a Dovecot specific issue other than that <http://hg.dovecot.org/dovecot-sieve-1.0/> contains a copy of the sieve code from Cyrus imapd.
These certainly do look like reasonable suggestions. I am going to be looking at exactly the vacation handling code over the next few days and already suspect that I need to make some changes. I'll certainly look at adding the suggested tests but see below.
CM> The original text (prefixed by double quote characters) in the CM> following exchange is what I copied/pasted from the wiki, [...]Assuming the wiki text has not changed significantly it is I believe a rendering, in english, of the tests performed all the way down in the CMU Cyrus sieve code. So strictly speaking this is not a Dovecot specific issue other than that <http://hg.dovecot.org/dovecot-sieve-1.0/> contains a copy of the sieve code from Cyrus imapd.
Ok... I think... I'm not sure exactly what you are saying... ;)
But as long as the vacation script that dovecot uses works better as a result... :)
--
Best regards,
Charles
On Wed, Jul 25, 2007 at 12:32:44PM -0400, Charles Marcus wrote:
Hi,
I don't know much about the sieve implementation used by dovecot LDA, so these are just generic remarks.
Since I will soon be attempting to get this working on one of my client's systems, I posed a question on the postfix list - since they mostly dislike vacation messages - but *ardent haters* of badly configured vacation message systems - as to the quality of the dovecot vacation message function. The only response I got did seem to have a few very good suggestions for additional conditions to test for, so I'm posting the response here to see if they can be incorporated (I'm not a coder or I'd attempt it myself).
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.
also, if the envelope sender is not available, no reply should be sent.
as specified by the vacation draft as well as RFC3834
The automatic replies aren't sent if any of the following is true:
<snip>
o begins with "owner-" (case-sensitive)replace with: o starts with "${token}-" (not case sensitive), where token is one of: owner, request, bounces
Yeah, the case-sensitive condition is odd, I would think it would be case-insensitive. RFC3834 uses "owner-" as an example of an address pattern "commonly used as return addresses by responders" and implies that there are probably other prefixes that an implementation should check for; "bounces-" seems like a good addition (I'll probably add it to my own), and "request-" probably is too.
o contains the string "-request" anywhere within it (case-sensitive)replace with: o contains "-${token}@" (not case sensitive), where token is one of: owner, request, bounces
I think the current "anywhere within it" and "case-sensitive" are both problematic. I dunno if -owner and -bounces are good localpart tails to test for, are these really in use to identify role addresses? I could imagine them being used in localparts of real personal addresses.
- 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.
- 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.
- 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.
- There is no header suggesting that this is possible spam
Maybe.. that seems like a can'o'worms.
mm
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
participants (3)
-
Charles Marcus
-
Mark E. Mallett
-
pod