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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 24 Aug 2004 11:46:02 -0700

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

If your understanding of English law is that you would be performing
a criminal act by doing so, then your duty to the Queen would surely
claim a higher priority than the mere opinions of this group?

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

Like fix the mess that is the SMTP spec.

> What do you propose instead?  Silently delete it?  

Lets see, more than 90% sure its garbage, delete it unless the
sender suggests some other disposition.

> Pass it off to the original recipients
> postmaster?  Neither is viable or acceptable in the context 
> of RELIABLE message transfer.

SMTP is not a reliable mail transfer protocol, neither as 
originally described or as implemented. 

The first step towards making SMTP reliable is to put authentication
in place.

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

We have no specific knowledge that the email is pornographic.

Mens Rea is not applicable to inanimate objects such as computers
and statues and has not been since 950 or thereabouts.

---

From: <[email-masked]>
Date: Tue, 24 Aug 2004 15:58:15 -0400

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

I fail to see the relevance, but anyway, I am only loosely a British subject, I am Canadian.  And
whether or not I am/am not criminally liable, does not protect me from civil liability.  And
although much civil suits are done frivolously, suits with less subtance then what we described have
been won (bouncing when email known bad and bounce recipient known invalid).

I need to protect myself from criminal AND civil liability in ALL countries where I do business.

> Like fix the mess that is the SMTP spec.

Correct.

> sender suggests some other disposition.

And that's what I do not consider to be acceptable behaviour.  Nor should anyone.  If we did, we
could just set our spamassassin scores low and let spamassassin kill anything that looks even
remotely bad.

That's just an example, so before you say "MARID is not about killing spam..." but the charter is
about mail authentication which is supposed to be a stepping stone toward fighting phishing, spam
etc.

> originally described or as implemented.

WRONG on both counts.

Try to stick to the facts please, I quote from RFC 821:
"The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and
efficiently."

http://www.faqs.org/rfcs/rfc821.html

And most MTA's (all that I have used) treat SMTP as a reliable messaging system, either send the
message, or indicate that it was not sent.

> and statues and has not been since 950 or thereabouts.

No, but it IS applicable to those who use tools/weapons to perform deeds to their design.  I am
going to quite, because the argument is moot, suppose in some countries there is no criminal
liability.  In a significant portion of the internet (United States comes to mind) there could be
criminal and/or civil liability implications by implementing sender id.