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. : )
-Doug
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: BATV breaks rfc2821bis?, (continued)
- Re: BATV breaks rfc2821bis?, Tony Hansen
- Re: BATV pseudo-Last Call, ned+ietf-smtp
- BATV smtp extension, Dave Crocker
- Re: BATV pseudo-Last Call, Tony Finch
- Re: BATV pseudo-Last Call, ned+ietf-smtp
- Re: BATV pseudo-Last Call, Tony Finch
- Re: BATV pseudo-Last Call, ned+ietf-smtp
- Re: BATV pseudo-Last Call, Tony Finch
- Re: BATV pseudo-Last Call, Carl S. Gutekunst
- Re: BATV pseudo-Last Call, ned+ietf-smtp
- Re: BATV pseudo-Last Call,
Douglas Otis <=
- Re: BATV pseudo-Last Call, Tony Finch
- Re: BATV pseudo-Last Call, Douglas Otis
- Re: BATV pseudo-Last Call, ned+ietf-smtp
- Re: BATV pseudo-Last Call, ned+ietf-smtp
- Re: remote signing, was BATV pseudo-Last Call, John Levine
- Re: remote signing, was BATV pseudo-Last Call, ned+ietf-smtp
- Re: remote signing, was BATV pseudo-Last Call, John R Levine
- Re: remote signing, Frank Ellermann
- Re: remote signing, was BATV pseudo-Last Call, ned+ietf-smtp
- Re: remote signing, was BATV pseudo-Last Call, John R Levine
|
|
|