Talk:Email system/Draft: Difference between revisions
imported>Howard C. Berkowitz (→Progressing the article: new section) |
imported>David MacQuigg m (added Message Submission (RFC-4409) as a transfer protocol) |
||
Line 13: | Line 13: | ||
SMTP (RFC-5321) | SMTP (RFC-5321) | ||
POP (RFC-1939) | POP (RFC-1939) | ||
IMAP (RFC-3501) | IMAP (RFC-3501) | ||
Submission (RFC-4409) port 587 | |||
Message Formats (RFC-5322) | Message Formats (RFC-5322) | ||
Multipurpose Internet Mail Extensions (RFC-2045..2049) | Multipurpose Internet Mail Extensions (RFC-2045..2049) |
Revision as of 20:59, 18 May 2009
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 <nowiki>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. ~~~~