Getting (and capturing) spam can sometimes be useful to see what's in it

April 12, 2019

We have what is now a long standing system for logging email attachment type information (everyone should have one). For more than a year we've been receiving .iso attachments that caused our program to log cryptic reports claiming that we sniffed these as tar archives that were oddly empty:

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

(This one is unusual in that it had a correct MIME type. The more common MIME type these come with is application/octet-stream.)

Our commercial anti-spam system (Sophos PureMessage) consistently identifies these as CXmail/IsoDl-A.

I've been vaguely wanting to figure out why these messages cause our program to do this and what was actually in these file attachments for some time, but I've been hampered by the fact that I didn't actually have an example file. Our email system consistently rejects these for being malware (and anyway they weren't sent to me), and for various reasons we don't try to have our attachment type logging system save copies of things under any circumstances. I added some extra logging to the system, but it didn't produce anything.

(In some environments, an attachment logging and filtering system would be critical enough that you should be able to capture copies of things that either cause it problems or that seem questionable. In our environment, it's not and making it capture things would raise both operational issues (like managing what it captures and not running out of disk space) and policy ones (around privacy and so on).)

However, I also run a sinkhole SMTP server on another machine. Recently it got a boring spam message which I almost ignored, except that I noticed it had a suspicious attachment that claimed to be an ISO file in the MIME type information (although it had a .img extension). Out of a spirit of curiosity, I extracted the attachment and poked around in it, discovering that it really was an ISO image (well, a UDF filesystem) and contained a single .EXE. Out of more curiosity, I fed it to our attachment logger program to see if it would reproduce the 'tar no files?!' issue. Lo and behold, it did. Now armed with a reproduction case that I could poke around in, I was soon able to narrow this down to a long standing issue in the Python tarfile module.

So, every so often it's useful to get (and capture) spam. Provided that it's interesting and useful spam, at least.

Comments on this page:

Maybe equip the sinkhole with some kind of trait matching so it can look out for kinds of spam that you are currently specifically interested in and alert you to them? Or do you have too few use cases to justify the effort for such a feature?

By cks at 2019-04-12 14:49:30:

Basically I don't have enough activity on either side to make such a check a useful feature. My sinkhole accepts very little spam to start with (because most of what it would otherwise accept is boring, like advance fee fraud, which I already have a ton of samples of), and it doesn't really get the same kind of spam as our main mailserver does.

If I needed this in any non-casual way, I would probably end up trapping samples on the main mail server. Both the technical and the policy issues are things we could deal with if we needed to.

(The simple way to deal with the policy issues is not to look at trapped samples until and unless the person they were sent to gives us the okay. I think most of our users would say 'sure' under the circumstances, especially if we only trapped copies of things that we were rejecting to start with.)

Written on 12 April 2019.
« The tarfile module is too generous about what is considered a tar file
WireGuard was pleasantly easy to get working behind a NAT (or several) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Apr 12 00:20:38 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.