Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages

From: "Jim Lyon" <[email-masked]>
Date: Tue, 24 Aug 2004 11:54:09 -0700

This thread has devolved into a fascinating discussion of arcane points
of British law, but it misses the fundamental point:

A reasonable use of SenderID is to use it at SMTP time, and to refuse to
accept forged mail.  If you refuse to accept it (by giving an error at
end of DATA), you won't generate a bounce.  The MTA that was sending the
mail might or might not generate a bounce, but that's his problem, not
yours.

In fact, most of the forged mail is sent by specialized spam engines or
virus propagation engines.  These engines won't generate bounces,
they'll just give up and go on to the next victim.

So, deploying SenderID should result in fewer bounces, not more. 

-- Jim Lyon

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

> Sorry for the typo, that should read:
> Wrong.  When you bounce it <NOT> knowing the validity of the 
> bounce recipient you have less liability then if you bounce 
> it KNOWING that the bounce 
> recipient is invalid.

Where is the Mens Rea?

The UK obscene publications act is a criminal offense, the issue is
whether the action is criminal, not whether there is a civil liability.

What the computer 'knows' is not relevant to Mens Rea, only individuals
and corporations are subject to criminal law. 

The last time an animal was prosecuted under English common law was
when the citizens of Sunderland hung a monkey as a spy during the 
Napoleonic wars. The only occasion I am aware of in which an inanimate
object was put on trial was before the Norman Conquest when a statue
of the Virgin Mary was convicted of murder and is believed to lie in a
grave that can be seen from my parent's house.

Sure you can find some really obscure offenses if you dredge up obscure
parts of English law. That does not mean that there is the slightest
chance that a Home Secretary is ever going to allow a prosecution.

---

From: <[email-masked]>
Date: Tue, 24 Aug 2004 16:06:31 -0400

Well said, well put, I agree to get off UK law and back to the point.  

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

> From: Jim Lyon [mailto:[email-masked]]
> Sent: Tuesday, August 24, 2004 2:54 PM
> To: Hallam-Baker, Phillip; [email-masked]; Chris Haynes;
> IETF MARID WG

---

From: "Chris Haynes" <[email-masked]>
Date: Tue, 24 Aug 2004 21:59:03 +0100

> mail might or might not generate a bounce, but that's his problem, not

I beg to differ.

I am the one who has discovered that I am being offered a forgery. If I reject
at SMTP time and a bounce is generated it is my responsibility, my karma.  I
knew full well that his machine may send a bounce, and include the malicious
content.

It is my decision, my responsibility, regardless of how the technology works.

If we had on offer a Mail-From test (with HELO/EHLO where needed) and new SMTP
semantics that said we MAY/SHOULD/MUST discard the message (with no bounce) if
the Mail-From test fails, then I would be satisfied.

> they'll just give up and go on to the next victim.

That may be true, but I'm concerned about everything that may happen, not just
'most'.

> So, deploying SenderID should result in fewer bounces, not more.

And incorporating the tests & semantics developed in SPF would result in even
fewer bounces - and totally eliminate the situations which concern me.

> -- Jim Lyon

Chris Haynes

---

From: "John Glube" <[email-masked]>
Date: Tue, 24 Aug 2004 17:00:39 -0400

From: Jim Lyon
Sent: August 24, 2004 2:54 PM

>A reasonable use of SenderID is to use it at SMTP time, and
>to refuse to accept forged mail.  If you refuse to accept
>it (by giving an error at end of DATA), you won't generate
>a bounce.  

>The MTA that was sending the mail might or might not
>generate a bounce, but that's his problem, not yours.

>In fact, most of the forged mail is sent by specialized
>spam engines or virus propagation engines.  These engines
>won't generate bounces, they'll just give up and go on to
>the next victim.

A number of issues:

* Your position presumes wide spread implementation of
Submitter, allowing for extraction of the PRD at the data
stage.

* Until this happens, as Sender-ID is presently drafted,
the receiving MTA has to 'swallow' the message and extract
the PRA from the headers. As has been previously stated
this leads to a greater risk of false positives.

* Sender-ID does not call for SMTP mail from checks at the
DATA stage in the absence of PRA. If you are suggesting
either amending Sender-ID or preparing a BCP document to
suggest that receivers do carry out SMTP mail from checks
at the DATA stage in the absence of PRA, I would whole
heartedly support this.

* I am concerned about the suggestion that:

>If you refuse to accept it (by giving an error at end of
>DATA), you won't generate a bounce.

I agree if there is no domain found in either Submitter or
SMTP mail from this may be appropriate. However, the
appropriate 55x error message must be generated, so that
legitimate senders with mis-configured mail servers can
rectify the situation. 

Also, in the event of Submitter or SMTP mail from spoofing,
again it is important to generate the appropriate 55x error
message, so that legitimate senders with mis-configured
email policy records can sort out the problems.

There is no love lost for forged headers. At the same time,
I suggest we need to take care not to throw out senders who
are endeavouring to comply but for some reason are using
mis-configured mail servers, who have made errors in
publishing their email policy records, or who have failed
to update their email policy records as a result of system
changes.

Finally you write:

>In fact, most of the forged mail is sent by specialized
>spam engines or virus propagation engines.  These engines
>won't generate bounces, they'll just give up and go on to
>the next victim.

My understanding is different. Apparently according to
published reports earlier this summer between 60 to 80% of
UBE is now sent by spammers accessing zombie computers on
infected networks. The use of specialized spam engines is
apparently no longer the spammer's weapon of choice.

(See in particular comments made by Stephen Linford in June
at an anti spam conference in London, England, along with
an article published by Tom Donnelly through Circle-ID.)

Recent reports indicate less than 1% of all filtered email
is CAN SPAM compliant. This leads me to believe most UBE
coming from zombie computers uses forged return paths.
Anecdotal evidence seems to confirm this understanding. 

Therefore I am not sure the conclusion you reach is correct.

Having said all of this, from my personal perspective,
having made a fuss about the license, I am satisfied with
the IPR statement given the representations made by MS in
the FAQ and the form of license. 

Others will strongly disagree and let the discussion
continue.

From my perspective, the core issues involve technical
concerns surrounding the need to protect the return path
and related deployment concerns arising from the failure to
protect the return path against spoofing or fraud in
Sender-ID.

Having said this I acknowledge the Sender-ID specifications
does not focus on these issues. 

I have previously stated these concerns can be resolved
through the use of a Best Current Practices document.

For more on this, see my earlier discussions in the threads
What Meng Said, Point of Order, Incomplete Flawed Response
to MARID WG Charter and Forged Sender (Resent From Attacks).

Unless this 'circle is squared' Sender-ID will in my view
continue to meet with opposition in the open source
community as it compels software developers to utilize the
PRA algorithm. 

I don't know whether this will ultimately result in the WG
rejecting Sender-ID. But I strongly believe without
resolution it will ultimately result in an attitude of two
solitudes between those supporting Sender-ID and those
supporting SPF.

I come from a country which has dealt with the problem of
two solitudes existing between founding national groups for
over 100 years. This has lead to the development of a
confederation which allows for co-existence of diverse
ethnic groups within one nation state.

This WG is essentially confronted with the same reality.
There is not just one way of dealing with sender
authentication.

It would be tragic if this WG was to ignore the underlying
problems now facing implementation of sender authentication
given the developing split between the SPF and Sender-ID
communities.

This is also why I support the CSV proposal.

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Aug 2004 14:16:58 -0700

On Tue, 2004-08-24 at 11:54, Jim Lyon wrote:

> accept forged mail.

A reasonable use of SMTP may be for relaying mail without completing all
checks at each MTA, such as ensuring recipients within the local domain
are all valid.  Even if Sender-ID were checked by each MTA, it would be
unreasonable to expect spam would be refused as a result.  Although
there may be a learning curve, don't expect finding "open" records to
prove an insurmountable discovery. 

> If you refuse to accept it (by giving an error at end of DATA), you
> won't generate a bounce. 

If the MTA is a relay receiving the refusal, then this MTA _MUST_
generate a bounce.  

> The MTA that was sending the mail might or might not generate a
> bounce, but that's his problem, not yours.

If the bounce is to you, from an MTA regarded as a reputable, you
receive these bounces.  If this mail stream is within an
administratively shared realm, then the problem may occur at your
provider's relay.  Either way, Sender-ID does not curtail this problem.

> they'll just give up and go on to the next victim.

These specialized spam engines are not likely to be rejected either. 
Sender-ID makes it _extremely_ easy to spoof MTA permissions! 

> So, deploying SenderID should result in fewer bounces, not more.

Sender-ID pays no attention to the return-path.  How do you arrive at
there being fewer bounces?  Those that attempt to ratchet up their
acceptance levels for Sender-ID will actually invite more of this
spoofed return-path behavior, as Sender-ID is unable to discern when the
return-path is valid.

-Doug

---

From: Mark <[email-masked]>
Date: Wed, 25 Aug 2004 08:09:16 GMT

Jim Lyon wrote:

> A reasonable use of SenderID is to use it at SMTP time, and to refuse
> to accept forged mail. If you refuse to accept it (by giving an
> error at end of DATA), you won't generate a bounce. The MTA that was
> sending the mail might or might not generate a bounce, but that's his
> problem, not yours.

I am coming out of delurk for a moment. But could someone please explain why
we are having this discussion? I mean, rejecting with a 5.x SMTP error code,
based on whatever criteria, creates neither less, nor more liability, than
doing so, also for whatever reasons, has done for the last few decades.
There is, from the perspective of the sender at SMTP level, nothing
fundamentally different between, say, being rejected based on an entry in
the access database, and being rejected based on something found, or not
found, in the headers.

Though I will carefully avoid saying people are "wrong" (what, with me not
having enough "standing" for that, and all; lol), I presume I am allowed to
*agree*, right? :) So, I agree with Jim. To say anything else, IMHO, is
really tantamount to defending the position that sending any 5.x code
potentially sets you up for legal liability. Which brings me full-circle: it
may or may not, but not more so, or less, than doing so for the last few
decades has done.

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

---

From: "Chris Haynes" <[email-masked]>
Date: Wed, 25 Aug 2004 10:29:06 +0100

"Mark" asked:
<snip>
> the access database, and being rejected based on something found, or not
</snip>

<sigh>
We are having this discussion because I assert that the introduction of a
forgery test IS fundamentally new.
</sigh>

In accordance with the process defined by the Chairs I am explaining _my_
inability to deploy Sender-ID.

Some have attempted to show me that the technical basis for my concern is
unfounded. That is a really valuable process to go through - but so far no one
has convinced me that I have misunderstood the technical situation.

Using Sender-ID you can achieve a state where the authority who was purported to
be responsible for a message can tell you categorically "That message is a
forgery."

You then proceed to cause a bounce to be sent to a recipient defined in a
message you _know_ to have been repudiated.

"Why", the courts may well ask, "did you send a message, known to you to be
forged and potentially carrying malicious content, to this innocent child?"

See the early parts of the thread for the potential consequences of this totally
new situation.

Ignore the uninvited forays into the peculiarities of English law - they are
irrelevant to this thread.

The conclusions on potential legal consequences are necessarily mine and mine
alone.

Chris

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Aug 2004 12:47:41 +0200

On Wed, Aug 25, 2004 at 10:29:06AM +0100,
 Chris Haynes <[email-masked]> wrote 
 a message of 48 lines which said:

> We are having this discussion because I assert that the introduction
> of a forgery test IS fundamentally new.

Introduction of a *standard* forgery test is new. But people have been
testing incoming SMTP clients or incoming SMTP transactions or
incoming email messages for years. 

Often, these tests are quite ill-advised (refusing mail from machines
without a PTR, for instance). But they exist and the bounces generated
by these tests have never created legal problems.

> "Why", the courts may well ask, "did you send a message, known to
> you to be forged and potentially carrying malicious content, to this
> innocent child?"

You did not send it. The MTA just before you did and it was the faulty
one, for having *not* performed SenderID tests. To me, this is the
most important thing against your idea: you do not send the bounce,
someone else does.
 
Yes, your action (refusing the mail with 5xx) was indirectly the cause
of the bounce. But (IANAL) I do not think it can be regarded as a
liability.

---

From: Graham Murray <[email-masked]>
Date: Wed, 25 Aug 2004 12:48:51 +0100

> of the bounce. But (IANAL) I do not think it can be regarded as a

But what would be completely unacceptable would be for the SMTP
transaction to accept a mail, perform (either at SMTP time or
subsequently) Sender-ID (or SPF, Domainkeys, or other) checks which
show the mail to be a forgery and then send a bounce (to the known
forged address) for any reason. I believe that, unfortunately, some
MTAs do accept all emails and only subsequently check that the
recipient mailbox is valid, not over quota, that the email does not
contain a virus etc, and send a bounce if these checks fail. The
operators of such MTAs might find themselves with more legal liability
if they generate bounces to addresses which Sender-ID etc show to be
forgeries.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Aug 2004 14:24:58 +0200

On Wed, Aug 25, 2004 at 12:48:51PM +0100,
 Graham Murray <[email-masked]> wrote 
 a message of 23 lines which said:

> forged address) for any reason.

I agree. It would be completely unacceptable. Almost every anti-virus
server software in use does it, nevertheless :-)

> I believe that, unfortunately, some MTAs do accept all emails and
> only subsequently check that the recipient mailbox is valid,

Postfix does it by default. Also, every MTA does it if you have a
front-end MTA in the DMZ which accepts everything before giving it to
the "real" MTA. So, these "late bounces" are a fact of life and we
have to live with it.

Giving the amount of bounces I already receive for mail which I've
never sent (and this is before Sender-ID deployment), I have little
sympathy for Chris Haynes' concerns.

---

From: Mark <[email-masked]>
Date: Wed, 25 Aug 2004 12:58:16 GMT

Chris Haynes wrote:

>> I am coming out of delurk for a moment. But could someone please
>> explain why we are having this discussion? I mean, rejecting with a
>> 5.x SMTP error code, based on whatever criteria, creates neither
>> less, nor more liability, than doing so, also for whatever reasons,
>> has done for the last few decades. There is, from the perspective of
>> the sender at SMTP level, nothing fundamentally different between,
>> say, being rejected based on an entry in the access database, and
>> being rejected based on something found, or not found, in the
>> headers.
>
> In accordance with the process defined by the Chairs I am explaining
> _my_ inability to deploy Sender-ID.

And I respect your objections. I just have a series of my own. :)

> You then proceed to cause a bounce to be sent to a recipient defined
> in a message you _know_ to have been repudiated.

But I do *not* cause a message to be sent. I reject a connection. As Jim
astutely pointed out, if others see fit to take my rejection and create some
sort of bounce, what is it to me? I am certainly not the one having sent any
message; nor the one having *caused* to be sent anything. Like I said, all I
do is reject a connection.

> "Why", the courts may well ask, "did you send a message, known to you
> to be forged and potentially carrying malicious content, to this
> innocent child?"

"But, Your Honor, I did *not* send a message. To up You even one, I caused
the immediate and unconditional abortion of the transmission of said
message, the moment I became aware of it being a forgery. Would Your Honor
rather have I had accepted the message, only to find myself in Your
illustrious Court, next month, for having aided and abetted in the
transmission of said forgery, whilst I had been made aware of its fraudulent
nature? Surely not!"

When a domain owner publishes a "-all" SPF-record, and a connecting host
falls within that category, then the domain owner is effectively instructing
me as follows: "I have not authorized IP address such-and-such to send mail
on behalf of me; please, treat the message as a forgery, and reject the
connection." Have you thought about the legal ramifications of ignoring that
instruction? If the entity in question is a large financial institution, for
instance, and I had been explicitely told, via DNS, that a message in their
name was a forgery, then I believe my safest legal bet consists of honoring
the domain holder's request to reject the message; or rather, not to deliver
it. Which leaves me DISCARD.

There *is* a technical reason against discarding a message, however. Quite
simply, it makes SUBMITTER useless. Because when you DISCARD a message, you
have to wait out the entire transmission, past the DATA phase, only to
pretend you accepted it, while discarding it silently.

See, the problem, IMHO, is not me *causing* a bounce to be generated on the
connecting host, but the connecting host sending me the forgery! Had the
connecting host checked for forgeries, he would A) not have sent me the
message to begin with; and B) not have bounced to a (possibly) innocent
third party upon my rejection. All of which, really, has nothing to do with
me. I just take *my* responsibility in rejecting the forgery.

YMMV; and, obviously, it does. :)

- Mark

---