John points out that a forger can defeat SenderID checks by inserting a
Resent-From (or similar) header that references either himself a domain
that hasn't published a SenderID record.
He goes on to suggest possible ameliorations, including EHLO checks
and/or classic SPF checks using MAIL-FROM.
He's right that there's a potential problem, but I think he got the
wrong amelioration.
If there's consensus that a change is required, I would recommend:
Whenever the PRA is not equal to the 2822 "From", and the SenderID
result is anything other than "pass", and at least 6 months have elapsed
since SenderID became a Proposed Standard, then the message SHOULD be
treated as forged.
Reasons for this proposal:
1. For most instances of personal mail, PRA == 2822 From == bounce
address, and none of these issues apply. They only apply in the cases
of specialized agents like forwarders, list servers, third-party mailers
and similar.
2. It's reasonable to hold specialized agents to a higher standard than
the rest of the E/Mail community (by requiring a "pass" instead of
merely the absence of a "fail", for instance.)
3. When the set of documents hits Proposed Standard, many of the
legitimate specialized agents won't yet be in compliance. But as a
whole, it's a well-managed community that can move fairly quickly.
Reasons against EHLO or bounce address:
1. EHLO tells you a name for the sending MTA. But it gives you no idea
whether that MTA is authorized to act on behalf of the name mentioned in
the message he's sending. It seems therefore to be irrelevant.
2. bounce address tells you who wants to know if the message isn't
delivered. It's also irrelevant when deciding whether the MTA is
authorized to act of behalf of the name mentioned in the message he's
sending.
-- Jim Lyon
mailto:JimLyon(_at_)Microsoft(_dot_)Com
tel:+1-425-706-0867
Internet commerce will never really take off until you can buy something
online without getting spammed by the vendor.
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of John Glube
Sent: Tuesday, August 24, 2004 10:51 PM
To: 'IETF MARID WG'
Subject: TECH OMISSION: Stronger checks against email forgery
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