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