Re: [Mimedefang] Email 101
--- On Tue, 3/16/10, David F. Skoll wrote: > ... > > Page 9 example: You should not use local parts that have special > > meanings. Replace "devnull" with something else. > > What makes you think "devnull" has a special meaning? :-) "devnull" => "/dev/null" = "bit bucket" => non-replyable address. > > 5.3: Actually, there are FIVE classes of reply codes. You left out > > the 1xx level. > > 1xx is not used in base SMTP. I'm also not aware of any ESMTP extensions > that use 1xx reply codes, but I'd be interested in hearing if there are any. Granted, no live examples as they convey an intermediate status. However, to be true to the RFC's and STD 10, there are still 5. > > 6.1.2 - Received header. > > You should NOT include examples of syntactically invalid received headers. > > Those are (slightly edited) examples of Received: headers that I really > did receive. The goal here is to teach novices how to interpret > real-world headers. It isn't to impress upon them the RFC-compliant > syntax of theoretical Received: headers. Just because you have received them doesn't make them valid. ;-) I understand your point, but let's do it with examples that are valid under the given syntax. ___ 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
Re: [Mimedefang] Email 101
D. Stussy wrote: [A number of comments] Thanks for your comments. I'll incorporate some of them. > 4.1.2: MX - Simply call the order value "preference." No one calls it "cost." Yeah, I know. But IMO, "cost" conveys the idea that the higher the number, the less-preferred the MX host. "preference" is confusing. > 4.2: Isn't "host" depreciated? Use "dig" instead. I don't believe host is deprecated, and I prefer its output format to that of dig, especially for the tutorial. > Page 9 example: You should not use local parts that have special > meanings. Replace "devnull" with something else. What makes you think "devnull" has a special meaning? :-) > 5.3: Actually, there are FIVE classes of reply codes. You left out > the 1xx level. 1xx is not used in base SMTP. I'm also not aware of any ESMTP extensions that use 1xx reply codes, but I'd be interested in hearing if there are any. > 6.1.2 - Received header. > You should NOT include examples of syntactically invalid received headers. Those are (slightly edited) examples of Received: headers that I really did receive. The goal here is to teach novices how to interpret real-world headers. It isn't to impress upon them the RFC-compliant syntax of theoretical Received: headers. Regards, David. ___ 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
Re: [Mimedefang] Email 101
--- On Tue, 3/16/10, Ben Kamen wrote: > On 3/16/2010 11:08 AM, Jason Bertoch wrote: > Ooo, and maybe mention (although possibly not a '101' > subject) the TXT record used for things like SPF? (although > maybe no longer relevant) I disagree with this. There was a glancing mention of SPF, and anyone who has PROPERLY implement the DNS side of the anti-forgery technology should have done so using the SPF-RR. The TXT-RR was a TEMPORARY measure until IANA logged and issued its own type (as was done in 2006, granting type 99 for this purpose). This is 2010: All SPF additions to DNS should be done using the SPF-RR ONLY. People have had FOUR YEARS to upgrade their DNS server software to accomodate this the way it was designed. With the upcoming deployment of DNSSEC in the root servers, all DNS software should be upgraded to handle this. Therefore, there is NO EXCUSE for using TXT-RRs for SPF purposes today. ___ 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
Re: [Mimedefang] Email 101
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
Re: [Mimedefang] Email 101
On Tue, Mar 16, 2010 at 17:43, Ben Kamen wrote: > > Ooo, and maybe mention (although possibly not a '101' subject) the TXT > record used for things like SPF? (although maybe no longer relevant) TXT records are still the main DNS record type used for SPF since so few DNS hosts support the SPF type. DKIM also uses TXT records from memory. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ 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
Re: [Mimedefang] Email 101
Ben Kamen wrote: > I also wonder if it might be worth while mentioning that DNS can > source from a port other than 53. For those configured intricate > firewall policies, this could trip them up on the outbound side as > well. Hmm, maybe. Actually, I didn't even want to mention DNS-related firewall policies because it's a bit too "102-ish" for something entitled "Email-101". However, someone else here at Roaring Penguin thought it would be a good idea. Perhaps I will add a section with a somewhat more diplomatic title than "Common Screwups" that will warn novices of typical dumb mistakes. :) Or maybe I'll write a whole other paper called "How to mess up email delivery" Regards, David. ___ 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
Re: [Mimedefang] Email 101
On 3/16/2010 11:08 AM, Jason Bertoch wrote: I found it well written and could certainly find a use for it with new employees and support technicians. It may not be relevant to your target audience, but I thought a useful addition to the DNS Transport section might be to mention firewall restriction of DNS packets to 512 bytes as another common mistake. I also wonder if it might be worth while mentioning that DNS can source from a port other than 53. For those configured intricate firewall policies, this could trip them up on the outbound side as well. Ooo, and maybe mention (although possibly not a '101' subject) the TXT record used for things like SPF? (although maybe no longer relevant) This is nice. I'm going to link it on my website. -Ben -- Ben Kamen - O.D.T., S.P. = Email: bkamen AT benjammin DOT net Web: http://www.benjammin.net ___ 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
Re: [Mimedefang] Email 101
> -Original Message- > From: mimedefang-boun...@lists.roaringpenguin.com [mailto:mimedefang- > boun...@lists.roaringpenguin.com] On Behalf Of David F. Skoll > Sent: Tuesday, March 16, 2010 11:11 AM > > > Anyway, please let me know what you think. > > http://www.roaringpenguin.com/files/email-101_0.pdf > David, I found it well written and could certainly find a use for it with new employees and support technicians. It may not be relevant to your target audience, but I thought a useful addition to the DNS Transport section might be to mention firewall restriction of DNS packets to 512 bytes as another common mistake. /Jason ___ 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
Re: [Mimedefang] Email 101
On 3/16/2010 11:10 AM, David F. Skoll wrote: Hi, I've written a basic introduction to Internet email. Some of you may find it a useful teaching resource. Anyway, please let me know what you think. http://www.roaringpenguin.com/files/email-101_0.pdf Well done. I immediately added it to our "e-mail" dictionary and it will definitely go to good use here! Regards, KAM ___ 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
[Mimedefang] Email 101
Hi, I've written a basic introduction to Internet email. Some of you may find it a useful teaching resource. Anyway, please let me know what you think. http://www.roaringpenguin.com/files/email-101_0.pdf Regards, David. ___ 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
