Subject: RE: DEPLOY: Legal liability for creating bounces from forged mess ages

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 24 Aug 2004 10:39:34 -0700

> > 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.

> > 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.

At some point we need a better mechanism for reporting failures
of all kinds. Something that is authenticated and out of band.

> 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.

---

From: <[email-masked]>
Date: Tue, 24 Aug 2004 13:57:39 -0400

> on the other hand is one of the strongest defenses possible in

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)

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

---

From: <[email-masked]>
Date: Tue, 24 Aug 2004 14:17:12 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Hallam-Baker,
> Phillip
> Sent: Tuesday, August 24, 2004 1:40 PM
> To: [email-masked]'; Hallam-Baker, Phillip;
> 'Chris Haynes';
> 'IETF MARID WG'
> Subject: RE: DEPLOY: Legal liability for creating bounces from forged
> messages
>
>
>
>

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.

> use of a particular mechanism, specify bounces as the fallback

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.

> 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).