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(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html