William,
Thanks for your very helpful suggestions. You are right about the
unintended implication that "path authentication" was the only way to
authenticate an email. I had to re-read the whole page to see what you
did, but now it is obvious.
Such as it is, because I do not see any way to create general email
authentication information based on current text (except the first
couple paragraphs), I strongly recommend renaming that page into
Email_Path_Authentication and clearly indicate that it describes only
one type of email authentication. Note that references to DomainKeys
should then be removed as its not supposed to be path authentication
Rather than re-title and cut the scope, I think I can just add a paragraph
and some links to pages on the cryptographic methods. There won't be room
to cover these in depth, but there are already Wikipedia pages on the two
you mentioned - PGP, and S/MIME.
Here are the first three paragraphs of the section Authenticating
Senders. The new paragraph is the second one:
There are a number of ways to authenticate a sender's domain name (
SPF<http://spf.pobox.com>[2],
SenderID<http://www.microsoft.com/mscorp/twc/privacy/spam/senderid/default.mspx>[3],
DomainKeys<http://antispam.yahoo.com/domainkeys>[4] ). All are nearly 100%
effective in stopping the kind of forgery now prevalent. None exclude the
use of other methods. The most widely used will likely be the ones that
require the least effort on the part of ISPs and others currently operating
public mail servers.
SPF and SenderID authenticate just the domain name. DomainKeys uses a
digital signature to authenticate the domain name and the entire content of
a message. This requires more computation, but may be necessary in
high-security situations. Similar cryptographic techniques include PGP
http://en.wikipedia.org/wiki/Pgp and S/MIME
http://en.wikipedia.org/wiki/S/MIME.
SPF and SenderID work by tying a temporary IP address to a relatively
permanent and reputable domain name. Every incoming email has an IP address
that cannot be forged {1}, a bunch of domain names in the email headers,
and a few more in the commands from the sender's SMTP server. The methods
differ in which of these names to use as the sender's domain name. All of
them can be faked, but what cannot be faked is a domain name held by a DNS
server for that section of the Internet {2}.
Also I have serious problem with you including on that page
Resent-From: [<IP Address>] <sender> VERIFIED
You simply can not reinvent new syntax or use of existing and actively used
header and Resent-From is defined as standard by RFC821, RFC2821, RFC2822
Good point. It wasn't my intention to propose changing an existing
header. For illustrative purposes, I'll invent a whole new header:
Authenticate: SPF1 [<IP Address>] <senders-domain> PASS
This should make sense to a non-expert, while not making the experts
uncomfortable.
-- Dave
At 07:13 PM 2/18/2005 -0800, William Leibzon wrote:
On Fri, 18 Feb 2005, David MacQuigg wrote:
> See http://en.wikipedia.org/wiki/Email_Authentication for a more complete
> description.
I've read through it and I do not agree with some of that is written there.
While I understand that this wikipedia page is designed for general person
and not an email tech, it may have oversimplified the infrastracture that
is more complex and as such it may not pain an accurate picture for person
not familiar with email authentication and email security, besides that
some of the details are also not right.
First lets note that what is described is what many now call path
authentication, but that is not the same as general email authentication.
For path authentication each email node tries to authenticate immediately
proceeding node and in order to establish authentication from sender to
recipient it is necessary to establish authenticated chain of trust which
means each node must have verified the previous one and furthermore that
each node trusts the information provided by proceeding one about
previous authentication done.
But general email authentication includes other available mechanisms such
as cryptography. Cryptography works completely different and instead
of trying to authentication previous source it tries to verify cryptographic
data included by that previous source in email message. That is how S/MIME
and PGP work (and how DomainKeys, IIM and Meta Signatures propose to do
similar things, but they instead focus on MTA adding signatures where as
S/MIME and PGP are primarily intended for MUAs), both S/MIME and PGP are
common and used authentication methods and there is no mention about it.
Such as it is, because I do not see any way to create general email
authentication information based on current text (except the first
couple paragraphs), I strongly recommend renaming that page into
Email_Path_Authentication and clearly indicate that it describes only
one type of email authentication. Note that references to DomainKeys
should then be removed as its not supposed to be path authentication
(although because of inability to deal with too many forwarding/redirection
systems if it is used, it will end up being used in similar way, buts its
entirely different problem and not to be discussed on that page).
Also I have serious problem with you including on that page
Resent-From: [<IP Address>] <sender> VERIFIED
You simply can not reinvent new syntax or use of existing and actively used
header and Resent-From is defined as standard by RFC821, RFC2821, RFC2822
and it has only one argument - email address and header itself is used
by MUAs that resend existing piece of email to new address. If you want
a reference to existing header to indicate results authentication, please
use SPF-Received header or Authentication-Results header with references
to appropriate drafts.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com