A reader took me to task for suggesting, in this week's column, that we need to do a better job of spelling out the user-interface implications of Internet standards. Robb Beal agreed with me, though, and today I found another example of the kind of guidance that his functional annotations provide.
Last July, I mentioned RMX (Reverse Mail eXchange) in an article on anti-spam technologies. Since then there's been a lot of activity on this front. Now I'm looking into SPF (proposed by pobox.com), Caller ID for Email, (proposed by Microsoft) and Domain Keys (proposed by Yahoo, not yet published).
The various strategies for weaving authorization and email policy into the Domain Name System are quite fascinating. But I was also struck by this passage I found in the Caller ID spec:
Common historical practice in mail reading software regarding the mail originator and resent headers has been to present only the contents of the From: header to the users; the other related headers (Sender:, Resent-From:, Resent-Sender:) have not been shown. This behavior SHOULD change. Messages with combinations of identities in the originator headers SHOULD be rendered differently than messages in which the identities are the same. Specifically, it is RECOMMENDED that if the purported responsible addresses of a message is not the same as the address that would be rendered as the From: address that both these addresses be exhibited to the user. For example, the message in the example -3.2.3 might be presented by e-mail client software as being
From bob@forwarderexample.com on behalf of adam@example.com
or
From adam@example.com via bob@forwarderexample.com
instead of the historical
From adam@example.com
Exactly! Nobody should care what's jammed into the DNS TXT records used to authorize an SMTP sender, but everybody should care about dodgy identity trails. While acknowledging that such matters are "properly a role of mail filtering and e-mail client software," the spec nonetheless ventures "some suggestions regarding how that might work." Applause.
Former URL: http://weblog.infoworld.com/udell/2004/04/02.html#a962