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.
Alas, this is what happens when you get to the standards party so late: Vast
amounts of infrastructure get built that don't conform to what you find to be
best practices or requirements. Had vacation responses been specified, oh, say,
20 years ago we might have had a chance to get some measure of compliance. But
it wasn't. In fact the text you cite was only added to this draft pretty much
at the last minute, so implementations done to earlier drafts do not meet this
requirement. (In our own case the majority of out cutomers are running
versions of our software that don't do this.)
message not having a return-path also failing to identify the message
causing the response seems ample justification for its loss.
Not if you expect to be able to receive the majority of the vacation replies
that are generated.