Re: Spamming...

>I wanted to interject with a question, which is if any of you have looked at 
>SES which I have been developing with a few other "SPF alumni".  I would 
>love to give up on the existing e-mail architecture but it appears that we 
>are married to it for quite some time to come although I have long thought 
>my time would be better spent aiding IM2000. 
>
>If you have the time, give SES a look at: http://ses.codeshare.ca 

I've given it only a cursory look; apologies if I'm off-track below.

First, I suggest a change in terminology, in your docs, to distinguish
the *actual* sender of a message from the *supposed* sender.

Otherwise it's too easy for a reader to not realize that some
handwaving might have just happened, or that opportunities for forgery
exist, or whatever.

Perhaps "injector" or "submitter" could be used to refer to whichever
(SMTP or whatever) client initially "injects" the message into the
Internal mail system as a whole.  (From the point of view of an SMTP
server handling an incoming message, the injector/submitter would be
the SMTP client on the other and; from the point of view of *that*
client, it either "knows" it is the injector/submitter, or has its own
idea of who that is.)

Whereas, the "sender" is still whoever *supposedly* sent the message,
as in [email protected] (for this message) or [email protected],
whichever my email system happens to use for the enveloper sender.

Does that make sense?

>It is designed as a solution to the SPF forwarding problem, only we soon 
>quickly discovered that SES could easily replace SPF and eliminate all of 
>the DNS nastiness associated with SPF. 

Yes and no.  It appears to only eliminate such nastiness when the
injector/submitter chooses to tell the recipient to use some
*different* mechanism.

That strikes me as giving the injector/submitter *way* too much
control over how a recipient is supposed to validate whether a message
actually came from a sender's domain.

You could change SES so that the DNS for options "3" and "M" can, in
turn, specify a UDP query to a particular host.  That way, the
"sending" host can still require UDP queries even when the
injector/submitter ask not to use them.

(I wonder if that almost completely boils down to something akin to
djb's proposal to use MX priorities as a way to encode mail-exchange
protocols?  I don't have the URL handy, but if everyone's going to be
looking up MX'es or similar anyway, why not just design a way to use
the priorities to designate validation methods?  That way, the
injector/submitter wouldn't be given much, if any, control over the
way a recipient and a sender decide the validation method(s) to be
used.)

(For that matter, maybe DNS could be used to store bytecode of some
sort, which, when "run" by a recipient, validates an incoming message
based on envelope sender, and is able to, itself, use DNS queries,
send and receive UDP packets, or do some basic TCP stuff, as it sees
fit?  As long as a recipient is going to want to do *any* DNS lookup
keyed on a sender's domain, why not have the result of the lookup be
maximally useful, since it can be cached on a nearby nameserver,
assuming the bytecode doesn't necessarily expose, to spammers, ways to
produce "valid" addresses/messages?)

>I also wanted to respond to the "spammers just buy lots of domains" 
>argument.  Whilst in a black and white argument, you are right, people can 
>just buy more, if you expand the argument to encompass the overwhelming 
>adoption of email as a communicative medium by the entire world, a "globally 
>deployed" SPF could have strong value. 

I'm not sure how.  As all the rants, pro and con, about SPF have
suggested, either we're going to have a world in which every "known"
email address is globally determinable to send email from only a
handful of (tightly controlled) origination points (IP addresses), in
which case SPF is helpful, or we're not, in which case deploying SPF
is a modestly expensive version of playing whack-a-mole.

>I'm looking to contribute to whatever helps combat smtp forgery now, but 
>also provides a potential transitional move over to IM2000. 

The UDP validation methods of SES (6.1) are a bit like putting a toe
in the water vis-a-vis IM2000; a recipient doesn't get the whole
*message* from a (thingy, such as a message store, acting on behalf of
an actual) sender, just an indication of whether the source address
makes sense, right?

>I'm also not looking to start a discussion about SES specifically, but more 
>so I wanted to see what was thought of this technique to prevent forgeries 
>and if it has any relevence to IM2000. 

IM2000 strikes me as not needing SES at all, except insofar as a
recipient might want to be able to make a distinct request for
validation that a message exists on a message store, without
necessarily requesting the message itself.  (Maybe djb's or somebody
else's proposal already provides that?  I haven't reviewed the docs
lately.)


In essence, *all* of these technologies -- IM2000, SPF, SES --
compare, favorably or unfavorably (depending on your point of view),
to SMTP, in that they require *more* infrastructure, acting on behalf
of the *sender* of an email, to be in place and correctly operating
for that email to be accepted by a recipient.

My biggest worry about that, *conceptually*, is that the increased
infrastructure makes a very big target for spammers to hit, in order
to convince recipients that they are unable to receive *legit* email
and that they should therefore (temporarily) disable reliance on that
*sender-side* infrastructure.

This page of yours hits on some of these points quite well, IMO:

  http://ses.codeshare.ca/ses_vs_dk+iim.html

Excerpting:

  - preferred UDP validation server has lower attack profile and is
    more secure than DNS

  - UDP validation is one packet request and one packet response - no
    DDoS amplification

The UDP approach is definitely the soundest, "from-the-horse's-mouth"
means to validate a sender's address, AFAICT.

But isn't DNS going to be used to look up the host to which a
recipient will send a UDP packet in the first place?

If so, doesn't that make DNS (still) a tempting target for anyone
wishing to convince recipients (or their sysadmins) to stop rejecting
all email involving problematic DNS lookups when validating?

(These are pertinent questions for IM2000, not just SES!)

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>