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
>>>>> "CM" == Charles Marcus <CMarcus at 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.
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, bouncesYeah, 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, bouncesI 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 sameWhere 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 headerThe 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 spamMaybe.. that seems like a can'o'worms. mm