Recent Posts

Spamcop mail changes

Spamcop is shutting down it’s email service. While anyone could report spam using Spamcop, the system also provided users email addresses behind the Spamcop filters. This shut down should have no major impact on senders. Email addresses in use will still be accepting email, but that mail will simply be forwarded to another address, instead of users being able to access it through POP or IMAP.
The one problem some senders may have is IF they are solely authenticating through SPF and they are publishing a p=reject DMARC statement. This may result in some of the mail being rejected at the forwarding mail server, like AOL, Yahoo and other services respecting DMARC policy statements.
User forwarded mail will be coming from 68.232.142.20 (esa1.spamcop.iphmx.com) and 68.232.142.151 (esa2.spamcop.iphmx.com). If you don’t want to apply DMARC policy to known forwarded mail, those are the IPs to special case.

DMARC and report size limits

I just saw an interesting observation on the dmarc-discuss mailing list. Apparently some of the larger providers who are implementing DMARC for inbound email may not be handling some of the grubbier corners of the spec perfectly. That’s not surprising at all – early adopters tend to deploy code that implements early versions of the draft specification – but I can see this particular issue tripping up people who are beginning to deploy DMARC for their outbound mail.
DMARC includes the feature of requesting feedback reports about authentication failures – you just include the email address you want them sent to as a mailto: URI in the rua= and ruf= fields:

What about the bots?

M³AAWG published a letter to the FCC addressing the implementation of CSRIC III Cybersecurity Best Practices (pdf link)
The takeaway is that of the ISPs that contribute data to M³AAWG (37M+ users), over 99% of infected users receive notification that they are infected.
I hear from senders occasionally that they are not the problem, bots are the problem and why isn’t anyone addressing bots. The answer is that people are addressing the bot problem.

B2B email filtering

I’ve written about B2B filtering in the past, but I don’t blog too much about corporate filtering overall. The reason for this is that the corporate landscape is a lot broader and less consistent than the consumer space. That makes it much more difficult to tell senders how to handle corporate filtering, because each corporation is different.
But as I think I about it, I realize that’s not necessarily true. In the corporate space there are a few big filtering providers, a couple major hosting systems and a major open source package. While the overall goals of business filtering are slightly different, many businesses have similar goals for their inbound filtering.

Alice and Bob and PGP Keys

Last week Alice and Bob showed how to cryptographically sign messages so that the recipient can be sure that the message came from the purported sender and hasn’t been forged by a third party. They can only do that if they can securely retrieve the senders public key – which means they need to retrieve it from the actual sender, rather than an impostor, and be sure it’s not tampered with en route. How does this work in practice?
If I want to send someone an encrypted email, or I want to verify that a signed email I received from them is valid, I need a copy of their public key (almost certainly their PGP key, in practice). Perhaps I retrieve it from their website, or from a copy they’ve sent me in the past, or even from a public keyserver. Depending on how I retrieved the key, and how confident I need to be about the key ownership, I might want to double check that the key belongs to who I think it does. I can check that using the fingerprint of the key.
A key fingerprint looks like this:

Think you know about deliverability?

Check out the tweets from my AMA webinar sponsored by Message Systems today.
Thanks to the AMA and Message Systems for having me.

Reminder: AMA webinar

Today is the last day to sign up for the AMA webinar hosted by MessageSystems and listen to me talk about the future of deliverability.
I hope to see you there!

Alice and Bob Sign Messages

Alice and Bob can send messages privately via a nosy postman, but how does Bob know that a message he receives is really from Alice, rather than from the postman pretending to be Alice?
If they’re using symmetric-key encryption, and Bob is sure that he was talking to Alice when they exchanged keys, then he already knows that the mail is from Alice – as only he and Alice have the keys that are used to encrypt and decrypt messages, so if Bob can decrypt the message, he knows that either he or Alice encrypted it. But that’s not always possible, especially if Alice and Bob haven’t met.
Alice’s shopping list is longer for signing messages than for encrypting them (and the cryptography to real world metaphors more strained). She buys some identical keys, and matching padlocks, some glue and a camera. The camera isn’t a great camera – funhouse mirror lens, bad instagram filters, 1970s era polaroid film – so if you take a photo of a message you can’t read the message from the photo. Bob also buys an identical camera.
sign1
Alice takes a photo of the message.
sign2
Then Alice glues the photo to one of her padlocks.
sign3
Alice sends the message, and the padlock-glued-to-photo to Bob.
sign4
Bob sees that the message claims to come from Alice, so he asks Alice for her key.
sign5
(If you’re paying attention, you’ll see a problem with this step…)
Bob uses Alice’s key to open the padlock. It opens (and, to keep things simple, breaks).
Bob then takes a photo of the message with his camera, and compares it with the one glued to the padlock. It’s identical.
sign6
Because Alice’s key opens the padlock, Bob knows that the padlock came from Alice. Because the photo is attached to the padlock, he knows that the attached photo came from Alice. And because the photo Bob took of the message is identical to the attached photo, Bob knows that the message came from Alice.
This is how real world public-key authentication is often done.

Who's publishing DMARC?

DMARC is a way for a domain owner to say “If you see this domain in a From: header and it’s not been sent straight from us, please don’t deliver the mail”. If a domain is only used for bulk and transactional mail, it can mitigate a subset of phishing attacks without causing too many problems for legitimate email.
In other cases, it can cause significant problems. Some of those problems impact discussion lists, but others cause problems for ESPs servicing small companies and individuals. ESP customers use their email addresses in the From: field; if they’re a small customer using the email address provided by their ISP, and that ISP publishes a DMARC record with p=reject, a large chunk of the mail they’re sending will bounce. When that happens recipients will stop getting their email, they’ll be removed from the mailing list due to bounces, and there’s some risk of blocks being raised against the sending IP address.
Because of that, it’s good to be able to see what consumer ISPs are doing with DMARC.
I’ve created a tool at dmarc.wordtothewise.com that regularly checks a list of large consumer ISPs and webmail providers and sees what DMARC records they’re publishing.
There are two main variants of DMARC records.
One is policy “reject” – meaning that mail that isn’t authenticated (or for which authentication has been broken in transit) will likely be rejected.
The other is policy “none” – meaning that the ISP publishing the record doesn’t want recipients to change their delivery decisions, but are asking for feedback about their mailstream, and how much of it fails authentication. That can mean that the ISP is evaluating whether or not to publish p=REJECT, or is in the process of deploying p=REJECT. Or it can just mean that they’re using DMARC to monitor where mail using their domain in the From: address is being sent from. There’s no way to tell which is the case unless they’ve made an announcement about their plans.
Hopefully this will be a useful tool to monitor DMARC deployment by consumer ISPs, and to help diagnose delivery problems that may be caused by DMARC.

Cryptography with Alice and Bob

Untrusted Communication Channels
This is a story about Alice and Bob.
Alice wants to send a private message to Bob, and the only easy way they have to communicate is via postal mail.
closedletter
Unfortunately, Alice is pretty sure that the postman is reading the mail she sends.
openletter
That makes Alice sad, so she decides to find a way to send messages to Bob without anyone else being able to read them.
Symmetric-Key Encryption
Alice decides to put the message inside a lockbox, then mail the box to Bob. She buys a lockbox and two identical keys to open it. But then she realizes she can’t send the key to open the box to Bob via mail, as the mailman might open that package and take a copy of the key.
Instead, Alice arranges to meet Bob at a nearby bar to give him one of the keys. It’s inconvenient, but she only has to do it once.
lockstore
After Alice gets home she uses her key to lock her message into the lockbox.
shared1 Then she sends the lockbox to Bob. The mailman could look at the outside, or even throw the box away so Bob doesn’t get the message – but there’s no way he can read the message, as he has no way of opening the lockbox.
shared2
Bob can use his identical key to unlock the lockbox and read the message.
shared3
This works well, and now that Alice and Bob have identical keys Bob can use the same method to securely reply.
Meeting at a bar to exchange keys is inconvenient, though. It gets even more inconvenient when Alice and Bob are on opposite sides of an ocean.
Public-Key Encryption
This time, Alice and Bob don’t ever need to meet. First Bob buys a padlock and matching key.
public1
Then Bob mails the (unlocked) padlock to Alice, keeping the key safe.
public2
Alice buys a simple lockbox that closes with a padlock, and puts her message in it.
public3
Then she locks it with Bob’s padlock, and mails it to Bob.
public4
She knows that the mailman can’t read the message, as he has no way of opening the padlock. When Bob receives the lockbox he can open it with his key, and read the message.
public5
This only works to send messages in one direction, but Alice could buy a blue padlock and key and mail the padlock to Bob so that he can reply.
Or, instead of sending a message in the padlock-secured lockbox, Alice could send Bob one of a pair of identical keys.
publichared
Then Alice and Bob can send messages back and forth in their symmetric-key lockbox, as they did in the first example.
shared2
This is how real world public-key encryption is often done.