Hi folks,
--On December 19, 2007 9:48:17 AM -0500 Cyrus Daboo
<cyrus(_at_)daboo(_dot_)name>
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.
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