2005-09-10
Hotmail's Other Spam Problem
The 'Microsoft Personal Addresses' issue covered in HotmailSpamProblem is not Hotmail's only problem with spam.
Real Hotmail email addresses are a not insignificant source of various forms of advance fee fraud spam. Much of it comes from SBL and XBL listed IP addresses, sufficiently many that we've had to do Hotmail's filtering job for it as discussed back in WebmailBadSources.
In this day and age, letting IP addresses like 80.179.107.229 (listed since January 2005 as SBL15568) or 212.52.145.234 (SBL22101, December 2004) send email out through one's services counts as at least significant disregard for other people on the Internet. Hotmail is serving as an enabler to these people's spamming; it should not be.
Shame on you, Hotmail and Microsoft. I expected better from a company that claims to be as firmly anti-spam as Microsoft has been in the past. Filing big lawsuits is nice, but you need to do other things too.
Hotmail and other webmail providers are 'attractive nuisances' for spammers, much like accessible swimming pools are for kids. It is time (and long past the time) that Hotmail and others put up the antispam equivalent of fences.
Hotmail has a spam problem
Allow me to make that more sensational: Hotmail has a bad spam problem. Despite everything that Microsoft has said and done about being against spam, their Hotmail service is the source and the facilitator of an increasingly large amount of spam email.
As noticed most recently by Chris Linfoot in a series of blog entries (How to abuse Hotmail and get away with it and More on Hotmail and Personal Addresses), Microsoft will allow more or less anyone to register a 'Microsoft Personal Address'.
A 'Microsoft Personal Address' is your own domain name. Through Hotmail, Microsoft provides all of the services your domain needs: DNS, incoming mail, a URL forwarding service, and even outgoing email through Hotmail's own mail machines. In other words, about eight and a half yards of the full nine yards of spam support.
Worse, Microsoft provides no mechanism for people to report spam related to these domains. As Chris Linfoot has discovered, even complaints about spam email sent from Hotmail's own servers will be rejected by Hotmail with a form letter claiming that they are not responsible for any of this because it doesn't involve a '@hotmail.com' mail address.
Practically any other ISP in the world would be publically pilloried for spam support this blatant, and several of them have been. But for some reason Microsoft and Hotmail get a free pass, despite the parade of various sorts of advance fee fraud spams that constantly emanate from Hotmail's mail servers.
Locally, we have dealt with this problem by refusing any email message
from the Hotmail mail servers that doesn't have a MAIL FROM of
hotmail.com. In at least a year of operation, we have yet to have a
user complain that they aren't getting email, and we routinely reject
200 such messages every week. Unfortunately this is not something that
leads to a real solution, since it does almost nothing to get Hotmail's
attention or make it painful for them to continue doing it.
Chris Linfoot has also had to do this. (And shortly after he put the rule into place, it started blocking spam. Not surprising; at around 200 a week, that's 28 spam messages a day from Hotmail's servers.)
More Fedora Core 4 Anaconda fun
Another day, another Fedora Core 4 Anaconda bug stumbled over. This time it is #160911, where if your system has any bind mounts, Anaconda can't upgrade it and aborts. (Some other systems call bind mounts 'loopback mounts'.) From the error message that I remember, it seems that Anaconda was trying to treat the source directory as a disk device and not getting very far.
Naturally I was in too much of a hurry to actually get our central fileserver upgraded to remember to save any debugging logs that Anaconda might have written. (Suggestion to the Anaconda people: make Anaconda automatically save its logs any time it aborts an installation. Disk space is cheap, you can put a message in about it, and it will save everyone a bunch of effort.)
Workaround: assuming that the bind mount is not for anything vital,
temporarily comment it out of your /etc/fstab. Remember to comment
it back in before you bring the system up, or things may explode.
(If the bind mount is for something vital, I believe you are up the
creek. Watch #160911 for updates.)
The thing that really irritates me is that this is a new Anaconda bug; the Fedora Core 2 Anaconda did this right. And I know that because we upgraded this very central fileserver, with this very bind mount, from Red Hat 7.3 to Fedora Core 2 without problems.
It is depressing to think that perhaps the best advice for the future is 'don't do anything on a new Fedora Core without reading the Anaconda buglist front to back'. Or maybe the entire bug list, given the (finally fixed) X bugs mentioned in FC4FirstIrritations.
An update on the unlabeled swap partitions bug
Since I managed to get our central fileserver upgraded, clearly I
worked around the 'Multiple devices are labelled' bug I covered in
AnotherFC4AnacondaBug. Unfortunately, mkswap -L didn't do it,
either with the FC4 source code recompiled on FC2 and run while the
system was up, or in the FC4 installer environment itself.
Eventual workaround: totally zeroing out both swap partitions with
dd from /dev/zero. This meant that our Fedora Core 4 install came
up without swap partitions (since they did not have valid signatures),
but fortunately the server has enough memory that it doesn't need swap
to boot. After it came up I used mkswap -L on both partitions.
Since mkswap -L didn't work, I now have the sinking feeling that
this problem is going to reappear next upgrade.