> The ticket scheme involves creating a ticket service that would issue
> tickets, which can then be submitted with an email message.
This is a flavor of epostage. Like all forms of epostage, it doesn't
scale to a mail system large enough to be interesting.
Indeed, any scheme that requires a callback per message has severe scaling
problems.
Let's make sure there is a clear distinction between what is being labeled
"callback", versus the DNS query needed for some of the proposed authentication
schemes:
One category of scaling problem is on large senders who'd have
to maintain rapidly updated databases of valid or invalid messages, of a
size and performance which I've concluded is far beyond the state of the
art. (Lots of queries are a problem we've solved for DNS, but lots of
updates kill you.)
Whereas the auth schemes are not per-message and don't even have to be
per-user, so the data being queried are relatively stable. Updates do not have
to be all that frequent.
The other category of scaling problem is for us poor
suckers whose addresses are often forged. Today I'm having enough trouble
dealing with bounce storms, and I do not want to have to solve other
people's problems by dealing with their callback storms as well.
I'm inclined to guess that "auth storms" are plausible and maybe even likely.
So I'd guess the distinction here is that high DNS query volume is a
well-understood issue. The added traffic might be an issue, but not a
"problem".
For a whole lot of discussion on the merits and shortcomings of per
message callbacks, see the mail archive of the SES group that's trying to
do remotely verifiable signatures in 2821 bounce addresses.
I'm thinking that an RFC discussing the technical, administrative, and
operational tradeoffs would be useful. I'd be glad to participate in creating
it, but am not quite feeling up to taking the lead.
Obviously, this could be a massive tome, but I'm not suggesting that. One of
the nice things about doing it as an RFC is that it need not be a verbose
tutorial, as much as a more terse checklist (or somesuch.) We can require a
higher level of reader technical competence than most other publication forms
might require.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net