|
Re: [Asrg] How about we do something about spam?
2007-01-31 10:41:24
On Wed, 31 Jan 2007 11:05:21 -0500
David Maxwell <david(_at_)crlf(_dot_)net> wrote:
On Tue, Jan 30, 2007 at 10:07:51PM -0600,
gep2(_at_)terabites(_dot_)com wrote:
[problem of botnets as spam originators]
The solution to the problem is actually AMAZINGLY
simple... I know that a lot of y'all have this fixation
on
IP-based solutions, but a FAR better solution (rather
than
attempting to block spam AFTER the botnets are
recruited)
is to block the virus/worm code-containing E-mail
messages
BEFORE they infect those computers.
And that is really rather easy... you simply block any
HTML or attachments (and particularly EXECUTABLE
attachments) that isn't coming from a sender that is
known
and trusted by the recipient TO SEND THEM EXECUTABLE
CONTENT.
Note that MOST users (probably 98-99%) will not
whitelist
ANYBODY to send them executable content in E-mails...!
The reason people have a fixation on IP-based, or
signature-based
identification mechanisms is simple.
Without a guarantee of 'identity', you can't whitelist
someone. You'll
end up adding a whitelist entry which viruses will forge
mail from in
order to get to your inbox.
Well, it IS likely that desperate spammers would try to
forge mail to seem like it comes from widely-trusted
senders who recipients are likely to have some kind of
whitelist entries for.
On the other hand, that still limits spammers and viruses
in terms of WHAT they can send, and encourages legitimate
senders to not send types of content which are likely to
be misused for malicious purposes by forgers.
A whitelist is simply an end-user accredited reputation
service.
If it were a simple go/no-go whitelist, yes. The fact of
it being a fine-grained whitelist is a horse of a
different color, because it also creates a narrow
sender-specific keyway through which mail from THAT
SPECIFIC sender must fit in order to be accepted.
Like
all reputation mechanisms, it makes no sense if the
entity being queried
for can not be proven to be the same as the one being
vouched for.
While that's a valid point, I'll also point out that once
an E-mail has gone through an intermediary MTA, (in fact,
even BEFORE then) it's hard to be 100% sure where it
originally came from in IP address terms, either.
Spammers OFTEN forge counterfeit, bogus Received: headers
too.
So what's to prevent them from forging a Received: header
with a trusted-sender IP address?
The bottom line is that the best way to decide that an
E-mail is legitimate or not is by examining THE TOTALITY
of the information available, and that goes well beyond
the information in the headers. It includes relating the
CONTENT of the mail to what the recipient expects from
that sender.
If someone got, for example, an e-mail that claimed to be
from me but which was all in chinese characters, they
would probably quickly conclude that my return address was
forged.
The fact remains that putting so much effort behind
IP-address-based solutions will NEVER yield as good a
solution as a solution which includes message content
analysis ("SpamAssassin" or similar), ALONG WITH
fine-grained, sender-specific rules which robustly deny
spammers nearly all the tricks that they use to evade
content analysis filtering.
And the OTHER major thing we need to do is to come up with
a set of "best practice" guidelines (probably based on the
"fine grained whitelist" and suitable default rules like
I've proposed here) which basically eliminate E-mail as a
recruitment mechanism for zombie spambot armies. Forcing
spammers to directly use their own machines for spamming
would put a MAJOR crimp in their operations, and help make
virtually all the other anti-spamming approaches to be a
lot more effective.
I honestly don't understand why we're even still arguing
about this. It's obvious that it makes for a HUGE
improvement, and obvious that it can be implemented
without having to re-engineer the whole E-mail system or
the whole Internet.
The biggest area of discussion is that it would
(admittedly) be nicer to truncate the unwanted E-mail
earlier in the distribution chain. But that's not
critical, at least from the end-user position.
More to the point is that if we DO implement this at the
end-user position, nearly everywhere, spammers simply will
give up trying to send E-mail that they KNOW will get
through in only such tiny numbers that it simply isn't
worth the effort anymore.
At THAT point it doesn't matter where we truncate the
flow, because the only people still trying are those who
are simply trying to play with the infrastructure of the
Net, and:
1) there isn't any money to be made doing that;
2) it's about as satisfying as trying to argue with a
vending machine that stole your money.
So it probably isn't NECESSARY to stop the transit earlier
in distribution, if it WILL be stopped SOMEWHERE enroute
(even at the end).
At least we can offer relief to the great majority of
Internet users, and reduce the remaining problem (if there
still is one) to something that ISPs and backbone
operators can deal with.
BTW, that's another reason for my proposal that we limit
the maximum size of non-whitelisted E-mails, too... so
hopefully the bandwidth used by such residual spam
messages will become smaller, as a percentage of total
backbone traffic, as legitimate higher-volume traffic
(video webcams, high-quality streaming audio, video
streaming, etc) become dominant. Hopefully it will also
help discourage the spammers possibly shifting to bulkier
types of messages which clog inboxes and the limited
bandwidth of dialup users.
Gordon Peterson
http://personal.terabites.com
1977-2007 Thirty year anniversary of local area
networking
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
|
|