> 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
