Today, the only thing in an email that's pretty much guaranteed not to
be forged is the source IP. If LMAP/MARID becomes widespread, domains (in
HELO,
2821 FROM, 2822 From:, etc.) will be like IPs: They, together will be the only
thing in an email that's pretty much guaranteed not to be forged.
I know that there is still all kinds of concern about trying to identify the
sender of spam, with all kinds of convoluted approaches to trying to solve that
problem, but ultimately that just IS NOT going to solve the real problem.
What you're going to find, upon tracking back, is often going to be a proxy
spambot that's been infected by a worm... with a clueless (or not) person
operating it, and probably unaware that they're pumping spam out to the Net.
So
what do you do then, punish a fellow victim?
What I think makes more sense is to instead "follow the money"... to locate the
actual seller of the drugs, or the mortgage spammer, or whatever... and go
after
the Web hosting they're using, for example.
Towards that end, it needs to be a lot easier to find out who the ACTUAL Web
host is of the site the spam is promoting... not just the link to the (say)
Geocities site which only just forwards to another rogue site elsewhere.
If we're ever going to REALLY get a handle on this problem, I still believe
that
what matters more is:
1) putting the quash on unexpected attachments (especially if they are
executables); it's much harder to infect a machine with a worm or virus if the
only kinds of attachments that the recipient has authorized are JPG, GIF, and
TXT types. :-)
2) likewise, making support for HTML-burdened E-mail (which can contain all
kinds of malicious scripting, text-as-image, Web bugs, obscured URLs, ActiveX
malware, spoofed links, and all the other nasty tricks that spammers use to
deceive the targets of their spam) much less of a given.
I believe that the most significant way to hugely improve both of these
situations is the ability of the recipient to whitelist individual specific
senders with SPECIFIC rights to:
a) send them attachments (and subapprove based on the class of the
attachments)
b) send them HTML (and POSSIBLY subapprove based on categories of HTML tags
allowed).
The default without being whitelisted would be to only accept plain ASCII text,
no attachments, no HTML.
That means that plain ASCII text E-mail would be the only practical way to
initially establish a communication with someone for the first time. After you
had established a relationship with that person, you could then negotiate with
them for the right to send them attachments, HTML-burdened mail, or whatever AT
THE OPTION OF THE RECIPIENT.
This solves the problem of (say) a Customer Service Department of (say) a
consumer products company, who will need to receive unsolicited E-mails from
maybe millions of individuals.
It means that unsophisticated users MIGHT set up their systems so that Aunt
Gertrude can send them JPGs of her poodle Fifi. They are unlikely to EVER
(especially with a suitably dire-sounding dialog box warning them about
enabling
the capability) whitelist anybody to send them (say) PIF files...! The result
anyhow will be that "almost nobody" will be authorized to send executable
attachments, and few will be authorized to send HTML-burdened E-mail.
Spammers as a result will resort to sending plain ASCII E-mails, but at least
content-based filters don't have TOO hard a time dealing with those... the
biggest problems for such filters are all the HTML-based tricks that spammers
so
love to use.
Again, my solution doesn't require rethinking the whole world's Internet, POP3
or SMTP infrastructure. It doesn't eliminate viruses and worms 100%, but it
will take a damned large hunk out of their collective hides, and do so faster
and at a far lower cost (both money and inconvenience) than anything else I've
seen tossed around.
Most of this other stuff, SPF, or Microsoft's proposed "solution" for the
problem, are going to change all kinds of stuff and break a lot of existing
applications and systems, which ALMOST might be worth it IF they actually
solved
the problem.
BUT THEY WON'T.
(As for tracking IP addresses, presumably to allow blacklisting. note the
recent
story of one of the Nigerian spammers who was actually arrested because he was
stupid enough to reuse a familiar haunt... and was hooked up in a NAT
configuration from a local Internet cafe that offered a wireless connection.
Now yes, it IS true that in that case they caught him due to finding his IP
address, but there are enough wireless hot spots around that a clever and
highly
mobile spammer could play cat-and-mouse for a long time before being caught.
Ultimately, what will do a lot more to quash both spam and worms/viruses, *I*
think, would be if the sender realized that it was nearly impossible to get
them
through to anybody at the other end.)
We don't want to try everything and see what sticks; we want to develop
a plan to achieve ultimate victory in the long term. (Unless we are
part of the industry and don't want the problem resolved once and for all!)
The nice thing about my approach is that there is almost no downside, and it
can
be implemented QUICKLY and with an immediate payback for each person doing so.
The payback doesn't wait until "everyone goes along". What's more, it doesn't
in any way PRECLUDE any of these more intrusive solutions should someone come
up
with a "good" one some day.
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