Tony Hansen wrote:
In section 5.1, it says:
5.1. Legacy MUAs
[...]
>
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.
This was a specific (and perhaps bad) example of what I think is actually a good
idea, namely using existing means to communicate results to MUAs that haven't
yet (and may never) add support for the A-R header. How about including
something more generic which pushes that idea but makes no specific suggestions?
I chose "Priority" in this case because there are examples of MUAs that can
change the colour of a message in its mailbox summary page. Certainly though I
didn't want to subvert its other uses.
For example, there's some header "hack" you can use to make a a line appear in
bright red with a flag next to it in Outlook, though I forget exactly what it
is. Someone implementing a verifier who knows he'll only be protecting Outlook
boxes might want to exploit that to draw attention to likely forgeries, until
Outlook actually supports A-R.
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html