On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote: > On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy > <[email protected]> wrote: > >>> WTF is the point of inserting an A-R header if you are not willing >>> to take responsibility for what you have done by signing it? >>> >>> And why should anyone else believe your A-R if you have omitted >>> that elementary step? >> >> Because, if you've followed the RFC defining it, the border MTA >> has removed any others present that could possibly be >> misinterpreted by internal agents. > > Yes, but that is the MTA at MY border. I would expect the assessor > at MY border to have indicated some degree of suspicion if the A_R > header it was about to remove (before substituting its own) was not > included in the signature that accompanied it. >> >> You're not required to sign them, but it's not a bad idea. > > Then why are people on this list not trying to enocourage that good > practice? Indeed, why are they so vociferously trying to DIScourage > it?
Before A-R headers can be trusted, A-R headers MUST be removed by incoming border MTAs. See section 1.6 of RFC 5451. Border MTAs may exchange messages with internal servers that might process filters where internal routes are influenced by message content. Whenever removing A-R headers is done on a conditional basis, this creates gaps in security, especially when trust is placed upon A-R headers added by a subsequent filtering process. Only removing A-R headers at the border exactly matching those added by the receiving domain invites trouble. There are many three-step tricks that thwart matching techniques, where these headers might appear differently at some later stage. The safest approach for handling A-R headers would be to remove _all_ of them as they arrive. After filtering messages, incoming MTA can decide what they wish to do with the message. When a filtering process decides to reject a message, this should be done prior to adding A-R headers, perhaps even after removing existing A-R headers. A safe process must ensure there is no overlap between where incoming A-R headers are removed, and where the incoming receivers add A-R headers to messages. The issue of A-R headers being trusted only when signed by DKIM runs counter to their intended use. When it is concluded that MUAs should independently check DKIM signatures that include A-R headers, this suggests A-R headers are not very trustworthy, which might be the case. Whatever leak that allows a bad actor's A-R header to appear could also find itself inadvertently signed by the incoming domain. Just check originating DKIM signatures, and ignore A-R headers would be the safest solution. Use of A-R headers allow providers a means to visibly modify messages without the recipient being aware that the visible content had been added by the provider. In general, this seems like a bad idea with respect to DKIM. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
