-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of
Hallam-Baker,
Phillip
Sent: Tuesday, August 24, 2004 1:40 PM
To: 'terry(_at_)ashtonwoodshomes(_dot_)com'; Hallam-Baker, Phillip;
'Chris Haynes';
'IETF MARID WG'
Subject: RE: DEPLOY: Legal liability for creating bounces from forged
messages
First off, there is nothing that requires you to copy
anything into the
bounce.
Providing that you are willing to accept the original email
LOST. Bounces are done to:
In this case it would suffice to notify the purported sender that
a message from them failed validation. It is not necessary to
quote any of the text of the message.
NOT if you are among those who believe the email is reliable transport. Once
your MTA has accepted
an email you are obliged to either:
1) deliver it
2) return it as undeliverable
In this case, refusing it in the first place is MUCH MUCH better (see SPF
classic, or the middle
ground Unified SPF)
But, as the list was requested, I am simply pointing out DEPLOYment problems.
Secondly if it is an automatic process your liability would
be no greater
than it would be following original SMTP.
Wrong. When you bounce it now knowing the validity of the
bounce recipient has you have less
liability then if you bounce it KNOWING that the bounce
recipient is invalid.
One way that the spec could be improved would be to state that the
sender SHOULD notify the purported sender without mandating the
use of a particular mechanism, specify bounces as the fallback
mechanism.
Fine. But if you believe that SMTP is used for reliable communication, you
have to do *something*
with it. What do you propose instead? Silently delete it? Pass it off to the
original recipients
postmaster? Neither is viable or acceptable in the context of RELIABLE message
transfer.
At some point we need a better mechanism for reporting failures
of all kinds. Something that is authenticated and out of band.
Uh, yeah. Thanks for stating that, but better SMTP is *exactly* what we are
all working towards
here. I am just not sure that SenderID (as stated) is better then what we have
(if it creates more
bounces, or allows bounces to known forged recipient address).
That may be sufficient for some to believe, but "ignorance is
no excuse" has been the big stick that
many courts have wielded time and again.
Ignorance of the law is no excuse. Absence of intent or knowledge
on the other hand is one of the strongest defenses possible in
almost all cases.
Look up Mens Rea.
The "culpable mental state" of Mens Rea is not applicable here:
1) We are bouncing BECAUSE we know the email to be bad with reasonable high
probability,
2) the bounce recipient is known to be invalid (which is what I object to,
don't bounce to when you
*know* the bounce target is an uninvolved third party)