Talk:Email system/Draft

This article is intended to be the most basic on how the Internet email system works (as opposed to history, applications of email, etc.) Our target audience includes non-technical professionals such as lawyers and administrators who make policy involving email systems. We will defer to subtopics details such as message formats and transfer protocols. Topics relating to email security are also proper subtopics, because it is much easier to discuss email security once you understand how the system works. Email abuse (spam, phishing, etc.) is a related topic, because it does not expand on or depend on this article.

Here is our current thinking on how this hierarchy of topics should be developed:

Email System
 Parents
   Computers > Networks > Applications > Email
                        > Internet > Email
 Subtopics
   Message Transfer
     SMTP           (RFC-5321)
     POP            (RFC-1939)
     IMAP           (RFC-3501)
     Submission     (RFC-4409)  port 587 
   Message Formats  (RFC-5322)
     Multipurpose Internet Mail Extensions (RFC-2045..2049)
     Message Headers (RFC-5322)
   Authentication Methods
     SPF
     SenderID
     DKIM
     CSV
     
 Other
   TCP
   DNS
   PGP
   Kerberos
   History
   Abuse
   Email User Programs (Webmail)

Progressing the article

First, I'm sorry; I think I missed the retitling.

From a procedural standpoint, I'm going to make suggestions on the talk page rather than directly edit them into the article. By doing so, I will be able, eventually, to Approve it on my own. If I made substantial changes, we'd need several Computers editors to approve.

Let's begin with the "lede". Right now, it's a bit too narrative and outside the CZ opening paragraph convention. An opening sentence, unless it just won't work gramatically, should restate the title in bold and explain briefly what the term means. Material about the purpose and context follows, but isn't the role of the first sentence.

I'd avoid just saying "see textbooks" in the introduction. Very short definitions in the opening paragraphs can be appropriate, and then use wikilinks, Related Pages, Bibliography, and External Links.

Since I know you are using "Actor" as a term of art, a brief explanation would help.

Next, start a subhead for "Architecture".

You have a lot of terms with external footnote definition, such as Transmitter, Relays, MDA (not defined except in the graphic; do think of the reader using text-to-speech), etc. External references, and even footnote definition, are often our last preference.

You can define some as subtopics in the article. For example, I'd define Transmitter and Relay under subheadings, perhaps as second-level subheads, and internally wikilink using a structure such as [[#Relays|Relays]]. Certainly, that subhead can be brief and then, preferably, link to at least a stub article, where the external references can be heavier. I personally dislike having much beyond citations and abbreviation expansions in footnotes; if an explanation, as for Relay, is important, it should be in the main article.

"Let's follow a message from start to finish." should form yet another top-level section, with appropriate subheads for readability.

Consider a section introducing administration, error handling, and defense, again that primarily links to other articles.

Rev. 2

I've posted the second revision of this article at User:David_MacQuigg/Sandbox/Email_System following the suggestions above. Feedback from the editor on the second rev tells me maybe we want to add a few footnotes back in. I'll wait for more on that. --David MacQuigg 01:04, 20 May 2009 (UTC)

Rev. 3

Resynchronizing...should I be looking at the page here or the sandbox?

If the page here, several first comments with a first cup of coffee.

If our goal is to be the best self-contained reference, I wouldn't refer to hard copy texts in the lede, even as introductions. Instead, I'd even redlink to tutorials subpages, or at least link to online presentations.

Good elementary discussions of these topics can also be found in most texts on computer networks.

<ref name=PnD>{{citation | author = L. Peterson, B. Davie | title = Computer Networks: A Systems Approach | edition = 4th | year = 2007 | contribution = Sect. 9.1.1 Electronic Mail}}</ref> And yes, Bruce Davie is good people.

Next, we do have the usual CZ lede conventions, such as bolding the article title, or as close as grammatically possible, in the first sentence. As far as the title, maybe it's me, but I still wince at "email" rather than "electronic mail" as a formal title.

For the layman, however, I do think we need a very basic definition of the problem: passing "envelopes" around a "postal system". I've added a few words. Howard C. Berkowitz 12:59, 6 July 2009 (UTC)

==Email Message Transfer This is a table of definitions that can be worked into a subtopic article that delves into more technical details later on...

Term	Definition
MTA	Mail Transfer Agent; the software on the server side for moving email messages around and forwarding them to other email server hosts
MDA	Mail Delivery Agent; the server that accepts mail for a user from a remote MTA and holds it until the user's mail client (their MUA) downloads the message
MUA	Mail User Agent; a fancy name for an email client such as Mozilla Thunderbird or Microsoft Outlook. Nowadays a MUA can actually reside in a web browser or in a mobile phone as well
SMTP	Simple Mail Transfer Protocol; the protocol used to transfer mail from one mail system to another. Uses port 25 or 587 for unencrypted message transfer.
POP	Post Office Protocol; A protocol where a client connects, downloads mail from the server and then deletes that mail from the server. Mail that is downloaded then "sticks" on the computer the user retrieves their mail from. Contrast with IMAP.
IMAP	Internet Message Access Protocol; IMAP differs from POP in that messages are left on the server; this allows a user to "float" between different clients at different locations but still have access to all their mail