Subject: Re: [ietf-dkim] chained signatures, was l= summary

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 01 Jun 2009 11:14:59 +0100

On Fri, 29 May 2009 22:22:11 +0100, John R. Levine <[email-masked]> wrote:

> I would really like to remove l= from DKIM to make it clear that it is  
> not
> a good idea to even try to guess the history of a message based on
> signatures that don't verify and cover the whole messag.

Speak for yourself.

I see a message with a broken, but otherwise plausible, signature, and  
that seems on the face of it a genuine message that I might very well care  
about, then I might well start to play around to see if some small munge  
of the message might have caused the broken signature. I have often done  
this in the case of seemingly broken Usenet control messages.

Just because a feature is likely to be used only rarely, and then only by  
people who have a good understanding of the protocol, is no reason to  
remove that possibility entirely from those people. That is just called  
"dumbing down", and "dumbing down" is a dumb idea.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer \(5304\)" <[email-masked]>
Date: Mon, 1 Jun 2009 09:35:22 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John R. Levine
> Sent: Friday, May 29, 2009 5:22 PM
> To: Barry Leiba
> Cc: DKIM List
> Subject: Re: [ietf-dkim] chained signatures, was l= summary
> 
> >> DKIM is too complicated as it is, and it strikes me as an extremely
> poor
> >> idea to add yet more cruft to work around perverse situations that
are
> as
> >> yet (and probably always) entirely hypothetical.
> >
> > I don't understand what "cruft" you think I'm talking about.
> 
> Telling people that it is reasonable to add a chain of A-R headers to
> messages with broken signatures, and expecting recipients to apply
some
> ill defined algorithm to decide how much they believe each level of
> alleged signature.
> 
not
> R's,
> John

+1

---

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Jun 2009 10:49:28 -0400

On Fri, May 29, 2009 at 5:22 PM, John R. Levine <[email-masked]> wrote:
> messages with broken signatures, and expecting recipients to apply some ill
> defined algorithm to decide how much they believe each level of alleged
> signature.

What part of my message makes you think that's what I'm suggesting?
Surely not the part where I say, "Chaining isn't the point.".  And it
certainly can't be the part where I say, "remove all previous sigs AND
all previous A-R".

I think it's a terrible idea to (1) leave signatures in a message
after you break them, (2) add A-R without removing any already there,
or (3) add A-R without a signature covering it.

Or are you just trolling?

> I would really like to remove l= from DKIM to make it clear that it is not a
> good idea to even try to guess the history of a message based on signatures
> that don't verify and cover the whole messag.

Yes, that seems to be the consensus, and I agree with that.

Barry, as participant

---

From: Paul Russell <[email-masked]>
Date: Mon, 01 Jun 2009 12:12:45 -0400

> Yes, that seems to be the consensus, and I agree with that.

It appears that you either missed or chose to ignore recent messages from
individuals who do not agree that l= should be removed.  I have been reading
the arguments on both sides of this issue and lean towards leaving it in the
spec.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 01 Jun 2009 10:01:20 -0700

why?

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 02 Jun 2009 11:29:00 +0100

> or (3) add A-R without a signature covering it.

And I, on the contrary, believe it is a terrible idea EVER to remove a  
signature or an A-R header. There is never anything to be gained by  
throwing away information that someone more perceptive than yourself might  
find useful.

---

From: [email-masked] (Wietse Venema)
Date: Tue, 2 Jun 2009 08:05:27 -0400 (EDT)

> throwing away information that someone more perceptive than yourself might  

Except, of course, when the bad guys use this to have their bogus
signatures and their bogus A-R headers "laundered" by naive signers.

	Wietse

---

From: Paul Russell <[email-masked]>
Date: Tue, 02 Jun 2009 09:17:19 -0400

> signatures and their bogus A-R headers "laundered" by naive signers.

I agree.  DKIM is supposed to make it easier for recipients to recognize the
few legitimate messages in the flood of unwanted, if not intentionally
malicious, messages that are presented to our servers.  I see little, if any,
value in leaving broken signatures and the matching A-R headers in a message,
and a great deal of potential for problems resulting from the flawed assumption
that the signature must have been valid at some point in time, or it and its
matching A-R headers would not be present.

Just because you're paranoid doesn't mean they aren't out to get you.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 02 Jun 2009 06:24:43 -0700

>>> or (3) add A-R without a signature covering it.

A signature covering it? That's quite a new requirement for a-r and
one that nobody that I'm aware is following.

> signatures and their bogus A-R headers "laundered" by naive signers.

People who use bogus information to make go/no-go decisions quite
literally get what they deserve. Why single out DKIM?

In any case, removing signatures seriously sucks from a forensics
standpoint. The DKIM rule is that if they're broken, they're equivalent
to not existing. Leaving signatures in hurts *nothing*, and
provides a lot of feedback to the original sender if needed to
diagnose why signatures failed.

This shit happens in the real world. Often.

		Mike

---

From: John Levine <[email-masked]>
Date: 2 Jun 2009 20:40:28 -0000

>and a great deal of potential for problems resulting from the flawed
>assumption that the signature must have been valid at some point in
>time, or it and its matching A-R headers would not be present.

That strikes me as more of an educational problem than a technical one.

After years of filtering based on trying to block the bad stuff, it's easy
to assume that any filtering technology has to be extremely complicated
to use, since bad guys change all the time, and good guys occasionally
change, too.

But not we're trying to recognize and accept the good stuff, so DKIM usage
boils down to two easy rules:

1) Put valid signatures on all your mail.

2) Don't send (and sign) mail that will annoy the recipients.

It is in the interest of legitimate senders to do both of these, which
means that everyone should want to sign their mail.  So the solution
to broken signatures is not for receivers to do backflips trying to
guess what a broken signature might mean, it's to tell senders to be
sure there's a valid signature if they want their mail recognized.

R's,
John

---

From: Jon Callas <[email-masked]>
Date: Tue, 2 Jun 2009 14:49:29 -0700

On Jun 2, 2009, at 5:05 AM, Wietse Venema wrote:

> Charles Lindsey:
>> On Mon, 01 Jun 2009 15:49:28 +0100, Barry Leiba <[email-masked] 
>> >
>> wrote:
>>

I agree with Wietse on the basic principle here.

If one is providing an email service where one is *processing* a  
message, then removing old signatures and resigning is the best thing.

For example, a mailing list server processes the message in that it  
takes incoming messages and then resends them in some similar-to- 
identical form. I believe it is ideal in this case to remove the old  
signature and resign.

I as the ultimate receiver, filter and process those messages based  
upon the mailing list, not based upon the original sender. I'm on a  
number of lists with many of you and I want them organized by mailing  
list, not sending person. DKIM should be similar.

However, if someone implemented a mailing list server that did its  
best to be invisible, I wouldn't say it was doing the wrong thing,  
either.

The bad case is where I have a message that is signed by both parties  
and one signature is broken. That puts the message into some weird  
state. It's less weird when the person's signature is broken and the  
list signature isn't. The broken signature now just creates confusion.  
The other case is even more confusing, but yet the message is still  
cryptographically intact.

That's why if I were the author of the list server, I'd strip and  
resign (or resend while preserving the signature).

	Jon

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 03 Jun 2009 10:49:24 +0100

> one that nobody that I'm aware is following.

It is such a blatantly obvious necessity that I am surprised it is  
occasioning such surprise.

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?

> diagnose why signatures failed.
+1. That is exact;y the point I was trying to make.

---

From: John Levine <[email-masked]>
Date: 3 Jun 2009 13:58:06 -0000

>And why should anyone else believe your A-R if you have omitted that  

The most common use of A-R will likely involve a secure channel
between the place where it's applied and the place where it's
interpreted, e.g., it's applied at a border MTA and it's interpreted
in a downstream MTA or MUA within the same network.  In that case, you
don't need a signature.

If you imagine that there are strangers elsewhere in the world who
would be impressed by your opinion of a message you were forwarding,
you might want to sign it, but as I've noted before, if you're
forwarding it and mutating it enough that recipients wouldn't use an
incoming signature (i.e., you're a mailing list) you'd best take care
to send and sign only mail that recipients are likely to want.

I'm with Mike here -- signing A-R isn't important, because chained
signatures won't be useful in practice.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Jun 2009 09:13:02 -0700

> 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?
> 

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.

You're not required to sign them, but it's not a bad idea.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 3 Jun 2009 11:11:54 -0700

On Jun 3, 2009, at 9:13 AM, Murray S. Kucherawy 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.
>

ISPs seem unlikely sign incoming messages because they include their A- 
R headers.  A-R headers are expected to be removed at border MTAs, so  
when forwarding, signatures intended to protect A-R headers will  
normally become invalid.  One would not be able to tell whether these  
signature were being spoofed by the ISPs outbound server, or whether  
the signature represents a failed attempt to protect A-R headers.    
Should DKIM signatures not include missing A-R headers?

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 04 Jun 2009 13:12:16 +0100

> in a downstream MTA or MUA within the same network.  In that case, you

Agreed, but that is not the situation of concern.
> to send and sign only mail that recipients are likely to want.

A competent mailing list admin would reject all messages from dubious  
sources. But it would be foolish to assume that all such admins are as  
competent as we would wish. So the mere fact that they (re)sign messages  
does not prove their origin, except insofar as you are prepared to have  
confidence in their competence.

If they try to bolster your confidence in them by offering an A-R header  
to show their diligence in eliminating dubious messages, then that is well  
and good, but if they are unwilling to put their signature where their  
mouth is, then why should I be impressed? I don't see why you would choose  
to regard me, as a member of your mailing list, as some "stranger  
elsewhere in the world".

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 04 Jun 2009 13:20:01 +0100

> removed any others present that could possibly be misinterpreted by  

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?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 04 Jun 2009 06:41:53 -0700

> signature that accompanied it.

The cases, IMO, of when a ar-header is useful from a foreign domain
are vanishingly small, so removing it is just a matter of good hygiene.
If capturing its essence is important, I suppose that we'll first see
border mta software using it for something. To my knowledge, nobody is.
(foreign a-r that is).

> practice? Indeed, why are they so vociferously trying to DIScourage it?

Because it's a marginal case. At Cisco, the only thing that I'm aware*
that we were using a-r for was generating gross statistics, where what
even a trusted foreign verifier -- which we had none -- were useless for
what we were using it for. Maybe we were outliers, but I doubt it.

[*] yes a couple of us were using ar to color messages in our muas, but
we were a pretty self-selected, self-interested population

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 4 Jun 2009 12:19:34 -0700

On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote:

>> 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.
>>

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

---

From: John Levine <[email-masked]>
Date: 4 Jun 2009 20:38:26 -0000

> A competent mailing list admin would reject all messages from
> dubious sources. But it would be foolish to assume that all such
> admins are as competent as we would wish. So the mere fact that they
> (re)sign messages does not prove their origin, except insofar as you
> are prepared to have confidence in their competence.

I've been subscribing to mailing lists since the 1970s, and other than
a brief flurry about 15 years ago when spammers used open lists as
mail amplifiers, I have never seen bad mail leaking through lists as a
particularly serious or insoluble problem.

Could you explain why you think DKIM will make hitherto competent list
managers unable to control what gets onto the lists, and perhaps
suggest a few lists where you expect the managers to be too
incompetent to manage what gets onto the list, yet competent enough to
add DKIM verification, add an A-R header, and resign it?

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 4 Jun 2009 14:27:23 -0700

> counter to their intended use.

That's not necessarily true.

You're making hard assertions about a fuzzy situation.  DKIM signing might work just fine in certain installations.  That's why RFC5451 suggests doing this without requiring it.

> Whatever leak that allows a bad actor's A-R header to appear

I agree that this is a security consideration, but it doesn't mean signing A-R headers is a waste of effort.  At some sites it's probably the ideal solution.

> seems like a bad idea with respect to DKIM.

I disagree with "in general".  There seems to have been enough consensus to put A-R up to proposed standard status, and that seems to fly in the face of your claim that it's not useful.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 05 Jun 2009 14:36:09 +0100

> incoming border MTAs.  See section 1.6 of RFC 5451.

No, that is NOT what section 1.6 of RFC 5451 says. It requires removal of  
any pre-existing A-R header "claiming to be valid with in its [the ADMD's]  
boundaries", which essentially means (AIUI) any A-R header that might be  
mistaken for one that might/would/should have been created within that  
same ADMD.

BUT the cases we are considering are where, in the course of its travels,  
a message has picked up two signatures, S_1 and S_2, but where S_1 has  
(possibly) been invalidated by some change at an intermediate site  
(typically a mailing list expander) en route, and even where S_1 has been  
removed at some point. So there are at least three ADMDs involved:

|    sending ADMD   |       Mail List ADMD        |       Receiving  
ADMD     |
| orig MUA orig MTA |                             |    Recv MTA     Recv  
MUA |
|    M ---> M+S_1 --+-> M+S_1+A_1 -> M*+A_1+S_2 --+-> M*+A_1+S_2+A_2  
-->     |

A_1 was added by a validator/assessor on the strength of S_!
A_2 was added by a validator/assessor on the strength of S_2
Observe that M was transmogrified into M* at some point, breaking S_!.

If some "helpful" MTA, somewhere between the Mail List and Receiving  
ADMDs, had also added an A_2, then THAT is the one that should be removed  
by Recv MTA, before inserting its own (which it obviously would not do if  
S_2 covered A_1, and A_1 was no longer there).

What Recv MTA passes on to Recv MUA is entirely a matter to be decided  
within the Receiving ADMD, but I hope it would be everything that was  
available (even S_1 if it were still available).

Note that Appendix B.6 of RFC 5451 contains an example exactly equivalent  
to the one I have just given, including the retention of A_1 (and even  
S_1).

---

From: Doug Otis <[email-masked]>
Date: Fri, 5 Jun 2009 10:27:06 -0700

On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote:

>>> Then why are people on this list not trying to enocourage that  
>>> good practice? Indeed, why are they so vociferously trying to  
>>> DIScourage it?
>>
> No, that is NOT what section 1.6 of RFC 5451 says. It requires  
> removal of any pre-existing A-R header "claiming to be valid with in  
> its [the ADMD's] boundaries", which essentially means (AIUI) any A-R  
> header that might be mistaken for one that might/would/should have  
> been created within that same ADMD.

By selecting specific A-R headers to remove, header content might be  
processed post delivery, and then appear to match against some trusted  
domain.

The safest solution would be to remove _all_ A-R pre-existing A-R  
headers from different environments or not since they may not have  
been treated as trace headers or are encoded in some fashion.  It is  
hard enough to decide whether A-R headers that appear to be from the  
incoming domain can be trusted.  To better ensure trustworthiness of A- 
R headers, it seems wise to remove _all_ preexisting A-R headers.   
Until A-R handling has demonstrated consistent safety, and not just  
safe most of the time, it seems imprudent to trust foreign A-R  
headers.  YMMV.

> BUT the cases we are considering are where, in the course of its  
> travels,  a message has picked up two signatures, S_1 and S_2, but  
> where S_1 has (possibly) been invalidated by some change at an  
> intermediate site  (typically a mailing list expander) en route, and  
> even where S_1 has been removed at some point. So there are at least  
> three ADMDs involved:
>
> | orig MUA orig MTA |                             |    Recv MTA      
> Recv MUA |
> A_1 was added by a validator/assessor on the strength of S_1
> Observe that M was transmogrified into M* at some point, breaking S_1.
>
> ADMDs, had also added an A_2, then THAT is the one that should be  
> removed by Recv MTA, before inserting its own (which it obviously  
> would not do if S_2 covered A_1, and A_1 was no longer there).
>
> What Recv MTA passes on to Recv MUA is entirely a matter to be  
> decided within the Receiving ADMD, but I hope it would be everything  
> that was available (even S_1 if it were still available).
>
> Note that Appendix B.6 of RFC 5451 contains an example exactly  
> equivalent to the one I have just given, including the retention of  
> A_1 (and even S_1).

IMHO, appendix B.6 is overly optimistic for today's environment.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 08 Jun 2009 11:24:20 +0100

> processed post delivery, and then appear to match against some trusted

For sure, individual recipients may wish to check signatures etc. for  
themselves, espeicially if they have doubts about the policies applied by  
their local assessors. If the local assessor has unnecessarily removed  
sone A-R that is actually covered by the signature, then that becomes  
impossible.

And if they have doubts about the policies of sone earlier mailing list  
expander, they might wish to see exactly what that expander had actually  
done to the message. For such forensic investigations, removing useful  
information (aka "dumbing down") is always a dumb thing.
> headers from different environments ...

But that's not what the standard says.

> IMHO, appendix B.6 is overly optimistic for today's environment.

Maybe so, but that document is a proposed standard, and unless you have  
plans to get it revised, we must try and work with it as it stands.  
Nothing in that example is contrary to what that standard says normatively.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Jun 2009 05:51:22 -0700

> > processed post delivery, and then appear to match against some trusted

I believe the Security Considerations of RFC5451 covers this adequately.

+1

+1

> > IMHO, appendix B.6 is overly optimistic for today's environment.

Have you seen actual attacks like this in the wild already?

+1

(BTW, does this still qualify as being "on topic" for this list?)

---

From: Doug Otis <[email-masked]>
Date: Mon, 8 Jun 2009 11:30:38 -0700

On Jun 8, 2009, at 3:24 AM, Charles Lindsey wrote:

>> By selecting specific A-R headers to remove, header content might  
>> be processed post delivery, and then appear to match against some  
>> trusted domain.
>
> For sure, individual recipients may wish to check signatures etc.  
> for themselves, espeicially if they have doubts about the policies  
> applied by their local assessors. If the local assessor has  
> unnecessarily removed some A-R that is actually covered by the  
> signature, then that becomes impossible.

The use of the DKIM l=,  z= and x= features provide a means for  
recipients to separately evaluate DKIM signatures without reliance on  
intermediary assessors.  In addition, the A-R header does not capture  
the IP address when assessing path registration protocols, which means  
that safe recipient reassessment might only be possible in the case of  
DKIM or reverse DNS.

> And if they have doubts about the policies of sone earlier mailing  
> list expander, they might wish to see exactly what that expander had  
> actually done to the message. For such forensic investigations,  
> removing useful information (aka "dumbing down") is always a dumb  
> thing.

Removal of foreign A-R headers provides better security.  Since A-R  
header fails to capture source IP addresses for path registration  
schemes, the forensic value of this header is very limited, to the  
point of being dangerous.

Reliance upon the A-R header offers providers permission to modify  
messages.  Some providers offer their services free, however there  
remains a profit motive where their security may overlook embedded  
iFRAMEs referencing malware injected into one of their third-party ad  
servers.   A-R header may indicate to recipients that the message  
originated from Big-Bank, but ads might appear from a different  
entity.  In this case, the goal of DKIM is has been lost.    
Unfortunately, the introduction of ads is fairly common, and the  
authserv-ids may not offer a means to consolidate or identify who is  
being trusted.  There are significant risks and problems created when  
dealing with A-R headers.  DKIM without A-R headers does not invite  
questionable practices likely to create many duped victims.   An  
appearance of a message being from someone trusted can be worse than a  
message with an unknown status when the content source is in doubt.

> But that's not what the standard says.

Wrong.  See RFC 5451 section 5, complete removal is suggested for  
maximum security.  It also suggests:

"A more robust border MTA could allow a specific list of  
authenticating MTAs whose information should be let in, removing all  
others."

>>> equivalent to the one I have just given, including the retention  
>>> of A_1 (and even S_1).
>>
> Maybe so, but that document is a proposed standard, and unless you  
> have plans to get it revised, we must try and work with it as it  
> stands.  Nothing in that example is contrary to what that standard  
> says normatively.

No.  Nor does the RFC warn of encoded headers or header reordering.   
Headers may be altered during handling.  In addition, the "Trust  
Environment"  can use any type of token, and not just those derived  
from a host name.  The lack of uniformity or standardized means of  
ensuring uniqueness means little should be assumed regarding any A-R  
header not generated by the receiving MTA.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Jun 2009 15:37:50 -0700

> [...]

Could we please not re-re-re-rehash these A-R issues on ietf-dkim?  They were already covered on mail-vet-discuss more times than I can count.  The archives of that list are public in case anyone really needs to go through them all again.

---

From: Doug Otis <[email-masked]>
Date: Mon, 8 Jun 2009 17:58:06 -0700

On Jun 8, 2009, at 3:37 PM, Murray S. Kucherawy wrote:

>> recipients to separately evaluate DKIM signatures without reliance  
>> on intermediary assessors.  In addition, the A-R header does not  
>> capture the IP address when assessing path registration protocols,  
>> which means that safe recipient reassessment might only be possible  
>> in the case of DKIM or reverse DNS.
>> [...]
>
> Could we please not re-re-re-rehash these A-R issues on ietf-dkim?

This was in response Charles making the statement:

"For such forensic investigations, removing useful information (aka  
"dumbing down") is always a dumb thing."

These headers represent an active and potentially hazardous component  
used in email annotation.  Unless the border MTA is willing to assert  
the A-R headers not removed are safe, the A-R headers should be  
removed.  The point of "rehashing" information excluded from the A-R  
header was to emphasize the point that these headers were not intended  
to play a role in forensics.  Otherwise, the source of a message would  
have been important.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Jun 2009 10:12:04 +0100

I think Murray's point is a fair one. This thread isn't
really progressing in terms of what to in/exclude from
4871bis as far as I can see so let's leave it there.

Stephen.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 09 Jun 2009 11:59:26 +0100

> that safe recipient reassessment might only be possible in the case of

I accept that my remarks concerning the retention of A-R headers are  
directed at the case where those headers are confirming the analysis of  
some DKIM signature. Different considerations may well apply when the A-R  
is reporting on some other security mechanism.

> maximum security.  It also suggests:

When you first made your claim, you were relying on Section 4.1. Now I  
have shot that one down, you have transferred to Section 5.

But section 5 merely says you MAY remove A-R headers, but then immediately  
goes on to warn you of two situations where this might be counter  
productive. Both of those situations arise in the scenarios I have been  
discussing.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 09 Jun 2009 11:48:09 +0100

On Mon, 08 Jun 2009 23:37:50 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> Could we please not re-re-re-rehash these A-R issues on ietf-dkim?  They  
> were already covered on mail-vet-discuss more times than I can count.   
> The archives of that list are public in case anyone really needs to go  
> through them all again.

Actually, this discussion is a spin-off of the thread on the usefulness of  
the l= tag, which is definitely on topic for this group.

What I think it makes clear that we are in serious need of some document  
to provide Best Practice for how mailing list expanders should handle  
DKIM, and I think that is something that this WG needs to take on board.