Thursday, April 30

Email Signature Block Etiquette

I was involved in a discussion today about Email signature blocks and how obnoxious some of them are. I saw one today, with literally, an entire page of certifications and stuff. I’ve written about this before, but it never hurts for a little refresher.


Although the individuals reading my blog shouldn’t have this problem and know how to write email signature blocks right?


Let’s look at some best practices, and some other common stuff --


  1. Start you signature block with “-- “. This allows email clients that correctly parse emails to collapse or grey out this area.
  2. 4 lines or less.
  3. Phone number, Primary, maybe fax (if you depend on the fax technology)
  4. No email address (If you are sending an email, what’s the point in having your email in your signature block? They already HAVE your email address!)
  5. Webpage (okay, this is fine, but keep it simple)
  6. No quotes. If I want a witty quote, I’ll go find one. Your email should tell me a lot about you, not the quote.
  7. Instant Messenger name (If you are the kind of person that would rather communicate via that medium, as opposed to phone.
  8. Disclaimer -- The jury is still out on this “Disclaimer, legal copy” nonsense. Has it one of these ever been Enforced in Court? Not that I know of.
  9. Company Name -- Good idea to have
  10. Address? No. I can go look it up, or email you back to get it. 99% of the emails you send will not need the address. Besides, if I feel you’ll need my address, I’ll send it to you, along with a short url of Google Maps on how to get here.
  11. Logo, multi colors, html, and various other nonsense? No.


Keep it simple. Signature block reads:


--

Joel Esler | Sourcefire | gtalk: jesler@sourcefire.com | | http://twitter.com/joelesler


Short, sweet, to the point. You know how to get a hold of me via 4 mediums. Phone, IM, Twitter, and of course, Email.

Email Signature Block Etiquette

I was involved in a discussion today about Email signature blocks and how obnoxious some of them are. I saw one today, with literally, an entire page of certifications and stuff. I’ve written about this before, but it never hurts for a little refresher.


Although the individuals reading my blog shouldn’t have this problem and know how to write email signature blocks right?


Let’s look at some best practices, and some other common stuff --


  1. Start you signature block with “-- “. This allows email clients that correctly parse emails to collapse or grey out this area.
  2. 4 lines or less.
  3. Phone number, Primary, maybe fax (if you depend on the fax technology)
  4. No email address (If you are sending an email, what’s the point in having your email in your signature block? They already HAVE your email address!)
  5. Webpage (okay, this is fine, but keep it simple)
  6. No quotes. If I want a witty quote, I’ll go find one. Your email should tell me a lot about you, not the quote.
  7. Instant Messenger name (If you are the kind of person that would rather communicate via that medium, as opposed to phone.
  8. Disclaimer -- The jury is still out on this “Disclaimer, legal copy” nonsense. Has it one of these ever been Enforced in Court? Not that I know of.
  9. Company Name -- Good idea to have
  10. Address? No. I can go look it up, or email you back to get it. 99% of the emails you send will not need the address. Besides, if I feel you’ll need my address, I’ll send it to you, along with a short url of Google Maps on how to get here.
  11. Logo, multi colors, html, and various other nonsense? No.


Keep it simple. Signature block reads:


--

Joel Esler | Sourcefire | gtalk: jesler@sourcefire.com | | http://twitter.com/joelesler


Short, sweet, to the point. You know how to get a hold of me via 4 mediums. Phone, IM, Twitter, and of course, Email.

Saturday, April 25

My Email set up

Earlier today, I found myself in a conversation on Twitter about how I process email with my friend Bryan Liles. He uses the Inbox Zero method, as do I, to a bit, so I thought I’d actually write a post.


The last time I talked about email, I believe I was still using Mail.app, which, of course, I still like because of it’s nice integration with other Apple Apps. I have to admit, however, that I no longer use it.


I use Gmail, the web interface. That’s all I use. I mentioned before that I used to have about 10 email accounts, all for various reasons, none of which I could truly justify. None of them were hidden or anything, they were all some derivative of “eslerj” or “joelesler” or something. So I started consolidating.


Right now, all my personal email, (friends and family) use one address. All my list servers go to a second address, and of course, I have my work email.


I found logging into three different accounts to be very annoying, so I found out through playing around in the Gmail settings that you can enable your Gmail to be able to send email “on behalf” of other email accounts. So, for example, I set my “from” address to be any one of the three addresses, and when I hit “reply”, Gmail knows to reply from the proper account. (If you have it set up correctly.)


So, I took my other two accounts and forwarded them to the one. That way, I have one single account to check all my email from. Very nice.


So, onto the meat, how do I process email?


Like a lot of people I use Gmail’s filters and labels. Since I forward all my email into one account, I get anywhere between 600-1000 emails a day, so I needed an efficient way to handle this stuff automatically.


All listservers, when I receive an email from them, are tagged automatically with a label, based upon the list header. (I suggest you let Google filter this stuff for you, use the “Filter Messages like this” feature.)


Google will suggest what it thinks you should use as a Filter. Whether it be from a certain person, etc.. For the listservers, it does a nice job of parsing headers. For example, the filter in my Gmail to filter emails sent to the Snort-Sigs list for http://www.snort.org is “list:"snort-sigs.lists.sourceforge.net"”

I then let Gmail apply a label, and Skip the Inbox.

That way I don’t get bogged down in the listserver email when I am trying to do actual email processing. All listservers are set up like that (Except for my “Snort” based ones, I want those in my Inbox, so I can respond to people.) That eliminates about 400-800 emails from my daily processing. I take a look at all my listserver email about once a day, scan the subjects, and if I don’t see anything interesting, I mark them all as read and move on. (BTW -- so, if you want me to particularly look at your email if you post to a listserver, cc me! You’ll find out why in a sec ;)


BTW -- If you aren’t using these two features in Gmail, you are absolutely crazy.

The first option is Keyboard Shortcuts. Once you learn the keyboard shortcuts in Gmail, you FLY through your email so much faster.


The Personal Level indicators place little arrows next to the emails that are sent only to you “>>” or sent to your name (as well as someone else, like for instance, if you were “cc’ed” on an email. “>”.


Anyway --

So, when I read my email in my inbox, I use a labels/filters to process the ones from my corporate domain “sourcefire.com” and (and a couple other domains) and label them a particular color. This allows me to quickly glance down a huge page of email, determine which of the emails with the “>>” arrows are from my company or not.


I process all the email in my inbox to “zero”, making “todo’s” (I use OmniFocus for this (learn your keyboard shortcuts!) Responding quickly to those that need responding, and archiving the things I don’t want to respond to. I can burn through a couple hundred emails in a very short amount of time.


I also try to keep to the 5 sentences or less method of email if I can. I do make exceptions to this rule if I need to, (rarely), but I find that I don’t generally have a problem if I keep my emails quick, descriptive, and to the point.

Wednesday, April 8

Sourcefire's Exploit Development Class

First off, if you were to go look at this class on Sourcefire’s website, it states “Exploit Development Class for Snort Rule Writers”. We need to fix this. In the words of Lurene, “This class has nothing to do with Defense. At all. Ever.” The class should be more appropriately named, “Fundamentals of Exploit Development”, or “Writing Exploits, we’re going to hurt you”


So, let’s describe this class in two words or less:


Freakin Awesome.


Beginning on day one with a lot of terminology, introduction and drinking from the firehose on Assembly and gdb, by the end of the first day, you are well versed in how to read assembly, pick it apart, and even being able to reverse simple programs at this point. Your Brain will hurt.


Day Two, more drinking from the firehose, more reversing, more assembly, more gdb, drawing stacks, and by the end of the second day, you are learning to control EIP, and doing it. Your Brain will hurt even more.


Day Three, you just sit all day and hack programs. From simple to intermediate, (you aren’t cracking Microsoft Office just yet ;), by the end of the day, you are using reverse shells and shellcode like nothing. Your Brain is now fried. Go drink beer. Seriously.


This was the best class I have ever taken in my life. Srsly.


You know those classes where you go and sit, and you could probably figure out 80% of it, and the other 20% of the class you pick up little tricks and tips on whatever you are learning? This is not one of those. If you know assembly, or have experience in reversing assembly, this is not the class for you (even though you will probably learn something). The class I took was taught by 4 of the Vulnerability Research Team members, people I am glad to call my friends.


So, my hat’s off to Lurene, Matt, Ryan, and Nigel, along with all the other members of the VRT that contributed, came out, and helped with the class. It was great, and I’d gladly take it again anytime.


The best part of the class, I thought, was during the class, on a separate projector, they fuzzed software and found some 0days. I don’t want to disclose which pieces of software were fuzzed, but let’s just say that they are pieces of software that people use everyday.


In one piece of software, over 200 crashes and bugs were caused. No word on how many were exploitable yet.


No, I will not tell you which piece of software it was either.