On Monday 03 December 2007 13:00, Murray S. Kucherawy wrote:
This came up both at the last IETF and at this one, so I thought it
worth opening up here once before I submit the draft to the area director.
Should the normative text in the draft specify that this header SHOULD
be signed?
The point comes from someone who operates in an environment in which he
doesn't necessarily want to trust that the border MTAs are properly
removing forged A-R headers. This would mean there needs to be a shared
or distributed secret between the border MTAs where the header is added
and the clients where the header will be used. It also means I'd either
have to reference a header signing/verifying mechanism or define one.
Some of the risk of this is mitigated by the AUTHRES ESMTP extension
draft, but the time to implement there is going to be longer than the
support for this header.
The hallway track at the last IETF and since was that the current
draft's Section 8.1 (especially the last paragraph) provide sufficient
discussion of this issue. I might change "posted" to "posted or shared".
What are the list's opinions?
I think that it's a big can of worms to open.
How a network internally handles this is not something that I think is really
easily standardized. Sign and trust only signed headers (insert favorite
signing tech here) is one way. Make sure externally applied headers are
stripped at the border is another. I know spamassassin looks at trusted
relays and where recieved headers fall to know what to trust.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html