Subject: RE: Alternative to TXT or new RR

From: "Jim Lyon" <[email-masked]>
Date: Wed, 16 Jun 2004 15:01:02 -0700

Regarding publishing via web services, Eric A. Hall says 
> [if a domain doesn't install new software,] they wouldn't be enforcing
a
> reciever-side enforcement system either.  If they don't think that
forgery
> is enough of a problem for them to bother enforcing, then they've
abstained.

You're confusing the *publish* decision with the *check* decision --
it's perfectly reasonable to make them separately.  We want to make it
dirt easy for a domain to publish, because that increases the value of
every one else's checking.  It would be a grave mistake to tell people
they can't publish without running a web server and installing new web
service software.

-- Jim Lyon

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 2004 19:15:46 -0500

> they can't publish without running a web server and installing new web

You're confusing lightweight UDP transactions with "web server" -- what
we've been describing is a simple input-output datagram transaction.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 17 Jun 2004 09:53:59 +0100

> we've been describing is a simple input-output datagram transaction.

I'm sure that what you want to do, might be done with such a service.

On the other hand, I'm not sure that a more heavyweight protocol must be
ruled out. We're already taking the trouble to talk (pretty verbose) SMTP
over TCP here, I'd guess that extra workload involved in something
heavyweight must be <= 100%. Load on my mailservers has been going up that
much every year without me doing anything. I could justify a one-off step
of that magnitude if it did something about the continual increase in
demand. Besides, we've now offloaded the MARID processing costs (although
I'm sure that doesn't save much).

There might also be substantial advantages in (for instance) wed-service,
the protocols are established, the software is largely written already,
cacheing and cache-control is well understood ...
You could deploy such a thing tomorrow. Or if you can't, you need to ask
yourself whether you should be running an MTA.

Something like this answers many questions about extensibility, per-user
policy etc. The policy can be evaluated dynamically, with access to rules
and data unavailable at the receiver.

Whatever you think about that, I believe Eric's general point, that the
publishers policy can be executed at the publisher, deserves an answer. It
needs to be a better answer than "don't make it hard for the publisher". As
it stands, we seem to be promising them something for effectively nothing,
and that does seem too good to be true.