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.