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
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 (220.127.116.11, 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.
X's network transparency has wound up mostly being a failure
I was recently reading Mark Dominus's entry about some X keyboard problems, in which he said in passing (quoting himself):
I have been wondering for years if X's vaunted network transparency was as big a failure as it seemed: an interesting idea, worth trying out, but one that eventually turned out to be more trouble than it was worth. [...]
My first reaction was to bristle, because I use X's network transparency
all of the time at work. I have several
programs to make it work very smoothly,
and some core portions of my environment would be basically impossible
without it. But there's a big qualification on my use of X's network
transparency, namely that it's essentially all for text. When I
occasionally go outside of this all-text environment of
emacs and so on, it doesn't go as well.
X's network transparency was not designed as 'it will run
well'; originally it was to be something that should let you run
almost everything remotely, providing a full environment. Even apart
from the practical issues covered in Daniel Stone's slide
clear that it's been years since X could deliver a real first class
environment over the network. You cannot operate with X over the
network in the same way that you do locally. Trying to do so is
painful and involves many things that either don't work at all or
perform so badly that you don't want to use them.
In my view, there are two things that did in general X network transparency. The first is that networks turned out to not be fast enough even for ordinary things that people wanted to do, at least not the way that X used them. The obvious case is web browsers; once the web moved to lots of images and worse, video, that was pretty much it, especially with 24-bit colour.
(It's obviously not impossible to deliver video across the network with good performance, since YouTube and everyone else does it. But their video is highly encoded in specialized formats, not handled by any sort of general 'send successive images to the display' system.)
The second is that the communication facilities that X provided were too narrow and limited. This forced people to go outside of them in order to do all sorts of things, starting with audio and moving on to things like DBus and other ways of coordinating environments, handling sophisticated configuration systems, modern fonts, and so on. When people designed these additional communication protocols, the result generally wasn't something that could be used over the network (especially not without a bunch of setup work that you had to do in addition to remote X). Basic X clients that use X properties for everything may be genuinely network transparent, but there are very few of those left these days.
xterm is any more, at least if you use XFT fonts. XFT
fonts are rendered in the client, and so different hosts may have
different renderings of the same thing, cf.)
What remains of X's network transparency is still useful to some of us, but it's only a shadow of what the original design aimed for. I don't think it was a mistake for X to specifically design it in (to the extent that they did, which is less than you might think), and it did help X out pragmatically in the days of X terminals, but that's mostly it.
(I continue to think that remote display protocols are useful in general, but I'm in an usual situation. Most people only ever interact with remote machines with either text mode SSH or a browser talking to a web server on the remote machine.)
PS: The X protocol issues with synchronous requests that Daniel Stone talks about don't help the situation, but I think that even with those edges sanded off X's network transparency wouldn't be a success. Arguably X's protocol model committed a lesser version of part of the NeWS mistake.