Subject: Re: Vacation draft

From: Tim Showalter <[email-masked]>
Date: Sun, 01 Aug 2004 21:14:18 -0700

Michael Haardt wrote:

> I have two comments to the section security considerations:
> 
> Sending out an automated reply with "Re: " and the subject is dangerous.
> Many mailing lists verify the mail address by sending a mail with a key
> in the subject.  Simply replying to such a mail confirms you want to
> subscribe to it.  If people use vacation, it is easy to subscribe them
> to a spam list and prove that it *is* opt-in by keeping the confirmation
> and throwing away the original faked subscription request.

This is obviously a problem, but the fix is not quite obvious.  The 
obvious thing to do is to change the subject to whatever, but that's not 
clearly the right thing to do, because it loses context of the original 
message.  We could specify that this happens unless a List-* header is 
present or unless Auto-Submitted is not present or set to no (I have no 
idea if this header was ever documented).

> Mail systems should be allowed to bypass the time if the database to
> remember senders becomes too large.  I suggest to allow the implementation
> to expire entries if the number of different senders becomes too big.
> The draft could set a minimum database size. Say 100 or 1000 different
> senders must be remembered, but implementations may store more.

I am adding the following text to section 3.2:

Implementations are free to limit the number of remembered responses,
provided the limit is no less than 1000.  Implementations SHOULD make
the limit no less than 1000 per vacation command if using the hash
algorithm described above.

I figure a thousand is enough for a lower limit, but maybe that should 
be a SHOULD.

Tim

---

From: Michael Haardt <[email-masked]>
Date: Tue, 03 Aug 2004 12:37:08 +0200

> Why would they bother claiming opt-in?  It wouldn't be worth exposing 
> their SMTP servers to obvious attack; most people do not have a vacation 
> command in place most of the time; and it's easier to just lie big 
> instead of lie small.

Don't ask me about a spammers thinking.  I see all kinds of odd behaviour
that makes no sense to me, including obviously made up excuses and
threats against sueing for blocking their "legitimate" mail.

This time of the year, there is a good chance to hit vacation
auto-responders.  Ask mailing list admins about that issue, but duck
fast. ;-)

> I added verbage stating not to reply to Auto-submitted messages (wasn't 
> there, I was surprised), so in any case, there's an obvious fix for 
> mailing list managers that aren't covered by List-* headers, owner-*, 
> *-request, etc.

Good.  Will the new version also contain a warning about the risk of
responding with the old subject?  Since ":subject" already allows to
change it to a fixed subject, everybody can decide between the risk
and losing the context.

Michael

---

From: Michael Haardt <[email-masked]>
Date: Tue, 03 Aug 2004 12:46:16 +0200

> 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.

Interesting! I got absolutely no negative feedback here at all.

> 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.

And it would require variables to reach the same functionality, plus
code to strip the "Re: ".  A hack like ":resubject" could solve that,
but it is ugly.

> 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.

That may well be.  I don't like riskful defaults, that's all.  Since
few people ever write Sieve scripts on their own, it is not as bad,
though.  GUI authors hopefully read the draft/RFC, so they know what
they are doing.

Michael