[ietf-clear] No callbacks, please, was Re. CLEAR Charter

> From: John Levine
> Sent: Sunday, October 03, 2004 10:01 PM
>
>
> > If BATV uses a public scheme, presumably there is at least a DNS
> > query per message, to get the key.
> >
> > Although this query would not go directly back to the 'caller'
> > and, therefore, is not strictly a call-back scheme, it does
> > impose a per-message, receive-time, cross-net exchange.
> The public schemes I've seen proposed use per-domain keys, not per
> mailbox keys.  If a random Russion site gets a 10,000 spams with
> forged abuse.net addresses, which they do all the time, I'd much
> rather they do one lookup for a per-domain key and cache it than
> 10,000 lookups for 10,000 fake return addresses.
The SES mechanism is agnostic to the granularity of the keys.  With DNS
callback, you can choose between domain or user keys.  With UDP callback you
can choose between site (as in multiple domains), domain or user keys.  With
SMTP callback (ugh), you can choose between domain or user keys.  I mention
the latter, although rather distasteful, for a reason.  Several large
providers today, including Verizon, routinely do SMTP callbacks.  Even BATV
or SES signatures that were designed to just prevent forged bounces and
_not_ provide sender validation can result in SMTP callbacks.  Unless you
are willing to ban all services that do this or forgo DSN's, you can't
really prevent it.

As a partial answer to your other issue, you have to look at the result of
having a validation schemes in place that allows rejecting envelope
forgeries.  After some experience with forging signed return-paths, the
spammer discovers (eventually) that the delivery rate for signed forgeries
is lower than the rate for unsigned forgeries.  What would you expect to
happen?  Since spammers ultimately do what they do to make money, which
depends on getting their payload delivered at least once in a while, I
expect that spammers will do a combination of two things:  a) keep sending
unsigned forgeries to take advantage of sites that do not use authentication
and b) start sending properly authenticated mail from throw-away domains.

The latter case is the one that is more interesting to this group.  Because
that is likely to happen with any authentication means we put in place, the
use of authentication will not avoid the need for content filtering
post-acceptance.  We can hope for faster and more accurate blacklisting, but
ultimately, we will still have to run content filters on anything that
passes whatever authentication hurdles we put in place.  Therefore, the
transaction cost of authentication is very important, as it is a load _in
addition_ to content filtering, rather than instead of it.

> > In terms of transaction costs, how would this differ from what
> > SES is proposing?
> Per domain rather than per mailbox or per-message.  I think that's
> significant.  It's also DNS which is known to perform adequately for
> per-domain data, rather than some yet-to-be invented per-mailbox
> protocol which, according to recent messages, is simultaneously UDP to
> be very lightweight, and TCP to be more reliable.
There are a few issues here, so I'll try to address each of them.  With
regard to DNS vs. custom UDP service, the protocol supports various callback
methods so the sender can provide validation service through whatever
channel they prefer.  We originally came up with the UDP callback validation
service because a) we didn't want to require modifications to a DNS server
to participate, b) some people felt that the additional load to DNS was
unwanted after our experience with SPF and c) some people felt that the MTA
was the appropriate place for the validation load.  Though everything is
debatable, these arguments have at least some merit.  Tony Finch then
pointed out that another alternative was to set up a "stunt" DNS server for
a specifically delegated subdomain like "_ses.example.com" that only did
signature validations.  This would leverage everything we already know about
DNS while separating the validation load from the main DNS for a domain.
This approach also has obvious merit.  Finally, Roger Moser made some BIND
modifications and Stuart Gathman modified a Python-based DNS server to
demonstrate that a domain's main DNS server could process validation
requests without major changes.  This approach has merit, as well.

> From the standpoint of a transaction, each of these is one UDP packet
request and one UDP packet response, and all are cacheable.  TCP doesn't
really belong in this discussion as it is not necessary for validating
ordinary email with any of the schemes on the table.

The question at hand, IMHO, is how does a per-message callback validation
scheme compare to other validation methods.  Even with something as light as
CSV, a spammer that HELO's with your domain name will generate a DNS request
to your nameserver if it is not in the recipient's cache.  I think the
answer is not as simple as any of us have been implying.  Let's try and
consider the total transaction cost of various approaches and who bears
those costs.  As you point out below, putting all the validation load on the
recipient has it's weaknesses, they are just different ones.

> R's,
> John
>
> PS: If bad guys put fake DK signatures on their spam with random
> fake selectors, we're back to a per-message DDOS.  Hmmn.
--

Seth Goodman