ietf-mxcomp
[Top] [All Lists]

Re: DEPLOY: Legal liability for creating bounces from forged messages

2004-08-25 02:09:28

"Jim Lyon" opined:


Chris,

You're between a rock and a hard place.  If you simultaneously believe
that all of the following are sinful:

1. To accept and deliver forged mail.
2. To accept forged mail and silently discard it.
3. To accept forged mail and then generate a bounce.
4. To reject forged mail because the sender might generate a bounce.

then you have no alternatives left.

Actually I was advocating (2) - but only in the special case when the Mail-From
entity has declined responsibility for the message by causing a test 'fail'.

We need to have SPF_Classic+SRS or an equivalent 'on the table' so that the
experts can explain to you why a (2) can be justified following a Mail-From
test, but not following a PRA test.


The current drafts give you a way to avoid (1) -- that's their whole
point.  They leave it as a local policy decision as to which of 2, 3 or
4 you choose.  They recommend (4) with a "SHOULD", but you can
reasonably do either of the others.

Today, many large ISPs silently discard mail that they classify as spam.
I expect that those ISPs will choose (2) when implementing SenderID.



Woah! Home on there!  There's a new, really serious point here.

You claim in (2) that the drafts give authority for MTAs to silently discard
messages. I cannot find that authority in the drafts.

There is an absolutely critical, overriding requirement imposed on all
components of SMTP systems by RFC2821.

I quote from section 2.1
   ".. message transfer can occur in a single connection
   between the original SMTP-sender and the final SMTP-recipient, or can
   occur in a series of hops through intermediary systems.  In either
   case, a formal handoff of responsibility for the message occurs: the
   protocol requires that a server accept responsibility for either
   delivering a message or properly reporting the failure to do so."

This is fundamental to SMTPs' ability to provide a reliable service.

Now -core-03.txt, section 5.3 says that on failure a server 'SHOULD reject the
message' using a 550 method. That conforms to RFC2821. But what alternative
actions are available?

I had assumed that the alternative, should the advice not be heeded, would be to
continue to process the message in some way - still in conformity with the
RFC2821 requirement  to 'deliver or report'.

I hope you are wrong in your assertion in (2) that the -core draft authorises
the silent discarding of messages.

If the drafts do conform to RFC2821, then the technical assertions backing this
entire thread, and justifying my inability to deploy Sender-ID  remain
unchallenged.

If these drafts do permit the silent discard of messages on the basis of a PRA
test failure as a 'local policy decision', as you suggest, that would be grounds
for a significant TECH-ERROR submission: Sender-ID would be breaking the general
requirement imposed by RFC2821.

Where do the drafts authorise or advocate the silent discarding of messages?



Your thoughts about MAIL-FROM, HELO and EHLO don't change the above
calculus at all.  They merely change the details of which messages you
classify as forged.


No. not 'merely'.

The repudiation of a message by its envelope sender (Mail-From entity) has an
entirely different significance in the context of RFC2821 than repudiation of
its content by a PRA test.

We need SPF_Classic+SRS, or an equivalent, on the table for this sub-debate to
be continued.

-- Jim Lyon



Chris Haynes



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