[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-20 12:44:11

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.

You still have to have agreement on the format plus a way to share the secret.
Not everyone uses the same MUA all the time (in fact with ISPs providing
webmail, IMAP4 and POP3 it has become quite common not to) and sharing MUA
configuration is for all intents and purposes an unsolved problem (akthough not
for lack of trying, i.e., ACAP).

An alternative way to handle this is to not bother with a secret but instead
keep track of the message-ids of every message you've sent in the past, say,
month. This is actually marginally easier in most cases to do - think shared
"Sent" folder, although it still requires upgrading all yourr MUAs.

If MUAs universally implemented a
standardized hash authentication mechanism within the Message-ID,
there would less motivation for attempting to distribute spam via

OK, I can see how an MUA might be able, in the case of messages with its own
address as the originator, perform this sort of screening. But we're talking
about DSN backscatter here. How is this supposed to work? While the standard
DSN formats are structured in a way that allows extraction of the original
message's message-id, countless other notification formats are used in
practice, each with their own wierd and wonderful characteristics.  Digging
through the message in hopes of finding a matching message-id seems very
dubious to me - if for no other reason that it may not even be present.

Again, if I were going to implement this at the MUA level, I would instead
correlate the message-id with sent mail. Done right that would also make
it possible to link the report with the original message in the UI.

Moving this authentication mechanism into the MUA would
also remove the authentication burden from SMTP.

Which IMO is the wrong direction to push it. For most ISPs this is tantamount
to giving up on the problem. Users can and will use all sorts of different
MUAs, including ancient ones. And the history of adoption of these sorts of
features in MUAs has been nothing short of dismal - look at the extent to which
proper localation of DSNs is done, or the correlations I mentioned previously,
or any number of other things.

Moreover, as email service has gotten simultaneously more centralized and more
ubiquitous, the number of MTAs and stores has dropped while the number of MUAs
in use has exploded. (Webmail has acted to reverse this trend in some cases,
but by no means all.) An MUA upgrade may be easier than an MTA upgrade, but
that fails to consider how many of each are out there.

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. : )

Sorry, I just don't see that happening. The numbers are against it and user
behavior is against it. But even if it were true, it isn't the problem at hand.


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