[mail-vet-discuss] Re: Auth-Results issues? #7 section 4.1

Tony Hansen tony at att.com
Thu Apr 27 20:06:04 PDT 2006

Murray S. Kucherawy wrote:
> Getting back to this again...
> Tony Hansen wrote:
>> In section 4.1, it says:
>>            Naturally then, users would not activate such a
>>    feature unless they are certain the header will be added by the
>>    receiving MTA that accepts the mail which is ultimately read by the
>>    MUA, and instances of the header added by foreign MTAs will be
>>    removed before delivery.
>> Where does it say that foreign A-Rs are to be removed? I don't see that
>> anywhere in the spec.
> I didn't want to mandate such a thing, again for reasons along the lines
> of speed of adoption.  Do you think that should be mandatory?

I could see a mailing list server doing verification and putting in an
A-R header, then signing the message before sending it out again, and
including the A-R header within the signature's list of headers. If the
foreign A-R header were removed, the mailing list server's signature
would not verify.

So I'm not sure that foreign A-R headers should be removed.

However, purported local A-R headers *must* be removed. That's a
different story.

I don't think requiring / not requiring the removal would make any
difference as to the speed of adoption. The MTA will have to do various
things to support A-R headers; including removal in that list of things
to do should not make a difference as to how fast it's adopted.

>> Later in section 4.1, it says:
>>    An MTA adding a header MUST add the header at the top of the message
>>    so that there is generally some indication upon delivery of where in
>>    the chain of handling MTAs the sender authentcation was done.
>> This actually places the A-R in the same category as a trace header, as
>> defined in [MAIL]. This should be mentioned.
> If I get my way on ietf-dkim, there will be a way to specifically
> associate certain results with specific signatures.  In that case I
> don't care where the A-R header goes, and this doesn't need to be
> labeled as a trace header.

Either way is fine with me.


More information about the mail-vet-discuss mailing list