I've specifically mentioned HTML and attachments, but a similar
control might be
that a recipient might want to limit the ability of non-whitelisted
senders to
(say) drop messages bigger than a certain SIZE into their Inbox, too.
If
someone is going to be gone on a cruise for a week or two...
I don't think that recipients really give even a half-hoot about
stamps. What
they have is a limited resource (Inbox, and their time!), and they
typically
want to restrict WHO has access to it, or (if they're a newcomer) how
much space
they can use until the recipient has decided whether or not to grant
them more.
That's also an interesting way of looking at the problem,
Thanks. The biggest problem with unrestricted sending is that one's inbox
fills
up and mail starts bouncing. THAT creates HUGE problems for (at least many)
people.
...but it can already be handled without extra standards.
Sure, and my solution doesn't really require "standards" either, since by its
nature it is single-ended.
Perhaps someone could write something to hook into procmail, and/or write a
BCP.
I guess I really need to find out more about BCP documents. What does it take
to write them, is there a particular format they must adhere to, and where must
they be submitted for review/distribution/archiving/etc?
In a recipient-driven scheme, senders still have to be able to buy
stamps, but they will be able to choose their stamp vendor, rather
than being limited to their ISP.
Stamps are stupid and cumbersome. I agree with those who point out
that the
purpose is to limit sending rate and volume, and that there must be
easier and
less complicated/expensive/disadvantageous ways to do that.
Without attaching *some* new piece of information to the mail itself,
the only even partial solution I can see is rate-limiting by the
sender's ISP.
And that implies that the ISP treats E-mail as a special case, and/or forces
originators within their network to use the ISP's mail servers (which many of
us
REALLY do not want to do).
In my case, for example, I'd really rather use the mail server provided by
DomainDirect (my domain provider for terabites.com, and indeed for all the
domains I provide for my consulting clients) rather than the one provided by
comcast.net. It simply looks more professional to have my server be
"mail.terabites.com" or "smtp.terabites.com" than "dfw.comcast.net" or whatever.
And of course, there's also the issue about braindead SPF-type schemes which
try
to FORCE users to use mail server IP addresses which are coherent with the
From:
address... if I'm going to use my terabites.com E-mail address, then I would
not
be able to do that from my comcast.net-provided SMTP server.
One interesting-sounding alternative approach is to MAKE SURE that any Web site
being promoted by the spam gets LOTS AND LOTS of hits... for example, by having
EVERY recipient of the spam auto-generate hits against the Web sites being
promoted. (The result is essentially a DDOS attack against the spammer's
site!)
The problem with that approach, as fun as it initially sounds, is that it's
far
too easy for the spammer to use that mechanism to "joe-job" someone else.
Which isn't happening, in general.
And for a number of good reasons, including that in general they don't have any
ready way to control what is and isn't E-mail... and to decide what you count
and what you don't. Do copies count as much as original destination addresses?
How about bcc copies? What about mails sent to forwarding services or mailing
lists (or zombies, for that matter)? It's ultimately pretty easy to evade such
schemes.
Only a few ISPs - the most savvy and network-oriented (as opposed to
revenue-oriented) - seem to have any mechanism to detect and deal with zombies.
It's very hard to deal with in any definitive way. How do you distinguish
whether outgoing mail from a normally-reputable system is really still
legitimate?
There's always going to be a zombie-PC problem, to some extent at
least.
Thanks for also pointing that out. That is in fact the KEY problem,
at least using present-day spammer approaches.
Hold onto that thought.
Why did spammers start using zombies? Because we got good at
blacklisting by IP address.
That, plus they simply decided that it was silly for them to use their OWN
resources for spamming, when it was so easy to steal resources from other
people.
Why did we blacklist by IP address, rather than whitelist by e-mail
address? Because we didn't have any strong authentication method that
was widely used - and we still don't.
Well, not really.
A salesman who hands out thousands of business cards a year (or a company which
posts a customer service e-mail address on the labels of their products) is
EXPECTING to get mail from people they haven't whitelisted... just as
publishing
your telephone number in the phone book is done PRECISELY SO THAT you can be
called by people you haven't given your phone number to, personally (and thus
'whitelisted'). Normal whitelisting schemes generally don't allow you to get
mail from people not yet on your whitelist. Blacklisting IP addresses, on the
other hand, allowed us to block known-bad open relays and other familiar sites
that spammers were massively misusing.
This fixation on "authentication" and forged From addresses is really dumb
because it really does NOT solve the problem. (NEITHER the spam problem NOR
the
worm/virus problem). It's really just a diversion chewing up a lot of
engineering time and standards committee effort which ultimately isn't going to
be effective for the stated purpose.
There's NOTHING inherently more secure about the Mac, other than the
fact that
it's a distinctly second-string system in terms of frequency and
therefore
hackers haven't focused their attention on it. If everyone were
running Macs,
or everyone were running Linux, then hackers would be writing Mac or
Linux worms
instead, and they'd be comparably successful.
Note that (just recently) a multi-university "distributed
supercomputer cluster"
of *nix-based boxes was penetrated by hackers, much to the chagrin of
the
associated administrators. And THAT was a system which DID have savvy,
highly-intelligent-and-qualified admins AND expensive,
professional-grade
systems and "serious" OSes.
The difference is that the cluster was hacked by a determined,
"professional" cracker in an isolated incident. The Wintel zombies are
being compromised by what we used to call "script kiddies" using
mass-market exploits, via vulnerabilities that were either known (and
were patched) long before, or social engineering coupled with poor OS
design.
Most spammers are NOT casual "script kiddies" working out of their dorm room
just on a lark. Hackers, maybe, are of that ilk.... but not spammers.
Spammers
are generating REAL MONEY by their antisocial behavior, and are plenty ready to
use any techniques they can to continue doing so. It took concerted, ongoing
court actions over many years to put Spamford Wallace out of the business.
I still contend that Macs and *nix boxes are generally just as vulnerable, and
are only "safer" because they're less numerous and thus less attractive targets
for spammers and hackers to go after.
While the Mac and Linux are not perfect, they do lack many of the
fundamental design flaws that make Windows such a soft target.
Microsoft has gotten the message, and their new systems are going to be
substantially harder to break into. We're just starting to see the results of
those changes.
Regardless, the fact is that the ultimately secure system has never been
created
(despite billions of dollars spent by the military over several decades trying
to do so) and if we ever DID create such a beast, it probably wouldn't be good
for much of anything.
Linux MUAs are largely incapable of creating an executable file on their own,
Who or what says the MUA has to do it?
...and have to be deliberately coaxed into expanding a tarball in such a
way. Apple Mail isn't quite as mistrustful, but it's generally clear
to a Mac user what is an executable and what isn't.
Mac and Apple are largely RESPONSIBLE for much of the problem. They are the
ones who created and pushed the idea of hiding file extensions and file types,
and for dumb users to "just click on everything" [blindly!] to make it do
something.
A problem is that zombies can't merely be used as a relay, they can
also be used to leech any stamp account the victim uses for their own
e-mail.
Absolutely. And that's why _all_ of these modified-DNS, SMTP-auth,
SPF,
certificate, E-postage, and similar such systems are ALL simply
non-starters.
NONE of them solve the problem, because zombie enlistment will enroll
legitimate
(trusted, legitimate) systems to serve spammers.
Then how do you propose to get rid of the zombies? I thought we just
agreed they were always going to be a problem.
One major move towards getting rid of them, as I've stated repeatedly, is to
restrict (by default, at least) incoming attachments (by several classes of
risk
and danger) to only specified, recipient-approved senders. That would (at a
minimum) virtually eliminate E-mail attachments as a vector for spambot zombie
worms, since the great majority of recipients probably wouldn't accept
executable-type attachments from ANYBODY AT ALL.
If the resource being leeched is controlled by a third party, however,
it's easier to monitor and take action on suspicious behaviour.
That's like saying that there ought to be somebody (FBI?) monitoring and
pursuing stuff like Nigerian spam. If there really were, then why in the hell
does this crap keep going and going? Why don't they round up these scum and
put
them all out of business? There can't POSSIBLY be THAT many of them. The fact
seems to be that the third parties that are supposed to be protecting the
public
simply are NOT doing their job.
This is why e-postage can be helpful - as I mentioned immediately
afterwards, the compromised account will quickly run dry.
As has been repeatedly stated (and just as repeatedly ignored) there is NOTHING
about E-postage and requiring money and payments that can't be achieved without
money or payments entering into it.
For that matter, you could even GIVE away the "stamp" that the sender would
need
to use. For instance, when you give someone your E-mail address (at your Web
site, on your business card, whatever) simply tell them to "put 17XyZ in the
subject line somewhere, otherwise your mail won't be delivered to me."
Everyone
would present the key in a different way, complicating address (and key!)
harvesters. This could then be used in conjunction with a permissions
whitelist
such as I've proposed... you can whitelist people (mailing lists, for example)
that don't need to include the passkey, but non-whitelisted senders (that still
could be restricted against sending HTML-burdened mail or attachments of
various
kinds) might also have to have one of the recognized passkeys in the subject
line somewhere.
However, the compromised stamp account will quickly either become
empty or run up a monstrous bill on the victim's credit card (the
former situation is obviously preferable, and I'd hope that consumer
stamp accounts were set up that way).
Either way, there's going to have to be a procedure (probably
involving per$onnel) to deal with that $ituation when it (frequently)
develop$.
Of course. Education is vital!
That type of "education" is brutal and ineffective. Ultimately, what happens
when people run up (via worms etc) thousands of dollars of phone bills to
Moldavian 900-number dialup accounts is that the phone companies end up getting
stiffed, but not before they spend hundreds or thousands of dollars worth of
time trying to deal with the mess.
Perhaps, to save personnel costs, ISPs (especially those who are also stamp
vendors) will start throwing in antivirus software, easy-to-use personal
firewalls, and even (wow!) day classes for net-newbies.
And who do you believe will pay for all of that stuff? Not the spammers,
that's
for sure. And when are busy people going to make time to attend those classes?
Get real.
Taking the "Harry Hardass" approach ("well, that's just too frickin'
bad, maybe you'll learn next time to not let your system get
infected!") will end up eventually driving a lot of people offline
that *need* to be online. This kind of thing will eventually become a
NIGHTMARE, and a costly one to boot. I really don't see it as a
practical solution.
ISPs that take that kind of attitude probably deserve to lose
customers.
As do the ones that simply pass on the high costs of these ill-conceived and
ultimately ineffective "anti-spam" solutions...!
The *right* approach is to offer advice on how to clean up
and secure their machine, and how to avoid future infections.
And maybe a Web site could help teach people that, but there are plenty of
sites
with that information available today and lots of people that just don't find
it, or care enough to take it to heart.
Meanwhile, ISPs that ought to know better (such as AOL, with perhaps the
highest
ratio of "clueless newbies" of anyone) are among the WORST by virtue of
promoting the pointless and gratuitous use of HTML-burdened E-mail!!!
It's not really all that hard, and they could even print a leaflet about it
with step-by-step instructions.
And who will pay for THAT? Again, not the spammers.
After that, the zombie can still spew mail all over the place, but it
will be unstamped. The empty account (or huge bill) also serves as a
wake-up call to the victim, to get their machine cleaned and secured.
Fine, but again, meanwhile, you're going to have lots and lots of
spam. And for every spambot zombie that you clean up, the spammer
will create two new ones.
Unstamped spam isn't going to get into the inboxes of participating
recipients - that's the whole point.
There are more than enough stamps to go around, and plenty of infected zombies
to "steal" stamps from.
Once woken up, the victim might be one less person to get re-infected in the
future,
Nice thought, but....
...so perhaps the endless supply of zombies will get less plentiful in the
future.
In fact, experience demonstrates otherwise... people who get infected by worms
and viruses tend to get infected over and over again. And this isn't just
about
computing... consider folks in the hospital for life-threatening emphysema, who
still insist that they have a 'right' to keep smoking.
At the moment, there's little or no feedback to victims, so they don't
learn anything.
It's not just a "learning" thing, they have to CARE. And many, simply, do not.
The interesting thing is that a stamp can also act as proof of where
the mail was sent from, and/or who by, because there's a money trail
(if nothing else) to follow, and each stamp is unique.
Again, I think this is one of those "it seems like a step in the right
direction" things, like SPF, that ultimately doesn't really answer the
spam problem in a meaningful way.
...but it's not actually a *bad* thing, is it?
Anything that increases costs and doesn't solve the problems it's claimed to
solve (or at least comprise a major step in right direction, and without
significant counterbalancing negatives) is "a *bad* thing", IMHO at least.
Forgery detection sounds fine, and I suppose that you could even just
build your
OWN statistical table based on IP addresses that you've seen in the
headers of
valid E-mails coming from whitelisted senders, but again that fails
dramatically
when the "valid" non-forged sender gets infected and starts sending
spams with
valid return addresses.
But in that case, you know who's sending it, so you can block them
temporarily and help them fix it.
Do YOU intend to go around cleaning up other people's messes? *I* don't have
the time for that, as a general rule. I do it for my consulting clients, but
then again THEY *pay* me for that. :-)
I think that one can forego trying to detect forgeries, actually, as
long as you have a good way to detect spams based on their CONTENT.
But we don't. If we did, we'd be able to stop spam, NOW, just by
slapping one of these perfect filters on the front of our inbox.
You really haven't been paying attention, have you?
There are a number of familiar tricks and evasions that spammers use which
frustrate and confound antispam content filters. One of them is 'text as
image'
which would require OCR software or something (at least) to decipher the
content
of the mail message. Another is obscuring the content by HTML tricks (bogus
tags, scripted decryption, misrepresented links, font and color tricks,
obscured
non-canonical URLs, and so forth ad infinitum).
Denying the spammer those tricks and evasions makes it VERY VERY MUCH EASIER
for
effective and practical antispam content filters to do their job.
But also let's recognize that when dealing with the question of antispam
content
filters, "good" might be quite adequate, even if they're not 100% "perfect".
It
wouldn't really bother me TOO much if a spam or two got through my filter, say
once a week or once or twice a month.
And there are a number of apparently "good" antispam content-based filters out
there. They will be BETTER once the attachment/HTML issues are resolved.
Here's some news: we already do use content filters - everything from
Bayes through distributed bulk detectors to phrase matching. It helps,
but it is absolutely nowhere near perfect.
Doesn't have to be perfect. Most importantly, we need to be able to have
techniques which evolve as spammers get more devious. SpamAssassin is a good
start, at least in terms of what it apparently does (I'd probably be less
impressed about the language it's likely written in).
E-postage is cumbersome, costly, and very labor-intensive to deal with
the problems that would inevitably result from it.
Some of the proposed schemes undoubtedly are. Have you read the
discussion I've been having with "der Mouse" over the past day or so?
Sure.
I think we've hashed out something a lot more scalable than most,
though I won't pretend it's finished. Many schemes and objections seem
to assume, for example, that stamps have to be anonymous like e-coins -
which makes them unreasonably hard to verify.
I simply think they're (still!) cumbersome and inconvenient, and don't really
solve the problem.
...The gist of it is that while zombies can indeed be turned into hashcash
factories, they will still be limited to a tiny fraction of what they'd
normally
be capable of if they were just limited by bandwidth.
There are SO MANY zombies (and spammers can make about as many more as they
want) that for all intents and purposes they have no genuine limits to EITHER
computing power, OR bandwidth.
So it improves the situation dramatically when compared to the status quo.
So what happens to companies (say, like Yahoogroups) that (legitimately) sends
out probably billions of E-mail messages a day?
Sorry, I truly don't like ideas that make sending (legitimate!) E-mails
significantly more expensive. ULTIMATELY, we LEGITIMATE users have to pay the
price for that... spammers won't pay it, that's for sure.
And that's while keeping the bit count low enough to run on Aunt
Tillie's prehistoric Mac IIcx. If we forget about the IIcx and
concentrate on Pentium-class customers, the rate limit gets even
tighter.
Sorry, I don't like junk like that. It's a lot like schemes that used to count
on slower processors and which then fail when timing loops (say in device
drivers) time out far faster than they were ever supposed to.
And likewise, "identified" systems can be taken over by zombies. So
neither of these schemes work. Period.
If an identification is compromised, a few spams will get through to
particular recipients who have it on their whitelist, but the
recipients will know exactly who needs to be told about it, and can
remove the appropriate whitelist entries until it gets fixed.
You don't have to have stamps or authenticated IDs to achieve that. All you
need is a multilevel address scheme, or (barring that) even just the "free
stamp" passcode thing in the subject line as I discussed earlier. (A new
header
line would work just as well, if you didn't want to use the subject line for
it.)
Without the whitelist, the identification becomes moot, as the filter will
fall back on other schemes.
We agree that whitelisting and filtering are key parts of the solution, anyhow.
(At the moment, most recipients' barriers to entry are exceptionally
low, even with today's content filters, because there's no practical,
universal way to detect forged mail.)
Detecting "forged" mail, while arguably nice to know, only tells you
whether mail is (probably) forged. It doesn't tell you EITHER that
the mail is, or that it is not, spam.
Do I want forged mail in my inbox? No, because whoever sent it can't
be trusted to even say who he is. End of discussion.
So let's say that we stop all forged or bogus from addresses. BFD. Spammers
change (overnight) to use "real" return addresses. There, are you happy now?
(Really... THINK about the implications...) Again, you've probably made the
problem WORSE, rather than better.
[...] Likewise, they in general don't know who the intended recipient
might have whitelisted, so they don't know either which machines
they'd need to infect (or what From addresses they'd have to
counterfeit) in order to get their spam through to that specific
recipient.
Stop. Think. How do mass-mailing worms usually find machines to
infect? They scan the latest victim's address book. Then they send
infected mail using every combination of addresses they can think of
from that list. Chances are good, a lot of these people know each
other and maybe even trust each other to send attachments once in a
while.
That doesn't help unless (1) you know what TYPE of attachments the sender is
approved to send to a given recipient, _and_ (2) sending that specific type of
attachment can be used to the spambot's advantage.
The same logic applies to spam. Chances are, a lot of people in the
address book will be in each others' whitelists.
Actually, probably not. Most of my correspondents don't send me HTML-burdened
E-mail, and fewer still send me attachments. Almost none send me executable
attachments! Of those who DO send HTML-burdened E-mail (with my very
begrudging
approval), basically NONE of those use scripting or ActiveX in their E-mail
messages.
It's very much mistaken to believe that you have to whitelist everyone you
receive E-mail from. You apparently don't really understand my proposal.
And the biggest problem confounding most antispam approaches, the
spambot zombie, is virtually eliminated as a threat (at least for
E-mail transmission) by my approach's default of not allowing
executable attachments from non-whitelisted (TO SEND EXECUTABLES!)
senders. Again, note that typical users will normally not whitelist
ANYBODY AT ALL to send them executable attachments!
Executable attachments are old news. Every ISP with a clue already
blocks them. The new threat is ZIP archives! Even better, they're
polymorphic, password-encrypted ZIP archives that are hard to scan with
antivirus programs!
Antivirus programs are based on the premise that you know all the viruses,
which
presumption clearly fails for new viruses.
Tell me, how do these fit into your brilliant scheme?
Very simple. Since they're potentially carrying extremely dangerous cargo, AND
since they're very rarely used for legitimate purposes, you either classify
them
like you do executable attachments, or you could create a special attachment
class for encrypted archives. Then you'd only receive such stuff from people
(if any, probably there aren't any) that you had already arranged with and
whitelisted to send you that type of stuff.
Don't forget that these ZIP archives are often apparently
coming from people the recipient trusts, and probably has in their
whitelist...
You've completely ignored or misunderstood the nature of my whitelist, it
seems.
Think of it as more than a binary "whitelist", rather more like a "permissions
list". Each whitelisted sender would have your approval to send you certain
classes of mutually agreeable HTML and/or attachments, based upon your
relationship with that sender. By default, non-whitelisted senders could only
send you plain ASCII text E-mails, without any HTML or attachments at all (and
those would be subject to further limitations, say a maximum "unknown sender"
size limit and (hopefully!) after having passed a good antispam content filter.
Think of it more like the type of permissions that an NTFS file system
supports... some users can list the filenames in a directory but not access the
files, maybe they can't list the filenames but CAN open them (only!) if they
know the filename already, maybe they can write a file but not read it, maybe
they can read or write a file but not delete or rename it, or whatever.
The fact that it's so much more fine-grained than a crude binary "whitelist"
means that you can create a very narrow set of rights and permissions for the
people you normally deal with, and most spammers or zombies won't understand or
be able to figure out the rules, and therefore will have a lot of trouble not
running afoul of them and having their spam output t-canned.
Does that make more sense now?
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