It's possible to track FIOS rollouts merely by noting spam sources whose rDNS matches it, e.g., "*.fios.verizon.net". To date, this has been a 100.00% indicator of spam. For example, in the last few minutes, one of my mail servers has observed the following:
That's a mail server with one user. Production mail servers with tens of thousands of users typically note 5000-10000 such systems every day.
So from here, it appears that new FIOS rollouts are being 0wned nearly as quickly as they're connected, and that they're staying 0wned. I'm sure the spammers are quite pleased with the quality service provided by Verizon et.al.
As has been noted in numerous places, Comcast isn't just forging RST packets to disrupt P2P traffic -- they're also doing it to disrupt Lotus Notes traffic...which makes the "we're doing it to stop the bad guys" excuse a transparent lie.
Moreover, disrupting P2P traffic will have no effect on "spammers and other miscreants", as they have far more sophisticated, self-organizing C&C methods already deployed. (No doubt having anticipated that use of traditional P2P would leave them vulnerable to such countermeaures.)
But the truly galling part is that Comcast continues to repeat the same big lie they trotted out years ago: "We take the spam problem seriously". This is utter nonsense, of course; spam emission levels from their network continue to steadily increase, as they have for half a decade, to the point where their only serious rival for the #1 spot on the world's list of top spam-sending network is Verizon.
So what this episode tells us is that Comcast has the capability to monitor and modify traffic, but only chooses to do so when it might affect their profits -- not when it might could the unceasing flow of abuse outbound from their network.
The problem is not that users fail to use anti-virus, anti-spyware, anti-phishing, anti-left-handed-metric-wrench software.
The problem is that users CHOOSE to use operating system and applications which are so miserably designed and written that they are susceptible to these problems as-shipped by the vendor(s). (I take the position that any OS which needs anti-virus software to survive in the wild is clearly broken and should never by used. By anyone.)
Anti-* software is a band-aid. Its use is a clear indication that the product it's trying to band-aid is broken. And anyone deliberately using known-broken products should not be very surprised if Bad Things happen as a result.
It continues to amaze me that anyone is surprised by this -- although I suppose by now I ought to have gotten accustomed to this state of affairs. [Some] people install obviously defective operating systems (e.g., any version of Windows), use obviously defective mail clients (e.g., Outlook), use obviously defective web browsers (e.g., IE) and then actually expect that they can somehow make up for this series of stunningly poor decisions by installing enough add-ons. It doesn't work, of course, which is why we see hundreds of millions of infected systems out there, spewing spam, conducting DoS attacks, poking at web servers, brute-forcing ssh servers, and so on.
My point being that by the time the conversation has gotten to anti-* software -- it's too late. The damage has been done, and there's no undoing it (despite lots of wishful thinking and the earnest assurances of anti-* vendors, who of course, let's not forget, have a substantial profit motive).
(Ah. About this point, some M$ apologist will raise one of the usual canards -- for example, "M$ products are attacked because they're popular". Not true, of course; M$ products are attacked because they're miserably weak as a result of incompetent design and even worse implementation. M$ is hardly alone in this, it's that for some inexplicable reason, it seems to attract the most defenders -- despite the fact that as possibly the most well-funded, well-staffed, well-equipped software company in the world...it has repeatedly proven that it can't even write a decent mail client.)
So. These studies shouldn't ask questions like "Are you using anti-spyware?" They should ask questions like "Why are you dumb enough to use an OS/application software combination so badly written and maintained that anti-spyware is deemed necessary?"
Others have already explained at length how this is yet another FUSSP -- and they're quite correct. It appears to be the product of the same confusion that gave us SPF, Domain Keys, et.al.: that is, mistaking the forgery problem for the spam problem. Yes, they're related; yes; they're both abusive; and yes, they're often seen together; but they are NOT the same problem and it's a serious, fundamental error to think they are.
At this point in time, there is no solution to the forgery problem available, because there are (depending on whose estimates you'd like to believe) something between 10e7 and 10e8 (or more) fully-compromised systems out there, which are of course capable of transmitting mail using any identity whose credentials are located on those systems. No fix is even on the horizon for that situation.
As to the spam problem, a limited solution presents itself via this approach: any system which emits spam is either (a) owned by a spammer, that is, a leased server in a co-lo or similar or (b) broken, that is, an open SMTP relay or perhaps a system with an exploitable proxy or (c) hijacked by a spammer, that is, effectively owned while still putatively under the control of its "real" owner.
In all cases, such systems are de facto enemy territory, and the appropriate course of action is to (a) identify them and (b) deny ALL traffic from them until they're no longer enemy territory. There is little sense in expending bandwidth, CPU cycles, and expertise trying to work out what traffic from them might not be spam -- even if this futile effort is successful, it doesn't matter, because accepting traffic from a known-hostile source is just not a good idea no matter what might be in it. Moreover, due to failure to maintain and monitor RFC 2821 and RFC 2142 role addresses, refusing mail is often the ONLY way to bring the attention of the responsible party to the situation (I'm thinking of (b), above, here).
But back to this FUSSP: consider for a moment how this system could be used to target attacks via (a) forgeries (b) redirected MX records (c) fast-flux DNS (d) targeting of blind users (which is why ANY use of captchas is quite, quite stupid) (e) deliberately induced deadlock (f) bogus responses to mailing list traffic and (g) some number of other things that will probably occur to me if I can force myself to read this poorly-written gibberish again.
My own experiments show much larger numbers: in January 2007, one such experiment revealed a confirmed 1.8M bots with another.7M probable/possible. The number of bots worldwide has been estimated by others as in the range of 100M (Evron et.al. 70M; Cerf, 140M) so I very much question the methodology used here.
I wouldn't be suprised in the least if the worldwide numbers were much higher. But there's no way they're less than ~100M.
For starters, it's quite easy to run a secure, high-performance, scalable mail system using open-source tools on cheap hardware. An *example* of such a combination might be: OpenBSD, postfix, SpamAssassin, CLamAV, UW-IMAP, perdition. This combination supports secure POP and IMAP, along with mail submission via SSL and TLS, thus accomodating horribly broken clients like Outlook. Building a cluster of such systems (to distribute load and provide fault-tolerance) is a well-understood exercise.
Second, any solution which does not support Internet standard protocols like POP and IMAP may be rejected immediately. It's far too silly to merit serious consideration.
Third, there are some very troubling questions here concerning: - security - privacy - data retention - data repurposing - academic integrity For example, we have seen a series of serious security problems at MSN/Hotmail; there is no reason to believe that any other service operated by Microsoft will be unblemished. We have seen disturbing policy changes at Google in re their data retention. We have seen privacy issues at Yahoo. And so on. My point being that none of these services have providing convincing proof that they can operate at a level acceptable for professional use.
Moreover, entangling a university's computing infrastructure with a commercial organization's raises questions of academic integrity: which is why having the mail system operated by the university's own professional staff (who are under the university's authority) seems necessary to me in order to exert an acceptable level of control.
I find this news very disconcerting; even more so when I read that others report that their institutions are considering similar moves. While it may be attractive financially (although I would be perfectly to bet that I could implement an in-house solution that's cheaper), this is not something that should be scrimped on. Faculty, staff, and student communications are too important to be delegated to the lowest bidder.
The obvious way is to try to work out which IP addresses the crawler is operating from, and use the business end of a firewall to block it. (Given past events, I don't think a robots.txt is likely to work.)
A less-obvious way is to discover what the watermark is and slap it onto a few...hundred million files that have nothing to do with what it's looking for. Those files don't need to have actual audio content -- as long as they meet the criteria that the spider is looking for. So perhaps a bit of Perl, a few calls to rand() and some well-chosen filenames might be enough.
Registerfly is one the few registrars that has earned a blacklist-on-sight policy for any domain registered with it. Their complete failure to take any action against any domain -- for spamming, spyware, phishing, and worse -- indicates to me that the registrar is run by incompetent amateurs.
I won't recommend another registrar because I don't want it to seem like I'm shillling for them; but I'll recommend also avoiding GoDaddy, Bulkregister, GKG, Nameking and Domains at Cost simply to avoid sending someone from frying pan to fire.
But I don't think you can possibly do worse than Registerfly.
While I'll grant that your point is true for *some* systems, it's not true for most. If you watch network traffic with tools such as ntop or etherape for a while (especially the latter thanks to the way that it facilitates visualization), and then focus on particular systems, what you'll likely find it that traffic patterns are surprisingly predictable.
Consider, for example, a client system (OS doesn't matter) sitting on a corporate network. It probably uses DHCP at boot and periodically thereafter -- so we should expect to see light, sporadic DHCP traffic and we should expect to see that traffic confined to the LAN. It probably uses local DNS servers (and has been told about them via DHCP) so we should expect to see a relatively low-level stream of DNS queries and we should expect to see all of them directed at those local servers. We should expect to see HTTP requests going out -- but none coming in. We should expect to see SMTP traffic going out, but only to local SMTP servers and none coming in.
And so on. Now -- as someone pointed out in a followup -- a good way to make *sure* that this is what we see is to put in place a solid firewall and configure it properly -- starting with bidirectional "deny all" and then opening up only the ports/protocols necessary. (And then we can also use that firewall to observe exceptions to the "normal" traffic that I started to laundry-list above.)
This gets sightly more complicated for servers, especially multi-purpose ones, but it's still a tractable problem. For example, an inbound SMTP gateway should not be sending out HTTP requests; and a dedicated web server shouldn't be making outbound SMTP connections (except perhaps to a local SMTP server for mail traffic generated on the web server).
The Bad Guys can evade some of this by severely rate-limiting traffic. But while that makes detection more difficult, it does at least mean that their attempt at evasion slows down their own attacks. And that malware which just blunders around is more likely to be spotted, which helps a little bit.
So it's not "a fix" or anything like that; it's just another approach, to be combined with firewalls/self-scanning/etc.
This idea was discussed in considerable depth on various anti-spam lists several years ago. Nearly all hosts on the Internet talk to one mail server: the one designated for mail submission from the network they're on. (s/one/few/ for networks large enough to have multiple SMTP gateways.)
Such systems, if observed suddenly making connections on port 25 to hundreds (or more) other mail servers, are almost certainly spewing spam. This is particularly true if those connections meet certain criteria (e.g. traffic sent before waiting for SMTP greeting from remote side, or failure to send QUIT before closing connection). Slapping a port 25 block on such systems at least partially quarantines the problem, buying time for more thorough investigation.
The same could be said of systems observed making hundreds of SSH connections (to one destination or many), etc. The basic concept is to figure out what "normal" looks like -- which, granted, may vary with what uses a system normally has -- and then do something when things don't look normal. "something" could be "log it" or "issue an alert" or "rate-limit connections" or "rate-limit traffic" or "block" or some combination; the trick is to select an appropriate response that does something useful while not making the mechanism so twitchy that it trips when it shouldn't.
A. This problem has been discussed in depth on various anti-spam mailng lists and newsgroups for many years. This long-standing problem has been steadfastly ignored by Yahoo, who went so far as to dismiss the key people on their own abuse staff when they tried to address it.
As a consequence, it's now a better-than-even bet that any site hosted by Yahoo belongs to a spammer, phisher, spyware injector, child pornographer, scammer or other lowlife. My own meager list of Yahoo-hosted dropboxes for such stands at 26,831 this morning and those are just the ones that brought themselves to my attention, i.e. I'm passively noting them and not actively searching them out.
As a result, Yahoo is one of the biggest spam-sending and spam-supporting operations on the entire Internet. (Oh, and Geocities is now completely infested. Rejecting all inbound mail [except anti-spam discussions] that contains a Geocities URL is a surprising effective tactic.)
B. They're not alone. For instance, MSN BCentral should be renamed MSN SpamCentral -- it's just as bad. And Hotmail cheerfully hosts spammer dropboxes by the tens of thousands.
There are others, but what makes these two particularly annoying is that they make a public show of being anti-spam by promoting snake-oil like SenderID and DomainKeys, both of which are worthless. (If it isn't obvious why, then think about the hundreds of millions of zombies -- hijacked Windows systems -- out there and consider that their new masters have possession of all email credentials belonging to their former owners -- from POP passwords to PGP keys. It is not possible to solve the forgery problem -- for any useful definition of "solve" -- without solving this problem first. Good luck. This same thing applies to SPF and variants, by the way, all of which are complete failures.)
Another thing that distinguishes them is the absolutely irresponsible, totally clueless way in which abuse reports are handled. Most seem to disappear into black holes. The majority of the rest are returned with semi-literate denials that the abuse has any connection with their operation -- even when their own IP address are clearly the source. If you'd like to browse a huge number of examples of this, go to Usenet's news.admin.net-abuse.email and search for "Yahoo clueless" or "Hotmail clueless". Make coffee first.
The bottom line is that both of these services are huge abuse magnets and have been for years, so I find it curious that yet another report of the same old thing is deemed noteworthy.
And even he doesn't cover all the problems; for
example, as everyone with the slightest clue about
spam has known for years, responding to
the spammer in any way is absolutely idiotic.
But since the people involved in this company have
no anti-spam credentials, no track record of
involvement, and no clue how their "counter-attacks" will be neatly retargeted
(surely nobody is naive enough to believe that
spammers will sit still for this?) I can't
say I'm surprised. This is merely the latest
bonehead idea in a long series (e.g. challenge-response, callbacks, SPF, etc.) of bonehead
ideas put forth by people who have clearly failed to
comprehend even the rudimentary aspects of
the spam problem...or who have, but simply do
not care about the conequences for everyone else
as long as they can selfishly "solve" their part
of the problem.
I've already blacklisted the company behind
this tripe and null-routed their address space.
I recommend the same for everyone else. There's
simply no place on the Internet for those who
want to profit from our collective misery
by making it worse.
Sure, there are still some people of limited ability
who cling to VMS _decades_ after it became obsolete,
but this is more a reflection of their failure to
adapt and evolve than anything else.
It's simply not necessary to use such a primitive
operating system to achieve a high degree of security. Contemporary open-source 'nixes
(by which I mean Linux and *BSD) are vastly superior
in terms of both functionality and performance,
and of course do not share the inherent design flaws
which doomed VMS a very long time ago.
There has been copious discussion and analysis
of this over the past two years or so on Spam-L.
(Spam-L is THE place to find the Internet's
leading experts on spam. Anybody who's anybody
is there; anybody who's not there just isn't paying
attention.)
It was a highly predictable move, given the success
that spammers have already had with direct-to-MX
spam via zombies -- thanks in large part to the
incompetence and neglect of consumer broadband ISPs,
who were warned about this early and often,
and chose to sit on their hands -- and let it burn.
This became even more of a certainty, as
poorly-thought-out and largely worthless proposals
like SPF, SenderID, and DomainKeys were trotted
out: this undercuts all of those neatly. (And
it's not the only way: there are a number of
other tricks that spammers can be expected to
employ as the need arises that render all three
of these proposals so much disposable nonsense.)
There is at least one factual error in that article,
though: the author says
"This means the junk mail appears to come from the ISP [...]
If it's coming from their servers or
their network, then it is IS coming from
the ISP; it's their
spam and they bear full responsibility for
making it stop.
No excuses. No whining. No stalling. Anyone
who's not competent and diligent enough to
detect this problem and deal with it immediately should unplug their entire
network until they can -- or at least have the
guts not to complain when they are -- correctly --
blacklisted for spamming.
It doesn't matter if it's a spammer on your network,
or an insecure mail server, or an exploited Formmail
script, or a hijacked Windows box, or anything else:
if you can't keep your network from sending spam,
then you need to disconnect it from the Internet
until you can.
A corollary to this is that if you're supporting spam --
providing DNS, hosting a web site, handling a mailbox,
providing a dialup account, routing traffic, anything:
that's your spam, too. You need to stop. NOW.
It really is as simple as that: spam doesn't just fall
out of the sky and magically land on the Internet:
it comes from hosts, and hosts are on networks.
And it doesn't matter whether the people who are
permitting this to happen are doing it (a) because
they're clueless or (b) because they've been paid
to look the other way: the result is the same in either case.
Accountability for this is long overdue, but it's coming:
That's how it's going to have to be, because the people
who are responsible for spam won't have it any other way. We're long past the time when we asked nicely:
we've arrived at the time where anyone spamming
or supporting spam -- and who won't stop immediately -- needs to blacklisted forever.
"Sunbelt Software of Clearwater, Fla., on Friday confirmed reports
that it has exclusive rights over certain aspects of the anti-spyware
programs Microsoft gained in its acquisition of Giant Company
Software on Thursday."
The real point of SPF and Sender ID is to make it hard for spammers to forge their "from" addresses, so that blacklists and whitelists can be more effective.
1. They don't have to. Spammers have control of something between 10e7 and 10e8 zombies, and could easily instruct them to send out properly-SPF (or SenderID or DomainKeys or whatever) -tagged messages whenever they feel like it.
Nothing (well, okay, not much) stops them from acquiring more zombies: the potential pool is comprised of every Windows system on the 'net, including those connected only intermittently or behind firewalls. So unless you're proposing that SOMEONE is going to secure all those boxes, and I don't see anybody volunteering for that task, all these technologies are moot.
2. But let's make a couple of big assumptions -- both of which are invalid, but let's try them anyway. Suppose that SPF (or SenderID or Domainkeys, it doesn't matter which one) was globally deployed and worked perfectly. Does this get us anywhere?
No it does not.
Because, you see, spammy has already anticipated this move. And spammy is registering domains by the thousands -- a task made easier and cheaper by the fact that at least a couple of registrars are owned and operated by spammers.
Which means that spammy has, for all practical purposes, an infinite supply of cheap domains. And spammy has already demonstrated that he/she is perfectly happy to burn one per spam run.
So. You get spammed from domain000001.com. You use SPF and prove to your satisfaction that yes, it really came from there. You block it.
Tomorrow, you get spammed from domain000002.com. Same spammer; same payload; different domain. And you can use SPF on this one too.
Lather. Riinse. Repeat.
I'm up to 135,000 blocked domains and nowhere near the end. Just building that list has taken nearly a year -- and there are some definite scalability and performance issues in using it.
But yes, GHG has been on the staff of the Engineering Computer Network there for many years. But it'd be a pity if all he was known for were the BBQ experiments: GHG was part of (a) the first multi-cpu Unix system, the dual-cpu Vax, and (b) one of the first Unix networks -- which featured interactive login, load balancing, and so on several years before TCP/IP came to town.
Not to mention a *ton* of work on all kinds of things relating to Unix. GHG may not be as well known as some other folks, but he probably should be.
"I don't want to needlessly frighten anyone, but this one really scares the bejeesus out of me."
I'm right there with you, for several reasons:
1. None of the three entities which could seriously address
this problem are doing so or have any plans to do so.
(a) Their former owners either don't know or don't care
(yes, there are happy exceptions, but they're rare).
(b) The consumer broadband ISPs connecting them
by the millions don't want to admit that the problem exists because then they'd have to accept some
responsibility for doing something about it.
(c) Microsoft is in the same position -- and here we
are, what, 2+ years into their "focus on security"?
2. There are tens of millions of zombies. We could
argue endlessly about how many, but experienced
and credible observers have pegged it at above 20
milllion and maybe as high as 100 million.
Frankly, the exact number hardly matters: only a fraction
of those are required to DDoS just about any network
resource on the planet. (Think about that for a moment,
and then try to work out a defense against an attack
coming from, say, 3.5 million autonomous systems
located on networks all over the planet.)
3. Every time one of those end-user systems is
upgraded or moved to a faster network connection...
the Bad Guys get a performance increase.
4. Compare size of the zombie networks to size of
some of the larger distributed computing projects.
5. Unused zombies are unlikely to be detected.
6. Some zombies move around: they're laptops. This
enables creation of additional inside firewalled networks
thanks to people who carry them in.
7. A lot of zombies move around: they're assigned
IP addresses with DHCP and the like. The combination
of 5, 6 and 7 means that just FINDING all the zombies
is pretty hard.
8. Spammers are of course all over this. Spammer
web boards offer zombies for sale by the thousand,
others offer DDoS attack services at so many $$/hour.
9. Spammers are moving past spam via SMTP and
getting into all kinds of other mischief -- after all,
with that much horsepower at their disposal (at zero
cost) they can afford to. Which is why mere anti-SMTP-
spam measures are fast becoming obsolete.
10. There are no signs that any of this will get better;
every indicator we have says it will get worse. Arguably,
the only way to REALLY make it better is to install an
OS and application suite on those boxes that is at least
minimally resistant to being zombied. But of course,
as we all know, there is incredible resistance to that
idea: people will cling to their Microsoft OS even when
it's demonstrated to them that not only are they hosing
themselves, but everyone they share a network with.
Unfortunately, not even a crypto solution will solve the
problem you've outlined -- and you're correct, SPF is
of negligible value in stopping spam and only slightly
more in stopping forgeries. (It's becoming increasingly
obvious that the people touting its benefits have little
experience actually dealing with spam and thus little
understanding of the speed with which spammers develop
new techniques. Did you know that they're already using
SPF to their advantage?)
Anyway, crypto will not help because there are millions
and millions of zombies out there -- hijacked Windows
systems on all kinds of connections, on all kinds of
networks. Since the attackers in control of those zombies are in TOTAL control of them, they are also
in control of any crypto taking place on those systems.
Therefore, absolutely nothing is stopping them from
sending out mail through the "legitimate" gateways
that those systems are supposed to be using -- in fact,
they're already doing it. (Check the last
48 hours of traffic on Spam-L and read notes from
AOL's anti-spam chief.) Nor is anything stopping them
from sending spam via the same path AND signing
it with the user's private key : the only reason they're
not doing it already is that they don't need to.
To put it another way: the continuing existence of those
millions and millions of zombies makes SPF (and
DomainKeys, and SenderID) utterly moot. And those
zombies aren't going to go away, because nobody is
working seriously on making them go away. (What
most people are doing is trying to pretend very hard
that they don't exist.)
So what's the answer? Well, the first answer -- the one
that would solve the biggest problem the fastest -- is
to get everyone to stop bouncing SMTP traffic and
start rejecting it. That single step, which everyone can
do today without needing any new technology,
would cut out a lot of completely useless traffic --
and, by the way, largely alleviate the need for things
like SPF. (Why? Because if you reject rather than
bounce, then the SMTP sender, whether forged or
unforged, is the one that deals with it. This is far better
than trying to bounce it to a mail server which may or
may not actually be responsible for handling it.)
1. Will it solve spam?
Well, it was announced with the statement "Spam as
a technical problem is solved by SPF." but -- despite
the lack of a full public retraction of that statement, we're
now told it was never intended to solve spam.
Fine...but let's note that if it didn't claim to have something
do with spam, few people, if any, would care about it.
2. Will it solve forgeries?
No. There are still a myriad of ways forgeries can
be constructed -- and many of those will pass SPF
checks, because they utilize the outbound mail servers
as unforged mail. (And while you might think that
the people running those mail servers would detect
and correct this...you'd be wrong. They've built
up multi-year track records demonstrating that
they either don't know or don't care -- so it's
unlikely they'll wake up tomorrow feeling differently.)
3. Will it stop bounces from forgeries?
Maybe. But it's important to note that it doesn't
stop them by actually FIXING the broken mail
systems which are generating them. This is a
brittle approach to solving the problem which has
as its only merit that it may be easier than tackling
the core issue. But experience strongly suggests
that it would be much better for the long-term health
of the Internet's mail system to roll up our sleeves
and actually deal with the bounce-vs-reject issue
than find a way to sweep it under the carpet.
4. Will it stop joe-jobs?
Maybe -- if enough people use it, if spammers don't
game it (and they're already working on it) and if it
doesn't impose its own consequences. (Consider what
will happen to your DNS servers if some spammer
decides to joe-job your domain and N mail servers
out there -- instead of just rejecting the traffic and
being done with it -- all try to verify your SPF records
simultaneously.)
5. Does it solve an important problem?
No. Forgery isn't a serious problem -- spam is.
6. Does it solve the problem thoroughly?
No. Really solving mail forgery requires
secure DNS, public-key encryption of message content,
secure end-user systems, secure mail clients, and
other components. These all exist, but until they're
ubiquitous, any sense that the mail forgery problem
is "solved" is illusory.
Despite all this, there are a few good ideas in SPF,
and in DomainKeys, and in some of the other proposals
which are out there. But those ideas need to be weighed in light of the environment in which we find
ourselves, and take into account:
Millions of hijacked systems
Cheap "throwaway" domains
"Bulletproof" hosting
Rapidly-updating DNS (which just got worse)
non-SMTP methods of sending spam
poorly-maintained mail gateways
Scalability (SMTP, DNS, etc.) concerns
among other things. For example, a much better
(and far simpler) proposal that could be implemented
immediately with minimal impact is:
here.
Of course, this doesn't solve everything either, nor
does it claim to: but what it does tackle, it handles
very well. Backers of SPF/DomainKeys/etc. would
be well-advised to take a long look at it.
Yahoo is a spammer favorite for dropboxes because
their (decimated-by-layoffs-of-the-clueful) "abuse"
desk is legendary for failing to nuke them even when
presented with copious documentation which proves
that, yes, they are spamming, and yes, they are using
Yahoo.
Yahoo's mailing list mechanisms are frequently used
for spamming because they allow the list-owners to
forcibly subscribe victims -- and because, once again,
the Yahoo "abuse" desk takes no action.
In addition, subscribers to Yahoo mailing lists can look
forward to spam, because somehow, addresses that
are subscribed to them but never exposed anywhere
else end up on spammer lists.
And of course Yahoo Stores is a cesspool overflowing
with spammers of all descriptions.
And then there's the nagging question of just how newly-created Yahoo accounts end up getting so
much spam. It doesn't happen every time: but it
happens often enough.
You can read about this in more detail than you'd
ever possibly wanto know just by browsing Usenet's
news.admin.net-abuse.email.
And so now Yahoo, which can't even come close to keeping its own house in order, is going to trot out
The Cure For Spam.
Both companies have shown themselves to be
utterly devoid of the slightest hint of ethical
business conduct. Both companies have acted
to reinforce their monopoly position in the
marketplace and to restrict consumer choice.
Both companies have invaded user privacy via
spam and spyware. Both companies have suppressed
competing technologies. Both companies have
refused to support popular/emerging platforms.
In summary, both companies are slime and no
thinking, ethical person should use their products.
The argument that these things should not matter
"because there is a job to do" is naive and foolish. We are not at liberty to disable
our consciences simply because someone has given
us an assignment; we are required to leave
them running and to apply what they tell us
in ALL situations, not just those situations
where it is convenient.
And given the past and present business conduct
of both companies, mine tells me that it is wrong
to use or support the products of either...so I
don't. Yes, this has a cost attached to it --
but that's irrelevant, because the decision has
to be based on principle, not on any momentary
inconvenience.
Slashdot Mirror
It's possible to track FIOS rollouts merely by noting spam sources whose rDNS matches it, e.g., "*.fios.verizon.net". To date, this has been a 100.00% indicator of spam. For example, in the last few minutes, one of my mail servers has observed the following:
pool-70-104-193-136.nrflva.fios.verizon.net
pool-71-170-157-58.dllstx.fios.verizon.net
pool-71-178-175-162.washdc.fios.verizon.net
pool-71-180-67-156.tampfl.fios.verizon.net
pool-71-187-176-23.nwrknj.fios.verizon.net
pool-71-245-227-130.bstnma.fios.verizon.net
pool-71-245-247-31.nycmny.fios.verizon.net
pool-71-245-74-238.prvdri.fios.verizon.net
pool-71-251-69-183.tampfl.fios.verizon.net
pool-72-64-87-227.dllstx.fios.verizon.net
pool-72-66-1-223.washdc.fios.verizon.net
pool-72-75-227-248.bflony.fios.verizon.net
pool-72-90-121-2.ptldor.fios.verizon.net
pool-72-94-19-223.phlapa.fios.verizon.net
pool-72-95-136-185.pitbpa.fios.verizon.net
pool-96-229-80-50.lsanca.fios.verizon.net
That's a mail server with one user. Production mail servers with tens of thousands of users typically note 5000-10000 such systems every day.
So from here, it appears that new FIOS rollouts are being 0wned nearly as quickly as they're connected, and that they're staying 0wned. I'm sure the spammers are quite pleased with the quality service provided by Verizon et.al.
As has been noted in numerous places, Comcast isn't just forging RST packets to disrupt P2P traffic -- they're also doing it to disrupt Lotus Notes traffic...which makes the "we're doing it to stop the bad guys" excuse a transparent lie.
Moreover, disrupting P2P traffic will have no effect on "spammers and other miscreants", as they have far more sophisticated, self-organizing C&C methods already deployed. (No doubt having anticipated that use of traditional P2P would leave them vulnerable to such countermeaures.)
But the truly galling part is that Comcast continues to repeat the same big lie they trotted out years ago: "We take the spam problem seriously". This is utter nonsense, of course; spam emission levels from their network continue to steadily increase, as they have for half a decade, to the point where their only serious rival for the #1 spot on the world's list of top spam-sending network is Verizon.
So what this episode tells us is that Comcast has the capability to monitor and modify traffic, but only chooses to do so when it might affect their profits -- not when it might could the unceasing flow of abuse outbound from their network.
The problem is not that users fail to use anti-virus, anti-spyware,
anti-phishing, anti-left-handed-metric-wrench software.
The problem is that users CHOOSE to use operating system and
applications which are so miserably designed and written that they
are susceptible to these problems as-shipped by the vendor(s).
(I take the position that any OS which needs anti-virus software
to survive in the wild is clearly broken and should never by used. By anyone.)
Anti-* software is a band-aid. Its use is a clear indication that the
product it's trying to band-aid is broken. And anyone deliberately
using known-broken products should not be very surprised if Bad
Things happen as a result.
It continues to amaze me that anyone is surprised by this --
although I suppose by now I ought to have gotten accustomed to
this state of affairs. [Some] people install obviously defective
operating systems (e.g., any version of Windows), use obviously
defective mail clients (e.g., Outlook), use obviously defective
web browsers (e.g., IE) and then actually expect that they can
somehow make up for this series of stunningly poor decisions
by installing enough add-ons. It doesn't work, of course, which is
why we see hundreds of millions of infected systems out there,
spewing spam, conducting DoS attacks, poking at web servers,
brute-forcing ssh servers, and so on.
My point being that by the time the conversation has gotten to
anti-* software -- it's too late. The damage has been done, and
there's no undoing it (despite lots of wishful thinking and the
earnest assurances of anti-* vendors, who of course, let's not
forget, have a substantial profit motive).
(Ah. About this point, some M$ apologist will raise one of the
usual canards -- for example, "M$ products are attacked because
they're popular". Not true, of course; M$ products are attacked
because they're miserably weak as a result of incompetent design
and even worse implementation. M$ is hardly alone in this, it's
that for some inexplicable reason, it seems to attract the most
defenders -- despite the fact that as possibly the most well-funded,
well-staffed, well-equipped software company in the world...it
has repeatedly proven that it can't even write a decent mail client.)
So. These studies shouldn't ask questions like "Are you using
anti-spyware?" They should ask questions like "Why are you dumb
enough to use an OS/application software combination so badly
written and maintained that anti-spyware is deemed necessary?"
Others have already explained at length how this is yet another
FUSSP -- and they're quite correct. It appears to be the product
of the same confusion that gave us SPF, Domain Keys, et.al.:
that is, mistaking the forgery problem for the spam problem.
Yes, they're related; yes; they're both abusive; and yes, they're
often seen together; but they are NOT the same problem and
it's a serious, fundamental error to think they are.
At this point in time, there is no solution to the forgery
problem available, because there are (depending on whose
estimates you'd like to believe) something between 10e7
and 10e8 (or more) fully-compromised systems out there,
which are of course capable of transmitting mail using any
identity whose credentials are located on those systems.
No fix is even on the horizon for that situation.
As to the spam problem, a limited solution presents itself
via this approach: any system which emits spam is either
(a) owned by a spammer, that is, a leased server in a co-lo
or similar or (b) broken, that is, an open SMTP relay or
perhaps a system with an exploitable proxy or (c) hijacked
by a spammer, that is, effectively owned while still putatively
under the control of its "real" owner.
In all cases, such systems are de facto enemy territory,
and the appropriate course of action is to (a) identify them
and (b) deny ALL traffic from them until they're no longer
enemy territory. There is little sense in expending bandwidth,
CPU cycles, and expertise trying to work out what traffic from
them might not be spam -- even if this futile effort is
successful, it doesn't matter, because accepting traffic
from a known-hostile source is just not a good idea no
matter what might be in it. Moreover, due to failure to
maintain and monitor RFC 2821 and RFC 2142 role addresses,
refusing mail is often the ONLY way to bring the attention
of the responsible party to the situation (I'm thinking of
(b), above, here).
But back to this FUSSP: consider for a moment how this
system could be used to target attacks via (a) forgeries
(b) redirected MX records (c) fast-flux DNS (d) targeting
of blind users (which is why ANY use of captchas is
quite, quite stupid) (e) deliberately induced deadlock
(f) bogus responses to mailing list traffic and (g) some
number of other things that will probably occur to me
if I can force myself to read this poorly-written gibberish
again.
My own experiments show much larger numbers: in January 2007, .7M probable/possible. The number of bots worldwide has been
one such experiment revealed a confirmed 1.8M bots with another
estimated by others as in the range of 100M (Evron et.al. 70M;
Cerf, 140M) so I very much question the methodology used here.
I wouldn't be suprised in the least if the worldwide numbers were
much higher. But there's no way they're less than ~100M.
For starters, it's quite easy to run a secure, high-performance,
scalable mail system using open-source tools on cheap hardware.
An *example* of such a combination might be: OpenBSD, postfix,
SpamAssassin, CLamAV, UW-IMAP, perdition. This combination
supports secure POP and IMAP, along with mail submission via
SSL and TLS, thus accomodating horribly broken clients like Outlook.
Building a cluster of such systems (to distribute load and provide
fault-tolerance) is a well-understood exercise.
Second, any solution which does not support Internet standard
protocols like POP and IMAP may be rejected immediately. It's
far too silly to merit serious consideration.
Third, there are some very troubling questions here concerning:
- security
- privacy
- data retention
- data repurposing
- academic integrity
For example, we have seen a series of serious security problems
at MSN/Hotmail; there is no reason to believe that any other service
operated by Microsoft will be unblemished. We have seen disturbing
policy changes at Google in re their data retention. We have seen
privacy issues at Yahoo. And so on. My point being that none of these
services have providing convincing proof that they can operate at
a level acceptable for professional use.
Moreover, entangling a university's computing infrastructure with
a commercial organization's raises questions of academic integrity:
which is why having the mail system operated by the university's
own professional staff (who are under the university's authority)
seems necessary to me in order to exert an acceptable level of control.
I find this news very disconcerting; even more so when I read that
others report that their institutions are considering similar moves.
While it may be attractive financially (although I would be perfectly
to bet that I could implement an in-house solution that's cheaper),
this is not something that should be scrimped on. Faculty, staff,
and student communications are too important to be delegated
to the lowest bidder.
The obvious way is to try to work out which IP addresses the
crawler is operating from, and use the business end of a firewall
to block it. (Given past events, I don't think a robots.txt is likely
to work.)
A less-obvious way is to discover what the watermark is and
slap it onto a few...hundred million files that have nothing to
do with what it's looking for. Those files don't need to have
actual audio content -- as long as they meet the criteria that
the spider is looking for. So perhaps a bit of Perl, a few calls
to rand() and some well-chosen filenames might be enough.
Registerfly is one the few registrars that has earned a
blacklist-on-sight policy for any domain registered with
it. Their complete failure to take any action against any
domain -- for spamming, spyware, phishing, and worse --
indicates to me that the registrar is run by incompetent amateurs.
I won't recommend another registrar because I don't want
it to seem like I'm shillling for them; but I'll recommend also
avoiding GoDaddy, Bulkregister, GKG, Nameking and Domains at Cost
simply to avoid sending someone from frying pan to fire.
But I don't think you can possibly do worse than Registerfly.
While I'll grant that your point is true for *some* systems, it's not
true for most. If you watch network traffic with tools such as ntop
or etherape for a while (especially the latter thanks to the way that
it facilitates visualization), and then focus on particular systems,
what you'll likely find it that traffic patterns are surprisingly predictable.
Consider, for example, a client system (OS doesn't matter) sitting on
a corporate network. It probably uses DHCP at boot and periodically
thereafter -- so we should expect to see light, sporadic DHCP traffic
and we should expect to see that traffic confined to the LAN. It probably
uses local DNS servers (and has been told about them via DHCP) so we
should expect to see a relatively low-level stream of DNS queries and
we should expect to see all of them directed at those local servers.
We should expect to see HTTP requests going out -- but none coming in.
We should expect to see SMTP traffic going out, but only to local SMTP
servers and none coming in.
And so on. Now -- as someone pointed out in a followup -- a good way
to make *sure* that this is what we see is to put in place a solid firewall
and configure it properly -- starting with bidirectional "deny all" and then
opening up only the ports/protocols necessary. (And then we can also
use that firewall to observe exceptions to the "normal" traffic that I started
to laundry-list above.)
This gets sightly more complicated for servers, especially multi-purpose
ones, but it's still a tractable problem. For example, an inbound SMTP
gateway should not be sending out HTTP requests; and a dedicated web
server shouldn't be making outbound SMTP connections (except perhaps
to a local SMTP server for mail traffic generated on the web server).
The Bad Guys can evade some of this by severely rate-limiting traffic.
But while that makes detection more difficult, it does at least mean that
their attempt at evasion slows down their own attacks. And that malware
which just blunders around is more likely to be spotted, which helps a
little bit.
So it's not "a fix" or anything like that; it's just another approach, to
be combined with firewalls/self-scanning/etc.
This idea was discussed in considerable depth on various
anti-spam lists several years ago. Nearly all hosts on the
Internet talk to one mail server: the one designated for
mail submission from the network they're on. (s/one/few/
for networks large enough to have multiple SMTP gateways.)
Such systems, if observed suddenly making connections on
port 25 to hundreds (or more) other mail servers, are almost
certainly spewing spam. This is particularly true if those
connections meet certain criteria (e.g. traffic sent before
waiting for SMTP greeting from remote side, or failure to
send QUIT before closing connection). Slapping a port 25
block on such systems at least partially quarantines the
problem, buying time for more thorough investigation.
The same could be said of systems observed making hundreds
of SSH connections (to one destination or many), etc. The
basic concept is to figure out what "normal" looks like --
which, granted, may vary with what uses a system normally
has -- and then do something when things don't look normal.
"something" could be "log it" or "issue an alert" or "rate-limit
connections" or "rate-limit traffic" or "block" or some
combination; the trick is to select an appropriate response
that does something useful while not making the mechanism
so twitchy that it trips when it shouldn't.
A. This problem has been discussed in depth on various
anti-spam mailng lists and newsgroups for many years.
This long-standing problem has been steadfastly ignored
by Yahoo, who went so far as to dismiss the key people
on their own abuse staff when they tried to address it.
As a consequence, it's now a better-than-even bet
that any site hosted by Yahoo belongs to a spammer,
phisher, spyware injector, child pornographer, scammer
or other lowlife. My own meager list of Yahoo-hosted
dropboxes for such stands at 26,831 this morning and
those are just the ones that brought themselves to
my attention, i.e. I'm passively noting them and not
actively searching them out.
As a result, Yahoo is one of the biggest spam-sending
and spam-supporting operations on the entire Internet.
(Oh, and Geocities is now completely infested. Rejecting
all inbound mail [except anti-spam discussions] that contains
a Geocities URL is a surprising effective tactic.)
B. They're not alone. For instance, MSN BCentral should
be renamed MSN SpamCentral -- it's just as bad. And Hotmail
cheerfully hosts spammer dropboxes by the tens of thousands.
There are others, but what makes these two particularly
annoying is that they make a public show of being anti-spam
by promoting snake-oil like SenderID and DomainKeys, both
of which are worthless. (If it isn't obvious why, then think
about the hundreds of millions of zombies -- hijacked Windows
systems -- out there and consider that their new masters
have possession of all email credentials belonging to their
former owners -- from POP passwords to PGP keys. It is not
possible to solve the forgery problem -- for any useful
definition of "solve" -- without solving this problem first.
Good luck. This same thing applies to SPF and variants, by
the way, all of which are complete failures.)
Another thing that distinguishes them is the absolutely
irresponsible, totally clueless way in which abuse reports
are handled. Most seem to disappear into black holes. The
majority of the rest are returned with semi-literate denials
that the abuse has any connection with their operation -- even
when their own IP address are clearly the source. If you'd
like to browse a huge number of examples of this, go to
Usenet's news.admin.net-abuse.email and search for
"Yahoo clueless" or "Hotmail clueless". Make coffee first.
The bottom line is that both of these services are huge abuse
magnets and have been for years, so I find it curious that
yet another report of the same old thing is deemed noteworthy.
Please see http://groups.google.com/group/net.unix/browse_thr ead/thread/8a55fc5a43194ad/ca28c53d1020e06c?lnk=st &q=net.cog-eng+spaf%40gatech.uucp+proposal+adventu re&rnum=1&hl=en#ca28c53d1020e06c
which discusses a precursor to this idea from 20+ years
ago.
Unbelievably stupid. Or, as Mitch Wagner observed:
And even he doesn't cover all the problems; for example, as everyone with the slightest clue about spam has known for years, responding to the spammer in any way is absolutely idiotic.
But since the people involved in this company have no anti-spam credentials, no track record of involvement, and no clue how their "counter-attacks" will be neatly retargeted (surely nobody is naive enough to believe that spammers will sit still for this?) I can't say I'm surprised. This is merely the latest bonehead idea in a long series (e.g. challenge-response, callbacks, SPF, etc.) of bonehead ideas put forth by people who have clearly failed to comprehend even the rudimentary aspects of the spam problem...or who have, but simply do not care about the conequences for everyone else as long as they can selfishly "solve" their part of the problem.
I've already blacklisted the company behind this tripe and null-routed their address space. I recommend the same for everyone else. There's simply no place on the Internet for those who want to profit from our collective misery by making it worse.
Sure, there are still some people of limited ability who cling to VMS _decades_ after it became obsolete, but this is more a reflection of their failure to adapt and evolve than anything else. It's simply not necessary to use such a primitive operating system to achieve a high degree of security. Contemporary open-source 'nixes (by which I mean Linux and *BSD) are vastly superior in terms of both functionality and performance, and of course do not share the inherent design flaws which doomed VMS a very long time ago.
There has been copious discussion and analysis of this over the past two years or so on Spam-L. (Spam-L is THE place to find the Internet's leading experts on spam. Anybody who's anybody is there; anybody who's not there just isn't paying attention.)
It was a highly predictable move, given the success that spammers have already had with direct-to-MX spam via zombies -- thanks in large part to the incompetence and neglect of consumer broadband ISPs, who were warned about this early and often, and chose to sit on their hands -- and let it burn.
This became even more of a certainty, as poorly-thought-out and largely worthless proposals like SPF, SenderID, and DomainKeys were trotted out: this undercuts all of those neatly. (And it's not the only way: there are a number of other tricks that spammers can be expected to employ as the need arises that render all three of these proposals so much disposable nonsense.)
There is at least one factual error in that article, though: the author says "This means the junk mail appears to come from the ISP [...]
If it's coming from their servers or their network, then it is IS coming from the ISP; it's their spam and they bear full responsibility for making it stop.
No excuses. No whining. No stalling. Anyone who's not competent and diligent enough to detect this problem and deal with it immediately should unplug their entire network until they can -- or at least have the guts not to complain when they are -- correctly -- blacklisted for spamming.
It doesn't matter if it's a spammer on your network, or an insecure mail server, or an exploited Formmail script, or a hijacked Windows box, or anything else: if you can't keep your network from sending spam, then you need to disconnect it from the Internet until you can.
A corollary to this is that if you're supporting spam -- providing DNS, hosting a web site, handling a mailbox, providing a dialup account, routing traffic, anything: that's your spam, too. You need to stop. NOW.
It really is as simple as that: spam doesn't just fall out of the sky and magically land on the Internet: it comes from hosts, and hosts are on networks. And it doesn't matter whether the people who are permitting this to happen are doing it (a) because they're clueless or (b) because they've been paid to look the other way: the result is the same in either case.
Accountability for this is long overdue, but it's coming:
That's how it's going to have to be, because the people who are responsible for spam won't have it any other way. We're long past the time when we asked nicely: we've arrived at the time where anyone spamming or supporting spam -- and who won't stop immediately -- needs to blacklisted forever.
- "Sunbelt Software of Clearwater, Fla., on Friday confirmed reports
that it has exclusive rights over certain aspects of the anti-spyware
programs Microsoft gained in its acquisition of Giant Company
Software on Thursday."
Now go read: SPEWS record 471which is one of the oldest SPEWS records and thus means that these spammers have been known for quite some time.
1. They don't have to. Spammers have control of
something between 10e7 and 10e8 zombies, and
could easily instruct them to send out properly-SPF
(or SenderID or DomainKeys or whatever) -tagged
messages whenever they feel like it.
Nothing (well, okay, not much) stops them from
acquiring more zombies: the potential pool is comprised
of every Windows system on the 'net, including those
connected only intermittently or behind firewalls.
So unless you're proposing that SOMEONE is going
to secure all those boxes, and I don't see anybody
volunteering for that task, all these technologies are
moot.
2. But let's make a couple of big assumptions -- both
of which are invalid, but let's try them anyway. Suppose
that SPF (or SenderID or Domainkeys, it doesn't
matter which one) was globally deployed and worked
perfectly. Does this get us anywhere?
No it does not.
Because, you see, spammy has already anticipated
this move. And spammy is registering domains by
the thousands -- a task made easier and cheaper
by the fact that at least a couple of registrars are
owned and operated by spammers.
Which means that spammy has, for all practical
purposes, an infinite supply of cheap domains.
And spammy has already demonstrated that he/she
is perfectly happy to burn one per spam run.
So. You get spammed from domain000001.com.
You use SPF and prove to your satisfaction that
yes, it really came from there. You block it.
Tomorrow, you get spammed from domain000002.com.
Same spammer; same payload; different domain.
And you can use SPF on this one too.
Lather. Riinse. Repeat.
I'm up to 135,000 blocked domains and nowhere
near the end. Just building that list has
taken nearly a year -- and there are some definite
scalability and performance issues in using it.
Actually, it's Purdue (Perdue does chickens).
But yes, GHG has been on the staff of the Engineering
Computer Network there for many years. But it'd be
a pity if all he was known for were the BBQ experiments:
GHG was part of (a) the first multi-cpu Unix system,
the dual-cpu Vax, and (b) one of the first Unix networks --
which featured interactive login, load balancing, and so
on several years before TCP/IP came to town.
Not to mention a *ton* of work on all kinds of things
relating to Unix. GHG may not be as well known as
some other folks, but he probably should be.
I'm right there with you, for several reasons:
1. None of the three entities which could seriously address this problem are doing so or have any plans to do so. (a) Their former owners either don't know or don't care (yes, there are happy exceptions, but they're rare). (b) The consumer broadband ISPs connecting them by the millions don't want to admit that the problem exists because then they'd have to accept some responsibility for doing something about it. (c) Microsoft is in the same position -- and here we are, what, 2+ years into their "focus on security"?
2. There are tens of millions of zombies. We could argue endlessly about how many, but experienced and credible observers have pegged it at above 20 milllion and maybe as high as 100 million. Frankly, the exact number hardly matters: only a fraction of those are required to DDoS just about any network resource on the planet. (Think about that for a moment, and then try to work out a defense against an attack coming from, say, 3.5 million autonomous systems located on networks all over the planet.)
3. Every time one of those end-user systems is upgraded or moved to a faster network connection... the Bad Guys get a performance increase.
4. Compare size of the zombie networks to size of some of the larger distributed computing projects.
5. Unused zombies are unlikely to be detected.
6. Some zombies move around: they're laptops. This enables creation of additional inside firewalled networks thanks to people who carry them in.
7. A lot of zombies move around: they're assigned IP addresses with DHCP and the like. The combination of 5, 6 and 7 means that just FINDING all the zombies is pretty hard.
8. Spammers are of course all over this. Spammer web boards offer zombies for sale by the thousand, others offer DDoS attack services at so many $$/hour.
9. Spammers are moving past spam via SMTP and getting into all kinds of other mischief -- after all, with that much horsepower at their disposal (at zero cost) they can afford to. Which is why mere anti-SMTP- spam measures are fast becoming obsolete.
10. There are no signs that any of this will get better; every indicator we have says it will get worse. Arguably, the only way to REALLY make it better is to install an OS and application suite on those boxes that is at least minimally resistant to being zombied. But of course, as we all know, there is incredible resistance to that idea: people will cling to their Microsoft OS even when it's demonstrated to them that not only are they hosing themselves, but everyone they share a network with.
Unfortunately, not even a crypto solution will solve the problem you've outlined -- and you're correct, SPF is of negligible value in stopping spam and only slightly more in stopping forgeries. (It's becoming increasingly obvious that the people touting its benefits have little experience actually dealing with spam and thus little understanding of the speed with which spammers develop new techniques. Did you know that they're already using SPF to their advantage?)
Anyway, crypto will not help because there are millions and millions of zombies out there -- hijacked Windows systems on all kinds of connections, on all kinds of networks. Since the attackers in control of those zombies are in TOTAL control of them, they are also in control of any crypto taking place on those systems.
Therefore, absolutely nothing is stopping them from sending out mail through the "legitimate" gateways that those systems are supposed to be using -- in fact, they're already doing it. (Check the last 48 hours of traffic on Spam-L and read notes from AOL's anti-spam chief.) Nor is anything stopping them from sending spam via the same path AND signing it with the user's private key : the only reason they're not doing it already is that they don't need to.
To put it another way: the continuing existence of those millions and millions of zombies makes SPF (and DomainKeys, and SenderID) utterly moot. And those zombies aren't going to go away, because nobody is working seriously on making them go away. (What most people are doing is trying to pretend very hard that they don't exist.)
So what's the answer? Well, the first answer -- the one that would solve the biggest problem the fastest -- is to get everyone to stop bouncing SMTP traffic and start rejecting it. That single step, which everyone can do today without needing any new technology, would cut out a lot of completely useless traffic -- and, by the way, largely alleviate the need for things like SPF. (Why? Because if you reject rather than bounce, then the SMTP sender, whether forged or unforged, is the one that deals with it. This is far better than trying to bounce it to a mail server which may or may not actually be responsible for handling it.)
1. Will it solve spam? Well, it was announced with the statement "Spam as a technical problem is solved by SPF." but -- despite the lack of a full public retraction of that statement, we're now told it was never intended to solve spam. Fine...but let's note that if it didn't claim to have something do with spam, few people, if any, would care about it.
2. Will it solve forgeries? No. There are still a myriad of ways forgeries can be constructed -- and many of those will pass SPF checks, because they utilize the outbound mail servers as unforged mail. (And while you might think that the people running those mail servers would detect and correct this...you'd be wrong. They've built up multi-year track records demonstrating that they either don't know or don't care -- so it's unlikely they'll wake up tomorrow feeling differently.)
3. Will it stop bounces from forgeries? Maybe. But it's important to note that it doesn't stop them by actually FIXING the broken mail systems which are generating them. This is a brittle approach to solving the problem which has as its only merit that it may be easier than tackling the core issue. But experience strongly suggests that it would be much better for the long-term health of the Internet's mail system to roll up our sleeves and actually deal with the bounce-vs-reject issue than find a way to sweep it under the carpet.
4. Will it stop joe-jobs? Maybe -- if enough people use it, if spammers don't game it (and they're already working on it) and if it doesn't impose its own consequences. (Consider what will happen to your DNS servers if some spammer decides to joe-job your domain and N mail servers out there -- instead of just rejecting the traffic and being done with it -- all try to verify your SPF records simultaneously.)
5. Does it solve an important problem? No. Forgery isn't a serious problem -- spam is.
6. Does it solve the problem thoroughly? No. Really solving mail forgery requires secure DNS, public-key encryption of message content, secure end-user systems, secure mail clients, and other components. These all exist, but until they're ubiquitous, any sense that the mail forgery problem is "solved" is illusory.
Despite all this, there are a few good ideas in SPF, and in DomainKeys, and in some of the other proposals which are out there. But those ideas need to be weighed in light of the environment in which we find ourselves, and take into account:
- Millions of hijacked systems
- Cheap "throwaway" domains
- "Bulletproof" hosting
- Rapidly-updating DNS (which just got worse)
- non-SMTP methods of sending spam
- poorly-maintained mail gateways
- Scalability (SMTP, DNS, etc.) concerns
among other things. For example, a much better (and far simpler) proposal that could be implemented immediately with minimal impact is: here. Of course, this doesn't solve everything either, nor does it claim to: but what it does tackle, it handles very well. Backers of SPF/DomainKeys/etc. would be well-advised to take a long look at it....on discovering Usenet as experienced with a threaded,
scoring newsreader and a mail-to-news gateway.
Welcome to 1983.
Yahoo is a spammer favorite for dropboxes because their (decimated-by-layoffs-of-the-clueful) "abuse" desk is legendary for failing to nuke them even when presented with copious documentation which proves that, yes, they are spamming, and yes, they are using Yahoo.
Yahoo's mailing list mechanisms are frequently used for spamming because they allow the list-owners to forcibly subscribe victims -- and because, once again, the Yahoo "abuse" desk takes no action.
In addition, subscribers to Yahoo mailing lists can look forward to spam, because somehow, addresses that are subscribed to them but never exposed anywhere else end up on spammer lists.
And of course Yahoo Stores is a cesspool overflowing with spammers of all descriptions.
And then there's the nagging question of just how newly-created Yahoo accounts end up getting so much spam. It doesn't happen every time: but it happens often enough.
You can read about this in more detail than you'd ever possibly wanto know just by browsing Usenet's news.admin.net-abuse.email.
And so now Yahoo, which can't even come close to keeping its own house in order, is going to trot out The Cure For Spam.
I don't think so.
In summary, both companies are slime and no thinking, ethical person should use their products.
The argument that these things should not matter "because there is a job to do" is naive and foolish. We are not at liberty to disable our consciences simply because someone has given us an assignment; we are required to leave them running and to apply what they tell us in ALL situations, not just those situations where it is convenient.
And given the past and present business conduct of both companies, mine tells me that it is wrong to use or support the products of either...so I don't. Yes, this has a cost attached to it -- but that's irrelevant, because the decision has to be based on principle, not on any momentary inconvenience.