On Thu, 2004-05-06 at 11:56, Dustin D. Trammell wrote:
[snip]
This is exactly why I was originally attracted to proposals like SPF.
Most technologies being created to battle spam and email abuse were
addressing the SYMPTOMS of various problems and not one of the PROBLEMS
itself. SPF actually addresses a PROBLEM. Addressing symptoms of a
problem and not the problem itself is one of my pet peeves. Simply
drives me nuts to see misdirected effort.
Yes, and some detractors of SPF claim that does not solve the
problem. But the question to ask is what is 'the' problem you think SPF
is designed to solve? It's not designed to stop spam. Personally, I
don't care if I have the same amount of spam after SPF, SRS, and SMTP
AUTH are widely deployed. As long as the Return-Path is set to
something that allows me to pinpoint where the email actually came from.
SPF alone can't do that. But coupled with market pressure to
implement SMTP AUTH and egress port 25 filtering, it will be getting
easier to track culprits down, or stop them in their tracks altoghter.
(Yes, I know the debate about port 25 filtering vs. individual rights,
and I'm *very* much on the side of individual rights. But as long as
there are vendors that will give you fixed IP addresses, they could
require you to run your own domain(s) with your own mail servers if you
want port 25 open. Then, you get the freedom, but also the
responsibility associated with your domain registration.)
If complaining to this sender yields a clueless Outlook user who's
machine is infected with a spam cannon virus of some sort and who does
not respond or responds with a confused "I didn't send you spam," then
the next stop is the user's ISP. With the current non-authenticated
email world, NONE of the information in the envelope or headers is of
any use in tracking down the source.
I predict the spam/virus writers will adapt quite quickly to SPF and
other sender policy schemes. Their code will likely be (if they are not
already) IRC clients and/or HTTP clients (or even P2P networks or other
distributed platform-like environments) that will easily be able to
accept new updated engines and spam content to be delivered en-mass.
These engines will do things like send their spam through the infected
user's SMTP server at his ISP, authenticated with the user's username
and password (either saved on the user's system, or sniffed while he
types it in).
But when this happens, we will be in a better place. As more hapless
victims of spam/viruses get cut off from their ISPs, they will be forced
to either take more proactive measures to keep their systems clean
and/or put pressure on their software vendors to put security far above
convenience.
SPF is on the fast track, it seems. But I'm also in disagreement with
the last paragraph of the eWeek article reference in this thread. We
have working code and a pretty significant uptake so early on. And
reports of it working as intended. Keep up the good work, folks.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets