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.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net