[mail-vet-discuss] SHOULD the header be signed?
mike at mtcc.com
Mon Dec 3 11:04:28 PST 2007
Scott Kitterman wrote:
> 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.
we strip auth-res at the border, and I don't think there should be anybody
telling us that that simple security measure should be illegal, immoral or
More information about the mail-vet-discuss