Talk:Email processes and protocols

From Citizendium
Jump to navigation Jump to search
This article is developing and not approved.
Main Article
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
To learn how to update the categories for this article, see here. To update categories, edit the metadata template.
 Definition Brief explanation of an email system at the relay level. [d] [e]
Checklist and Archives
 Workgroup category computers [Editors asked to check categories]
 Talk Archive none  English language variant American English

Note: Much of this article has now been moved to "Email processes and protocols", another subtopic of "Email system". It's still worth keeping for the example telnet session and its step-by-step explanation. We may want to rename the article, something like "Example SMTP session". --David MacQuigg 22:34, 12 August 2009 (UTC)

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. We will include just those details that are needed for a coherent presentation of this topic, or that are interesting enough to outweigh the burden of including them.

Luckily, we have an authoritative reference (RFC-5321) which covers all the details of SMTP in 94 pages. There is also a Wikipedia article on SMTP, which has a lot of facts and might be more readable than the RFC. 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.

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. Relay instead of relay).

Possible Additional Subtopics

  ESMTP - RFC-5321
  Port 587 - RFC-4409
  Reply Codes
    550, 450 - greylisting

Titles: names versus abbreviations

In the R-templates, I wouldn't pipe things like Simple Mail Transfer Protocol to SMTP. With rare exceptions, it's general CZ style to avoid abbreviations as article titles. While the article title is not supposed to be repeated in the Definition, it seems OK to me (might get other opinions) to put the abbreviation into the definition, with the specific point of getting it to appear with R templates. Howard C. Berkowitz 02:36, 25 November 2008 (UTC)

I like this suggestion, and I will make the changes in all the articles of this group. There are a few acronyms, however, that don't have a meaningful full name (e.g. reverse acronyms, where a programmer worked a little too hard to come up with words to fit his clever acronym). That might include the authentication methods SPF, and DKIM. DKIM was a political compromise between DK and IM. One can only guess how DK got the top billing. :>) David MacQuigg 20:26, 25 November 2008 (UTC)
It's a common sense rule. For example, over on the military side, I did title an article MACV-SOG, because the unclassified expansion was Studies and Observation Group while the then-classified one was Special Operations Group. Howard C. Berkowitz 20:58, 25 November 2008 (UTC)