Talk:Email authentication

I've read through it and I do not agree with some of that is written on Email_Authentication page. While I understand that 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 paint an ccurate 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 torecipient it is necessary to establish authenticated chain of trust which means each node must have verified the previous one and furthermore that

But general email authentication includes other available mechanisms such as cryptography. Cryptography works completely different and nstead 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 ouple paragraphs), I strongly recommend renaming that page into mail_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.

Note: Above is slightly modified copy of post made spf-discuss, see http://archives.listbox.com/spf-discuss@v2.listbox.com/200502/0082.html

03/11/2005 William,

I've made some updates to the this article, which I hope will provide a more balanced perspective on the two authentication methodologies.

Of all the available protocols, I referenced the three which seem to be most likely to be widely deployed in the next few years. There are also Category links which will lead to pages on some of the other protocols. We could add a list of links to these other specific pages. I'm concerned about the length of the article if we try to say something about each one.

As for the title, I would like to keep it short, and use the first paragraph to define the scope of the article more precisely - ensuring a valid identity on email. There are already broader topics ( see catagory Authentication Methods ) and narrower topics on individual protocols.

I took out the example header, which was intended only as illustration, not correct and detailed syntax. That also helped keep the article short. I worry that the section is now missing any concrete examples, which is always a problem for non-expert readers, but this occurs *after* we say the section is only about detail, and most readers can skip it.

Thanks again for your expert help.

-- David MacQuigg

The main issues still remain with this article:

(1) It is still too focused on the path authentication (email authentication step-step at each session mainly based on ip address of connecting mail server)

(2) It is almost 100% on MTA (email servers) email authentication where as the article has general title (email authentication) and there exist other methods of email authantication such as those done at MUA (email clients)

(3) In regards to MTA email authetication none of the 3 methods you chose to focus (SPF, SID, DomainKeys) are yet widely deployed and these proposals have been in existance often < 1 year, where as MUA email authentication methods such as S/MIME and PGP have in fact years of deployment and standadization behind them. There are also a LOT of controversy that SPF, SID and DomainKeys in their current form are not a good solution and break email system, there is no guarantee that all 3 or in fact that any of them will still be out 10 years from now (and trying to guess as you do is not a good idea - not for encyclopedia article anyway). It is also notable that in addition to those 3 proposals at least 6-10 others have been published in the same area that are also being worked on by various groups including IETF, and none has received an unconditional support of the email community

(4) In regards to 2 and 3 it seems that the article is biased and maybe trying to provide marketing support to those particular 3 proposals which are not yet even deployed widely enough in email system and not IETF approved standards. But this is wikipedia and its supposed to have only non-biased articles on the issue and issues that are well known and no gussing for the future (although historical documentation is possible and in fact wikipedia is great as historic references). I would also note that this is in fact a LIVE system and if there are any changes in email system and email authentication the article can always be changed (and I expect it will), so trying to guess the future here is bad idea, when such future comes so would wikipedia and this article evolve with it

In my opninion the only way to resolve all those issues without loosing current content (much of it is good and I praise the author of the article for it) is to move majority of the article into its own article focused on path authentication and expand it to include information on RMX, DMP and several other methods (they are together called LMAP) and then move to SPF and provide information on it as current most used system in path authentication. A new much shorter article should be written on email authentication in general that would include general information on what email security is and short paragraphs on several email authentication categories and links to specific articles for each category.

Also I would encorage author to do further research about internet security, message security and get more familar with various aspects, protocols and issues as well as familiarize more with terms used. For terms, I've actually created a glossary that might be of interest, its copy can be found at [1]