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
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