The issue of stronger checks against email forgery has come
up during last call for the Sender-ID drafts.
The discussion originally arose under the thread:
DEPLOY: Legal liability for creating bounces from forged
messages
In response to a message from myself, Jim Lyon wrote:
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.
See the following exchange:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03572.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg03576.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg03582.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg03587.html
I have followed Jim's suggestion by starting a new thread on
the MARID mailing list with the subject heading:
TECH OMISSION: Stronger checks against email forgery
and sent the following message to that list:
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.
Since my suggestion in essence picks up on the theme of
Unified SPF, I am referencing this thread to the
spf-discuss list.
Not being a security or operations expert (although
admittedly I have learned a great deal over the last few
months) it may be beneficial for others to also express
their views on this topic.
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