CategoryTechnical

Email History through RFCs

Many aspects of email are a lot older than you may think. There were quite a few people in the early 1970s working out how to provide useful services using ARPANET, the network that evolved over the next 10 or 15 years into the modern Internet. They used Requests for Comment (RFCs) to document protocol and research, much as is still done today. Here are some of the interesting milestones. April...

Asynchronous Bounces

There are three ways that an email can fail to be delivered: immediate rejection timeout asynchronous bounce Rejection A rejection is any delivery attempt where the sending smarthost can tell immediately that the mail can’t be delivered. That will often be when the receiving machine accepts a connection but returns a “hard bounce” or “5xx” error at some point in...

Fun with new mailservers

I’m building a new set of mailservers for wordtothewise.com – our existing mailserver was “I’ll repurpose this test box for a week” about four years ago, so it’s long past time. I tested our new smarthost by sending a test mail to gmail. This is the very first email this IP address has sent in at least three or four years, possibly forever: host gmail-smtp-in.l...

DKIM Key Rotation

Several people have asked me about how to rotate DKIM keys in the past few days (as if you’re modifying anything to mitigate replay attacks, you need to invalidate the signatures of all the mail you sent before you made those changes).    [icon name=”key” class=”2x spin”] You really, really should be rotating your DKIM keys on a regular basis (monthly, weekly...

DKIM and injected headers

If you look at the DKIM-Signature header in any piece of email signed with DKIM you’ll see that one of the fields it contains, the h= field, lists some email header names, for example: h=From:Subject:Date:To:MIME-Version:Content-Type Those are the headers that were signed when the mail was sent, and they’re the only headers that will be checked by the DKIM validator. There are some...

DKIM replay attacks

Replay attacks on DKIM signed messages When you receive an email validly signed with DKIM by example.com that might not mean that example.com sent the email to you, or that they even sent this email at all. What it does tell you is that at some point in the past, example.com signed an email with exactly the same headers and body and sent it to someone. That’s often close enough to the same...

Emoji – older than you think

It might just be random 17th Century punctuation, but this poem from 1648 certainly seems to be using a smiley face emoji.
(OK, it’s probably not intentional, but it’s lovely intersection of the emoji and the word.)

TLS and Encryption

Yesterday I talked about STARTTLS deployment, and how it was a good thing to support to help protect the privacy of your recipients. STARTTLS is just one aspect of protecting email from eavesdropping; encrypting traffic as the mail is being sent or read and encrypting the message itself using PGP or S/MIME are others. This table shows what approaches protect messages at different stages of the...

Protect your email with TLS

You probably use TLS hundreds of times a day. If you don’t recognize the term, you might know it better by it’s older name, SSL. TLS is what protects your data in transit whenever you go to Google, or Yahoo or even this blog. The little padlock in your browser address bar tells you that your browser has used the TLS protocol to do two things. First, it’s decided that the server...

SMTP Level Rejections

While discussing a draft of a Deliverability BCP document the issue came up of what rejections at different phases of the email delivery transaction can mean. That’s quite a big subject, but here’s a quick cheat sheet. At initial connection Dropped or failed connection: your reputation with the receiver is so bad that they don’t want to see any email from you, ever their mail...

Recent Posts

Archives

Follow Us