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