Re: Vacation draft

> > First of all, users will be annoyed by being subscribed to a list, and
> > be very annoyed if subscribed to multiple lists.  Vacation MUST contain
> > heuristics to lock out mailing lists and their owner/request addresses,
> > but there is no safe way to detect them.  Subscribing typical users to
> > old-style lists without web interface causes them grief to no end and
> > there are enough idiots around having fun doing so.
>
> there are plenty of lists which don't require confirmation messages,
> either.  Sieve can't fix these.  if there are lists which don't do
> proper checks to see if the confirmation checks are automatically
> submitted, Sieve can't fix these either.

When it comes to not using "Re: $subject" for not replying with a sent
secret key, Sieve can fix the problem. :)

Personally, I use a fixed subject to address this problem.  With a large
number of users, I don't think I have a choice.  I see Tim's point in
that it loses context (something I am not afraid of) and it is certainly
unexpected for users that know autoresponders.

If the majority on the list does not think that the default subject
should be changed to a fixed string, it would be fine with me to add
this topic under the section "security considerations".

> the vacation extension should leverage whatever mechanisms other RFCs
> specify for recognising automatically submitted messages.  this includes
> RFC 2919 (List-Id) and RFC 2369 (List-Help etc.), but not heuristics
> like "if the local part of the sender address starts with 'owner-' or
> ends in '-owner'".  making such heuristics standard is work for a
> different group, IMHO.

Apart from "List-", draft 05 (I didn't find 06) says:

     Implementations are encouraged, however, to include well-known
     addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other
     addresses typically used only by automated systems.  Additionally,
     addresses ending in "-request" or beginning in "owner-", i.e.,
     reserved for mailing list software, are also suggested.

That's heuristics to me.  Is this different in draft 06? I would
appreciate if it still contained this, because it specifies current best
practice, at least part of it (listmaster, Precedence: bulk|junk|list
are not listed).  It does not give people a choice to get this wrong
and the more Sieve is used, the less broken vacation mails will be sent.

Michael