Talk:Email authentication

message: 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. 
** 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)
thread_title:  Beginning some encyclopedia style here 

message: 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
Please rewrite most of the article in English and define MTA etc. 
Also, please define what the political controversy is...195.38.17.129 (talk) 10:03, 12 March 2009 (UTC)
thread_title:  Author Bowing Out 

message: 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)
replies: text: 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)

text: 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)
thread_title:  FUD about SPF and CSV 

message: 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)
replies: text: 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)

text: 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)
thread_title:  >>> 

message: 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)
replies: text: I am surprised as the article as you said talks more about Spam prevention and less about email authentication. also the article nowhere speaks about phishing Kalivd (talk) 14:57, 7 June 2008 (UTC)
thread_title:  Spam 

message: The second part of this quote is rather "unencyclopedic", fighting backscatter is the main goal of SPF, and if say Google or Hotmail have no FAIL-policy that's their decision. Receivers are free to treat NEUTRAL mails from these sources as "bad enough". No e-mail authentication scheme can be made mandatory, they are voluntary. SPF has that little twist to offer spammers an incentive to stay away from forging FAIL-protected addresses, as long as there are enough unprotected addresses. Remove this section, trim it to the first part, or leave it alone? --212.82.251.44 (talk) 13:22, 23 July 2008 (UTC)
thread_title:  Controversy 

message: This page should mention the existence of the Authentication-Results header fields, RFC 5451, and cover each method defined there. That's about as rewriting the whole page, but it can be done step by step.  I'm late now, but I'll start that on my next occasion...
More methods, such as Vouch by Reference or PGP signatures, that are not (yet) defined in Email Authentication Parameters can also be mentioned, of course.
ale (talk) 16:33, 27 October 2010 (UTC)
thread_title:  Authentication-Results 

message: Iconix eMail ID, are there others ? -I guess they are not being mentioned to prevent promotion of software, but should the existance of browser addons etc be mentioned, or is this article too technical for most email users?? 79.66.216.62 (talk) 10:29, 8 February 2011 (UTC)
thread_title:  Iconix eMail ID 

message: ECS works by sending mail content independently of the mail envelope. A content server, which exists outside of the mail network, manages content and returns pointers to the content to the mail client which the client inserts into the envelope. In the implementations used by the company ChiaraMail, senders must authenticate prior to sending an ECS message and the content server enforces this. Thus, when spoofing an e-mail address, the spoofer must know the content server password of the user it is spoofing in  order to send an e-mail using ECS.  — Preceding unsigned comment added by Robert Uomini (talk • contribs) 22:18, 16 October 2012 (UTC)
thread_title:  Using Envelope-Content Splitting (ECS) technology to prevent e-mail address spoofing 

message: I saw there's been little change since JD's tagging on 22 September 2010. It called for much more cleanup than the above #Beginning some encyclopedia style here.  Rather than rewording paragraph by paragraph, I've actually rewritten the beginning of the article, copying any content that I found relevant from existing sections, but sticking to the topic of Email authentication.  The most important task is to give a view of how email gets authenticated, possibly sketching what advantages that can bring about.  That has to be accomplished in such a way that a casual reader can grasp it even with minimal technical skills, while an expert can read it without disappointment.
Next, I will remove those old sections, numbered 4-8 and 10 in the current version.  Reasons are as follows:
* Sender's IP verification: The basic content is explained in the added sections.  Deeper explanation of phishing is off topic.
* Blacklisting:  This has nothing to do with email authentication.
* Controlling users:  This has little to do with email authentication.  Blocking port 25 can be seen as an invitation to users to configure their MUAs properly, so that authentication can take place —which was noted in an added section.
* Authenticating senders:  This is the core of the topic, and I believe it is explained more clearly in the added sections.
* Difficulties with email forwarding:  One point that will be missed is that email forwarders (or are they called forwarding services? Hm... someone proposes mediators) are crucial for the portability of email addresses.  Other parts are covered in the added sections.  The rest is so technical and confused that it looks like original research.
ale (talk) 17:38, 18 February 2013 (UTC)
thread_title:  More encyclopedic tone and content 

message: I've moved the less/never used items into their own heading. There have been a truckload of proposals over the last 20 years, but I believe that it's important to readers of this article to be able to differentiate between those that are actually in widespread use, and others that are not - whether because they failed or that they've not yet gained traction. - Snori (talk) 02:43, 24 November 2018 (UTC)
thread_title: "Widespread use"