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