Message-ID: <40D3357C.27631.9418C9A3@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Spam Solution

Alavan <alavan@...geatech.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

Powered by blists - more mailing lists