At 1:08 PM -0800 3/7/03, Nate W wrote:
Sending spam with a customized address in the "From" header of every
single outgoing message requires much more bandwidth than the usual relay
hijack approach of sending a single message with many enevelope
recipients. It does happen now, but AFAICT it's unusual, I assume because
it requires enough bandwidth to get noticed and stopped. I'm curious
about this though, if anyone has evidence to the contrary I'm all ears.
I just ran a database query on 22,000 pieces of confirmed spam. They
came from 18,000 distinct email addresses. They already have to
change the from header because they need to avoid filters and
checksums. In fact, if I look at the top repeating addresses most of
them are actually viruses. The rest are messages from spam-friendly
bulkmailers (GreatDeals, DailyInbox, ClickForMail...).
Now admittedly, that's on a small user-base and over time. You'd
need to talk to someone with a huge real-time database to get an idea
of how frequently they change the data.
Having usable addresses posted in mailing list archives strikes me as an
exceptionally bad idea, though. It's rather ironic that an anti-spam
I've long since given up worrying about obscuring my email address.
My experience has been that your address on one web page or having it
on 4000 does not make much difference in how much spam you get.
Having it on one just means the spam ramps up a bit more slowly. I'm
not going to let spammers get in the way of people communicating with
me--whether by obscuring my email address or by using challenge
response systems.
Then again. Microsoft put my webmaster address on every template
shipped in one version of FrontPage. So I'm kind of resigned to
having my addresses public. The number of sites that change the text
of the mailto but not the data is scary. The number of people who
click on it and don't notice (or know to edit the address) is even
more so.
True, but I doubt that there will be an effective MTA-level solution.
The information the MTA has to work with just isn't enough to make a
reliable decision about consent. (Not to mention the number of MTAs
controlled or hijacked by spammers.) We have DNSBLs and the like, and I
think that's about as far as MTA-only solutions will get. Adding
information for the MTA to base the consent decision upon will require
changing the MUA at one end or the other.
First of all, I think we can go a long way without even thinking
about consent. You need to leverage incentive. Legitimate bulk
mailers (like ZDNet and those that handle commercial mailings) are
running scared. Two many anti-spam solutions are likely to nail
them. (Especially the ones that talk about economic models.) They
are incented to authenticate, and they'll pay to make it happen.
[Kind of repeating what I said before here, but I'm still trying to
come up with the clearest version of the process.]
MTAs at ISPs are incented to reduce volume and customer complaints.
They could use existing systems to identify bulk email, but they'd
get false positives (mind you, some of them don't care :-). Combine
a tool for recognizing bulk email (e.g. DCC) and a tool for
authorizing bulk mail (pick one) and what we have left are the
lower-volume spammers.
A solution? No. But we've bought ourselves some breathing space.
*Then* we can talk about moving tools into the MUA. Again, we start
where the incentive is there. Nobody likes their domain to be
forged. The vast majority of users are at ISPs and enterprises.
Those domains can implement domain authorization systems similar to
what we imposed on the bulkmailers. Who gets burnt in the legit user
space? The roadwarriers and the techies, who now have to find a way
to authorize their out-of-domain email. But those are the folks who
will find it with the pain to take advantage of MUA changes, VPNs or
other techniques.
At that point you've reduced the number of forgeable email addresses
by (I'm completely guessing here) an order of magnitude. Now it
becomes reasonable to start instituting general filters against all
unauthenticated email, not just unauthenticated bulk email. And with
that, the DCC-like portion can be retired from the system.
> 2. Over time as companies move to protect their domains (and that is
the incentive--protecting yourself from forgery), they can (or
individuals can) block based on domain or personal authentication
even for non-bulk email. Note that at this point there is still no
MUA change required unless you are sending email from a location
other than one authorized by your domain.
How does one block email based on sender authentication information
without adding authentication information to the message with an
MUA? Perhaps I misunderstand; please elaborate.
You still make it an MTA decision. Mind you, that doesn't mean that
the end user can't make the choice via a configuration option--but
the blocking is done at the MTA.
> What I don't know in that model, is how we deal with malicious ISPs.
I like that model a lot. Two ideas come to mind for dealing with losers:
Revoke their certificates. How this is accomplished is left as an
exercise for the reader.
Require member ISPs to join with a contract stating that they will:
...
Keep in mind that this assumes they have to join something. It's not
clear how you persuade (for instance) 163.net to signup for anything.
Sure, they don't get to block spam with the system, but who's going
to stop them from sending?
--
Kee Hinckley
http://www.puremessaging.com/ Junk-Free Email Filtering
http://commons.somewhere.com/buzz/ Writings on Technology and Society
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg