![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> >But I'm disturbed that Exchange is using the Precedence: line as its > >selector mechanism. I'm hardly an email expert, but a quick grep > >through the RFCs turned up exactly one mention of the Precedence: > >header line. That reference is in 2076, which describes it as > >"Non-standard, controversial, discouraged". No RFC definition is cited. > >It would be nice if such an important feature relied only on > >standardized headers. > > In this case, there are > non-standard headers in common use that give valuable heuristics to > programs, and no standard ones that give the same information. Many > companies, apparently including Microsoft, use that non-standard > information. Extension header fields are explicitly permitted by the standards, and (for better or worse) other vacation programs also recognize the Precedence field. So it's unfair to single out Microsoft for using it also. But although the heuristic is widely used, it has never been considered sufficient. Keith p.s. there are a lot of problems with Precedence, not the least of which are that it is used for at least 5 different things by different mail packages: for influencing queueing priority, deciding whether to return content in nondelivery reports, deciding whether to return a vacation message, indication of message importance, and as a loop prevention sentinel by mailing list software. There are probably others. Most of these uses do not conflict with one another, but occasionally they do. It's not exactly a robust mechanism.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.