On 6/16/2004 5:01 PM, Jim Lyon wrote:
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.
You're confusing lightweight UDP transactions with "web server" -- what
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.