mail-vet-discuss
[Top] [All Lists]

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

2006-04-27 20:07:34
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.

        Tony
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html 

<Prev in Thread] Current Thread [Next in Thread>