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+12345domain.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 "$-" (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 "-$"
(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
<CMarcusMedia-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://h
g.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://h
g.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 "$-" (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 "-$"
(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