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

From: "Jim Lyon" <[email-masked]>
Date: Tue, 24 Aug 2004 16:32:04 -0700

John cites a whole slew of previous messages, which by the time you
strip out the irrelevant stuff appear to raise the following question:
Given how easy it would be for a forger to insert a Resent-From header
(for example), shouldn't we have some sort of stronger check?

John, I think you should raise the issue in a separate thread.
Conflating this with a thread that has already visited issues like
whether British law allows conviction of non-humans does not seem like a
good thing.

-- Jim Lyon

---

From: "John Glube" <[email-masked]>
Date: Wed, 25 Aug 2004 01:51:16 -0400

It is very easy to forge domain information in email.

Two simple cases:

* Forging the SMTP mail from address; and

* Inserting a false received line or resent-from header. 

In essence this involves using someone else's domain without
consent.

Also, many who forge domain information also apparently send
direct from an IP address to the recipient's mail server.

Shouldn't we have stronger checks to prevent these types of
activities?

One approach is to run a mail from check at the data stage using
the SPF record format and test protocol.

Another is to run an ehelo or helo check using client smtp
validation.

Keep in mind those engaged in email forgery (which for
sophisticated operators is a form of criminal fraud) will likely
adopt approaches to muddy and defeat authentication, so that
those engaged in fighting email forgery will need to use a range
of tools, recognizing that although one data set might be
corrupted, matching of data against a number of identifiers will
likely generate better results.

(I am basing these general comments on existing research and
studies carried out by others in the criminal forensics field.)

Amending the Sender-ID drafts to reflect using a number of
data sets is one option. 

My personal recommendation is that a best current practices
document be published concurrently with any authentication
technologies recommended by this WG which would in essence
recommend receivers run PRA checks using Sender-ID:
Authenticating Email, mail from checks using the SPF record
format and test protocol and ehelo/helo checks using client
smtp validation.

It may also be appropriate to establish a steering group to
review and propose document updates on a regular basis, although
there may be other ad hoc groups which could include this process
within their mandate.

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: "John Glube" <[email-masked]>
Date: Wed, 25 Aug 2004 10:17:48 -0400

This is a follow up to my earlier message on the same
subject.

I have re-framed the content in the specific manner
requested by the WG chairs in their message with the
subject line:

>Working Group Last Call on Sender ID Documents

This is done in the event my earlier message was not in
compliance. Please read the two together. I regret any
inconvenience this may cause.

1. It is generally understood that:

>a huge majority of unwanted email contains headers that lie
>about the origin of the mail.  This is true of most spam
>and substantially all of the virus email that is sent.

The Sender-ID documents set describes a mechanism allowing:

>receiving MTAs, MDAs and/or MUAs to recognize mail in the
>above category and take appropriate action.  For example,
>an MTA might refuse to accept a message, an MDA might
>discard a message rather than placing it into a mailbox,
>and an MUA might render that message in some distinctive
>fashion.

In both cases, I am quoting from Sender ID: Authenticating
Email.

The mechanism is to extract the purported responsible
address: (i) from the sender address, or re-sent sender
address as supplied at the data stage; or (ii) from the
header information at the transport stage and using the
purported responsible domain's email policy record found in
that domain's DNS file, check to see whether the sending
MTA is authorized to send email for that domain.

2. Domain information may be easily forged in email headers
so potentially corrupting data information. Also, many who
forge domain information also apparently send direct from
an IP address to the recipient's mail server. 

The authors of the SMTP Responsible Submitter Extension
document acknowledge these problems as follows:

>Verifying MTAs are strongly urged to validate the SUBMITTER
>parameter against the RFC 2822 headers; otherwise, an
>attacker can trivially defeat the algorithm.

It is suggested that we have stronger checks to allow for
more substantive testing without sole reliance on parsing
the RFC 2822 headers. 

This can be done by also:

* running a mail from check using the SPF record format and
test protocol; and,

* running an ehelo or helo check using client smtp
validation;

concurrently with the appropriate checks called for under
the Sender-ID documents.

The purpose of these necessary features recognizes that
although one data set might be corrupted or absent,
matching of data against a number of identifiers will
likely generate better results.

It allows receiving mail transfer agents to conduct more
rigorous testing, reducing the risk of trivial attacks
defeating Sender-ID at the data stage, without the need for
heavy reliance on parsing header information. 

3. This can be achieved through publishing a best current
practices document concurrently with the Sender-ID set of
documents, should this working group decide to recommend
the Sender-ID documents set for approval as an RFC.

This document can in essence recommend receiving MTAs run:

* purported responsible domain checks when the submitter
extension is available in accordance with the schemes
outlined in the Sender-ID documents set; 

* mail from checks using the SPF record format and test
protocol; and 

* ehelo/helo checks using client smtp validation.

The result? It would:

* strengthen the goal of allowing receiving MTAs to
properly recognize unwanted email with headers that lie
about the mail's origin, while reducing false positives.
This allows for rejecting of messages with stronger
confidence along with the appropriate rejection notice. 

The later ensures complying with the requirement imposed on
all parts carrying out the simple mail transfer protocol as
found in section 2.1 of RFC 2821:

>.. message transfer can occur in a single connection
>between the original SMTP-sender and the final
>SMTP-recipient, or can occur in a series of hops through
>intermediary systems.  In either case, a formal handoff of
>responsibility for the message occurs: the protocol
>requires that a server accept responsibility for either
>delivering a message or properly reporting the failure to
>do so.

(As an aside also see the concerns raised by Chris Haynes
concerning this issue in the following message:

http://www.imc.org/ietf-mxcomp/mail-archive/msg03601.html)

* reduce the suggested likelihood of MDAs deciding to
discard messages, or users of MUAs sorting through
distinctively marked unwanted email.

I also reiterate the material referenced in my message
found at:

http://www.imc.org/ietf-mxcomp/mail-archive/msg03582.html

I add for the reader's benefit, although the original
message and this follow up are found in the thread dealing
with the subject DEPLOY: Legal liability for creating
bounces from forged messages my concern is not with the IPR
notice filed by Microsoft, the license form or the FAQ.

As previously stated, although I was one of the individuals
raising concerns about the IPR notice and license form as
originally filed with the Caller-ID draft, the material
filed and documents distributed has satisfied my personal
concerns.

It appears to me at least the material provided is a
genuine response to the concerns of many in the open source
community.

I appreciate others disagree with my personal views on
this point. 

For those who have views on the IPR and license claims,
avoid my error. The preference is not to combine issues.
Send messages on the IPR and license claims with DEPLOY in
the subject line and keep in mind the guidance of the WG
chairs.

John Glube
Toronto, Canada

---