[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-20 12:19:42

On May 20, 2008, at 10:42 AM, Tony Finch wrote:

On Tue, 20 May 2008, Douglas Otis wrote:

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.

That doesn't work, because a significant proportion of blowback does not contain any of the original message - for example vacation messages. Also, you lose the advantage of cheap envelope-time rejection.

Although only a SHOULD in RFC3834 section 3.1.6, at least such messages would be non-compliant with RFC5230 section 5.8 is a MUST. A message not having a return-path also failing to identify the message causing the response seems ample justification for its loss.

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

That would unnecessarily increase the junk mail load on the message store and MUA<->MS connection.

This abuse is because the path normally lacks protection. Widely adopting a simple authentication scheme should have the effect of reducing this burden as well as the authentication process.

Reliance upon the MUA recognizing its own messages

Lots of people use more than one MUA - for us it's 15% - 20%.

A BATV like standard for Message-IDs that depends upon a user provided pass-phrase would be fairly easy to manage. When the user desires protection, they would simply use a MID-TV enabled MUA and enter their pass-phrase.