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