The web is social, and thus minor features can matter a lot
For a very long time, DWiki (the software behind this blog) had a very primitive comment system. One of the ways that it was primitive is that it didn't have any explicit user-visible field for your name. When you made a comment here it showed up with your IP address at the time and it was up to you to explicitly sign the comment in some way if you wanted to. I always knew that this was rather low-rent, but it took me years to get around to fixing it. One of the reasons that I didn't get around to it very fast was that I didn't see it as a very important change; after all, it was just being a bit more explicit about comment author identification.
I was wrong. After I made the change last August, my perception of the entire character of the comments section here changed. The easiest way to put it is that suddenly I was reading and interacting with people, people with names (and sometimes websites). Part of this is that people actually filled in their names where before many hadn't gone to the extra work of signing their messages, but another part of it is that once I had people's names I changed how comments were displayed to show the name instead of the IP address. And the two together worked a magic transformation from bland IP addresses to named people.
The first lesson I draw from this is something that I already knew in theory, namely that the web is a social place. Interacting with people is a powerful thing and we like it. The more we see our interactions on the web that way, the better, which means that features that encourage that feeling are probably a good idea (even if they're small and simple ones, as here).
The second lesson is the power of small changes (or at least what you think of as small changes). My current guess or theory about this is that ultimately the illusion of personhood on the web is made out of smoke and mirrors; it's at least partially a trick we all play on ourselves when we imbue some codepoints on a screen with personhood and so on. As a trick, little nudges can go a long way (and probably little glitches can ruin the illusion). We're predisposed to see things on the web (and anywhere) as people, so all it needs is a push to do it and that push can be a small one.
(This goes with the general idea that people are social that I wrote about a long time ago.)
(I doubt that this is a novel observation. I just feel like writing it down due to my own striking experience with the DWiki comment change. Such a relatively small change, such a big shift.)
Weird spammer behavior: a non-relaying relay attempt
One of the the interesting things about running a sinkhole SMTP server that accepts everything and basically serves as a spamtrap is that I get to see all sorts of odd and crazy spammer behavior. Take the following SMTP transaction log:
220 hisokusa.cs.toronto.edu go-smtpd HELO smelektronik.de 250 hisokusa.cs.toronto.edu Hello 188.8.131.52 MAIL FROM: <email@example.com> 250 Okay, I'll believe you for now RCPT TO: <XXXX@hawkwind.utcs.utoronto.ca> 250 Okay, I'll believe you for now RCPT TO: <firstname.lastname@example.org> 250 Okay, I'll believe you for now RCPT TO: <email@example.com> 250 Okay, I'll believe you for now DATA ....
This is a CBL-listed IP address and the spaces after the ':' in
MAIL FROM and
RCPT TO is typical of badly implemented spamware
(it's not RFC-compliant, although many mailers will accept it).
The interesting thing is the second and third
RCPT TO addresses.
My sinkhole here is not the
MX target for any of them (of course).
Sometimes you'll see deliberate relay attempt probes, but this
doesn't seem to be one of them. Instead it looks like the spammer's
software is just clumping lexically similar domains together and
then dumping N addresses one the
MX target of the first one,
regardless of whether the additional addresses will ever get accepted
(almost no MTA will, because almost all are configured to not relay
About all I can guess is that someone wrote software that either has a bug or that is simply extremely sloppy and wrong, and the authors either never tested it or don't care. Perhaps they make their money from selling it to people who simply don't notice that an appreciable amount of their delivery attempts can never succeed. I suppose the customers are probably not in a position to really notice this behavior.
(My logs shows three such attempts so far in a few days, from two different IPs in total. It all appears to be the same spam run.)