[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-20 10:32:26

On May 20, 2008, at 8:41 AM, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
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.

Agreed. MUAs _can_ implement BATV through exchanges of outbound server _secrets_. However, BATV problems and the need for outbound server co-ordination disappear by implementing the same BATV hash authentication mechanism within the Message-ID, rather than within the Return-Path as BATV does. If MUAs universally implemented a standardized hash authentication mechanism within the Message-ID, there would less motivation for attempting to distribute spam via backscatter. Moving this authentication mechanism into the MUA would also remove the authentication burden from SMTP. Reliance upon the MUA recognizing its own messages should also substantially increase the integrity of SMTP delivery as this should dramatically reduce the noise to signal ratio. : )