Wandering Thoughts

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.)

I've now received my first spam email over IPv6

One of the machines that I run my sinkhole SMTP server on has an IPv6 address, one that's currently present in DNS as the target of an MX record (not literally, of course, it's the AAAA record of the host that's the MX target). Back in October, in a somewhat different DNS setup, it saw its first IPv6 probe, and has seen a number since then. A bit over a week ago it got its first actual spam email over IPv6.

The source IPv6 address is in Asia, which doesn't surprise me; my impression is that APNIC is one of the most active areas for IPv6 usage for various reasons (including IPv4 address exhaustion). The sending host appears to also have an IPv4 address, but apparently it prefers to use IPv6 if it can (which is again not surprising). Its IPv4 address is listed in a couple of DNS blocklists, including b.barracudacentral.org, but is not in Spamhaus or the CBL.

(Spamhaus has an old policy statement about IPv6 that gives an example of querying them for IPv6 addresses. Out of curiosity I tried it for this IPv6 address and not unsurprisingly got nothing. I don't know if Spamhaus, or anyone else, is actually serving IPv6 address DNS blocklist information or if everyone has punted so far.)

The actual spam is your standard variety advance fee fraud spam, claiming to be from a completely unrelated email address in cox.net with replies directed to another address at 'net-c.com'. The spam message claims to be from someone with 'Egmont group, USA', which probably explains the choice of cox.net as the From: and sender address.

(The spammer probably means this Egmont group, which is plausible given the rest of the spam message, which is a typical 'we believe you have been scammed, we have some compensation to give you' thing. Since I didn't know about the Egmont group before this, I can't say that spam isn't educational.)

I have some vague thoughts on IPv6 and spam, but I've decided that they're for another entry. I have seen periodic IPv6 connections, but they appear to mostly be TLS scanners.

(My logs say that Google tried to deliver email over IPv6 back in early December, but I refused it because email from GMail to this sinkhole server is far too likely to be boring spam, usually advance fee fraud attempts. Perhaps I should declare that all spam received over IPv6 is interesting enough to capture.)

How the IPs sending us malware break down (January 2018 edition)

I recently wrote about how a misbehaving SMTP sender fooled me about some malware volume because it kept retrying the same message over and over despite getting permanent SMTP rejections. This made me interested in getting some numbers on how our malware rejections break down in terms of how many repeats, how many sources, and so on. All of the following figures are for roughly the past four and a half weeks.

The starting figure is that over this time we've done 2,729 rejections for malware and viruses. About 175 of these are have the same sending IP, sender address, destination address, and detected malware as other entries, making it very likely that they're resends. The most active resent message was rejected 97 times (that was the one with an ISO); after that we had one rejected 10 times (with 'CXmail/OleDl-AG'), one 8 times (with 'CXmail/OleDl-AL'), four that were rejected 3 times, and a whole fifty five that were rejected twice.

The resends came from 15 different IPs, including two other mail servers at the university; since these mail servers work properly, the 'resent' messages were actually more or less duplicated messages. It's possible that they originally came from different source IPs. Overall it seems that bad SMTP servers that resend in the face of permanent SMTP rejections are pretty uncommon.

(Since I'm blindly looking at messages across a very wide time range, it's possible that a number of the other 'resends' are really duplicate messages created by long-lived malware with insufficient variety in its sender addresses. Over four weeks, it's certainly possible that such malware would revolve around to targeting some of our addresses a second time.)

These 2,729 rejections came from only 124 different IP addresses (including a number of other mail systems at the university), with much of the volume coming from some very active sources:

   649 115.59.74.248
   443 115.59.74.242
   227 27.50.138.69
   210 115.59.74.243
   196 115.59.74.249
    97 103.4.122.16
 [...]
    41 27.50.138.100

115.59.74.0/24 is SBL387172 and 27.50.138.0/24 is SBL387171, both listed as 'suspected snowshoe spam' ranges. A few other less active IPs are in the CSS, SBL388761, and SBL383008. Somewhat to my surprise, only 24 of the IPs are currently in the XBL, although many of the earlier senders may have aged out.

(The true volume of malware from these SBL listed IPs is likely to be clearly higher than this, since some of their email will have been rejected at the RCPT TO phase.)

Only eight of the IPs sent us more than one type of malware, and a number of them are other mail systems that are forwarding email to some of our users and thus are aggregating a number of different real sources together. The 115.59.74.0/24 block sent us 'Mal/Phish-A' and 'Troj/Phish-BPZ'; the 27.50.138.0/24 block sent us 'Mal/Phish-A'.

(Since these were detected as malware, they were almost certainly HTML files as attachments, which is the pattern we've seen.)

However, many of the active sources tried to send email to quite a lot of different addresses here, as shown by a top five count:

   140 115.59.74.242
    99 27.50.138.69
    74 115.59.74.243
    64 115.59.74.248
    61 115.59.74.249

This is basically the pattern I would expect from spam sending operations, which is what these are. Aggregated together, 115.59.74.0/24 tried to send to 203 different addresses and 27.50.138.0/24 tried to send to 110. A lot of the destination addresses were targeted repeatedly in both cases.

With one exception, the most popular sender addresses were random GMail addresses like 'thivisid08@gmail.com'. The exception is 'quickbooks-email@notificationsystem.org', which was used for 27 messages from 21 different IPs, all trying to deliver a 'CXmail/OleDl-V' malware payload. Overall there were 1,610 different sender addresses, but 1,559 of them were GMail addresses.

(I was going to say that none of these would pass GMail's DMARC policy, but apparently Google blinked on their plans for a strict one. Right now GMail still publishes a 'p=none' DMARC policy that doesn't ask people to reject email that fails to pass DKIM and/or SPF tests.)

A misbehaving SMTP sender can fool me about malware volume

One of the things that I do is casually watch our external mail gateway's logs of mail rejections due to viruses and malware. When unusual things pop up, I then tend to look at what attachment file types were associated with this, in case something unusual pops up, or just things we want to block explicitly. For the past couple of weeks I've been seeing a reasonable number of rejections for what Sophos PureMessage is calling 'CXmail/IsoDl-A' and our attachment type logger was recording as:

attachment application/x-iso9660-image; MIME file ext: .iso; tar no files?!

(The 'tar no files?!' portion means that this was identified and accepted as a tar file by Python's tarfile module but that it contained no files. I don't know why this is happening.)

That we were seeing a reasonable number of these seemed interesting and maybe a bit alarming. Distributing malware in ISO images is bit eyebrow raising, but who knows, and of course I'd like for our tools to be able to see inside them (or at least figure out why they have an empty tarfile). So today I started some work on improving the situation and looked at our logs in more detail. When I did that, something jumped out at me: almost all of them were from the same IP address. Further, when I scanned some additional logs, everything I looked at had the same MAIL FROM and was all to the same email address here.

In other words, what we have here is another case of a sending system that thinks permanent failures are only temporary. The IP address in question (103.4.122.16, lweb1.slnet.com.au) responds on port 25 with a Postfix banner, so they may have unwisely set the Postfix soft_bounce option, or perhaps their web panel did it for them.

(Since the message headers Exim logged talk about 'Roundcube Webmail', one may guess that these people are running an insecure and more or less unmonitored webmail environment.)

Each of the re-delivery attempts of this particular message got logged separately, of course, since they were separate SMTP transactions and separate rejections. This inflated the log volume, making it look like there were a lot more ISO attachments and CXmail/IsoDl-A activity than there actually is.

(This IP is not the only source of messages with CXmail/IsoDl-A, but there aren't very many others and they do go away when we give them SMTP rejections.)

One of the lessons I draw from this is that perhaps I should write some scripts to generate systematic summary reports from our logs. If I did that, I could invest the effort to have the script look for this sort of resending and account for it, so I got a better picture of the real activity level of various sorts of malware and so on.

PS: TLS certificates are an interesting new vector for determining who is using a particular IP address (or at least determining one set of people). It's handy that they're increasingly prevalent. Of course this may not be the responsible party, to the extent that there is any party that considers themselves 'responsible' for any particular behavior of the machine.

Attachment types that we see in email from Zen-listed IP addresses

As part of yesterday's entry, I broke down what percent of various sorts of attachments we received came from IPs listed in zen.spamhaus.org. Today I'm going to basically invert the question and ask instead what sort of attachment types we get sent from Zen-listed IPs. As before, I'm going to be using the past nine weeks and a bit of logs, because our weekly log rotation makes it easy to do that.

(Because our attachment type logging comes after our RCPT TO time rejections, this is all based on email to people who don't reject all email from Zen-listed IPs.)

First up we have a collection of attachment types without MIME file names (and thus without MIME file extensions). For these I have to rely on the declared MIME types and sniffed file type information, and they break down like this:

   102 [Word XML]
    13 application/msword
    11 image/jpeg
    10 message/rfc822
    10 application/xml [either Word or Excel]
     6 [Excel XML]
     1 image/gif

Possibly this means that I should recurse inside message/rfc822 MIME parts. Some of these were file attachments; others I believe were the sole component of the email message.

Of attachments with MIME file names, the type breakdown is:

  1032 .doc
   623 .docx
   576 .html
   545 .htm
   308 .pdf
   253 .zip
   248 .xlsx
   170 .xls
   109 .jar
    90 .jpg
    83 .aspx
    61 .7z
    48 .ace
    26 .r11
    22 .xz
    20 .gz
    19 .tar
    15 .r00 .png
    14 .gif
    11 .rar
    10 .pdf.gz
     6 .iso .arj
     4 .pdf.z
     3 .txt .jpeg .chm
     1 .rtf .r01 .ppsx .lzh .bat

On the one hand, this is a broad assortment with a long tail. On the other hand, there's some very popular attachment types, especially Microsoft Word documents. I suspect that if I ground through our logs to cross-correlate them, I'd discover that a lot of these were seen as malware. Based on past discoveries, the .html and .htm are likely phish spam, perhaps with some malware mixed in.

(All of the .rars that we could successfully examine had .exes in them and got rejected on that basis.)

Those .zip archives break down as containing:

   114 .exe
    86 .zip
    26 .jar
    25 .vbs
     1 ".lnk .txt"
     1 .com

We rejected all the ZIP archives with .exe or .vbs payloads.

The inner .zip files are:

    84 .doc
     1 .scr
     1 .js

It turns out that we rejected all of these. The .scr and .js files got rejected by a generic 'in-zip' case, which is perfectly happy to match nested zips as well as plain zips. The doubly nested .doc files have been rejected for some time.

(It turns out that the few nested ZIPs in yesterday's entry that weren't from Zen-listed IPs must have all been .doc files.)

PS: That I keep having to check what we're actually rejecting suggests that our attachment type rejection rules are now sufficiently complicated that I should actually write them down, instead of leaving them sort of implicitly documented in the Exim configuration and then trying to remember them (it turns out that I got at least one case wrong in yesterday's entry). Possibly this will cause us to regularize some of them. Probably we won't drop any.

What file types we see inside ZIP archives with only a single file in email

Earlier this year, I wrote about how email attachments of a single .zip inside another zip were suspicious, and then did a file type breakdown for them. Malware is ever-mutating so nested ZIP archives have gone out of style by now, but instead we're seeing a not insignificant amount of attachments that are ZIP archives with only a single file in them. Today I want to do a breakdown of those file types that we've seen over the past nine weeks or so.

So here are the raw numbers; for some types I've added the percent that were received from IPs listed in zen.spamhaus.org at the time:

   434 .exe         (26%)
    91 .zip         (94%)
    86 .jar         (30%)
    43 .vbs         (58%)
    13 .bat          (0%)
     6 .com         (17%, ie 1)
     3 .wsf .pdf
     2 .scr .py .js
     1 .xls .rkt .rar .pot .jse .hta .eml .docx .csv

(Overall, about 36% of these messages were from IPs listed in zen.spamhaus.org at the time.)

Some of these we reject immediately these days, such as the .exe and .wsf cases. Others we probably should, like .js, .com, .vbs, and .bat (which we already reject as top-level attachments).

The single nested .zip cases break down like this:

    89  inner zip exts: .doc
     1  inner zip exts: .scr
     1  inner zip exts: .js

It's somewhat interesting to me that in all cases, there's only a single file inside the inner zip. Because of past events, we also reject the doubly nested .doc files. We'll also reject the doubly-nested .js attachment (because it's a .js inside a ZIP archive, even a nested one), but not the .scr one.

Unfortunately, what stands out in this list is the nested .jar files. Partly this is because these days Sophos PureMessage is identifying all of them as malware, for example CXmail/JarZip-A (which we saw in an epic case) and also Mal/DrodZp-A. Not a single one is making it through all of our anti-spam and anti-virus filtering to reach our users as presumed legitimate email.

(It's possible that this identification by Sophos is generic and means very little more than 'a single .jar file inside a .zip with some vague additional threat markers'. This doesn't matter in practice, since the net effect is the same.)

PS: As you might suspect, this entry came about because I noticed that .jars in .zips were being rejected as malware and then decided to go look at the numbers to see if we should be rejecting them immediately. My current answer is that we probably should be, along with some other rejections, although there are arguments against this reaction.