ietf-smtp
[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-20 09:07:02

On Tue, 20 May 2008, Ned Freed wrote:

If the client can't use its normal submission server then I don't see
what use a message submission protocol extension would be :-)

Firsst of all, I said nothing about not being able to use. There are
plenty of reasons (speed, policy, separate environment) why I might be
able to reach one server but prefer or be required to actually use
another for submission.

I think this points out something important that could perhaps be made
more explicit in the specification. BATV is designed for the usage model
where you must use the domain's submission servers if you want to send
email claiming to be from that domain,

I see no reason why BATV should be limied in this way.

and all the submission servers must
implement BATV. (It has a lot in common with DKIM in this respect.)

Well, I for one agree that DKIM is limited in this way, but I note in passing
that others in the DKIM group don't appear to be convinced. The notion of 
clients using DKIM directly has come up more than once.

So if
you deploy BATV and you have users with configurations that don't conform
with this model, they'll have to change even if that makes submission
slower or less convenient. If you deploy BATV and your policies say
clients on such-and-such a network must use such-and-such a submission
server, then that submission server had better be configured to correctly
tag messages for all the relevant domains, or you must adjust your
policies.

So I think all the reasons quoted above are, by design, not supported by
BATV. I also don't think there's any point in adapting BATV to remove this
limitation unless the same adaptations work for DKIM or origin-domain
security protocols in general.

I see. So we're intentionally going to cripple BATV so it cannot be used in a
broader set of scenarios it could, with minimal additional work, support?

I'm sorry, but I'm emphatically not on board with that. The focus of this whole
thing is starting to look so narrow and specialized to me, while simultaneouly
requiring such widespread changes to the email infrastructure, that I'm
beginning to think it isn't worth bothering to standardize.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>