Skip to main content

Bottom Posting

Recently was chastised for Bottom posting on a Mailing list, so I thought I'd write a few words about it.

I bottom (or inline post) mostly because I like the email to be a message. You read a message or a letter from top to bottom, from left to right. It wasn't until email clients started top posting (looking at you Outlook/Lotus Notes) that email was written in the top-posting format, forcing you to read an email backwards.

So I looked it up, basically looking at two different information stores.

Wikipedia -- http://en.wikipedia.org/wiki/Posting_style
RFC1855 -- http://www.ietf.org/rfc/rfc1855.txt

These two places will define how to write email and how email should be written, on mailing lists, use groups, or any other email transaction.

The particular part to pay attention to is in RFC1855 --

"- If you are sending a reply to a message or a posting be sure you
summarize the original at the top of the message, or include just
enough text of the original to give a context. This will make
sure readers understand when they start to read your response.
Since NetNews, especially, is proliferated by distributing the
postings from one host to another, it is possible to see a
response to a message before seeing the original. Giving context
helps everyone. But do not include the entire original!"

Summarize the email at the top, and post below it. In other words, bottom-posting is the correct way to write email, as per RFC.

Comments

Mike Litoris said…
I'm with you, dude... everyone else is doing it wrong.
Joel Esler said…
Thanks. I knew I wasn't alone. I knew someone out there was on my side!
MikeP said…
I prefer interspersed / bottom posting, but I'm tempted to write an RFC prescribing top-posting. I think it depends on who you're talking to and what their own norms are.

That said, I don't think you were attacked for bottom-posting; I think you were attacked for your employer, and the bottom-posting was a convenient excuse.

I must confess to taking a certain delight in removing everything below my reply when talking to top-posters.

What drives me nuts is when it gets mixed up. Augh.
evilghost said…
Bottom posting is annoying in that there are several people who often read messages in a preview pane; bottom posting requires the entire message to be re-opened or scrolled in the preview pane. You're forced to re-read what you've already said before the new content is visible. In-line posting, where applicable, is acceptable. RFC or not, bottom posting is as antiquated as bang paths.
Joel Esler said…
Yet, people still do both. So, I'll stick to the proper way.

--
[...] alter Episoden gibt, hier die Erkl¤rung von Peter Travis pers¶nlich: We have a total ...Bottom Posting | FinshakeRecently was chastised for Bottom posting on a Mailing list, so I thought I'd write a few words [...]
Waldo Kitty said…
bottom posting is OK but inline is much better... especially when responding point by point... top posting is just wrong in so many ways... it is, honestly, another form of laziness fomented on the world by a group with the incessant goal of dumbing down everything they can get involved in... has no one learned anything from 25 - 30 years of BBS messaging? deity knows we don't see half the problems there that we do in other supposedly new technology and especially the so called new communication capabilities where all the ugly is hidden behind pretty pictures :rolleyes:

MikeP and i seem to think similar in this aspect... i do delight in removing everything below my replies when i do that... and yes, the mixed up mess that we get when inline, bottom and top posting are all mixed together is really really really bad... those deserve a good zippy comment ;)
Darael said…
It is clear enough that inline is best - and furthermore, a careful reading of the RFC reveals that said RFC labels it the preferred style, with bottom-posting second and top-posting actively discouraged.

Popular posts from this blog

Offset, Depth, Distance, and Within

Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand.  They aren't difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

The five modifiers that I am talking about are
OffsetDepthDistanceWithinnocaseThese five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword.  That keyword is "content". The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string.  So for instance if I wanted to look for the word "joel" within a packet.  A simple:
content:"joel";Would allow me to do that.  The interesting part comes into play when you want to specify where inside of a particular packet you want the string "joel" to be looked for.  If you are running just a plain content ma…

Writing Snort Rules Correctly

Let me start off by saying I'm not bashing the writer of this article, and I'm trying not to be super critical.  I don't want to discourage this person from writing articles about Snort rules.  It's great when people in the Snort community step up and explain some simple things out there.  There are mistakes, it comes with the territory.  If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better.  That's why I write this blog post, not to bash the writer, but to teach.

I noticed this post today over at the "Tao of Signature Writing" blog, and to be honest I glanced over most of it figuring it was a rehash of things I've already read or things that have already been written from countless people about "Here's how you write Snort rules!".  I scrolled down quickly skimming, not reading at all really, and noticed this part:
Now, let us look at the second questio…

Safari 5.1.4 now available

Safari 5.1.4 now available, fixes issues and improves performance | TUAW - The Unofficial Apple Weblog:


Improve JavaScript performanceImprove responsiveness when typing into the search field after changing network configurations or with an intermittent network connectionAddress an issue that could cause webpages to flash white when switching between Safari windowsAddress issues that prevented printing U.S. Postal Service shipping labels and embedded PDFsPreserve links in PDFs saved from webpagesFix an issue that could make Flash content appear incomplete after using gesture zoomingFix an issue that could cause the screen to dim while watching HTML5 videoImprove stability, compatibility and startup time when using extensionsAllow cookies set during regular browsing to be available after using Private BrowsingFix an issue that could cause some data to be left behind after pressing the "Remove All Website Data" button