Wandering Thoughts

People receiving email don't feel it should be their job to stop spam

There is a popular observation when people get spam, especially spam from places that specialize in sending email such as Sendgrid, and that is that these places are not infrequently pretty good about handling spam issues. Sometimes they have 'complain that this is spam' links right in the email headers (not Sendgrid, though), or similar things. But thinking that this is sufficient is a mistake, perhaps not in the short term but definitely in the long term (in my opinion).

What places that are merely 'good at responding to complaints' are really doing is making it the job of people receiving email to deal with spam. Unsurprisingly, not infrequently people are unhappy with this, either quietly or loudly. As a general rule, people do not want it to be their job to deal with spam; they want it to be your job (where 'you' is some combination of the people operating their mail system and the people responsible for sending email to them). That in practice it currently is their job, requiring a bunch of labour and a bunch of annoying workarounds and hacks, is something that people are not exactly pleased about. They consider this a flaw in the system, and it is.

(Spam in general is a fundamental hard problem, but spam from major mail sending providers is merely because they aren't interested in trying hard enough to stop it.)

Of course, people receiving email do not necessarily understand the situation in the way I've put it here. But we do know that they are unhappy to get spam (there are very few people who are happy to get it); even if they are 'happy' to be able to do something to make it go away, they would be happier to not have to deal with spam at all. The more work they have to do and the less certain that work is in making the spam go away, the more unhappy they are, until you reach the stage of someone like me.

PS: A great many things are 'making it the job of the receiver to deal with spam', including the very basic one of 'I think I will use GMail and live with its drawbacks because they have really good spam filtering'. Certainly not taking genuinely effective steps to stop spam senders and then waiting for the complaints to roll in is one of them; the mail sending place has effectively outsourced a significant part of its spam detection to the people receiving its email. If said people did nothing, the mail sending place would not know it was being used to send spam.

PPS: To cut off one possible reply in advance, a claim of 'if no one complains, clearly it wasn't spam' is demonstrably and obviously false and anyone advancing it as a defense is either morally vacuous or doing so in a cynical manipulation to deflect criticism. That marketing and advertising organizations love to make claims like this is one reason why a great many people hate them.

How to run a mail sending service that will probably never send spam

I have written any number of times before that mail sending services could take steps that would make sure almost no spam would be sent through them, but they don't bother (eg on Amazon, on modern mailing list services in general and earlier). However, I have not written down my view of these steps, partly because I have considered them obvious in the community in general. For various reasons, I now feel like writing these steps down. So here is an incomplete list of obvious steps to take that would mostly gut sending spam through such a service.

In no particular order:

• Charge people a decent amount of money for your service, possibly with a deposit up front. Don't have a free or a cheap tier, because it attracts the wrong sort of customer (Patrick McKenzie has written at length on how too-low or free pricing is a bad idea in SaaS in general).

• Force people to put their address lists on your service, not just funnel their email through in bulk sending. Forced uploads allow you to scan the address list in advance to look for known warning signs, such as definitely nonexistent domains or known-bad addresses that never accept your email.

• Require all email addresses submitted to you by a particular customer to be confirmed. The gold standard would be confirming separately for every alleged mailing list the customer sets up; the silver standard is confirming once when the customer first submits the address as part of any list and then assuming that the customer has the right to use that address in other lists. As part of requiring confirmation, provide an extra link that communicates to you 'I have never heard of these people and I do not know why they have my email address'. Even a moderate level of use of this link is a warning sign.

  It should go without saying that having more than a trace level of bounces or email rejections during confirmation should be a big warning sign.

  Probably the silver version is the most realistic, since these days customers may not have distinct 'mailing lists' as such, if they're using you to deliver event-based notifications to people's email and so on.

  (Even sending an initial notification email to people saying 'your address has been added to our system by <customer>' would be a step forward. These days a mail sending service could claim it was a GDPR requirement.)

• Run all submitted mailing list messages through all of the available free open source anti-spam and anti-virus systems, and perhaps at least one of the commercial ones. If any of the systems flag the message, don't send the email and surface this in an alert both to the customer and to your abuse handling team.

  (It's not a service to the customer to let them send out email that you know will trip spam alerts for some recipients. Legitimate customers will likely thank you for such a pre-check service, and may even want a way to submit draft messages to it.)

• Make it trivial for people to report unsolicited email and spam, and to 'unsubscribe'.
• Pay attention to bounces, SMTP rejections in general, unsubscribes, and spam complaints. Mine them for addresses to add to your list of warning addresses. Rejections after SMTP DATA are probably an especially bad warning sign, because they suggest it was content filtering that caused the rejection.

  (As part of this, you should obviously recognize and parse the various SMTP 4xx and 5xx messages that major email providers use when they're dealing with questionable email messages. But this is so obvious that I suspect that any mail sending SaaS that wants to be successful is already doing it.)

I'm assuming as a baseline that you will do things like accept bounces and replies and properly implementing SMTP. These days you may want SPF, DKIM, or DMARC in order to pacify various large email providers who are getting increasingly insistent on it, but that's more in the realm of 'competently operating a commercial service'.

I'm pretty confident that any mail sending service that implemented all of these would send almost no spam, and I'm reasonably confident that it would still have a business. But of course it wouldn't have a business that's as big as you'd get by not bothering to do some of these things (especially confirming email addresses), and it would cost more to operate, and you wouldn't have as many customers because a certain number of the more shady people would stay away (as would all of the cheap people).

My GDPR pessimism

The latest great hope of various people, more or less including myself, is that the European GDPR will come along and put an end to various sorts of annoying email marketing activities and other intrusive ad and marketing activities. Under the GDPR, so goes the theory, companies like Yubico and Red Hat will not be able to abuse email addresses they happen to have sitting around to send marketing email; in fact they may not even have those email addresses sitting around at all.

(At least for people in the EU. The further great hope of the GDPR is that many companies affected by it won't bother trying to tackle the near-impossible task of figuring out who's in the EU and who's not.)

I'd like to believe this, but I'm not sure that I do. I'm not basing this on any examination of the GDPR or on what people have written about it. Instead, my pessimism comes from the cynical version of the Golden Rule. My simple observation that regardless of what they say, governments very rarely actually kill off entire decent-sized industries and slap large fines on a wide variety of prosperous and perfectly normal corporations who are conducting business as usual. It might happen, but it seems much more likely that there will be delays and 'clarifications' and so on that in the end cause the GDPR to have little practical effect on this sort of activity. If there is change, I expect it to happen only very slowly, as countries slow-walk things like fines as much as possible in favour of 'consulting' and 'advising' and so on with companies.

(In other words, a lot of stern letters and not many other effects. And I expect companies to take advantage of this to stall as much as possible, and to plead implementation difficulties and other things that tragically mean they can't comply quite yet. It may all be very theatrical, in the 'security theater' sense.)

Partly I come by this pessimism by watching what's happened with Canada's theoretically relatively strong anti-spam law. One of the strong features of this law was that it created a private right of action, where you could start a civil case against violators and thus you didn't have to depend on the official regulator getting around to doing something. Since Canada is a loser-pays legal system, this was always going to be a reasonably risky activity, but then in 2017 this provision was quietly suspended, including the charming quote:

The Government supports a balanced approach that protects the interests of consumers while eliminating any unintended consequences for organizations that have legitimate reasons for communicating electronically with Canadians.

This provision has yet to be revived, and there have been no 2018 enforcement actions by the CRTC under CASL (at least none that appear in the CRTC's public records).

It's possible that the EU will be more aggressive and determined about the GDPR and violations of it than Canada has been about our lauded (at the time) anti-spam law, especially in today's climate with increased public concern about these sort of issues, but I'm not going to hold my breath.

PS: It turns out that there has been some activity on the CASL front (and, and, and, and) and there may be good news someday. But if so, it will probably be significantly later than the already slow timeline that CASL itself specified. Applications to the speed of GDPR are left as an exercise for the reader.

Yubico fails to care that people give you email addresses for specific purposes

A while back, Yubico had a little security issue that forced it to replace any number of Yubikey 4s, including mine. In order to do this, they required people to give them an email address so they could send you some necessary information; following my usual practice I gave them a tagged, individualized address. Today I received email to that address, received from the server of a domain called 'mktomail.com', that started out like this:

Subject: Passwordless authentication is here

Yubico scales across enterprise

Passwords are out. You're in!

The passswordless evolution of the FIDO U2F standard has arrived with FIDO2. [... marketing materials removed with prejudice ...]

You are receiving this email because you made a Yubico purchase or contacted Yubico.

I'm sorry, that's not how this works. In the normal course of events, people do not give you email addresses to do with as you will; people give you email addresses for specific purposes. In this case, I gave Yubico an email address to get a defective product fixed, but one might report a bug, contact product support, or perform other limited interactions with the company. These specific and limited purposes do not include 'receive unsolicited commercial marketing emails'.

Of course, the marketing department does not want to hear this. The marketing department wants to use every plausible address it can get its hands on. People these days vaguely get that you usually cannot buy addresses from other people without getting badly burned, but they keep thinking that other addresses are fair game, regardless of the purpose for which they were originally handed to the company.

Some of the time, the company supports the marketing department, as it did at Yubico, and these addresses get used outside of the purpose they were given to the company. At that point the company betrays the trust of the people who handed over their email addresses in good faith and pisses off some number of people who have interacted with the company in the past, some of which have actually bought their products. The results are predictable, as is the resulting form-letter evasion.

(When enough companies do this sort of thing for long enough, you get things like the EU's GDPR, which will likely make this conduct illegal. Sadly it is probably not illegal under Canada's anti-spam legislation, and anyway I expect Yubico to ignore the GDPR issues until they or someone else visible gets slapped with a nice fine for this sort of thing.)

Sadly I have no idea what is a viable alternative to Yubikeys, but at least we're not likely to buy any more any time soon.

What sorts of good email attachments our users get (April 2018 edition)

I've looked at various breakdowns of bad attachment types that get sent to our users, but of course that's not the only reason we collect all of this data. In fact it's the lesser reason; the greater one is to know the legitimate types of files our users get in email. So today I'm going to look at a week's worth of data from our central mail server, which is logged after all rejecting, filtering, and spam tagging has been applied.

Over that week, we logged 4,166 attachments from 3,093 email messages. Some email messages had quite a lot of attachments; the winner had 26 attachments, and then there's one with 23, two with 12, four with 9, nine with 8, and I've run out of patience to count from there. The median message has one attachment, though, as you'd expect.

Almost all of the attachments had MIME filenames; only 50 didn't. For those 50, the MIME types varied, with the most popular one being message/rfc822, but there are also images, text/plain, text/html, PGP signatures, and apparently one Office XML file. For the attachments with MIME file extensions, the most popular types break down like this:

  2339 MIME file ext: .pdf
   429 MIME file ext: .docx
   273 MIME file ext: .jpg
   159 MIME file ext: .xlsx
   125 MIME file ext: .png
    91 MIME file ext: .doc
    72 MIME file ext: .ics
    69 MIME file ext: .txt
    57 MIME file ext: .asc
    54 MIME file ext: .html

There were 72 different MIME file extensions in total, although some of them are clearly not real file extensions but instead just parts of the filename that happened to go after a dot. One is a timestamp, for example. These may be for regular filenames that had extra stuff added on, for example 'file.pdf.<timestamp>'.

The popularity of PDF files is no surprise, given that we're a university department. That may also explain how MS Word scores relatively highly (and perhaps the spreadsheets too, but I don't know there). All of the .asc cases are PGP signatures (and were sent with the MIME type application/pgp-signature), and some of them come from mailing list email that I get.

I took a look at MIME type information, and unsurprisingly it is somewhat less reliable than MIME file extensions. For instance, here is the MIME type breakdown for .pdf attachments:

  2160 application/pdf
   175 application/octet-stream
     1 pdf
     1 application/octetstream
     1 application/octet
     1 application/download

Looking at all attachments, application/octet-stream was the third most popular MIME type. Mostly it's used for PDFs, but there is a long tail of MIME filename extensions, which doesn't really surprise me. If a mail program is attaching something to a message and it's not completely sure what it is, application/octet-stream will get the job done and no one can really argue with you for picking it.

(Sometimes I look at this data and what I find is, well, data.)

Spam from Yahoo Groups has quietly disappeared

Over the years I have written several times about what was, at the time, an ongoing serious and long-term spam problem with email from Yahoo Groups. Not only was spam almost all of the Groups email that we got, but it was also clear that Yahoo Groups was allowing spammers to create their own mailing lists. I was coincidentally reminded of this history recently, so I wondered how things were today.

One answer is that spam from Yahoo Groups has disappeared. Oh, it's not completely and utterly gone; we rejected one probable spam in last December and two at the end of July 2017, which is almost as far back as our readily accessible logs go (they stretch back to June 15th, 2017). But for pretty much anyone, much less what it was before, that counts as completely vanished. Certainly it counts for not having any sort of spam problem.

But this is the tip of the iceberg, because it turns out that email volume from Yahoo Groups has fallen off significantly as well. We almost always get under ten accepted messages a day from Yahoo Groups, and some days we get none. Even after removing the spam, this is nothing like four years ago in 2014, when my entry implies that we got about 22 non-spam messages a day from Yahoo Groups.

At one level I'm not surprised. Yahoo has been visibly and loudly dying for quite a while now, so I bet that a lot of people and groups have moved away from Yahoo Groups. If you had an active group that you cared about, it was clearly time to find alternate hosting quite some time ago and probably many people did (likely with Google Groups). At another level, I'm a bit surprised that it's this dramatic a shift. I would have expected plenty of people and groups to stick around until the very end, out of either inertia or ignorance. Perhaps Yahoo Groups service got so bad and so unreliable that even people who don't pay attention to computer news noticed that there was some problem.

On the other hand there's another metric, the amount of email from Yahoo Groups that was rejected due to bad destination addresses here (and how many different addresses there are). We almost always seen a small number of such rejections a day, and the evidence suggests that almost all of them are for the same few addresses. There are old, obsolete addresses here that have been rejecting Yahoo Groups email since last June, and Yahoo Groups is still trying to send email to them. Apparently they don't even handle locally generated bounces, never mind bounces that they refuse to accept back. I can't say I'm too surprised.

Given all of this I can't say I regret the slow motion demise of Yahoo Groups. At this point I'm not going to wish it was happening faster, because it's no longer causing us problems (and clearly hasn't been for more than half a year), but it's also clearly still not healthy. It's just that either the spammers abandoned it too or they finally got thrown off. (Perhaps a combination of both.)

Sometimes, not trying to reject some sort of spam is the right answer

I've written before about not doing anything about a temporary spate of spam, and it remains a useful guideline. But sometimes you're pretty convinced that certain spam patterns are long-standing, and it turns out that the right answer is still to not do anything, however reluctantly. As it happens, I have an example that we recently decided on.

One of the patterns we observe is that a decent amount of the attachments we get come from IPs listed in the Spamhaus Zen DNSBL. A further pattern we've seen is that a decent amount of those are detected as malware (see eg this), and we've also seen that there are some highly active Zen-listed sources (see this set of numbers from January). Given all of this, I recently put forward the idea of rejecting all messages from Zen-listed IPs that had an attachment, for the same broad reason that we reject some sorts of attachments; we're almost completely sure that these emails are bad and they're often dangerous, but our commercial anti-spam package may not pick the malware up on its own and cause us to reject them.

When I put it that way, this probably sounds good, and certainly that's how I thought of the idea when I proposed it. Then I put together some numbers, based on how many messages we would actually be shielding users from if we did this. It turned out that many of the messages were already being rejected and almost all of the remaining messages were already being scored as spam (and when I say 'almost all', I mean 816 out of 820).

We had a long discussion and decided that we weren't going to reject these messages. There are local reasons for why not that I'm not going to get into, but apart from them there is a larger one that caused me to not argue too hard for the rejections, which is that this doesn't seem like something with a high payoff in practice. It's not just that the volume is not huge; it's also that basically everything is already being detected as bad (and at least some of our users are discarding the email based on that).

There's an almost infinite set of things that you could do to reduce spam, with some payoff (and many with a reasonably worthwhile one). The challenge about anti-spam work is not finding things to do to reduce spam, it is partly in not doing things, because every thing you do has a cost that goes with its benefits. Sometimes that cost is too high relative to the gain, and it's not because the particular sort of spam is temporary; it's because the sort of spam is already being blocked well enough as it is, even though you could do better.

Sure, some of our users could ignore the 'this is probably spam' warnings and fall for malware that we allowed to be delivered to them. There could even be bad stuff in those four email messages that weren't scored as spam (to be honest, there probably was at least spam). But our existing system is doing well enough even though it's not perfect, and it's already complicated enough. So doing nothing this time is the right answer.

(It helps here that in the past I've enthusiastically put in some clever anti-spam trick, only to have it make somewhat less impact than I was hoping for. That's not a good feeling either.)

The correlation between Spamhaus Zen listings and attachment types (March 2018 edition)

Our program to capture information about what sort of email attachments our users get logs not just the attachment information but also whether or not the sending IP address was listed in zen.spamhaus.org at the time. For reasons beyond the scope of this entry, today I want to look at the correlation between sending us attachments and being in Spamhaus Zen, and what attachment types are popular. Because it's the most convenient option, I'm going to use four weeks of recent logs.

Over this time we logged 15,900 incoming messages with attachments (20,395 attachments total), although given my previous experience it's possible that some of these are repeated attempts from misbehaving senders that believe permanent SMTP rejections are just temporary. 3,890 of these messages (3,925 attachments total) were in the Spamhaus Zen at the time, or about one quarter, which is neither huge nor insignificant. The most popular attachment types for Zen listed IPs to send us are as follows:

  1312 MIME file ext: .html     [89%]
   754 MIME file ext: .docx     [38%]
   516 MIME file ext: .doc      [59%]
   352 MIME file ext: .xlsx     [51%]
   120 MIME file ext: .xls      [54%]
    85 MIME file ext: .pdf      [ 1%]
    57 MIME file ext: .pdf.gz   [87%]
    42 MIME file ext: .ace      [28%]

(For simplicity I'm looking only at things with MIME file extensions. 705 attachments in total, 435 from Zen-listed IPs, did not have file extensions. Almost all of the Zen-listed ones were Microsoft Word documents, usually .docx.)

The percentages are against the total number of that attachment type we received. PDFs by far our most popular attachment type in general, followed by .docx, .html (almost all from Zen listed IPs), JPGs, .doc, .png, and .xlsx.

The '.pdf.gz' attachments are actually all .exe files in disguise, which we reject. I'm not sure why malware tries this, but presumably it works on some people and some systems. The .html attachments are very likely to be what our commercial spam filtering system scores as 'Mal/Phish', because this is a pattern we see all the time. We reject all .ace attachments in general as they're all malware, so I find it interesting that only 30% of them come from Zen listed IPs; there seem to be a fair number of malware senders that aren't in Zen.

(This is something to bear in mind if you feel that the Zen alone will do a great job of protecting you. I'm not saying it won't; it depends on what you're worried about and what the attack patterns are against you.)

With the exception of .html (and the special case of .pdf.gz), there's no attachment type that is clearly beloved of Zen-listed IPs, although they're over-represented in a number of them (where they're roughly half of those attachment types despite being only roughly a quarter of our attachment volume). This seems mostly likely to be due to relatively low usage by legitimate senders rather than high usage by Zen-listed IPs. In turn this is probably because of the profile of our users probably tilts away from the use of Microsoft Office files.

Because of how we do server side spam filtering, some amount of Zen-listed IP addresses that would send us attachments don't make it this far, because they get entirely rejected at RCPT TO time. It's difficult to estimate how many such rejections we might have, so I'm not going to guess or try to throw raw numbers around.

PS: If I'm understanding the logs correctly, the number of Zen-listed IPs that sent us attachments is a drop in the bucket compared to the total number of Zen-listed IPs that got as far as submitting email. My log analysis suggests that there were roughly 77,500 such email submissions over the same time period, from 18,800 different IPs.

(See also the related attachment types we see in email from Zen-listed IP addresses, from last December. Some of the patterns have clearly shifted since then. For the absolute numbers, note that I did nine weeks of data then and I'm doing four weeks now.)

Sidebar: Some people are confused about MIME types

We got two messages with JPGs that were attached with the MIME type '*/*', which is not how MIME types work. Sadly I suspect that many mail clients will display the JPGs anyway, because that's how the Internet works (and it's not necessarily a bad thing, and even when it is it's hard to persuade people of that).

(Someone may have been thinking of browsers when they generated that MIME type, or they may just have been refusing to even try.)

A spammer misses a glorious opportunity

Most of the spam that I collect on the machines that I run my sinkhole SMTP server on is boring spam. Since it's boring, I've tried to block as much of it as possible; still, there are plenty of cases that get through, because that sort of spam can come from all over. Today I got what initially looked like one of those boring spams that sneak through. It appeared in my log like this:

[...] from 196.15.235.161 / <REDACTED@justice.gov.za> to <REDACTED>: [...] helo 'mail3.justice.gov.za' [...]

I saw that and shrugged; clearly it was another forged advance fee fraud spam, just like the ones claiming to be from the FBI. But when I looked at the full metadata of the logged message, I got a surprise. There in the metadata was the resolved, verified DNS name of the sending IP and it was mail3.justice.gov.za. This wasn't email pretending to be from the South Africa's Department of Justice; this actually was email from one of the DoJ's mail servers. The reverse DNS is real and valid, and in fact this IP is one of the four MX servers for justice.gov.za (a second MX server is right beside it in that /24).

So why do I call this a spammer missing a glorious opportunity? Well, let me show you the important bits of the spam message itself:

From: REDACTED <REDACTED@justice.gov.za>
To: "info@cc.com" <info@cc.com>
Subject: HELPDESK

To All,

Today Monday 12th of March 2018. We are shutting down your present web-mail to create space for 2018 Outlook Web Access with a high visual definition and Space.
This service creates more space and easy access to email. Please update your account by clicking on the link below and fill information for Activation.

[...]

That's right. Given the golden opportunity of access to the real, legitimate mail servers of the Department of Justice of South Africa (likely via a compromised account), the spammer used it to send not the most genuine looking advance fee fraud you could imagine, but a garden variety, completely untargeted phish spam.

Of course there's decent, boring reasons for this. For a start, the actual IP address source of advance fee fraud spam is completely unimportant, because the recipients who will even think of checking that aren't the kind of people who will fall for the spam in the first place. If anything, advance fee fraud spammers apparently may deliberately make their spam look bad and suspicious, so that anyone who actually answers is highly likely to be gullible enough to go through with the whole thing, instead of wasting their time. If that's so, sending from the real justice.gov.za is, if anything, a thing to avoid.

Still, I wish the spam message had been advance fee fraud. That's the way the universe should be when you get the chance to use justice.gov.za for your spam.

The question of what will be sending email spam over IPv6

In reaction to receiving my first spam email over IPv6, I've been thinking a bit about the moderate term future of email spam over IPv6. One of the questions I have is what will be sending out such email spam. More narrowly, will IPv6 spam email happen as an incidental side effect of random dual-stack machines trying IPv6 connections before IPv4 ones (as in my case), or will it be a deliberate attempt by spam operations to use IPv6 to evade various sorts of IPv4 blocks and other issues?

I'm interested in this question because it affects how important things like IPv6 DNS blocklists are, or just in general making sure that anti-spam precautions are ready for IPv6 and won't either explode or let people bypass them because of it. Also, obviously, it affects how desirable it is to allow yourself to receive email over IPv6 is at all. If enabling IPv6 SMTP is opening yourself to a flood of professional spam operations that will immediately pounce in the hopes that your defenses are low, you probably want to think twice about that (or at least make quite sure that your defenses aren't).

My current belief is that in the next few years, IPv6 email spam will almost entirely be the incidental side effect of random dual-stack machines instead of deliberate work by professional spammers. My reason for this is that I don't think the payoff for bringing up and using IPv6 is very high for such spammers. Most of the world and thus most of their targets are still IPv4 only and will be for some time; there is only a limited selection of IPv6 reachable targets, and many of the biggest ones are probably well defended even against IPv6 (I'm confident that Google Mail is, for example). Such a spammer might get some incremental improvements from also trying IPv6, but operating a dual-stack environment is more effort and there's also fixing your software to work with IPv6. It's almost certainly simpler to just keep using IPv4 only.

(There are probably plenty of people who would be more vulnerable via IPv6, but many of them are not even reachable by IPv6, especially for email. IPv6 email reachability is more than having IPv6 connectivity; you probably have to go out of your way to advertise an IPv6 address for your MX gateway.)

This matters for IPv6 DNS blocklists (and for client code that may or may not be able to query DNS blocklists for IPv6 addresses). If professional spam operations that are currently being blocked by things like the SBL CSS switch over to IPv6 to evade those blocks, we may have problems. However we'd only have those problems until Spamhaus brought up full IPv6 support (which they may already have done, and which they've certainly been thinking about for more than half a decade) and mailers and so on were updated to work right for IPv6 DNSBLs. This would probably happen pretty rapidly if professional spammers shifted in volume (since a bunch of people would get pretty motivated), which is another reason to not worry about it. If people would compensate pretty rapidly, professional spammers definitely don't get much out of the effort of bringing up IPv6.

(I'm sure there will be professional spam operations working over IPv6, but that's because more and more people will be IPv6 enabled in general. Spam just comes along for the ride as part of the ambient Internet background noise.)