ietf-mxcomp
[Top] [All Lists]

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

2004-08-26 19:03:04

 "Jim Lyon" argues that messages may be silently discarded / 'bounces' may be
suppressed as follows:



Regarding silently discarding messages, Chris Haynes writes:

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

In other words, Chris believes that it's OK to silently discard mail
when you believe the bounce address is forged, but not when the PRA is
forged.

I submit that, as a matter of practice, people who forge one also forge
the other.  Also as a matter of practice, checking the PRA will produce
fewer false rejections than checking the bounce address will.

Chris also disputes that there is any legal basis for silently
discarding mail at all.  He's right that RFC 2821 requires that every
message be delivered, rejected or bounced.

However, see draft-zinn-smtp-bounces-01, which explicitly authorizes
silent discards. (I know, it's not a standard.  Yet.)


 If Sender-ID is relying on another darft for its authority, then should not
that draft be brought into this 'last call' process, so that the overall
proposal can be assessed for technical coherence, compatibility etc.

However, let's look at the draft...

Section 3 - proposal says:
"Although there is clearly an obligation to deliver or notify .. when an MTA can
accurately determined (sic) that a message has a forged "reverse path" and has
no content useful to the addressee, the message SHOULD be silently discarded."

The draft ONLY permits silent discard when the message is shown to be a forgery
by testing the return path - the Mail-From address.

It makes it clear that in all other cases the 'deliver or notify' obligation
remains. Only a failed Mail-From test gives you authority to break the SMTP
obligation.

This is EXACTLY what I proposed in the first of my paragraphs that you selected
for quotation. Let me repeat my proposal here:

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

I congratulate BZ Zinn for drafting exactly the right rule.


However, you persevere...

See also RFC
3834, which deals with automated responses in general (including
bounces) and says:

   -  A responder MAY refuse to send a response to a subject message
      which contains any header or content which makes it appear to the
      responder that a response would not be appropriate.

RFC 3834 is now a Proposed Standard.

Thanks for referring to this new document (August 2004).

I contend that your claim that the paragraph that you quote above includes
'bounces' is wrong.

Earlier in RFC 3834 it says:

"At least two types of automatic responses have been defined in IETF standards -
Delivery Status Notifications [I2. RFC 3464] which are intended to report the
status of a message delivery by the message transport system, and Message
Diosposition Notifications ...   These responses are defined elsewhere and are
generally not within the purview of this document, except that this document
recommends specific cases where they should or should not be used."

Now, in my book 'bounces' are DSNs - they are described in RFC 3464.

The paragraph you quote above does not contain (and is not within the context
of) a specific recommendation that a DSN should not be used, so bounces are "not
within the purview" of the paragraph you quote.

Thus RFC 3834 does not give you authority to 'refuse to send a response' where
that response is an RFC 3464 'bounce'.

============

Thank you for drawing my attention to RFC 3834 - it is is indeed an interesting
document.  Take, for example, the sub-section immediately before the one you
quoted to me - the one on page 6 beginning

    "Because the vast majority of mail is unauthenticated...."

It proceeds to say that large responses [bounces] should not be returned

"...without specific knowledge that the request was actually authorized by the
party associated with the address to which the response will be sent."

Bingo!

To conform to this new RFC, resposes must either have all responses trimmed to
less than "a few kilobytes" or must have ensured that the request was actually
authorised by the party associated with the Mail-From address.

Looks like a _mandate_ to test the Mail-From address for forgery to me!

Either that or ensure that _all_ responses are trimmed, which is not something
you can actually do when you instruct an offering MTA to send the bounce for
you.

(I re-invoke my earlier argument about you still being responsible for
generating the bounce even if you ask another host to do it for you).

============

I knew I had morality, business ethics and legal considerations on my side, now
I have an  RFC and a draft as well!


You continue...


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

In the SenderID drafts, the only requirement imposed is that if an MTA
performs SenderID tests during a mail transaction and the test fails, it
SHOULD reject the message.  This leaves open two possibilities for
silent discards:

1. An MTA might ignore the above SHOULD (after all, it's not MUST).
2. An MTA might perform the tests after receipt, in which case the specs
impose no requirement on what the MTA does.


If detailed specs within the SMTP family specify options like SHOULD, but leave
other behaviour unspecified, my contention has been all along that the
unspecified behaviour MUST still be within the scope of the SMTP conmmitment to
'deliver or report', unless some other RFC provides specific authority for
dropping bounces.

Had RFC 3834 given you that authority, I would have conceded the argument to
you - but it clearly does not, as I have demonstrated above.

And please note the abstract to Zinn's draft, in which he states  " [his later
detailed advocacy of silent dropping following detection of a forged Mail-From
address] should not be taken as a permanent carte-blanche to silently discard
any message that one does not like".

==============

Thanks for the great references, Jim. They have clearly proven my case!


Chris Haynes