[mail-vet-discuss] Auth-Results issues? #8 secton 5.1

[Arvel Hathcock]

Yes, let's jettison this portion or else we'll get into a situation 
similar to what Microsoft is in with their retasking of the SPF data for 
other purposes.  That has caused a lot of problems for them.

-- 
Arvel

Tony Hansen wrote:
> In section 5.1, it says:
> 
> 5.1.  Legacy MUAs
> 
>    Implementors of this proposal should be aware that many MUAs are
>    unlikely to be retrofit to support the new header and its semantics.
>    In the interests of convenience and quicker adaptation, a delivery
>    MTA might want to consider adding things that are processed by exist-
>    ing MUAs as well as the header defined by this specification.  One
>    suggestion is to provide a Priority: header with a value that
>    reflects the strength of the authentication that was accomplished,
>    e.g. "low" for weak or no authentication, "normal" or "high" for good
>    authentication.
> 
> Wow. I know you're trying to deal with legacy MUAs. But this is placing
> a recommendation onto the MTA to do something wrong to work around a
> possible problem with any MUAs that *may* be connected to that MTA. Yuck.
> 
> If you really need to make this suggestion, which I don't think is
> really necessary, please note that Priority is already a registered
> header with very specific semantics defined for it. This suggestion
> subverts its other uses.
> 
> I think you should just get rid of this section.
> 
> 	Tony Hansen
> 	tony at att.com
> 
> _______________________________________________
> NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html