Page 2: "3. RFCs are available in plain-text format. They are easy to read online on any type of computer."
Add: They may be available in additional formats (e.g. HTML). 3 TCP/IP Change to: "... the differences ... are negligible..." "... distinguishing between versions except ...." Negligible may be better than small. Use "versions" instead of repeating "IPv4 and IPv6" again. We already know which versions are being compared. 3.1 The Network Layer. The text makes arrival of a packet sound more like a game of chance. IP is not a crap-shoot. Delivery, when possible, does happen more often than not. Instead of "probably arrives" (Figure 1), perhaps "usually arrives" would imply a higher rate of successful delivery. Paragraph 2: The detail of what is an IP address (e.g. how many bits, example IPv4 text representation, etc.) may be unnecessary - or deferred until section 4.1 (DNS). 3.2 The Transport Layer. Technically, there are more than two transport layers. However, it is not necessary to enumerate them. Change this to say, perhaps: "Two transport layers of interest in mail delivery are: TCP and UDP." 3.2.2 TCP isn't working around "IP's unreliability." It's working around "IP's failure to guarentee reliability and ordering of received data." Figure 2: IP addresses may be deleted. They're not necessary for showing what is happening with TCP. Lastly, you reference a "firewall" without defining what one is. Since this is being written for a novice, it should be defined. 4.1 DNS: Delete paragraph starting, "In the old days...." The history lesson adds no real information. At least you can spell separated. ;-) (Not "seperated"). Instead of using your own domain, perhaps "example.com" should be used. This is why the latter exists. Client (should be DNS SERVER?) actions: Add (or renumber 7 as 0): 0. It asks its local name server to see if the answer to the query is already known (i.e. cached). Then renumber. 4.1.2: MX - Simply call the order value "preference." No one calls it "cost." "... same cost, they may be tried in any order; random order preferred." 4.2: Isn't "host" depreciated? Use "dig" instead. 5: Reverse order of paragraphs 2 and 3. Having no authentication should follow the definition. Page 9 example: You should not use local parts that have special meanings. Replace "devnull" with something else. Line 13 - Transmits HEADERS and body. By saying body, novices may not understand the later-made distinction between header and virtual envelope. Leaving this to sections 5.1 and 5.2 on subsequent pages may be confusing. 5.3: Actually, there are FIVE classes of reply codes. You left out the 1xx level. 6.1.2 - Received header. You should NOT include examples of syntactically invalid received headers. 'with Microsoft SMTPSVC' is invalid. 'with "Microsoft SMTPSVC"' is valid. The "with" clause requires an atom (per RFC 5321 and older). Atoms include quoted strings. As "Microsoft SMTPSVC" contains a space, it must be a quoted string to be valid. Similarly with example line 4. These fail to be ABNF syntactically correct. Example line 5 is invalid because the "with" clause shown takes an unknown (i.e. a non-IANA-registered) sub-protocol name. However, that is not fatal to the explanation and is otherwise ABNF syntactically correct. Page 16: Instead of "something like this:", why not copy the exact syntax? You leave out "via" (appears before "with"), "additional_info" is only the "id" clause, and finally, "for" may take forms other than a single recipient. This is to say nothing of which clauses are required when, etc.... _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
