[mail-vet-discuss] Auth-Results issues? #8 secton 5.1
arvel.hathcock at altn.com
Tue Mar 28 12:01:26 PST 2006
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.
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
> 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
More information about the mail-vet-discuss