Or, alternatively, the problem SPF "solves" is NOT the spam
problem, nor is it the worm problem.
Yes, that's true, SPF attacks the problem of forged MAIL FROM
addresses and forged HELO domains.
Right, but if that's the ONLY thing it does then it shouldn't be talked about
as
a cure for spam, since spam DOES NOT HAVE TO USE forged From addresses or
forged
HELO domains.
...It's indirectly related to spam and worms at the moment, like open relays
were related to the spam problem some years ago.
"Indirectly related" is fine, as long as we recognize it ONLY as such. (And as
such, I think it gets WAY more discussion and attention than it deserves.)
as long as authenticated machines can be infected and
recruited to send "authenticated" worm/spam messages, SPF
and similar schemes do very little to prevent such things
It allows to find the relevant abuse desk fast, not too shabby.
There are already IP-based ways to do that (at least to the upstream node(s))
based on the Received: headers, along with Traceroutes. The From: address is
NOT needed.
Especially for "vanity" domains, there's no point in complaining to
abuse(_at_)getgreatinternetdealz(_dot_)com anyhow. The spammer knows what
they're doing.
The place to apply pressure is the upstream node(s).
All these weird challenges / out-of-office / vacation mails
won't hit innocent bystanders, if many receivers support SPF.
I don't see SPF as the solution for almost ANY questions.
"Many" is good enough, spammers and worm authors won't waste
their time with something not working at say AOL or behind SA.
The idea of creating a confusing patchwork lattice mesh that the spam would
have
to work its way through is fine. But SPF is not at all difficult to defeat...
you just send the mail using the infected victim's authorizations.
undoing the DAMAGE that SPF has done
There's no "damage", if you don't like it just don't publish a
sender policy.
Again, you're ignoring things like discussion group/mailing lists, message
digests, and so forth. Anybody who makes the mistake of supporting SPF later
finds that they can't send mail using their business E-mail address when they
are (say) on a cruise ship vacation or at an Internet cafe in some other
country.
your "solution" is to get rid of MIME multipart resp.
text/html, and mails bigger than 12 KB.
No, not at all.
You said so in <200411280518(_dot_)AAA23560(_at_)ietf(_dot_)org> :
Please don't misread or misrepresent what I said.
| default is to (by default) not accept messages that:
| (1) are are bigger than some limited size (say 10K-25K),
| (2) contain attachments, and/or (3) contain HTML
12,000 bytes is a limit in my own "popstop" script, but it's
within your size limits.
Fine, it matters relatively little what value you set the limit to. The point
is that there's little reason to accept "large" messages from people you've
never gotten mail from before. Once they've established contact, you can (if
you wish) allow them to send you bulkier stuff.
Once the contact has been made, and the recipient trusts the
sender, *if* there is going to be an extended correspondence,
then the recipient can enable ONLY JUST the type of
bulkier/riskier content that they agree
Okay, in fact I have "special" addresses (not nobody(_at_)xyzzy)
where I don't limit the size, and don't look for any TV or UE
starting a base64 attachment (poor man's AV, credits to John)
Sure, but of course an HTML tag that invokes an ActiveX could be just as bad.
But the UBE still sits there in my POP3 mailbox waiting for an
over quota or my script.
In my case, I pull and process all incoming mail from my POP3 mailboxes every
60
seconds or so. Agreed that network bandwidth would be optimized by doing the
blocking higher upstream, but as an ordinary user that's tilting at windmills.
Better to just fix the problem for me, and let others come along when they're
ready (if ever). (I re-stage the processed mail in a local POP3 server on one
of my server machines here, where mailbox space is only limited by the
available
space on that hard drive).
And many of the bounces and all other crap caused by forged addresses were
relatively small.
It can cause MAJOR problems if "hard bounces" instigated by spoofed From:
addresses interacting with braindead antivirus software cause ALL your
Yahoogroups to stop forwarding your mail. :-(((
With widespread adoption
That's the problem of all FUSSPs. As you see I have no problem
to mix different ideas, as far as that's possible for a normal
POP3 user without the root password for the MX of his provider.
The point about my permissions list approach is that *I* benefit fine, EVEN
WITHOUT widespread adoption.
Widespread adoption (such that spammers simply stop trying to send
HTML-burdened
E-mail, or attachments, knowing that the likelihood it will get through is
miniscule) both reduces spam byte volume by something like 70-85% *and* makes
it
far harder for them to get their spam past content filters, since it denies
spammers most of their most helpful tricks.
But starting from Day One of a permissions list, the permissions list in
conjunction with a good antivirus filter should eliminate (in E-mail, at least):
1) virtually all viruses and worms;
2) spams using text-as-image;
3) encrypted spams using Java decryption;
4) obscured and spoofed URLs;
5) malicious scripting;
6) malicious ActiveX;
7) malicious attachments.
It's simple, inexpensive, readily implementable, effective, and nearly
impossible to evade by technical means.
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections! http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg