Talk:E-mail authentication
From Wikipedia, the free encyclopedia
Contents |
[edit] Older comments
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 infrastruĊcture that is more complex and as such it may not paint 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
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 of 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 authentication such as those done at MUA (email clients)
(3) In regards to MTA email authentication none of the 3 methods you chose to focus (SPF, SID, DomainKeys) are yet widely deployed and these proposals have been in existence often < 1 year, where as MUA email authentication methods such as S/MIME and PGP have in fact years of deployment and standardization 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 guessing 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 opinion 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 encourage author to do further research about internet security, message security and get more familiar 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]
"Attempts to stop spam by blacklisting sender's IP addresses have failed to reverse the worldwide growth. " is not correct. AOL's use of blacklists has reduced spam delivery attempts to their network by about 50%, and reduced the spam received much more. I'm trying to fix this.
[edit] Beginning some encyclopedia style here
I've started some basic clean-up here -- fixing the page title and headers to match the Wikipedia style guide, for one.
There's a lot of work that needs doing, though, some with form and some with content:
- Markup style. There is excessive use of boldface throughout, and lack of use of italics to indicate defined terms, domain names, and so forth.
- Footnotes. The footnotes are currently pieces of dumb text, not wiki markup or hypertext.
- Tone. Encyclopedias do not address the reader as "you", and do not use a chatty or conversational style of writing.
- Confusion of issues:
- Spam is not the same as forged email. There is plenty of spam sent that is not forged; for instance, the spam for Gevalia coffee over which Kraft Foods is presently facing a lawsuit. [2]
- Forged email is not the same as email sent through a server other than the sender address's domain. This is partially addressed in the section on email forwarding; but there are many cases where legitimate persons who have (a) legitimate use of a mail server and (b) legitimate use of an email address for a different domain, might wish to send mail from that address through that server. --FOo 02:03, 19 May 2005 (UTC)
[edit] Author Bowing Out
I disagree with some of the edits since my last participation. I was hoping to avoid the political controversy around this topic, but I can see that will not be possible. Rather than get into an edit war, I think we should go our separate ways. I'll keep my version at http://purl.net/macquigg/email
You are welcome to copy my subsequent edits, and I will copy what I like of the edits I see here. -- macquigg
[edit] FUD about SPF and CSV
Again the same horror story as in DomainKeys, where I trimmed it to a pointer to this article. Now added again here, and I reverted it. It is untrue that Sender ID's PRA is in any way better suited than SPF's Return-Path MAIL FROM to fight replay attacks against DKIM.
The SenderID PRA is not necessarily related to anything DomainKeys does, exactly like the Return-Path is not necessarily related to anything DKIM does. Besides the theoretical worst case of 112 DNS lookups requires ten mx-mechanisms, each with ten MXs (Mail eXchangers), a completely unrealistic case.
One huge ISP with twenty million customers has in fact eight MXs. So a sender policy with 80 lookups (SPF or SenderID) would directly permit the MXs of ten similar ISPs. Who is customer of ten huge ISPs, all of them organizing their MXs in such a strange way?
With the recommended way to include the sender policies of ISPs where available the worst case would be five include-mechanisms each with one mx-mechanism staying within the limit of ten mechanisms. And if the 5*1 included ISPs all in fact have eight MXs the result is 2+5+5*8 = 47 theoretical lookups.
But in practice a query for MX often gets the relevant IPs in the additional answer section. DNS tries to be cute, it's clear what you'd ask next after an MX-query, if you don't know the IPs. So in practice you might need only 2+5+5 = 12 queries for this unrealistic case.
It's also FUD to mention the worst case only for SPF but not for CSV. It's FUD to mention the almost unknown CSV without the much wider deployed SPF HELO. Admittedly CSV is smarter than SPF HELO, but in essence, for the issue at hand, get PASS for whitelisted neighbour, they are almost equivalent.
A typical SPF HELO policy is v=spf1 a -all with exactly three lookups: TXT query, SPF query, A query. And that will be very fast as soon as it is cached. No idea about the CSV details, so I grant that it's probably better than three in the typical case relevant here for HELO and DKIM replay attacks.
This is an overview article. It is not your DKIM options draft, and it is also not the place to rehash your issues with the next DKIM-threats-draft, for that we have an IETF WG. Here's Wikipedia, it tries to be an encyclopedia, it has some ideas about WP:NPOV and original research. Stick to the facts, and don't twist them into FUD. Omniplex 06:49, 22 February 2006 (UTC)
[edit] >>>
Omni, I appreciate your efforts to keep this article on track. I would go even further in limiting the scope and complexity, removing some inappropriate plugs and quibbles over arcane details. Rather than get into an edit war, however, I suggest that anyone who wants to see an alternative presentation, put it on your own website, with a link from this page. I've started the list with my own original article - see Reference {1}. I dont think it is likely the experts will ever agree on what is important in an introductory article. Maybe a second more detailed article could be written, like an extended list of footnotes, that would cover all the details and alternatives anyone would like to present. Dave 19:44, 12 March 2006 (UTC)
- It has now its own Category:E-mail authentication, and essentially I've copied the acronym table from an obscure page on my own site. Omniplex 00:41, 13 March 2006 (UTC)
- Excellent! There is now a place for everything. I would still like to see the main article cut way back, but I think as long as we have a quick link to the "Introductory" version, it doesn't matter if this one is a little heavy. Maybe William could put in a link to his "Heavy" version. Dave 02:35, 14 March 2006 (UTC)
[edit] Legal
Is forgeing email illegal? If so, where? Why does everyone hate Torax2? 01:41, 17 October 2006 (UTC)
- It depends! In the U.S., for instance, it is illegal to send unsolicited commercial email (spam) with forged headers, under the CAN-SPAM Act. But to forge an email for a prank is not illegal, unless some other offense (such as libel) is involved.
- This is, of course, not legal advice. Consult a lawyer if you are planning to forge email and are worried about getting sued, arrested, or deported to Torturestan for it. Forging email may also be against your ISP's terms of service, meaning that you could lose all your internets for it. --FOo 03:41, 17 October 2006 (UTC)
[edit] Spam
I'm highly suspicious that the main focus of this article seems to be on spam prevention. Whilst authentication will help with filtering spam, it is only a tiny part of the whole picture. The main focus of email authentication is security. Personally, I have never encountered the need for encrypting mail (except as part of trust establishment), and I very rarely need to sign my emails (although I do because I can), yet I receive thousands of spam emails per day, and email authentication would not help in 1 case, because they all come through channels that need to be open to all comers. 129.234.4.76 (talk) 01:31, 6 December 2007 (UTC)
