Talk:Email authentication: Difference between revisions
imported>David MacQuigg |
imported>David MacQuigg mNo edit summary |
||
Line 4: | Line 4: | ||
There are several authoritative references (RFCs) on authentication methods. There are also Wikipedia articles that may be more readable than the RFCs. In this article, we will try to avoid the "written by committee" style, where every contributor gets to squeeze in a few facts that he considers important. The subtopics on each authentication method will be a better place for more detail. | There are several authoritative references (RFCs) on authentication methods. There are also Wikipedia articles that may be more readable than the RFCs. In this article, we will try to avoid the "written by committee" style, where every contributor gets to squeeze in a few facts that he considers important. The subtopics on each authentication method will be a better place for more detail. | ||
Terminology is a challenge. Should we use the same terms the experts use (MTA, Reverse Path, etc.) or terms that are more meaningful to non-experts (Mail Relay, Return Address, etc.)? We have chosen the latter, because our articles are intended for non-experts. Experts will have no trouble understanding what we mean, as long as we avoid mis-using any of their special terminology. We will capitalize terms that we intend to have a special meaning (e.g. | Terminology is a challenge. Should we use the same terms the experts use (MTA, Reverse Path, etc.) or terms that are more meaningful to non-experts (Mail Relay, Return Address, etc.)? We have chosen the latter, because our articles are intended for non-experts. Experts will have no trouble understanding what we mean, as long as we avoid mis-using any of their special terminology. We will capitalize terms that we intend to have a special meaning (e.g. Transmitter). | ||
--[[User:David MacQuigg|David MacQuigg]] 08:04, 3 February 2010 (UTC) | |||
=== Planned Additional Subtopics === | === Planned Additional Subtopics === |
Revision as of 02:05, 3 February 2010
The challenge in this article is to introduce a subtopic that has a huge amount of detail without overwhelming the non-expert reader. We can do that by keeping the focus narrow, relying on a parent topic to establish a conceptual framework and terminology for the discussion, and subtopics to offload much of the detail. In this article we will include just those details that are needed for a coherent presentation of the topic, or that are interesting enough to outweigh the burden of including them.
There are several authoritative references (RFCs) on authentication methods. There are also Wikipedia articles that may be more readable than the RFCs. In this article, we will try to avoid the "written by committee" style, where every contributor gets to squeeze in a few facts that he considers important. The subtopics on each authentication method will be a better place for more detail.
Terminology is a challenge. Should we use the same terms the experts use (MTA, Reverse Path, etc.) or terms that are more meaningful to non-experts (Mail Relay, Return Address, etc.)? We have chosen the latter, because our articles are intended for non-experts. Experts will have no trouble understanding what we mean, as long as we avoid mis-using any of their special terminology. We will capitalize terms that we intend to have a special meaning (e.g. Transmitter). --David MacQuigg 08:04, 3 February 2010 (UTC)
Planned Additional Subtopics
SPF SenderID DKIM CSV
Information security
You might want to look at the information security article and be sure that your bullet definitions in the introduction are consistent and linked. This doesn't mean that you can't edit information security: indeed delay, a subset of inadequate but not nonexistent performance, probably should be there. (D)DoS is a set of attack techniques rather than a type of security threat. Howard C. Berkowitz 15:18, 23 October 2009 (UTC)
- Good points. I've changed the wording to emphasize that we really mean security issues, not malfunction or reliability problems. In a security context, we always have an opponent. We look at delays not as a problem with network performance, but rather as a possible way to mislead an opponent, e.g. a delay in news affecting a stock price, while the bad guys place their orders first. DoS might be considered a special kind of delay. It should be included in timeliness. I've changed the wording to include blocking or delaying messages.
- Seems that every text has a different way to list the requirements for secure communications. The perfect schema is the one that covers all possible threats with simple, non-overlapping categories. Such a schema does not exist, because there are always overlaps. If you have authentication (you know the message came from Alice), then you have to have some degree of verification. If the message has been altered, what does it mean to say that it came from Alice.
- "Concealment" is the term used in Shannon's schema (1949 paper on secrecy systems). This does seem to better convey what we really mean on this aspect of security.
- --David MacQuigg 07:26, 3 February 2010 (UTC)