ietf-mta-filters
[Top] [All Lists]

Re: [spamtools] Refuse for IMAP Sieve

2004-05-16 16:08:50

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.

On 5/14/2004 3:05 AM, Alex van den Bogaerdt wrote:

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.

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


<Prev in Thread] Current Thread [Next in Thread>