Spam still accounts for a significant majority of all the emails that are sent. A world in which email can be used without spam filters is a distant utopia. Yet, the decline of spam volumes and the continuing success (recent glitches aside) of filters have two important consequences.

The first is that we don't have to fix email. There is a commonly held belief that the existence of spam demonstrates that email (which was initially designed for a much smaller Internet) is somehow 'broken' and that its needs to be replaced by something that is more robust against spam.

Setting aside the Sisyphean task of replacing a tool that is used by billions, proposals for a new form of email tend either to put the bar for sending messages so high as to prevent many legitimate senders from sending them, or break significant properties of email (usually the ability to send messages to someone one hasn't had prior contact with).

Still, if spam volumes had continued to grow, we would have had little choice but to introduce a sub-optimal replacement. The decline in spam volumes means we don't have to settle for such a compromise.

Secondly, current levels of spam mean there is little threat of a constant flow of spam causing mail servers to fall over.

At the same time, one would be hard-pressed to find a user whose email is not filtered somewhere — whether by their employer, their provider, or their mail client.

Thus, looking at the spam that is sent isn't particularly interesting as it provides us with little insight into the actual problem. What matters is that small minority of emails that do make it to the user — whether because their spam filter missed it, or because they found it in quarantine and assumed it had been blocked by mistake.

Equally important is the question of which legitimate emails are blocked, and why — and what can be done to prevent this from happening again in the future.

It is tempting to look at all the spam received by a spam trap, or by a mail server, and draw conclusions from that. They certainly help paint a picture, but in the end they say as much about what users see as the number of shots on target in a football match says about the final result.

Despite the doom predicted by some a decade ago, email is still with us — and we have won a number of important battles against spam. But if we want to win the war, we need to shift our focus.

Written by Martijn Grooten, Email, web security tester

Al Iverson over at Spamresource has a great round-up of the news, if you haven't managed to catch the news, go check it out, then come on back, we'll wait ...

Of course, bad guys are always mad at Spamhaus, and so they had a pretty robust set-up to begin with, but whoever was behind this attack was able to muster some huge resources, heretofore never seen in intensity, and it had some impact, on the Spamhaus website, and to a limited degree, on the behind-the-scenes services that Spamhaus uses to distribute their data to their customers.

Some reasonable criticism, was aimed at the New York Times, and Cloudflare for being a little hyperbolic in their headlines and so on, and sure, it was a bit 'Chicken Little'-like, the sky wasn't falling and the Internet didn't collapse.

But, don't let the critics fools you, this was a bullet we all dodged.

For one, were Spamhaus to be taken offline, their effectiveness in filtering spam and malware would rapidly decay, due to the rate at which their blocklists need to be updated. The CBL anti-botnet feed and the SBL list both have many additions and deletions every day. These services are used to protect mail servers and networks against the most malicious criminal traffic. If they go down, a lot of major sites would have trouble staying up, or become massively infected with malware.

There are also a ton of small email systems that use the Spamhaus lists as a key part of their mail filtering (for free as it turns out). Were those lookups prevented, or tampered with, those systems would buckle under the load of spam that they dispense with easily thanks to Spamhaus.

To put it into perspective, somewhere between 80% & 90% of all email is spam, and that's the stuff Spamhaus helps filter. So it doesn't take a Rocket Scientist to figure out that if filters go out, so do the email systems, in short order. AOL's Postmaster famously said, at an FTC Spam Summit a decade ago, before the inception of massive botnets, that were their filtering to be taken offline, it'd be 10 minutes before their email systems crashed.

Due to some poorly researched media reports (hello, Wolf Blitzer!), there is a perception that this is a fight between two legitimate entities, Spamhaus and Stophaus; some press outlets and bloggers have given equal time to the criminals (we use that word advisedly, there is an ongoing investigation by law enforcement in at least five countries to bring these people to justice). Nothing could be further from the truth. The attackers are a group of organized criminals, end of story. There is nothing to be celebrated in Spamhaus taking it on the chin, unless you want email systems and networks on the Internet to stop working.

So yeah, it was a big deal.

Written by Neil Schwartzman, Executive Director, The Coalition Against unsolicited Commercial Email - CAUCE

Dyn, the worldwide leader in Internet Infrastructure as a Service, has announced it will hold a joint Email Analytics Webinar with Ongage, an advanced email marketing middleware platform, which helps organizations optimize deliverability and maximize ROI.

Mike Veilleux, Dyn Director of Email Product, and Ongage Senior Product & Marketing Manager Noam Rotem will lead the hour-long session on Wednesday, February 27 at 2 p.m. Eastern. The two email experts will discuss reputation-based analytics, IP vs. domain reputation, feedback loops, how Ongage evaluates reports and other email related topics.

Registration is now open, but the number of seats is limited.

"This webinar will be incredibly educational for anyone interested in understanding email more," Veilleux said. "As the Internet continues to grow, email is still the most popular and influential form of communication. Ensuring that the emails you send reach their intended audience is critical for any business to succeed.

"Between what we're doing with deliverability and the innovative approach Ongage takes, we will be able to answer any of your questions," Veilleux continued.

Both companies are considered thought leaders in the Email Service Provider (ESP) space. DynECT Email Delivery — Dyn's enterprise email platform — delivers 960 million messages per month (approximately 32 million per day) for global enterprise companies like Box, Seeking Alpha, Spiceworks and SkillPages.

Ongage is one of the fastest growing email marketing organizations in the world. The Tel Aviv-based company focuses on front end user experience, from list management, email content management, to robust campaign management, and in-depth email performance analytic dashboards.

The joint webinar is a natural extension of the partnership between Dyn and Ongage, discussed in a new case study which explains how in this partnership, Dyn does all the backend deliverability, while Ongage handles the front end user experience.

"We've done API integration with many leading cloud SMTP services and email service provider vendors (ESPs)," said Danny Tal, VP Sales for Ongage, "However, the kind of relationship we have with Dyn, in which we send each other many mutual clients, is unparalleled with any other vendor."

"We have added three rock stars to our engineering team," said Dyn CTO Cory von Wallenstein. "Recruiting talent like this shows our commitment to engineering excellence and ensures that while we continue scaling, we will be producing the very best products in the world."

Santoro knows firsthand the challenges and opportunities in the email delivery market, bringing with her a wealth of knowledge and experience in scaling engineering teams. Prior to Dyn, she was the Chief Technology Officer at Vsnap, a Boston-based video messaging startup that she helped cofound.

Prior to that, the native of Rome, Italy, was the VP of Engineering at Exit41, a venture-backed company in Andover, MA. Santoro led Exit41's reinvention from a point-of-sale software provider to a provider of turnkey web and mobile ordering services for restaurants. Over five million transactions per year are being processed through this system. Before Exit41, Santoro held engineering roles at IBM and Epsilon.

"This is an awesome opportunity to work with a great team in helping grow Dyn's services and also to meet the massive scale delivery of quality email," Santoro said. "I look forward to bringing extensive experience building highly scalable systems along with the teams that make them possible. I can't wait to get started."

Connors brings years of experience as VP, Operations at Constant Contact into his new role as VP, Technical Operations. In this role, Connors — a Yale graduate in engineering — will be leading Dyn's technical teams as they continue to scale.

"Dave specializes in building web operations teams and capacity planning for large-scale infrastructure projects, making him a perfect fit," said von Wallenstein.

Sullivan has been working on future innovations for Dyn for the past year as Director of Labs. In his new role as Director of DNS Engineering, he brings that same pioneering spirit to the DNS team, ensuring the company is always looking toward the future of the Internet.

Sullivan has long been a leading voice in the DNS and Internet community and previously worked as the Director of Name Services at Afilias and as an Internet Scientist at Shinkuro, Inc.

"My work with the labs team was very exciting," Sullivan said. "It gave me the opportunity to work with the production engineers on an architectural review of the DNS systems. That review stimulated a number of thoughts about how things might evolve and improvements that were needed. At Dyn, if you have an opinion people expect you to step up and take action, so that's how I ended up moving to DNS engineering."

Dyn also announced the hiring of Paul Mailhot as VP, Business Operations. Mailhot, who comes from 19 years at Autodesk, is responsible for organization, design and development across the entire business, technology systems to support growth, including corporate IT, and strategic planning for the future. Mailhot welcomes the challenge of moving from a large multinational company to a smaller, fast paced growth company.

"Having the ability to use my business experience to help a company undergoing hyper growth was the key reason for joining Dyn's management team," Mailhot said. "The Dyn story is very exciting and has tremendous potential as we define the IaaS market. Being part of that future is exciting and I look forward to being one of the catalysts to growth."

While these are Dyn's most high profile hirings, they are certainly not the only top talent joining the team. After doubling in size for the past two years, growth is on the docket again for 2013 with a plethora of new technology positions available in the company's Manchester, NH, headquarters. Dyn also has offices in Brighton, UK, Wrexham, Wales and San Francisco, CA.

Keeping in mind that I am far from a usability expert (my ideal interface is a model 33 Teletype), there are a few things that I can describe without going into the details of exactly how they would look.

The first and most obvious is that users have to be able to enter the addresses. This is not as obvious as it might immediately appear. While I know how to configure my keyboard to type accented letters like the ones in josémartí@gob.cu, I haven't a clue how to type 毛泽东@政府.cn, if I wanted to send mail to someone who'd given me a business card with that address. Perhaps cards will add QR codes. Or perhaps internationalized addresses will mostly be used in communities that are sufficiently homogeneous that they'll all know each other's languages and it won't be enough of an issue to need a solution.

Typing the message shouldn't be a problem, since people will presumably write messages in languages they understand. The next issue is who gets what format of mail. With EAI mail, either a recipient can totally handle it, or not at all, with nothing in between. So if you send an EAI message to a non-EAI address, it won't be delivered. If someone's address includes non-ASCII characters, that means it has to be on an EAI mail system, but for ASCII addresses, you can't tell, unless you have a hint, such as an EAI message that they sent to you. (At some point, I'll upgrade my mail to handle EAI, but my address, which I've had since 1993, won't change.)

This suggests that the address books in mail programs will try and remember which addresses can accept EAI mail, much as a decade ago they remembered who accepted HTML mail. In principle this is a huge ugly hack, in practice I expect it'll work pretty well, send ASCII mail to ASCII addresses and EAI mail to EAI addresses, updating the address book whenever you get an EAI message from an ASCII address.

It's also likely that people with EAI addresses will continue to have ASCII addresses for a long time, so non-EAI mail users can continue to correspond with them. Hence address books are also likely to remember that maozedong@gov.cn is the same person as 毛泽东@政府.cn, so it should use the EAI address in EAI mail, but the ASCII address in messages also sent to non-EAI recipients. Again, a hack in principle, probably workable in practice.

I gather that some large mail systems in China are implementing EAI mail now, so we'll probably know soon how whether mail systems do all this. as opposed to just saying if you want to send me mail, find an EAI mail system.

Written by John Levine, Author, Consultant & Speaker

The new EAI RFCs define extensions to both POP and IMAP to handle EAI mail. Part of the extension simply lets a client (the user mail program) ask a server whether is has EAI capabilities, and if so enable them. This is the way a server can tell whether a client can handle EAI mail. Other extensions enable UTF-8 login names and passwords. For IMAP, they enable UTF-8 names for subfolders, and for POP, the server can provide the text part of responses in languages other than the default English.

If a mailbox contains EAI messages, and a client can handle EAI, the client just picks them up as usual. But if a client can't handle EAI, none of the options are great. One possibility is simply not to show the client the EAI messages, or to replace them with a placeholder that says something like to see this message, update your mail program. This may seem like a cruel joke (we're not going to show you your mail, neener neener), but in some environments, particularly ones where the local language isn't written in Roman characters and users are all expected to upgrade, it can make sense.

The softer alternative is to downgrade the messages, give the user an ASCII version of the message that more or less matches the original. The experimental predecessor to EAI tried valiantly to create downgraded messages that captured the complete original and failed. There are two remaining approaches to creating the downgrade at message retrieval time. The more complicated one encodes the non-ASCII material in a way that a suitably aware mail client could mostly reverse, adding Downgraded-whatever: headers for MIME-encoded versions of headers that don't allow MIME encoding, and a stylized way of representing non-ASCII addresses as MIME comments in address lines.

The less complicated one just makes the minumum changes required to get an ASCII message, without trying to preserve everything. I prefer the simpler approach; any effort spent making mail programs handle the more complex downgrades would better be spent making them handle EAI directly, and in either case, the most likely reaction by a human user is to go find an EAI mail client (web mail perhaps) if she wants to reply to an EAI address.

In the last part of this series, we'll see the surprisingly minor changes needed to make user mail programs handle EAI messages.

Written by John Levine, Author, Consultant & Speaker

EAI affects all of these pieces. In this article we'll look at some parts that don't directly interact with users, MSA, MTA, and MDA.

EAI Mail Submission

As I described in last year's articles, EAI creates a new parallel mail stream that can handle mail with UTF-8 characters in the mailbox name and other places that traditional SMTP mail doesn't. The MSA uses a new option code, SMTPUTF8, to tell MUAs that it can handle EAI mail. When an MUA submits a message that needs EAI features, it in turn uses the SMTPUTF8 option to say that this is an EAI message.

Since there will be parallel EAI and non-EAI mail streams for a long time, MSAs will have to support both, so for each submitted message, an MSA has to remember what kind of message it is, and a well-written MSA will try to verify whether an EAI message can actually be delivered. For example, if an EAI message is sent to an ASCII address, and the address happens to be handled by the same mail server as the MSA, it may be able to check whether that address is enabled for EAI mail, and if not immediately reject the message.

Since it is legal, albeit sloppy, to submit an ASCII message but set the UTFSMTP8 option, the MSA might check to see whether it's really an ASCII message, what I've called Deep Message Inspection, and if so treat it as one. Or if the recipient can't handle EAI, but the MSA happens to know that the submitting user also has an ASCII address and the message doesn't have other characteristics that require EAI, it is allowed (not required) to rewrite the message using ASCII addresses and turn it into an ASCII message.

EAI Mail Transfer

MTAs will also need to manage two mail streams, for ASCII and EAI mail. If an MTA receives an EAI message for an ASCII-only recipient, it will typically reject or bounce it. (The experimental predecessor of EAI tried to invent a general purpose EAI to ASCII downgrade scheme, but it turned out to be flaky and unworkable.) It could also do Deep Message Inspection to check whether EAI messages are in fact ASCII messages, and handle them as such. As mail is relayed to other MTAs, it needs to check that a recipient MTA for an EAI message supports UTFSMTP8 and if not, to bounce the message back to the sender.

EAI Mail Delivery

Some mail systems may make a "flash cut" so that all of their mailboxes handle EAI. Others may let users upgrade individually, as they upgrade their user mail software to handle EAI. In the latter case, the MDA needs to remember who handles EAI and who doesn't, so it can bounce EAI mail to non-EAI mailboxes. Alternatively, even if not all users have EAI software, a mail system can accept EAI mail to every mailbox, let the POP or IMAP server deal with the incompatibilities when the user tries to pick up the mail.

In our next installment, we'll look at what happens when there's EAI mail in an ASCII user's mailbox.

Written by John Levine, Author, Consultant & Speaker

Email Deliverability is considered to be affected by a mythical metric, the reputation of the sender, which is a measure of that sender behavior over time — and the reactions of the recipients to his messages.

As many industry veterans, over the years I've crafted a working definition that I use for this metric, which in my experience work very well as a performance predictor for the well-behaved mailing operators that I've had the pleasure to work with — and that has spared me of dealing with the other type of mailing operator. I'll call this metric a pseudo-reputation.

A Working Model

Nowadays email is an instant communication medium in the sense that messages can be delivered to the recipient's mailbox almost instantly most of the time. However, not everybody is waiting by the mailbox to read every new message as it arrives — although the mobile penetration is changing this.

Based on the demographics of the specific mailing list, messages will be read and acted upon within a time window that typically starts with a peak near the actual delivery and has a long tail. Chances are that a large proportion of the messages will be seen or acted upon within the first business day after delivery, but it's wise to allow a little extra time.

Then there's the engagement: The idea that senders need to reach frequently to their audiences to maintain their attention. Many senders resort to daily communications, so as to generate a repeated pattern of communication.

Different mail senders try to reconcile these facts as part of their very own secret sauce. In my case, I've found a mechanism that I called "n-day Window" for lack of a better name. The n-day Window allows the calculation of the pseudo-reputation in an easy way. The idea is to look at the rolling averages in a n-day time window over a comparatively long period to identify peaks and changes in the metrics.

The n in n-day is chosen based in the time it takes for a sizable percentage of the recipients to receive their messages — and ignoring comparatively long periods with no sending activity.

So, using this model with a 3-day window, a spreadsheet containing the total number of messages sent, the soft and hard bounces and the complaints received broken down per day can be easily put together. Then, the last 3-day totals would be compared producing an average of data spread over time.

Simplified Analysis

While it's reasonably simple to have data for the hard and soft bounces as well as for the feedback loop data — a.k.a. complaints — the model might not benefit from this directly. In many scenarios, it's valid to simply sum the number of complaints and the hard bounces, ignoring the soft bounces. After all, well maintained lists typically show small proportions of soft bounces.

This technique will produce a simple daily index that can easily be used to track the pseudo-reputation over time, correlating it with other metrics such as open rates, clicks, etc. This will allow the sender to fine tune the model, find better values of n and so on.

Thresholds and Goals

A typical question is what is the limit on the psedo-reputation value. And the answer is not easy. In general, senders are targeting recipients over many ISPs, each with different policies, response times, etc.

The typical sender probably has a few large ISPs that concentrate a large proportion of the recipients and naturally the tools have been tuned to work well in those cases: Bounces from the big ISPs are parsed and understood correctly, feedback loops are in place and are analyzed, etc.

But chances are that problems are not restricted to a single ISP. A mailing list that becomes uninteresting for its audience, will cause complaints and reactions all over the place, not only among the customers of a given ISP. However chances are that due to the status of the tools or differences in ISP policies — think of this as the ISP response time — the sender will get the feedback through one of the ISPs first, while the others will likely remain normal.

Because of this, tracking pseudo-reputation per-ISP is a good practice, provided that actions are triggered by the worst metric in the bunch.

The specific maximum acceptable value for the pseudo-reputation is harder to assess. Abrupt responses such as blocking a sender are not that frequent for well-behaved senders. Chances are that changes will happen over a longer period of time. And changes will happen at different speeds.

The industry as a whole seems to have converged in a the target for bounces or complaints around 0.1% (1 bounce or complaint per 1,000 messages sent). But in practice, problems start way earlier.

My observations suggest that when tracking pseudo-reputation with the model discussed above, effects can be measured with as little as 0.01% (1 bounce or complaint per 10,000 messages sent). Of course not all cases are alike — but long streaks of pseudo-reputation levels above this 0.01% figure often predict the onset of deliverability issues.

Simply put, there's no well-defined line in the sand. Instead, there's a wide gap. The higher the pseudo-reputation value, the faster your delivery probability decreases.

Written by Luis Muñoz

Now we have a similar suit filed in provincial court in British Columbia, Canada.

The argument is very much the same: the aggrieved parties have no business relationship with Google, send mail to Gmail users, and are shocked and horrified that Google shows its users ads based on what's in the messages, which mean that Google must be reading its users' mail. Since this is a Canadian suit, it's based on the B.C. Privacy Act.

Although Canada has much stronger privacy laws than the U.S., this suit appears to me (a non-lawyer and non-Canadian) just as absurd as the U.S. suits, because the argument that a mail provider isn't allowed to look at its users' mail is still ridiculous. The B.C. privacy law says:

(2) An act or conduct is not a violation of privacy if any of the following applies:

(a) it is consented to by some person entitled to consent;

It seems pretty self-evident to me that Gmail users are allowed to consent to Gmail looking at their mail, and although Gmail's Terms & Privacy page is remarkably short on details about Gmail (as opposed to Google in general), there's enough in there to make it clear that Google can pick ads based on what the user is looking at.

Canadian courts, unlike U.S. courts, generally have a loser pays rule which means that there is much less incentive for a defendant to settle when a plaintiff has a weak case. Sometimes the lead plaintiff, the person who's supposed to be a typical representative of the class of plaintiffs, is personally on the hook for the costs, although that seems uncommon in B.C., Google has every incentive to squash this case like a bug, so the main question is how far it gets before that happens.

Written by John Levine, Author, Consultant & Speaker

This is the first-ever outside funding received by the managed DNS and Email Delivery provider that incorporated in 2001. Since its origins at Worcester Polytechnic Institute, the company organically bootstrapped, securing a roster of enviable enterprise clients including Twitter, Zappos, CNBC and Pandora.

For North Bridge, the investment represents a chance to partner with one of the fastest growing technology companies in New England which has seen 70 percent compounding annual revenue growth in the past three years.

"We are doubling down in our commitment to being the world leader in Infrastructure as a Service and are delighted to partner with North Bridge, one of the leading technology and infrastructure investors in the country," said Dyn CEO and co-founder Jeremy Hitchcock. "This investment better positions us to cement our leadership position within a rapidly growing multibillion dollar IaaS opportunity."

"We have seen Dyn grow into the worldwide leader in Infrastructure as a Service with many of our portfolio companies as customers and are proud to be part of their story," added Ric Fulop and Russ Pyle of North Bridge. "We look forward to working with Jeremy, Tom and the Dyn team to help fuel their next decade of growth."

As part of the investment, Dyn is establishing a formal board of directors that will include:

• Jeremy Hitchcock, Dyn CEO and co-founder
• Tom Daly, Dyn Chief Scientist and co-founder
• Jason Calacanis, founder and CEO of Mahalo, co-founder of ThisWeekIn, co-founder and former CEO of Weblogs, Inc. (acq. by AOL) and a respected angel investor
• Ric Fulop, General Partner at North Bridge and co-founder of A123 Systems
• Russ Pyle, General Partner at North Bridge

In addition to over 2,000 enterprise clients, Dyn also services 450,000 ecommerce clients and over four million active users worldwide. The Manchester, N.H. based company, which also has offices in San Francisco, Brighton, UK, and Wrexham, UK, has 170 employees.

Waltham, Massachusetts-based North Bridge is also an investor in Dyn clients Disqus, Quora, Demandware, Acquia, and Spil Games.

Dyn is committed to the New Hampshire technology ecosystem. To support that community, the company added a co-investment from Borealis Ventures and its recently announced Granite Fund, which is focused on building New Hampshire's next generation of great technology companies.

The growth equity investment culminates a busy past month for Dyn, which recently acquired both TZO, a longtime leader in Managed DNS services, and the talent of the SEO/SEM and ecommerce development arm of Incutio LTD. Recent client wins include MLB Advanced Media, Zipcar, Spotify, LG CNS and Zillow.

Dyn was represented by Nixon Peabody, LLP for this deal, while Goodwin Procter, LLP represented North Bridge.

While spam from botnets is interesting, and the main source of spam, it is not the only source of spam. What about spam that originates from the MAGY sources?

MAGY stands for Microsoft (Hotmail/Outlook.com), AOL, Google (Gmail) and Yahoo. Spammers create botnets that go out, sign up for accounts on these services and then send spam from them. This continues until the service shuts them down.

Spammers also compromise legitimate MAGY users' accounts. Whatever method they use to acquire the password to these accounts, they subsequently log in and send spam until the user notices and changes their password.

In either case, this is known as reputation hijacking. Spammers are betting that spam filters will not IP block these accounts because it would cause too many false positives.

I've tracked mail from these four sources using the same scripts I use to track mail from botnets. I take the IPs in the service's SPF record and then record how much mail comes from these accounts. Below are some graphs of the total mail (not spam) from these services. Is there anything we can determine from these mailing patterns?

Before we continue, there are some things I must point out:

1. In August, my script that counts these things up crashed and died for a few days. I don't know why this is, but it mysteriously fixed itself without any intervention on my part.
2. I have not included the spam percentage in these figures. My goal is to only look at volume patterns.
3. I have only included six months worth of data — March through August 2012.

With that out of the way, what can we say about mail from MAGY? First up is Hotmail.

We can see that Hotmail uses a weekend sawtooth pattern — that is, during the week we see plenty of mail but it drops over the weekend. This means that most users are sending mail from Hotmail during the week but not on weekends.

Why is this?

It looks like people are sending from Hotmail at work but not from home on the weekends. Or possibly they do it at home but for some reason don't send that much mail from Hotmail on the weekend.

Do people have better things to do than send email on weekends?

Next up is Yahoo, the same caveats as #1-3 apply here, too.

Yahoo has the same sawtooth pattern as Hotmail but we see a spike at the end of March that was not present with Hotmail, and a huge spike in early July. These correspond to spam outbreaks (both in Yahoo and Hotmail). Whereas Hotmail had the spike near the end of the month, Yahoo's was near the beginning.

However, just like Hotmail, people aren't sending as much mail on the weekend.

Next up is Gmail. Below is their mail distribution sending to us:

Just like Hotmail and Yahoo, Gmail has the same sawtooth pattern. But unlike Hotmail and Yahoo, there are no spiky blips aside from my script crashing. We haven't seen any major spam campaigns from Gmail during this time.

Next is AOL:

As in the other three, there is the same sawtooth pattern, and a spiky blip in the middle of the Yahoo and Hotmail campaigns. This is evidence that spammers were rotating through those three services in July, but skipped Gmail. Interesting, the mail from AOL dropped off at the end of July and through the start of August but has since recovered.

So far, everyone pretty much looks the same. People send plenty of mail during the week but not so much on weekends. Weekends are roughly 35-40% the volume of weekdays.

But there is one exception to this pattern: Facebook. I collect statistics on mails from IPs on Facebook's TXT record. Below is what Facebook looks like:

Aha!

The sawtooth pattern here does not exist. Instead, it is very erratic but gradually increasing upward (that blip at the end looks ugly, doesn't it?). The summer months are really where we saw the largest gains, which corresponds to school finished for that part of the year.

Unlike the sawtooth pattern of MAGY, Facebook doesn't care about weekends very much. However, Facebook is not just about sending personal mail like Hotmail or Yahoo. Instead, Facebook sends you all sorts of notifications depending on your settings:

• Someone sent you a private message on Facebook
• Someone tagged you in a photo
• Sometime invited you to Farmville, or you have to take action
• And a bunch of others

But it doesn't really matter what people are doing, all of their friends are logged onto Facebook during all the days of the week and doing stuff, and people are getting alerts about it. Whether or not they read all those alerts is another question.

But it does go to show that people use Facebook differently than they use their email accounts. Email is for certain times of the day, Facebook is for whenever.

Written by Terry Zink, Program Manager

This study looks at the level in which national entities from 13 European countries gather, analyse and share (actionable) data or intelligence, participate in the national centres (to be) and cooperate at the national and international level.

The report provides conclusions and gives valuable recommendations provided by the participants to the study. You find a link to the report below.

Best wishes,

Wout de Natris

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

The DMARC Interopability event has been announced and will take place July 19th and 20th in Menlo Park California. As with previous interoperability events for other standards such as DKIM, the event for DMARC will help implementers ensure that their software is free of most basic interoperability barriers.

If you are writing and implementing DMARC code this is an event you shouldn't miss. If you do not have running code this is not an event for you.

Written by Michael Hammer

A hacker claims to have accessed Romney's Hotmail and Dropbox accounts after guessing the answer to the Republican candidate's 'favourite pet' security question. It's suspected Romney used the same password for more than one account.

While Romney's camp has refused to confirm or deny the hack, it is likely to be worrying for the Republican party. Their 2008 vice presidential candidate Sarah Palin had her Yahoo email account hacked and some of the contents were published online.

Romney's personal email address was published by The Associated Press earlier this year. Some of his private emails had been accessed under Massachusetts law because he had used his Hotmail account to conduct government business while serving as the state's governor.

There are concerns in political circles about the risks involved with using online email accounts for government business as they are usually more easily hacked than accounts hosted on company and government servers. Government watchdogs say the practice also raises transparency concerns, as emails sent through private accounts aren't archived with the emails sent from government accounts.

Probably the most noteworthy example was when the Bush administration was unable to produce all internal White House emails during investigations into the sacking of eight US attorneys in 2007. The White House was forced to admit that some government emails were sent via non-governmental email accounts and more than five million messages may have been either lost or deleted.

Do you use an online email account for business purposes? Do you think this is risky or does it work well for you? I would like to hear your thoughts in the comments section below.

Written by Susanna Sharpe, Social Media Manager

The PBL (Policy Block List) includes ranges of addresses that shouldn't be sending mail directly, either because they're retail customers who are supposed to use their providers' mail servers, or they're assigned to equipment that should send no mail at all. Each entry is a range of addresses. List maintenance is manual; network managers can and often do add ranges of their own addresses, and Spamhaus adds ranges that they've determined are appropriate. In some cases, it's possible to de-list an individual address to poke a hole in a PBL range and allow mail out.

The SBL is managed manually, and lists ranges of IP addresses that based on historical evidence are likely to send predominantly or entirely spam. Some SBL entries are single IP addresses, while others list entire networks that are controlled by criminals.

The XBL lists individual IP addresses of hosts that have been observed sending 'bot spam or other mechanical indications that they are likely to send spam but no legitimate mail. Listings are added automatically, and are removed automatically some time after the IP stops sending spam. It's usually possible to remove an entry manually, although not an unlimited number of times.

How do these map into a world of IPv6 mail?

All three kinds of lists still make sense, but it's much less clear how large a range of addresses each entry should be. In general, the high 64 bits of a 128 IPv6 address are the network number, and the low 64 bits are the host number within that network, but network operators have a great deal of latitude how they assign addresses. A cable ISP would probably assign a /64 to each user, but they might assign a /56 to a business customer that has more than a single LAN in its office. On the other hand, a hosting company might assign a /64 to a data center, to a rack in a data center, to a single server, or maybe to a blade on the server.

The SBL style lists are relatively straightforward, the range to list is chosen manually in IPv4, and it'll be chosen manually in IPv6. But granularity matters for the other two styles.

When a piece of spam triggers an entry in a botnet list, just listing the individual IP isn't likely to be very effective, since in the bot can use a different address on the same network for each message. (On IPv4 networks, hosts generally get an address via DHCP from the router, on IPv6 they just get the nework part from the router, and make up their own low bits, so they don't have to ask anyone to make up new low bits.) This means that in the common case that a bot is on a home or small office network, a botnet list would want to list the network, which might be a /64, or if it's in a hosting center, whatever range of addresses is allocated to the compromised server.

For policy lists like the PBL, the range to list is set by the network manager, but it's often possible for individuals to ask to delist their own IPs. It's an open question whether an IPv6 delist should be just for a single IP (since that's all a mail server needs), or the whole LAN.

At this point, there is no reliable way to look inside a network and see what the suballocation sizes are. There's some work going on, both a son-of-WHOIS project which could let networks publish the info along with the rest of the WHOIS info for the IP block and (unlike the current WHOIS mess) other people could query it mechanically. I've also talked to a few people at the IETF who say it's not out of the question to provide it through tweaks to existing protocols, but that would be some way out.

With information about suballocation sizes, it should be possible to manage IPv6 DNSBLs as effectively as IPv4 ones, but there's still the issue of whether it's practical to use existing methords to query them. Fortunately for the e-mail world, it will be many years before there is any v6 mail that can't be handled just as well via v4, so we have time to figure all these things out.

Written by John Levine, Author, Consultant & Speaker