Full Disclosure mailing list archives
Re: Spam Solution
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Fri, 18 Jun 2004 18:33:32 +1200
Alavan <alavan () pangeatech com> wrote:
Please correct me if I'm missing something here:
You're not. You are right and the SPF/Caller-ID/Domain Keys folks are just daft.
Microsoft and POBOX.com support Caller ID and SPF to help thwart phishing and SPAM. I can see it helping phishing (kind of) as the phishers won't be able to forge the FROM address. ...
True, and although phishing may be the most costly effect of forged Email addresses (a recent Gartner study put it at a US$2.4 billion loss _just to US victims_ in the last 12 months), it is far too recent a phenomenon to be the main justification or driver of all this idiocy. SPF was, I believe, originally conceived by some folk who were upset about being "joe-jobbed". Worse -- as sender faking is clearly (at least now) _NOT_ a necessary or even vaguely important part of the spamming process (with the possible exception of outright fraudulent spam like phishing) -- SPF would only ever have partly achieved the solution its proponents have always claimed for it. Under SPF, spammers using a relay or proxy or spam bot "inside" a given ISP's network will still be able to forge their Email as being from any address at any domain(s) for which that ISP's mail servers are "registered" as providing service. All the spammers have to do is change a few lines of code in spamming routines and, particularly for the increasing use of spam bots, add a few lines that pull local Email client config data from the registry and use those settings for their own spamming. Precisely the same trivial tweaks will need to be made to the "next generation" of mass mailers so they no longer forge from addresses, or at least, no longer forge "inappropriate" from addresses. SPF, etc will make no difference to the spread of self-mailing viruses nor to the "popularity" or volume of spam. The reason is obvious - it does not "authenticate" the user nor the process sending the Email, merely some superficial machine to machine connection details that are fundamentally _irrelevant_ to the process of spamming, self-mailing virus propagation and so on.
... But, that won't stop naive users from entering their personal information onto the fake site even with some rogue FROM address. Also, the phishers can just claim to be from a hired consulting agency and send the SPAM from a hijacked PC on a domain that sounds somewhat technical (or something like that).
Yep -- there are far too many other things that will more or less work here. It seems that the proponents of these schemes have lost site of the social aspects of the problems they claim their proposals will "fix". When a worthwhile payoff is achievable from a 0.001% _or even lower_ hit rate, a technological solution has to be bomb-proof to even begin to hope that it can work. As SPF/Caller-ID/Domain Keys and the like are leakier than Dear Liza's bucket they are doomed to abject failure.
Also, if spammers can't forge, so what? They'll just grab the domain name from the PC they've hijacked and send away or go back to using the e-mail client on the machine. Once the spammers change their methodology (which they do all the time to counter anti-spam efforts), these measures will have little to no effect.
Correct. You sir, clearly have more intellect than the whole SPF cartel rolled together (why do images of dung-beetles flash before my eyes?).
Plus, many people use a FROM address from one of their other POP accounts on other domains. For instance, let's say I'm sending an e-mail from home just before I leave to a business contact and I want them to see my corporate e-mail address instead. In order to accomplish this after Caller ID and SPF, all admins will have to get their users to switch to POP before SMTP to their corporate mail servers to avoid these returned e-mails (when the FROM address is intentionally forged).
Many people do, like me (in fact, my current headers must be really screwy because I've half-transitioned from one local ISP and one access method to another, and still insist on using the Email address for my UK provider who I cannot use for access and who, last I checked, did not support SMTP AUTH or TLS). And many folk who travel _have to_ forge Email (and often do not even know they are doing so!). Most of those hi-speed access methods in US (and increasingly European, Asian and Pacific) hotels and WiFi access points and all sorts intercept port 25 and silently redirect through their own (service providers') mail servers because world plus dog has disabled anonymous relaying as an anti-spam measure... I know, SMTP AUTH and/or TLS is supposed to be the solution to that, but as it is not part of the original spec, it is not as widely implemented as it should be (and many large service providers simply balk at the idea of making it available because of the CPU overhead, etc). _AND_ then there are all those "vanity" and "for life" Email addresses and all manner of forwarding arrangements that depend on "forging". Why should bob <at> ieee.org (sorry Bob -- hope you don't mind me picking you out, if you exist), who may have been using that address for all his (non-work) Email for a decade or three be deprived of that functionality? And all kinds of _really_ ugly problems are raised for mailing lists (which get even worse if you add something like Billy Boy's favourite, the so-called "Penny Black" scheme, to the mix. Of course, I'm sure the fact that he could smell some kind of never-ending income stream by way of commission or other service charges from having MS/MSN/Hotmail provide some significant part of the universal micro-payment scheme such would require has nothing to do with Bill's interest in this...) Sure, from the advantage of today's world view, the provision of address forging (well, more correctly, the non-provision of strong authentication and non-repudiation) in SMTP at the outset was a horrendous mistake -- one we certainly wouldn't make today if we were to completely re-design Email from the ground up, right?. Of course, it's easy for smart-a*se kids, who have no grip on what "Email without DNS" was like, to make such assessments, just as they entirely fail to comprehend the utter ugliness of a massively non-homogeneous "inter- network" with lots of competing and different messaging services all trying to relay and translate messages between each other. (For the record, in case anyone thinks I'm a real old-timer, I'm just old enough to have seen the bitter end of support for bang-paths and having to know which relays to point your servers at if they got messages addressed to Bitnet-hosted and C$ addresses.)
From what I've seen, most of the SPAM comes from hijacked machines - even the SPAM from other countries. So, port 25 blocking is good, but not the be-all end-all as some "users" will want to host their own mail.
Indeed. And, if SPF and the like become at all "successful", in the sense that they are actually used coercively to "reduce spam and viruses", the spammers and virus writers will update their "m@d 5kI11z" to beat the trivial restrictions SPF, etc put in their way, and will do so _MUCH_ faster than the broader IT community can "fix" the vast array of existing "SMTP but non-SPF compliant" infrastructure. Thus, if SPF, etc ever bites we will see viruses and spam continue apace (there will be a momentary drop in activity of a few days to weeks while the "old" viruses, spam bots, relays and proxies "die off" and are replaced/ updated) while large chunks of the net wallows to catch up and implement the function, but not spam and virus, limiting requirements of SPF, etc. Sounds like a really, really great deal to me. NOT!
It seems to me that if we make all MTA's register somehow (both SMTP and POST), this would eliminate the hijacked machine as spambot phenomenon. We already have MX records for SMTP, but a lot of providers use different machines to receive (via SMTP) and send mail (POST). So, maybe a new DNS record is introduced for POST. Your machine(s) could do both or not. When your server goes to accept a message, it looks to see if the IP of the sending machine is listed in this new DNS record. If not, return a 5XX error. Didn't I read something somewhere about the possibility of this?
Haven't you more or less just described SPF? And there I was thinking you understood what you were talking about... Oh well, hopefully the above helps you understand better. -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Spam Solution Alavan (Jun 17)
- Re: Spam Solution Nils Ketelsen (Jun 17)
- Re: Spam Solution Riad S. Wahby (Jun 17)
- Re: Spam Solution Paul Rolland (Jun 17)
- Re: Spam Solution Steffen Schumacher (Jun 20)
- Re: Spam Solution Nick FitzGerald (Jun 18)
- Re: Spam Solution Alavan (Jun 18)
- Re: Spam Solution Gadi Evron (Jun 18)
- Re: Spam Solution Alavan (Jun 18)
- Re: Spam Solution Gadi Evron (Jun 18)
- RE: Spam Solution Larry Seltzer (Jun 18)
- Re: Spam Solution Gadi Evron (Jun 18)
- Re: Spam Solution Valdis . Kletnieks (Jun 18)
- RE: Spam Solution Larry Seltzer (Jun 18)
- Re: Spam Solution Valdis . Kletnieks (Jun 18)
- RE: Spam Solution Larry Seltzer (Jun 18)
- RE: Spam Solution Bojan Zdrnja (Jun 19)
- RE: Spam Solution Larry Seltzer (Jun 19)