Subject: Re: [spamtools] Refuse for IMAP Sieve

From: "Matthew Elvey (FM)" <[email-masked]>
Date: Fri, 14 May 2004 14:42:00 -0700

On 5/14/2004 3:05 AM, Alex van den Bogaerdt sent forth electrons to convey:

>On Thu, May 13, 2004 at 12:54:15PM -0700, Matthew Elvey (FM) wrote:
>
>  
>
>>Hi. Just thought I'd let folks know that the IETF has published an
>>Internet Draft to reduce blowback from Sieve-generated bounces.
>>http://www.ietf.org/internet-drafts/draft-elvey-refuse-sieve-01.txt
>>Feedback (here or, preferably, on the ietf-mta-filters list) appreciated.
>>
>>Abstract
>>
>>   With "refuse", Sieve gains the ability to simply not accept an
>>   email during the SMTP transaction (instead of accepting it and then
>>   sending an MDN [MDN] back to the alleged sender using "reject").
>>   ...
>>   With "reject", MDNs contribute to
>>   the flood of Joe-job spam to victims of Joe-jobs; SMTP level
>>   refusals usually don't.  So "refuse" provides users the latter
>>   method to handle unwanted email.
>>
>>Sieve [RFC3028] is a language for filtering mail at the time of final
>>delivery.
>>    
>>
>
>Argh.
>
>There was not enough confusion yet, so let's redefine "reject" and use
>"refuse" for what others call reject?
>
>Why not simply repair the rfc and let reject do what it should do: give
>a 55x error on delivery.
>  
>
That was discussed on the list.  It was a tough call. 
(Points made by cyrus, kristin, ned, myself, around 13-25Feb04.)
Perhaps I gave posts from Ned (then Area Director, I think) too much 
weight, but I think not.
Thanks for the feedback. 
(Crossposting to make the mta-filters list aware of the feedback.  
Followups to one list, please.)

>Alex

---

From: Tim Showalter <[email-masked]>
Date: Sun, 16 May 2004 16:08:51 -0700

I'm sending this to spamtools in the hopes of explaining why things are 
the way they are.  My apologies if this is inappropriate or late.  I'm 
not on the list, and I haven't seen the discussion.

> Why not simply repair the rfc and let reject do what it should do: give

There's a reason why it works that way.  This was judged the suitable 
behavior of a client, which can't issue a 55x error because the message 
has already been delivered.  (Okay, the client could forge a bounce, but 
such things are not good design.)  Sieve could (and has) been 
implemented client-side without IMAP server support.

I can think of two reasons why we shouldn't change this to MUST either 
55x or DSN instead of MUST MDN:

If I can appeal to your sense of architectural purity, it is 
inappropriate for a client to generate a non-delivery report, because 
it's not the client's job to issue such things.  I believe this was the 
argument put forth at the time against either 55x or generating a DSN. 
(I believe one version of the document required either 55x or generation 
of a DSN, and it didn't make it.)

Or, if I can appeal to your sense of practicality, there is no 
performance reason for a client to generate a non-delivery report.  Once 
the final MTA has accepted responsibility for the message, it has to 
write to disk and do a lot of work that you're presumably trying to 
avoid.  If it generates a DSN or an MDN, it doesn't matter, it's not 
going to prevent the spammer from spamming you in the future.

The behavior in the RFC was, in fact, the only choice we could have 
made.  We did talk about it while the document was under development, 
but it wasn't a reasonable choice.

The advantage of "reject" is it allows this weaker behavior which is 
widely implementable.  Making refuse separate allows the best of both 
worlds.  I'm sorry the verbs aren't consistent, but there's nothing we 
could have done.  The damage to consistency was done a long time ago 
with these terms.

Tim