This month in email: February 2014

After a few months of hiatus, I’m resurrecting the this month in email feature. So what did we talk about in February?
Industry News
There was quite a bit of industry news. M3AAWG was in mid-February and there were actually a few sessions we were allowed to blog about. Gmail announced their new pilot FBL program. Ladar Levinson gave the keynote talking about the Lavabit shutdown and his new darkmail program. Brian Krebs won the Mary Litynski award for his work in investigating online security issues. The 4 major mailbox providers talked about their spam filters and spam filtering philosophy.
February was also the month where different companies evaluated their success or failure of products. LinkedIn announced the shutdown of their Intro product and Facebook announced the shutdown of their Facebook.com email service.
Security Issues
Cloudmark published their 2013 report on the Global Spam Threat and we discovered that the massive Target breach started through phishing. I also noticed a serious uptick in the amount of phishing mails in my own mailbox. There is  new round of denial of service attacks using NTP amplification. We provided information on how to secure your NTP servers.
Address Collection
The Hip Hop group De La Soul released their entire catalog for free, online, using a confirmed opt-in email process. On the flip side, the M3AAWG hotel required anyone logging into the wifi network to give an email address and agree to receive marketing mail. We also discovered that some political mailing lists were being used in ways the politicians and recipients didn’t expect.
Email Practices
I talked about how to go about contacting an ISP that doesn’t have a postmaster page or a published method of contact. Much of that information is actually relevant for contacting ISPs that do have a contact method, too. Finally, I talked about how ISPs measure engagement and how that’s significantly different from how ESPs think it is.
 

Related Posts

Gmail pilots new FBL

Yes, it’s true. Gmail announced last Thursday at M3AAWG that they were piloting a new Feedback loop.
The Gmail FBL is currently for ESPs only. The announcement during MAAWG was that only MAAWG ESP members were eligible. They are requiring a DKIM signature for the FBL, but ESPs using individual customer d= values can get a FBL based on IPs. They are also not providing ANY information that reveals the complainer. Gmail’s intention is only to give ESPs feedback so that ESPs can prevent abuse. They are not giving feedback so complainers can be removed.
The email has a .csv attachment that has 3 columns: date, identifier and complaint rate.
The identifier is an ESP provided customer identifier. One of the ESPs I talked to said they were adding an X-header into their emails.
I’ve heard from beta testers that there is a minimum of 100 complaints before you’ll get any report.
Reports are sent daily if there is sufficient traffic to trigger them.
If you’re a MAAWG member, check the senders list for the signup URL.

Read More

Using confirmation to get good email addresses

For 25 hours the group De La Soul is releasing their entire catalog for free online. What none of the articles are mentioning is that they’re using this to build their database of email addresses in a way that’s going to result in a clean database of high value email addresses.
How are they doing that? By making sure the addresses belong to their fans before they actually give fans access to the catalog. Yes, they are using confirmation as part of their signup process.
If you go to their website: wearedelasoul.com you’re asked for an email address so they can send the downloads to you.
dls_website
The fine print is the interesting bit:

Read More

More denial of service attacks

There are quite a lot of NTP-amplified denial of service attacks going around at the moment targeting tech and ecommerce companies, including some in the email space.
What does NTP-amplifed mean? NTP is “Network Time Protocol” – it allows computers to set their clocks based on an accurate source, and keep them accurate. It’s very widely used – OS X and Windows desktops typically use it by default, and most servers should have it running.
NTP is a UDP based service, like DNS, one that works by sending a packet to a server and the server sending a packet back rather than opening a persistent connection to the server as TCP based services (e.g. SMTP, HTTP, …) do. That simpler protocol means that it’s easy for me to send a request to an NTP server with a false source address, claiming I’m someone else – and the NTP server will send it’s reply back to that fake source address rather than to me. So if I want to DoS someone by flooding their network with packets I can send NTP requests to a public NTP server claiming to be the victims server. The NTP server will send the replies back to the victim – and it’ll be almost impossible for the victim, or the NTP server, to trace where I’m sending those request packets from.
As a malicious attacker that already sounds good – but it gets better. The size of a reply is often bigger than the size of a request, sometimes a lot bigger. If I choose the request I make carefully I can easily make sure the reply is at least an order of magnitude bigger than the request. So for every megabit of forged requests I sent to NTP servers, the victim might see at least 10 times that hitting their servers. That’s amplification.
What can you do about it? If you’re running NTP servers that will respond to requests from the general Internet, you ideally need to lock those down so that they’ll only respond to requests from your own clients. You can use the instructions and information at the open NTP project to check to see if you’re running open NTP servers and use the templates provided by Project Cymru as a basis to secure your NTP servers and appliances.
What can you do to prepare for this sort of attack? Have monitoring in place, so that you’re notified if there are large volumes of unexpected traffic. Overprovision your bandwidth, if possible, to give you more time to react. Block “large” (>90 bytes for IPv4, >110 for IPv6) UDP packets with a source or destination port of 123 as far upstream as possible, and all UDP packets that have both a source port of 123 and a destination port of 80 or 25 – this shouldn’t affect legitimate use of NTP by your users. Consider having your production servers use NTP servers operated by you, rather than public NTP servers – that way, if they’re targeted you can block any traffic that looks like NTP to them without affecting their time synchronization. Research DoS mitigation providers – different providers have different strengths and cost structures, and they can be much more reasonably priced if you talk to them before an attack rather than during one.
What if you’re targeted by this sort of attack? If you’re not a sysadmin, stay out of your sysadmins way and make sure there’s coffee, food and a quiet place without interruptions available. If you are a sysadmin, talk to your upstream NOC. They’re in a much better place, in information, resources and knowledge, than you to help mitigate. Reach out to your peers who are also being attacked and offer to share information. Look at Cisco’s mitigation advice. The attack will probably target your publicly visible website. If so, consider moving that to another network (or behind a commercial DoS mitigation provider) so that your production servers and customer portal web presence isn’t impacted.
More information

Read More