Subject: Re: Working Group Last Call: draft-ietf-sieve-refuse-reject-05.txt

From: Cyrus Daboo <[email-masked]>
Date: Sun, 10 Feb 2008 14:35:17 -0500

Hi folks,

--On December 19, 2007 9:48:17 AM -0500 Cyrus Daboo <[email-masked]> 
wrote:

> I would like to draw your attention to
> draft-ietf-sieve-refuse-reject-05.txt. We will start a working group last
> call on this document today that will run for four weeks (to account for
> the holidays in between). So this last call will end on January 16, 2008.
> Please review this document and send your comments to the list, thanks.

Lost track of time on this one - sorry!

The WG last call is well and truly over on this.

There was only one comment from Matthew Elvey (Subject: I-D 
Action:draft-ietf-sieve-refuse-reject-06.txt & spam blowback.).

I need to make a determination of WG consensus on this specification, and 
specifically need to know:

1) How many people have reviewed this draft?
2) Are there any problems with it?
3) Do people agree with Matthew's proposed text?

I need to get sufficient responses from WG participants so we can move 
forward with this draft.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 11 Feb 2008 10:50:45 +0100

Cyrus Daboo writes:
> I need to make a determination of WG consensus on this specification, 
> and specifically need to know:
>

I at least.

> 2) Are there any problems with it?

Not really. I think it's the best that can be done in the circumstances, 
and enough of an advance to be worth doing.

> 3) Do people agree with Matthew's proposed text?

Is that -06? I think -06 is fine. One nit.

> I need to get sufficient responses from WG participants so we can move 

Also: I'll rename my "refuse" in my code and verify that the code does 
everything in -06. (Draft -06 is closer to my code than the earlier 
version I implemented. I like that.)

Arnt

---

From: Ned Freed <[email-masked]>
Date: Tue, 12 Feb 2008 14:31:55 -0800 (PST)

> I need to get sufficient responses from WG participants so we can move

I just finished implementing this which gave me a chance to review the 
document fairly carefully.

First, a process issue: This document references RFC 2033 (LMTP) normatively. I
have no problem with this but I don't believe the rules allow us to have a
normative reference to a informational protocol specification. We're going to
have to ask for an exception to be made.

Second, the first paragraph of the introduction makes it sound like the ereject
action always results in a protocol-level error. This is untrue - the ereject
action mandates the use of an SMTP-level response whenever possible but it
doesn't require it because it cannot. I suggest adding "whenever possible" to
the last sentence of this paragraph.

Third, the draft in general and section 2.1.2 in particular almost makes it
seem like LMTP is some sort of solution to the blowback problem. This is
incorrect - all implementation at the LMTP server level does is push the
blowback generation one level off.

Unless you happen to have an MTA that can operate in passthrough mode and which
can pass back an LMTP server error response to the SMTP client that's still
connected and waiting for that final status, the MTA is going to
convert any errors it gets into a DSN, which in the case of a joe-job becomes
blowback spam. And even if you happen to have such an MTA, it still has to use
a DSN when there are multiple LMTP recipients that return different results.

This approach solves nothing unless the LMTP client is itself a spambot, and
if that's the case blowback spam is guaranteed to be the least of your worries.

Section 2.1.2 also implies that the reason the DSN exception doesn't apply to
LMTP is because of it's ability to perform per-recipient message rejections.
This is also incorrect - the reason the LMTP server shouldn't be generating
DSNs is quite simply that it is inappropriate and dangerous for it to do so. In
order to see why this is so, consider the case of a message with
NOTIFY=SUCCESS,FAILURE set which is then refused by the LMTP server. The LMTP
server has no way to know this setting was in effect. Generating a DSN of its
own places it in an impossible situation: it has to send either a 2yz or 5yz
response, and either way the originator ends up getting two DSNs for a single
recipient (5yz is arguably better because at least then the two DSNs don't
directly contradict each other.)

I therefore recommend changing the first paragraph to read something like this:

   An implementation may receive a message via SMTP that has more than
   one RCPT TO that has been accepted by the server, and at least one
   but not all of them are refusing delivery (whether the refusal is
   caused by a Sieve "ereject" action or for some other reason) or
   different recipients are refusing delivery for different reasons.
   In such cases, the SMTP server MUST accept the message and generate
   DSNs for all recipients that are refusing it.

   Note that this exception does not apply to LMTP because LMTP returns
   per-recipient message statuses and does not generate DSNs of its
   own. (However, note that when different recipients have different
   final statuses the SMTP has no choice but to generate DSNs of its
   own.)

Next, the recommendations on how to handle non-ASCII text are problematic in
the case of LMTP and a passthrough MTA. Section 2.1.2 says that an 8bit
response should be relayed back to the client if an 8bit protocol extension is
available and in the case of ereject flattened into a stock ASCII repsonse if
it is not. But suppose the LMTP connection supports the extension but the
SMTP connection does not. In this case the MTA isn't going to know that
the LMTP server would prefer to have the text replaced than send a DSN.

Given the uncommonness of passthrough MTAs I doubt this point is worth
addressing but I thought I should mention it.

Finally, the draft doesn't mention the case where different recipients
refuse the message for different reasons. I tried to cover this in my
suggested replacement test for 2.1.2, but there are some other places
in the document like the second list item in section 2.2 where we may
want to mention it..

One final comment. it has long been my view that while reject has certain
legitimate uses, dealing with spam isn't one of them. In my view reject is for
situations where a likely legitimate but nevertheless inappropriate message is
received and you want to inform the originator of the message's
inappropriateness. Examples include things like homework submitted after the
cutoff date is passed, messages that exceed some length limit for a given
recipient, and so on. To the extent that this draft focuses on making reject
safer and defining a new ereject that is safer still, I worry that we may
actually be making the blowback problem worse, not better by encouraging use of
these actions when a discard would be more appropriate.

Mind you, I'm not recommending any changes to the draft, but perhaps a direct
statement that "the risk that these actions will generate blowback spam are
minimized but canont be eliminated completely even in the case of ereject, so
caution is advised when using these actions to deal with messages determined to
be spam" would be worth considering.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Feb 2008 18:40:33 +0000

> have to ask for an exception to be made.

Indeed. I was also thinking about revising LMTP spec to move it to 
Standard Track, but it is sufficiently low on my list of IETF priorities.

---

From: Aaron Stone <[email-masked]>
Date: Wed, 13 Feb 2008 12:04:47 -0800

> Standard Track, but it is sufficiently low on my list of IETF  

At the Vancouver IETF, both Lisa and Chris indicated that it would be  
straightforward to get a variance for this. (As I understand, it  
requires the IESG to sign off on the variance?)

Aaron

---

From: Дилян Палаузов<[email-masked]>
Date: Wed, 13 Feb 2008 21:09:31 +0100

Hello,

If sieve scripts are written in the form:

if (envelope tests....) { reject; stop;}
some other tests and actions;

the scripts can be applied once after the RCPT TO: command and once 
after the DATA command. If the first script calling is successful (stop; 
is reached without trying tests, that require headers or body), and the 
reject action is performed, then the sieve script can reject the message 
at the RCPT TO: level.

The application of such scripts is, e.g. for mailing lists, with scripts 
like

	if (recipient is a mailing list and sender is not allowed to post 
there) {reject; stop;}

which will save the consequent NDRs, send from the mailing list 
software. This approach is not considered in 
draft-ietf-sieve-refuse-reject-06, 2.2 Action reject...However 
implementations MAY refuse delivery over protocol ..., if and only if 
all of the following conditions are true:  2. ...

	Със здраве,
		Дилян

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 13 Feb 2008 15:13:39 -0500

Hi Aaron,

--On February 13, 2008 12:04:47 PM -0800 Aaron Stone <[email-masked]> 
wrote:

> straightforward to get a variance for this. (As I understand, it requires
> the IESG to sign off on the variance?)

That is my recollection too. I will have to check up on the exact procedure 
for this - certainly the write-up I do will make mention of it, what I 
don't know is whether there has to be something in the draft itself.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 13 Feb 2008 22:02:27 +0100

Cyrus Daboo writes:
> That is my recollection too. I will have to check up on the exact 
> procedure for this - certainly the write-up I do will make mention of 
> it, what I don't know is whether there has to be something in the 
> draft itself.

The same thing (AFAICR) happened for RFC 4978, which refers normatively 
to RFC 1951. The dependency had to be called out in the IETF Last Call, 
that was the only thing I noticed.

Arnt

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 15 Feb 2008 13:19:03 -0800

There's also a fair argument for making the reference to LMTP  
informative.  It's certainly not necessary (and if I understand  
correctly, not common) to implement LMTP in order to implement SIEVE;  
it's not even necessary to read RFC2033.

The informational nature of this reference could be made more obvious  
in the text if we like.  E.g. in the first instance:

    1.  Refuse message delivery by sending a 5XX response code over SMTP
        [SMTP].  Optionally, if LMTP [LMTP] is used, refuse message  
delivery by
	sending a 5XX response code over LMTP.  See Section 2.1.1 for more  
details.

We could also gather the references to LMTP into one section.

But yes, if the main text stays like it is, the variance has to be  
requested in IETF Last Call -- don't let your AD forget to do that ;)

Lisa

On Feb 13, 2008, at 12:04 PM, Aaron Stone wrote:

> At the Vancouver IETF, both Lisa and Chris indicated that it would  
> be straightforward to get a variance for this. (As I understand, it