[mail-vet-discuss] results should be method specific

[Michael Thomas]

Murray S. Kucherawy wrote:
> I suppose it's par for the course that all these substantial changes 
> are coming in only as I'm trying to hand this stuff off to the area 
> director and not long ago... ;-)

Murray, I think you should keep in mind the high likelihood that late
feedback is due to a) the narrow set of people here and b) the even
narrower set of people who've really implemented/digested this. The
object here is to have a solid spec.
>
> Michael Thomas wrote:
>> The current draft breaks out the meaning of the results into a method
>> specific section. This is an improvement over the previous draft which
>> didn't discuss them at all, but shoe-horning the global set of results
>> into method specific results seems rather contrived and arbitrary.
>>   
> I don't think it's either.  Having a fixed set of results makes 
> writing and extending parsers easy.  It's easier in my experience to 
> have the parser still return one of a fixed set (or a subset of a 
> fixed set) of results and then have the thing using the parser decide 
> what to do with those values.  Parsers don't care about meaning, only 
> syntax.  If a new method comes along and uses a result keyword that's 
> not in the list of ones we're supporting, a module using the parser 
> has to wait for the parser to get updated.  When those two modules 
> aren't the same, it can get annoying to extend the system as a whole.

Well, I've implemented this and it didn't strike me as particularly onerous.
And you didn't address my main concern that the current results do not
allow for extension. Where does SSP NXDOMAIN get mapped into the
current authentication results? What if we decide we need another result?
I really don't see the point of being parsimonious here; they're just 
labels,
and the probability for human confusion due to weird overlays seems really
high.
>
>
>>     [mat: i've removed the "acceptable" parts... i'm not sure what 
>> that's
>>           bringing to the table... why should auth res go into the 
>> filter's
>>           domain? same goes for other methods, I suspect]
>>   
> Authentication-Results: lives quite squarely in the filter's domain.  
> The point of using it is to do complete evaluation of the 
> authentication method so that the MUA doesn't have to.  If the MUA has 
> to re-analyze signatures to determine if local policy is satisfied, we 
> haven't accomplished very much.

I don't think I agree: Authres is *input* into a filter so that the 
authenticator
isn't saddled with having to evaluate "acceptability" locally.  We 
should limit
Authres to *only* be what an authenticator is able to determine, and not
saddle it with additional requirements like determining what "acceptable"
is.

       Mike