[Dovecot] Vacation message functionality

[Charles Marcus]

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 at 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