Recent Posts

Does volume cause blocking?

There seems to be a never ending debate about volume and how it affects delivery and revenue. I regularly get questions asking if ISPs block senders just for volume.
The answer is no. Unless you’re actually sending enough mail to overwhelm the incoming infrastructure, something that’s difficult on today’s internet, you’re unlikely to be blocked due to simply sending a high volume of mail.
Sending mail recipients don’t want, or mail that looks like spam, that will get the mail blocked or filtered.

Read More

Yahoo.com on FCC wireless "do not mail" list

Update: As of mid-morning pacific time on 10/7 yahoo.com has been removed from the FCC list.
As part of CAN SPAM the FCC maintains a list of wireless domains that require proof of permission to send mail to. Recently, various email folks noticed that yahoo.com was added to this list.
According to the law, senders have 30 days to meet the permission standards for any recipients at domains on the FCC list. In practical terms what this means is that the FCC and Yahoo have 30 days to fix this error and get yahoo.com off the list. Based on conversations with people who’ve talked to Yahoo and the FCC this is in the process of happening.
This isn’t the first time a non-wireless domain has been added to the FCC list.
As a sender what should you do with your yahoo.com subscribers?
Right now, nothing. There is a 30 day grace period between when a domain goes on the FCC list and when senders need to comply. I have every expectation that this will be removed in less than 30 days.
But what if it’s not?
In that case you will need to segregate out yahoo.com subscribers in 30 days and not mail them until the domain is removed from the FCC list. While I can’t actively suggest ignoring the law, it’s unlikely that the FCC is going to start coming after senders for mailing yahoo.com addresses once the 30 days are up.
More information: Al Iverson’s Spam Resource.

Read More

Email marketing not dead yet

If Forrester research is to be believe, email marketing is feeling better. In fact, it seems email marketing is more effective than ever.

Read More

Marketing pet peeves

Loren McDonald has a great post over at Mediapost listing his email marketing pet peeves. I particularly love this because he includes those things annoy him as a subscriber.
Most of what annoys me as a subscriber is sloppy marketing. Really is it so hard to actually check what you’re sending and who you’re sending it to?
elloIFNAME
This was a notice from Ello telling me that they’d get to my request for an account “at some point.” There were two fails here. The first is very obvious from the To: line. The second is even worse. I have an Ello account, I’m not waiting. Apparently they pulled their “current user” file and added it to the “waiting user” file and then mailed all of them a notice the accounts were getting turned on, albeit slowly.
The footer of the mail made it clear they knew they were spraying and praying:

Read More

September 2014: The Month in Email

September was another busy month for us, but Steve stepped up and wrote a number of really interesting posts on email history, cryptography, and current technical issues in the email landscape.
We started the month with a look at the various RFCs that served as the technical specifications for developing message transfer protocols in the 1970s. It’s really fascinating to look at the evolution of these tools we use every day 40 years later. We followed up with a second post on the origins of network email, which is a great primer (or refresher) on the early days of email.
Steve’s four-part series on cryptography and email started with an in-depth look at how the industry is evolving with respect to encryption and privacy issues. He then introduced us to Alice and Bob (or reintroduced those of us who have been following the adventures of the first couple of cryptography), and described symmetric-key and public-key encryption. His next post described message signing, and how DKIM is used to manage this. He finished up the series with a post on PGP keys.
In industry news: Spamcop is shutting down its email service. There shouldn’t be any major impact on senders, but the post has some specific notes on DMARC implications. We also noted an interesting mail routing suggestion on Twitter, and wrote a post on using Mail.app for this.
In other DMARC news, we wrote about DMARC and report size limits, which might be useful information, depending on your configuration. We also launched a new DMARC tool to help senders understand who is publishing DMARC. Let us know what you think and if you’re finding it useful.
We couldn’t let a month go by without mentioning filters. We looked at a sector we don’t usually discuss, corporate filtering, and went in-depth on a much-misunderstood topic, content filtering.
Finally, Laura offered a webinar on a favorite topic, deliverability, in conjunction with the AMA and Message Systems. If you missed it, you can watch the recorded version here, or just take a peek at some of the reaction via Twitter.

Read More

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.

Read More

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:

Read More

What about the bots?

M3AAWG 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 M3AAWG (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.

Read More

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.

Read More

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:

Read More
Categories
Tags