* * * * *

       Funny how I haven't seen this anti-spam technique bandied about

The past month has been a continual fight with email [1]. It got to the point
where I sat down and designed an entirely new email system in the hopes that
it would stop spam once and for all (based upon some ideas [2] from Dan
Bernstein [3]) and since I've been mulling over it, trying to find flaws in
it.

And find I did.

The system involves three players, the mail client (MC (Mail Client)—an MUA
(Mail User Agent) in SMTP (Simple Mail Transport Protocol) talk), an outgoing
mail server (OMS (Outgoing Mail Server)) and an incoming mail server (IMS
(Incoming Mail Server)—under SMTP, there's a single server, called an MTA,
that handles both). There's one protocol between an MC and an OMS, another
protocol between an MC and an IMS, and two protocols for communication
between an OMS and an IMS. There were also restrictions about what can talk
to what; an OMS can only talk to the designated IMS for a domain (much like
sending email to an MX (Mail eXchange) record). Conversely, an IMS can only
accept connections from a designated OMS from the sender domain (much like
what SPF (Sender Policy Framework) tries to do). An MC needs to be
authenticated to the IMS/OMS (much like you need authentication for POP and
IMAP to receive email, and some sites now require SMTP AUTH for outgoing
email).

Yes, I'm glossing over a lot of details here, but that's the overview. ISP
(Internet Service Provider)s would still filter mail client traffic, much
like they do now. The enforcement of the sending server would pretty much
stop joe jobs [4], and using a notification scheme with the mail spooled on
the sender side would eliminate most, if not all, bounce messages.

So far, it seemed like a great scheme.

Until I realized that spammers would then just register tons of domains (or
cut deals with domain name registrars to use “just expired but we'll keep it
active until we can sell it again” domains) to send spam.

So the only thing I really did was find a way to stop joe jobs; it doesn't
really stop spam all that much, and thus, the flaw.

But one remark from Wlofie [5] (I ran the whole system past him a few days
ago) lept out at me—server signatures (one of the optional bits in one of the
protocols was a digital signature of the sender; Wlofie suggested I include a
digital signature of the server as well). We already have server signatures
for websites. And when I realized that, I realized a solution for spam. And
one that can be adapted with our current email system.

First, revise the SMTP specification. Remove literal network addressing—that
is, the ability to send email to an arbitrary IP (Internet Protocol) address
is no longer allowed. If the host portion of an email address does not have
an MX record, the email can't be delivered. On the recpient side, make the
use of SPF records mandatory, and they must be checked. Also, revise the SPF
specification [6] to remove the “SoftFail” and “Neutral” results.

This last step is the controversial one (as if the others weren't already)—
SMTP servers must have a signed secure certificate and the protocol must be
run over an encrypted channel, similar to how HTTPS (HyperText Transport
Protocol Secure) works. And if either side has an expired or revoked
certificate, the other side must refuse email.

What does this gain us?

Accountability.

Getting spam from a few hundred domains? Find out who sold them the signed
certificate and send the complaint there. After a few hundred (thousand?
Hundred thousand?) complaints and the easiest way handle the situation is to
revoke the signature. Sure, the spammer can try bribing the certificate
authority, but that's exactly what's missing from today's anti-spam
techniques—hitting the spammer where it hurts! And if the spammer tries to
use a self-signed certificate? Who would trust it?

Sure, it's an expense to get a signed certificate, but in today's reality,
you are either an individual using someone else's server for email (Gmail
[7], Yahoo [8], your ISP) or you're a business and can afford it (as part of
your hosting bill, or just outright, but hey, it's a business expense and can
be written off).

[1] gopher://gopher.conman.org/0Phlog:2008/03/31.1
[2] http://cr.yp.to/im2000.html
[3] http://cr.yp.to/djb.html
[4] http://en.wikipedia.org/wiki/Joe_job
[5] http://wlofie.dyndns.org/
[6] http://www.openspf.org/SPF_Record_Syntax
[7] http://www.gmail.com/
[8] http://mail.yahoo.com/

Email author at [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.