headers
Tim Showalter | 2 Aug 2004 06:14
Gravatar

Re: Vacation draft


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Haardt | 2 Aug 2004 13:19
Picon

Re: Vacation draft


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

Neither would stop spammers saying: "We use opt-in with address
verification, and you did verify your subscription request".  They won't
be stupid enough to make their newsletter system look like a regular
mailing list, because they *want* vacation responses to be sent in order
to gain subscribers.

> [database size of vacation message recipients]

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

1000 would be fine with me, because most people get mail from fewer
addresses within a week, so the average of large systems should be less
by far.

Michael
Permalink | Reply | 2 comments |
headers
Michael Haardt | 2 Aug 2004 13:26
Picon

Specification of ":mime" in vacation extension


Hello,

when using ":mime", CMU Sieve 2.3 uses the MIME header and body
to build a message with Content-Type multipart/mixed, the only
part being the reason string.

The vacation draft refers to RFC 3028, which in turn does not
specify how such mails are composed.

Do other implementations work the same way? What's the reason
behind not adding the MIME header to the message header, thus
giving the script writer full control over the message? The
current specification (or lack thereof) would allow doing so.

Michael
Permalink | Reply | 1 comment |
headers
Kjetil Torgrim Homme | 2 Aug 2004 14:06
Picon
Picon

Re: Vacation draft


On Mon, 2004-08-02 at 13:19 +0200, Michael Haardt wrote:
> > 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).
> 
> Neither would stop spammers saying: "We use opt-in with address
> verification, and you did verify your subscription request".  They won't
> be stupid enough to make their newsletter system look like a regular
> mailing list, because they *want* vacation responses to be sent in order
> to gain subscribers.

you have too little faith in the common sense of judges.  a spammer
claiming that a vacation message or a bounce (both should have "MAIL
FROM:<>") is opting-in would be laughed out of court.

--

-- 
Kjetil T.
Permalink | Reply | 0 comments |
headers
Michael Haardt | 2 Aug 2004 14:26
Picon

Re: Vacation draft


> you have too little faith in the common sense of judges.  a spammer
> claiming that a vacation message or a bounce (both should have "MAIL
> FROM:<>") is opting-in would be laughed out of court.

I have pretty much no faith at all in the common sense of judges when
it comes to technical issues indeed, and good reasons for doing so.
It may be a German issue, but I doubt it.  I could imagine very well that
a spammer using vacation based opt-in does not get in serious trouble
for a year or even longer over here.  Hell, even without that he may
not get any trouble.  All you can do is subscribing his administrative
addresses to his own list, among others. :-( But that's another point.

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.

Michael
Permalink | Reply | 2 comments |
headers
Kjetil Torgrim Homme | 2 Aug 2004 15:37
Picon
Picon

Re: Vacation draft


(please include References or In-Reply-To in your messages, every new
message from you creates a new thread, which is inconvenient.)

On Mon, 2004-08-02 at 14:26 +0200, Michael Haardt wrote:
> > you have too little faith in the common sense of judges.  a spammer
> > claiming that a vacation message or a bounce (both should have "MAIL
> > FROM:<>") is opting-in would be laughed out of court.
> 
> I have pretty much no faith at all in the common sense of judges when
> it comes to technical issues indeed, and good reasons for doing so.
> It may be a German issue, but I doubt it.  I could imagine very well that
> a spammer using vacation based opt-in does not get in serious trouble
> for a year or even longer over here.  Hell, even without that he may
> not get any trouble.  All you can do is subscribing his administrative
> addresses to his own list, among others. :-( But that's another point.

yes, I don't think fixing the German judiciary system is practically
possible for Sieve :-)

> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
ned.freed | 2 Aug 2004 16:56

Re: Vacation draft


> (please include References or In-Reply-To in your messages, every new
> message from you creates a new thread, which is inconvenient.)

> On Mon, 2004-08-02 at 14:26 +0200, Michael Haardt wrote:
> > > you have too little faith in the common sense of judges.  a spammer
> > > claiming that a vacation message or a bounce (both should have "MAIL
> > > FROM:<>") is opting-in would be laughed out of court.
> >
> > I have pretty much no faith at all in the common sense of judges when
> > it comes to technical issues indeed, and good reasons for doing so.
> > It may be a German issue, but I doubt it.  I could imagine very well that
> > a spammer using vacation based opt-in does not get in serious trouble
> > for a year or even longer over here.  Hell, even without that he may
> > not get any trouble.  All you can do is subscribing his administrative
> > addresses to his own list, among others. :-( But that's another point.

> yes, I don't think fixing the German judiciary system is practically
> possible for Sieve :-)

Or the American, for that matter. (Which one is more deeply broken is
a good topic for a bar-BOF...)

> > 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Haardt | 2 Aug 2004 17:02
Picon

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
ned.freed | 2 Aug 2004 18:36

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 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
ned.freed | 2 Aug 2004 19:05

Re: Specification of ":mime" in vacation extension


> when using ":mime", CMU Sieve 2.3 uses the MIME header and body
> to build a message with Content-Type multipart/mixed, the only
> part being the reason string.

This seems like one possible way to do it. Another way would be to construct a
message containing a single MIME part specified in the reason string, without
putting it in a multipart/mixed.

> The vacation draft refers to RFC 3028, which in turn does not
> specify how such mails are composed.

Perhaps not in the sense of what's done with the part, but the specification
certainly defines what goes in the reason string.

> Do other implementations work the same way?

Our implementation doesn't use a multipart/mixed wrapper. It simply treats
the content as a MIME entity and wraps it inside of a message.

> What's the reason
> behind not adding the MIME header to the message header, thus
> giving the script writer full control over the message?

So that things besides text/plain; charset=utf-8 can be returned.

> The
> current specification (or lack thereof) would allow doing so.

It is supposed to.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane