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 also have a large number of users, and I also don't have a choice - I either
offer the ability to use a subject of the form "Re: <origina>" or people won't
use the mechanism.
I know this because I originally tried not to have this in our implementation
for the reasons you have given. The result was I got my butt kicked, not once
but many times.
While I guess I could live with the *sieve* default being to use a fixed
subject, all that will mean for us is that the sieves our UI generates will
build sieve code to override this default.
The reality is that perceived need to incorporate the original subject into the
new one overwhelms the perceived risk of this being used for negarious
purposes. (I cannot and will not speak to the actual need and actual risk since
I have no good way to assess either one.)
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.
I note that this may be a cultural issue.
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".
I agree that it definitely needs to be discussed.
Ned