2015-02-27
Email from generic word domains is usually advance fee fraud spam
One of the patterns I've observed in the email sent to my sinkhole
SMTP server is what I'll call the 'generic word domain' one. Pretty
much any email that is from an address at any generic word domain
(such as 'accountant.com', 'client.com', 'online.com', or 'lawyer.com')
is an advance fee fraud spam. It isn't sent from or associated with
the actual servers involved in the domain (if there's anything more
than a parking web page full of ads), it's just that advanced fee
fraud spammers seem to really like using those domains as their
MAIL FROM addresses and often (although not always) the 'From:'
in their message.
Advance fee fraud spammers use other addresses, of course, and I haven't done enough of a study to see if my collection of them prefers generic nouns, other addresses (eg various free email providers), or just whatever address is attached to the account or email server they're exploiting to send out their spam. I was going to say that I'd seen only a tiny bit of phish spam that used this sort of domain name, but it turns out that a recent cluster of phish spam follows this pattern (using addresses like 'suspension@failure.com', 'product@client.com', and 'nfsid@nice.com').
I assume that advance fee fraud spammers are doing this to make their spam sound more official and real, just as they like to borrow the domains of things associated with the particular variant of the scam they're using (eg a spam from someone who claims to be a UN staff member may well be sent from a UN-related domain, or at least from something that sounds like it). I expect that the owners of most of these 'generic word' domains are just using them to collect ad revenues, not email, and so don't particularly care about the email being sent 'from' them.
(Although I did discover while researching this that 'nice.com' is a real company that may even send email on occasion, rather to my surprise. I suspect that they bought their domain name from the original squatter.)
(This elaborates on a tweet of mine, and is something that I've been noticing for many years.)
What limits how fast we can install machines
Every so often I read about people talking about how fast they can get new machines installed and operational, generally in the context of how some system management framework or another accelerates the whole process. This has always kind of amused me, not because our install process is particularly fast but instead because of why it's not so fast:
The limit on how fast we install machines is how fast they can unpack packages to the local disk.
That's what takes almost all of the time; fetching (from a local mirror or the install media) and then unpacking a variegated pile of Ubuntu packages. A good part of this is the media speed of the install media, some of this is write speed to the system's disks, and some of this is all of the fiddling around that dpkg does in the process of installing packages, running postinstall scripts, and so on. The same thing is true of installing CentOS machines, OmniOS machines, and so on; almost all of the time is in the system installer and packaging system. What framework we wrap around this doesn't matter because we spend almost no time in said framework or doing things by hand.
The immediate corollary to this is that the only way to make any of our installs go much faster would be to do less work, ranging from installing fewer packages to drastic approaches where we reduce our 'package installs' towards 'unpack a tarball' (which would minimize package manager overhead). There are probably ways to do approach this, but again they have relatively little to do with what system install framework we use.
(I think part of the slowness is simply package manager overhead instead of raw disk IO speed limits. But this is inescapable unless we somehow jettison the package manager entirely.)
Sidebar: an illustration of how media speeds matter
Over time I've observed that both installs in my testing virtual machines and installs using the virtual DVDs provided by many KVM over IP management processors are clearly faster than installs done from real physical DVDs plugged into the machine. I've always assumed that this is because reading a DVD image from my local disk is faster than doing it from a real DVD drive (even including any KVM over IP virtual device network overhead).