Subject: [ietf-dkim] Draft minutes...

From: [email-masked]
Date: Wed, 12 Jul 2006 20:17:37 -0000 (GMT)

...attached. Comments to me/Barry in the next week or two please.

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

---

From: Eric Allman <[email-masked]>
Date: Wed, 12 Jul 2006 19:28:22 -0400

A few comments on my action items:

1308 (language recommending use of t=s): In the description of the 
t=s flag, I've added "Use of this flag is RECOMMENDED unless 
subdomaining is required."

DNS discussion: There's a note from Olafur suggesting that the 
document add "do not use wildcards."  I'm not completely clear where 
this belongs: it can't be for _domainkey.*.example.com, so perhaps 
this means for *._domainkey.example.com?  Or is this about policy?

1316 #1 (define plain-text): It turns out it's already defined for 
tag=value lists (which is what matters for us) in the ABNF for 
VALCHAR.  I've added "INFORMATIVE IMPLEMENTATION NOTE: Although the 
"plain text" defined below only includes 7-bit characters, an 
implementation that wished to anticipate future standards would be 
advised to not preclude the use of UTF8-encoded text in tag=value 
lists."

1316 #22 (guidance on limiting trace headers): Section 5.4 now 
includes the text "Signers choosing to sign an existing header field 
that occurs more than once in the message (such as Received) MUST 
sign the physically last instance of that header field in the header 
block. Signers wishing to sign multiple instances of such a header 
field MUST include the header field name multiple times in the h= tag 
of the DKIM-Signature header field, and MUST sign such header fields 
in order from the bottom of the header field block to the top. The 
signer MAY include more instances of a header field name in h= than 
there are actual corresponding header fields to indicate that 
additional header fields of that name SHOULD NOT be added."

1317 #33 (use cases for 3rd party MTAs --- the notes have this listed 
as #30-#34, but I believe that is incorrect): I have added Appendix 
B.7 reading (sorry for the XML):

        <section
        title="SMTP Servers for Roaming Users"
        ><t
        >Roaming users may find themselves in circumstances where it
        is convenient or necessary to use an SMTP server other than
        their home server; examples are IETF conferences and many
        hotels.  In such circumstances the signature, if any, will be
        added by a party other than the user's home system.</t
        ><t
        >Ideally roaming users would connect back to their home
        server using either a VPN or a SUBMISSION server running with
        SMTP AUTHentication on port 587.  If the signing can be
        performed on the roaming user's laptop then they can sign
        before submission, although the risk of further modification
        may be high.  If neither of these are possible, these roaming
        users will not be able to send mail signed using their own
        domain key.</t
        ></section

Not explicitly listed in the notes:

Section 5.4 (Determine the header fields to sign) now has the 
following language (again, sorry for the XML):

        The From header field MUST be signed (that is, included in
        the h= tag of the resulting DKIM-Signature header field); any
        header field defined as an Originator Field in <xref
        target="RFC2822"
        ></xref
        > section 3.6.2, Resent-From, and Resent-Sender MUST also be
        included. The signed header fields SHOULD also include the
        Subject and Date header fields as well as all MIME header
        fields. Signers SHOULD NOT sign an existing header field
        likely to be legitimately modified or removed in transit. In
        particular, <xref
        target="RFC2821"
        ></xref
        > explicitly permits modification or removal of the
        "Return-Path" header field in transit. Signers MAY include
        any other header fields present at the time of signing at the
        discretion of the signer.<list
        style="empty"
        ><t
        >INFORMATIVE OPERATIONS NOTE: The choice of which header
        fields to sign is non-obvious. One strategy is to sign all
        existing, non-repeatable header fields. An alternative
        strategy is to sign only header fields that are likely to be
        displayed to or otherwise be likely to affect the processing
        of the message at the receiver. A third strategy is to sign
        only "well known" headers. Note that verifiers may treat
        unsigned header fields with extreme skepticism, including
        refusing to display them to the end user.</t
        ></list

eric

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jul 2006 16:36:41 -0700

Eric Allman wrote:

>        included. 

Why MUST these be signed?

       Mike

---

From: Eric Allman <[email-masked]>
Date: Wed, 12 Jul 2006 19:39:57 -0400

For the same reason From: has to be signed --- they represent the 
[fill in blank with your favorite word: author, originator, whatever] 
of the message.  I suppose we can legitimately ask why From: MUST be 
signed though.  In terms of interoperability it is not required, but 
in terms of being useful it seems like it is.

eric

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jul 2006 16:44:57 -0700

> in terms of being useful it seems like it is.

   I'm unclear on Resent-From and Resent-Sender: can they be added in 
transit?
   If so, the MUST as worded below will guarantee the signature won't be 
valid
   after somebody adds those headers.

   I guess if you're going to make these MUST requirements why Sender or
   ListID aren't MUST's too. Frankly I think the wording with From, Subject
   and Date is fine and leave the rest to the disgression of the signer.

       Mike

>
> eric
>
>
> --On July 12, 2006 4:36:41 PM -0700 Michael Thomas <[email-masked]> wrote:
>
>> Eric Allman wrote:
>>

---

From: Eric Allman <[email-masked]>
Date: Wed, 12 Jul 2006 19:50:30 -0400

Resent-* should only be added by MUAs when someone is re-submitting a 
message back into the MHS.  Essentially Resent-From subsumes the role 
of From when a message is re-submitted (ditto for Resent-Sender and 
Sender).  It's not quite this simple, since an MUA replying to a 
resent message should still reply back to the original originator, 
not the resending originator, but that's the basic gist of it.

eric

--On July 12, 2006 4:44:57 PM -0700 Michael Thomas <[email-masked]> 
wrote:

>> [fill in blank with your favorite word: author, originator,
>> whatever]  of the message.  I suppose we can legitimately ask why
>> From: MUST be  signed though.  In terms of interoperability it is
>> not required, but  in terms of being useful it seems like it is.
>
>
>    I'm unclear on Resent-From and Resent-Sender: can they be added
> in transit?
>    If so, the MUST as worded below will guarantee the signature
> won't be valid

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jul 2006 16:56:49 -0700

Eric Allman wrote:

> resent message should still reply back to the original originator, not 
> the resending originator, but that's the basic gist of it.

The reason I'm pushing back on this is that it's a protocol affecting 
change as I don't
think that I've seen many implementations that *always* add those fields 
(does
Murray's? Mine doesn't by default). The change you're making here would 
cause
a compliant verifier to reject those signatures. Is it really *that* 
important? Maybe
it's me, but Resent-From and Resent-Sender seem pretty quaint and in their
dotage.

       Mike

>
> eric
>
>
> --On July 12, 2006 4:44:57 PM -0700 Michael Thomas <[email-masked]> wrote:
>
>> Eric Allman wrote:
>>

---

From: Eric Allman <[email-masked]>
Date: Wed, 12 Jul 2006 20:21:04 -0400

Huh?  You've got me completely confused.  DKIM should /never/ add 
Resent-* fields.  I don't see how that is stated or implied.  I can 
see how you might think that it has to include them in h= even if 
they didn't already exist, so I've added "if included" to the text.

Resent-* may seem "quaint" to you, but they are still in-spec and 
used (by me, if no one else).

eric

--On July 12, 2006 4:56:49 PM -0700 Michael Thomas <[email-masked]> 
wrote:

> Eric Allman wrote:
>
>> Resent-* should only be added by MUAs when someone is
>> re-submitting a  message back into the MHS.  Essentially
>> Resent-From subsumes the role  of From when a message is
>> re-submitted (ditto for Resent-Sender and  Sender).  It's not
>> quite this simple, since an MUA replying to a  resent message
>> should still reply back to the original originator, not  the
>> resending originator, but that's the basic gist of it.
>
>
> The reason I'm pushing back on this is that it's a protocol
> affecting change as I don't
> think that I've seen many implementations that *always* add those
> fields (does
> Murray's? Mine doesn't by default). The change you're making here
> would cause
> a compliant verifier to reject those signatures. Is it really
> *that* important? Maybe

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jul 2006 17:27:57 -0700

Eric Allman wrote:

> see how you might think that it has to include them in h= even if they 
> didn't already exist, so I've added "if included" to the text.

I meant added to h=. You're forcing a DKIM protocol change to mandate that
they be present. And yes, your previous wording wasn't at all clear 
about whether
they only MUST be added if they were present. And I'm not sure that "if 
included"
would be right -- if they're that important, you'd want to guard against 
insertions
later in malicious MTA's, right?

> Resent-* may seem "quaint" to you, but they are still in-spec and used 
> (by me, if no one else).

The issue is whether we really need to break a bunch of DKIM 
implementations over
this. It sure doesn't seem to raise to that level of urgency to me.

       Mike

>
> eric
>
>
>
> --On July 12, 2006 4:56:49 PM -0700 Michael Thomas <[email-masked]> wrote:
>
>> Eric Allman wrote:
>>

---

From: Eric Allman <[email-masked]>
Date: Wed, 12 Jul 2006 20:30:51 -0400

The draft has /always/ said that these header fields are to be 
signed.  From -03:

        any header field that describes the role of the signer (for
        example, the Sender or Resent-From header field if the
        signature is on behalf of the corresponding address and that
        address is different from the From address) MUST also be
        included.

All I've done is re-word it.

eric

--On July 12, 2006 5:27:57 PM -0700 Michael Thomas <[email-masked]> 
wrote:

>> Resent-* fields.  I don't see how that is stated or implied.  I
>> can  see how you might think that it has to include them in h=
>> even if they  didn't already exist, so I've added "if included" to
>> the text.
>
>
> they only MUST be added if they were present. And I'm not sure that
> "if included"
> would be right -- if they're that important, you'd want to guard
> against insertions

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jul 2006 17:42:53 -0700

> All I've done is re-word it.

We clearly have a disconnect here. When I read the previous text, I see that
it is the *signers* resposibility to figure that role based stuff and if 
it can,
it MUST add those headers to h=. If it can't figure out that role, then 
it's not
under any obligation to add them. Thus a receiver MUST NOT enfore that
the same way that it can enforce From (which MUST be signed regardless).

What we're morphing into here is where the signer MUST understand its
signing role for these other headers, and that gives me a great deal of
heartburn. Worse, is that a receiver would be entitled to REJECT the
signature if it thought I got my signing role wrong. That's completely
nuts.  But that's the net effect of making inclusion of those MUST's.

I can't see the entire context of what you've modified, but if it still 
contains
any of the paragraph you just quoted, we've got a really big problem. If
it's just the new text, my previous comments apply: making those fields
MUST INCLUDE in h= probably breaks a bunch of happily working
implementations and I really don't think the gain (if any) is worth that.

       Mike

---

From: Mark Delany <[email-masked]>
Date: Thu, 13 Jul 2006 02:44:56 +0000

On Wed, Jul 12, 2006 at 05:42:53PM -0700, Michael Thomas allegedly wrote:
> it can, it MUST add those headers to h=. If it can't figure out that role, then 
> it's not

This is an interesting topic and dwells on the desire to protect UAs
from bad guys adding originating headers that could aid in a spoof. It
was part of my thinking wrt h=* discussion.

The problem of course is that no one knows what are, or will be,
originating headers either because we have no clue about the
destination UA or we have no clue about future headers.

My current thinking, FWIW, is that a diligent UA/MDA will likely
remove *all* headers that are not signed, excepting trace headers so
the need to ensure protection of any header becomes moot. That
includes, From: et al.

To my mind, the spec currently stands mid-way, it sort-of protects
obvious headers but cannot possibly protect all, so my druthers is
that we actually remove all compulsion as to which headers are signed
as it may well look truly quaint in five years time when other
important originator headers get created.

Mark.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 12 Jul 2006 23:16:27 -0400

Resent-From: and Resent-Sender: would be signed only if present in the
header. It's perfectly legit for a forwarding system to add them (and
expected according to the specs), and if that forwarding server then
signs the message, those headers MUST be treated in the same category as
From: and Sender:.

All four of these headers should be treated as: if present, it MUST be
signed.

	Tony Hansen
	[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jul 2006 23:18:42 -0400

> important originator headers get created.

If we take the view that -base should be limited to mechanism, and that it
defers "policy" issues to separate specification, as well as operational
preferences that develop over time, then this makes quite a bit of sense.

Given the discussion during today's working group meeting, I think we should
seriously consider taking Mark's suggestion seriously.

d/
-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 Jul 2006 23:28:28 -0400

> important originator headers get created.

+1

This makes good sense, especially with EAI activity likely to be  
making such changes necessary should this go wrong.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 12 Jul 2006 20:48:21 -0700 (PDT)

On Wed, 12 Jul 2006, Eric Allman wrote:

> For the same reason From: has to be signed --- they represent the [fill in 
> blank with your favorite word: author, originator, whatever] of the message. 
> I suppose we can legitimately ask why From: MUST be signed though.  In terms 
> of interoperability it is not required, but in terms of being useful it seems 
> like it is.

So if message has Resent-From field would SSP check be done against From
or Resent-From or both?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Mark Delany <[email-masked]>
Date: Thu, 13 Jul 2006 03:59:25 +0000

On Wed, Jul 12, 2006 at 08:48:21PM -0700, william(at)elan.net allegedly wrote:
> >blank with your favorite word: author, originator, whatever] of the 
> >message. I suppose we can legitimately ask why From: MUST be signed 
> >though.  In terms of interoperability it is not required, but in terms of 
> >being useful it seems like it is.
> 

Gosh. What a can of worms. Is SSP consulted on a verified signature?
If not, then how can SSP play into these headers?

Mark.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Jul 2006 21:34:22 -0700

I interpret this text differently.  If the signer uses a signing address
that matches (for example) Resent-From, and wishes the verifier to see
that its role is as a resender, then it must sign Resent-From.  But
suppose someone resends a message to a mailing list, which itself
signs.  The list isn't the Resent-From address, so it is not required to
sign Resent-From (although it may, of course).

-Jim

Eric Allman wrote:
> --On July 12, 2006 5:27:57 PM -0700 Michael Thomas <[email-masked]> wrote:
>
>> Eric Allman wrote:
>>

---

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Jul 2006 21:36:24 -0700

> So if message has Resent-From field would SSP check be done against From
From.  Always From, unless there is a valid signature where the signing
address matches the From address, in which case no SSP check is required.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Jul 2006 01:27:56 -0400

----- Original Message ----- 
From: "william(at)elan.net" <[email-masked]>

> So if message has Resent-From field would SSP check be done against From

The verification is already done before the Resent-From was added. 
i.e., Resent-* should not be in original mail.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Jul 2006 01:52:14 -0400

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: "william(at)elan.net" <[email-masked]>

>> So if message has Resent-From field would SSP check be done
>> against From or Resent-From or both?

> From.  Always From, unless there is a valid signature where the
> signing address matches the From address, in which case no SSP
> check is required.

Said another way, only for 1st party valid signatures, a policy check is not
required.

The reasoning has been:

To exploit the 1st party key, is to exploit the policy record as well since
the commonality is the domain name, hence same DNS storage. So if the key
was exploited unbeknowst to the verifier, the policy record is more than
likely exploited as well.  The exploited key will be authorized by the
exploited policy.

However, policy controls can be added against 3rd party signatures.

The 3rd party threat exploit is when 3rd party validated signings is not an
authorized nor an expected practice by the originating and responsible
domain.  The original domain is not exploited in this case.

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 07:20:00 -0400

--On July 13, 2006 2:44:56 AM +0000 Mark Delany 
<[email-masked]> wrote:

> that we actually remove all compulsion as to which headers are
> signed as it may well look truly quaint in five years time when
> other important originator headers get created.

I have to admit that I disagree with the argument but do agree with 
the conclusion.  I don't think it's likely that after 29 years (since 
the publication of RFC 733) that we are suddenly going to want new 
originator headers in five years that will make the previous history 
look quaint.  It would take far more than five years to update the 
MUAs.  However, in the spirit of "mechanism, not policy" I think it's 
a good idea to pull out the normative language (perhaps retain it in 
yet another informative note).

eric

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jul 2006 09:02:11 -0400

Person A sends the message to Person B. A's server AS does not sign the
message. Person B decides to resend the message to Person C, and B's
server BS duly adds a Resent-From: header and does signing.

As far as BS is concerned, the Resent-From: header is the one that
*should* be signed, not the From: header.

	Tony Hansen
	[email-masked]

---

From: Sandy Wills <[email-masked]>
Date: Thu, 13 Jul 2006 09:37:17 -0400

(I lurk for an education, and occasionally ask questions to help learn)

> *should* be signed, not the From: header.

    Assume that this "new system" you are creating is to be used by 
people with current MUAs.  Every MUA I am familiar with (the MS series 
and the Netscape/Mozilla series) does the same thing when your "Person B 
decides to resend": they create a new message, allowing B to put 
whatever he/she/it wants to put in it, and appends the original message 
(optionally allowing B to add, subtract, fold, spindle, and mutilate the 
original content).
    This is not a transparent retransmittal of the original message from 
A as an MTA would do.  Anyone who views this message from B has no way 
of determining what, if any, modifications B has made to the original 
content.

    Server BS _MUST_ treat this as a new message, from B, and sign as 
From.  How am I wrong, here?

-- 
Unable to locate coffee.
Operator halted.

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 09:49:33 -0400

> people with current MUAs.  Every MUA I am familiar with (the MS
> series and the Netscape/Mozilla series) does the same thing when
> your "Person B decides to resend": they create a new message,
> allowing B to put whatever he/she/it wants to put in it, and
> appends the original message (optionally allowing B to add,
> subtract, fold, spindle, and mutilate the original content).
>     This is not a transparent retransmittal of the original message
> from A as an MTA would do.  Anyone who views this message from B
> has no way of determining what, if any, modifications B has made to
> the original content.
>
>     Server BS _MUST_ treat this as a new message, from B, and sign
> as From.  How am I wrong, here?

There is a distinction between forwarding a message (which is what 
you describe) and re-sending a message (which is what Resent-* 
headers are for).  Resending /is/ supported by at least some MUAs, 
and involves re-submitting the original message to the mail system.

For example, A sends a message to B.  B determines that this really 
should have gone to C.  If B forwards the message and C replies, the 
reply goes to B, not A.  If B re-sends the message and C replies, the 
reply goes to A.

An example is when someone changes roles but is still getting mail 
intended for the old role.  They want to send old-role messages to 
the new person in that role and have it behave as if the message had 
originally been sent to the new person --- i.e., they want to wash 
their hands of the message entirely.

eric

---

From: Sandy Wills <[email-masked]>
Date: Thu, 13 Jul 2006 10:01:20 -0400

Eric Allman wrote:
> intended for the old role.  They want to send old-role messages to the 
> new person in that role and have it behave as if the message had 
> originally been sent to the new person --- i.e., they want to wash their 
> hands of the message entirely.

   I recognize the concept, and believe that I could make a supporting 
MUA do this.  The question is, how does the server BS _know_ that this 
is what happened, instead of the man in the middle making some 
self-serving changes and saying "Here it is, just as I got it."
   In a perfect world, not likely, but you are doing this because of 
some "bad actors", right?  If I can think of it in a few seconds of 
reading this morning's email, then someone else will figure a way to 
benefit from it.  Better to figure out, now, how to prevent it.

-- 
Unable to locate coffee.
Operator halted.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jul 2006 08:37:14 -0700

>All four of these headers should be treated as: if present, it MUST be

Here's my big question though: does your receiver enforce that, or is 
this just
a policy mandate on the signer? The original text made it sound a lot 
like the
latter. The new wording makes it sound a lot like the former, which I 
think is
a big problem. As I said, I'd be even happier to get rid of the normative
language here to eliminate this ambiguity on the receiver altogether.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Jul 2006 13:11:50 -0400

Tony,

I see your point.

Does this presume that BS will be taking responsibility for the original
domain?

If Resent-From: becomes the source for DKIM verification, in essence, it has
become a 3rd party signature system in the eyes of downlink verifiers?  Yes?

If it is viewed as a brand new submission, then I think it is more
consistent, but this is why SSP plays a vital role here.

As long as we have uncontrolled potential of 3rd party signers, we will also
have a big mess of who is truly valid or not, especially when it comes to
unsigned original mail.

In my view, the DKIM compliant BS server (router/resender) should be "picky"
on what it signs as original or as a resend.  This is where SSP helps.

Also another no so minor point:

Will DKIM mandate support for RESENT-* fields?  That's an awful big jump if
so.

---

From: Sandy Wills <[email-masked]>
Date: Thu, 13 Jul 2006 13:50:30 -0400

Thinking this over some more, I realize that "the problem I'm 
complaining about" is _not_ related to "the problem you guys are trying 
to solve".
    If A sends an email to B, who really doesn't want it because he is 
doing another job now, so he sends it to C, it doesn't matter 
_for_your_purposes_here_ whether he forwards it, resends it, or has his 
local office email server forward it without him ever seeing it.
    Similarly, if B sees a way to cause trouble for A and C, then he 
(being an Evil Programmer, or able to hire such) can send an email to C 
claiming to be a forwarded or resent post from A.
   All you guys are trying to do is come up with a way for C to be sure 
that the email he gets came from B.  You are not, in any way, trying to 
say anything about any alleged original email from A.
   Now that I've recognized this, I'll shut up.  Thanks for helping with 
my education.  Someday, I'll be able to help.  I promise.

-- 
Unable to locate coffee.
Operator halted.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jul 2006 14:21:13 -0400

> Does this presume that BS will be taking responsibility for the original

Of course not; BS is taking responsibility for its domain. Hence its
signing of the Resent-From: header.

> become a 3rd party signature system in the eyes of downlink verifiers?  Yes?

No; it's a 1st party signature system for the forwarder.

> consistent, but this is why SSP plays a vital role here.

Yes, it's a brand new submission, but acknowledging that the message is
being resent from a previous sender.

> Will DKIM mandate support for RESENT-* fields?  That's an awful big jump if

We already do. See section 5.4.

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jul 2006 14:29:48 -0400

Scott, please reread the appeal response note more carefully. It does
not denigrate Resent-*, but acknowledges that rfc822/rfc2822-compliant
systems were not required to follow the practice. (It's marked as a
SHOULD requirement.) Consequently, a system can be compliant without
supporting Resent-*. However, *IF* a system supports that SHOULD (and
they should, of course, :-) ), then DKIM had better be able to handle it
properly

	Tony Hansen
	[email-masked]

Scott Kitterman wrote:
> On Wednesday 12 July 2006 23:16, Tony Hansen wrote:
> IIRC, this issue was the matter of a recent IESG appeal:
> 
> http://www.ietf.org/IESG/APPEALS/appeal2-draft-lyon-senderid.txt
> http://www.ietf.org/IESG/APPEALS/appeal-response-william-leibzon.txt
> 
> Based on that, I do not believe it is correct to state that it is either 
> legitimate or expected for automatic forwarders to add resent-* header 
> fields.
> 
> RFC 4407 got published with an IESG note because it was experimental.  Here 
> the bar is higher, so however this issue gets resolved, I think it important 
> to not do anything that indicates resent-* header fields are to be added 
> automatically.
> 
> Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Jul 2006 14:41:39 -0400

From: "Tony Hansen"

>> Does this presume that BS will be taking responsibility for the
>> original domain?
>

Ok, so do have some insight into what HEADERS should be signed depending on
what role the signer is taking?

>> If Resent-From: becomes the source for DKIM verification, in essence,
>> it has become a 3rd party signature system in the eyes of
>> downlink verifiers?  Yes?
>

So its using From: for the key, and Resent-From: is just part of the signing
hash?  So basically, we have rule that says DKIM compliant Forwarders:

 a) Must Support RESENT-*
 b) Must Sign RESENT-FROM:

Correct?

>> Will DKIM mandate support for RESENT-* fields?  That's an awful big
>> jump if so.

> We already do. See section 5.4.

Tony, unless I missed it, this does not say Resent fields support is a
requirement. Specifically, it does not say that forwarder:

   a) Must support RESENT-*
   b) Must sign RESENT-FROM:

Per 2822, section 3.6.6, Resent fields are a "SHOULD" not a MUST. And as far
as I can tell, it is not a widely use practice.   If this is a DKIM mandate,
this goes against the idea that infrastructure change is not required for
DKIM support.

So once again, how does DKIM handle inconsistency and fail analysis.  There
is no Resent-*, the message is signed and it appears to be from a 3rd party?

In short, I hope we are not assuming there will always be a Resent-* header
from forwarders.  This is clearly not the current standard practice across
the board.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jul 2006 15:26:44 -0400

I'm saying that

	if there are Resent-* headers representing identity, they should
	be signed

We should be agnostic to the debate. If the MUA uses them, support them.
If the MUA does NOT use them, we don't.

	Tony Hansen
	[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Jul 2006 15:52:17 -0400

> If the MUA does NOT use them, we don't.

Agreed.  It is still to be seen what will be practical.  Message  
annotation proactively protecting recipients without suffering a  
discovery process climbing label trees looking for a possible policy  
confirmation that may, in the end say little, if anything, about what  
mail is acceptable.  Spammers can adopt policy record requirements  
and thus this requirement will offer little in the way of protection  
from abusive email, especially when email-address recognition is not  
assumed.  DKIM without some type of annotation is already prone to  
Microsoft X-Message headers, as well as notations related to the  
Sender header.  That involves just one of hundreds of MUAs.  Once MUA  
developers incorporate information confirmed by DKIM sans policy,  
substantial protections can be achieved by comparing signing domains  
against information collected in Address Books, or correspondence lists.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Jul 2006 16:42:49 -0400

> they should, of course, :-) ), then DKIM had better be able to handle it

The appeal had multiple points.  One of which was that resent-* header fields 
were for information only and should not be automatically acted on:

> 2. Use Resent-* headers for automatic action, which is incompatible
> with RFC2822

> Ref: http://www.ietf.org/rfc/rfc2822.txt (section 3.6.6):

> | Resent fields are
> | strictly informational. They MUST NOT be used in the normal
> | processing of replies or other such automatic actions on messages.

> I take "automatic action" to include rejection and bouncing of messages
> and draft-lyon-senderid-core-01 recommends when PRA address derived from
> Resent- header is not authorized based on corresponding SPF record check,
> then message is to be rejected by mail system in automated manner.

If the fields MUST NOT be used in processing on the receive side, what's the 
point in signing them?  While signing them surely doesn't hurt, I can't see 
how it should be required.

>> All four of these headers should be treated as: if present, it MUST be

I think this is incorrect.  Resent-* are fundamentally different than 
From:/Sender:.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Jul 2006 16:48:57 -0400

EVERYONE, PAY ATTENTION TO THIS!

Please STOP using this subject line.
If you have an issue to discuss, please create a new subject that 
describes the issue you are discussing.

DO NOT USE THIS SUBJECT LINE!

--
Barry Leiba, DKIM working group chair  ([email-masked])

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Jul 2006 17:05:21 -0400

I liked Dave's phrasing, so I'm using his message as the anchor for my 

> seriously consider taking Mark's suggestion seriously.

I agree.
I personally like the idea that we should leave the decision of which 
header fields to sign purely up to the signer.  But that's me, not the 
chair, talking.

As chair, I see a growing consensus to do it that way.  Let's try to 
resolve this issue tout de suite, and move on.  I'd like to hear from 
people who think we should have some headers as "MUST sign".  I'd like 
to hear from those who agree with Mark and Mike, that we should not have 
any with "MUST".

What say you?

Barry

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Jul 2006 17:17:27 -0400

----- Original Message -----
From: "Barry Leiba" <[email-masked]>

> to hear from those who agree with Mark and Mike, that we should not have

See my last message to Eric:

http://mipassoc.org/pipermail/ietf-dkim/2006q3/004249.html

I vote for a minimum requirement and expectation that is part of the
fundamental email infrastructure.  In regards to DKIM, that should be the
FROM:  (If I had my choice, I would suggest the DATE: too just to be
consistent with RFC 2822 minimum requirements).

However, I say this from a Domain Signature Authorization point of view
which as you know, I am a strong advocate of.  It can be "adjustable" if the
domain policy says its ok.   But  I believe this will complicate policy
concepts so I vote for a minimum requirement.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Jul 2006 18:00:58 -0400

On Thursday 13 July 2006 17:17, Hector Santos wrote:
> which as you know, I am a strong advocate of.  It can be "adjustable" if
> the domain policy says its ok.   But  I believe this will complicate policy
I think that a requirement to sign RFC 2822 required identity header fields 
(From and Sender if present) makes a lot of sense.  I expect that if we don't 
make this a requirement in Base, then in operations, receivers will pay 
little attention to signatures that don't include them.  So, if we fail to 
include that requirement, I think we are doing people a dis-service.

I am (no surprise) against any requirement to sign resent-*.  They aren't 
identity fields in the same way that From and Sender are.

Scott K

---

From: <[email-masked]>
Date: Thu, 13 Jul 2006 18:05:21 -0400

With no headers at all being signed, a signature should still be either
valid or invalid and therefore still useful. Don't NEED headers for
base.
Thanks,
Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, July 13, 2006 5:05 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Issue: which headers should we REQUIRE to be
signed?

I agree.

any with "MUST".

What say you?

Barry

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2006 18:09:13 -0400

Scott Kitterman wrote:
> little attention to signatures that don't include them.  

The critical language in your note is "I expect that".  THe entire point about
distinguishing mechanism from policy is that the latter is subject to learning
and preference.  Although your expectation might be right, it might not.  Either
way, it does not affect the technical mechanism for creating a signature and
validating it.

What it DOES affect is the UTILITY of that signature.  But lots of things affect
that utility.  That's the stuff of policy work.

d/
-- 

  Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Jul 2006 18:16:37 -0400

On Thursday 13 July 2006 18:09, Dave Crocker wrote:
> Scott Kitterman wrote:
> > I think that a requirement to sign RFC 2822 required identity header
> > fields (From and Sender if present) makes a lot of sense.  I expect that
> > if we don't make this a requirement in Base, then in operations,
> > receivers will pay little attention to signatures that don't include
> > them.
>
> The critical language in your note is "I expect that".  THe entire point
> about distinguishing mechanism from policy is that the latter is subject to
> learning and preference.  Although your expectation might be right, it
> might not.  Either way, it does not affect the technical mechanism for
> creating a signature and validating it.
>
> What it DOES affect is the UTILITY of that signature.  But lots of things
> affect that utility.  That's the stuff of policy work.
>
I think Sender is arguable and I don't care much either way.

Since From is mandated by RFC 822/2822 then I think a MUST sign since it MUST 
be present is entirely appropriate independent of any policy work.  It's a 
mandatory part of the message body.

Is there some benifit to be derived from not signing From?

Scott K

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jul 2006 18:32:03 -0400

With h=;, you don't need to sign the header. And with l=0, you don't
need the body either. But I'm not convinced that either one would be a
good thing to do.

	Tony Hansen
	[email-masked]

---

From: <[email-masked]>
Date: Thu, 13 Jul 2006 18:49:22 -0400

Good? Probably not, useful, not really but that is a policy thingee.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tony Hansen
Sent: Thursday, July 13, 2006 6:32 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Issue: which headers should we REQUIRE to be
signed?

	Tony Hansen
	[email-masked]

---

From: wayne <[email-masked]>
Date: Thu, 13 Jul 2006 18:40:07 -0500

> signs the message, those headers MUST be treated in the same category as

I realize that Eric has proposed dropping these headers, but...

RFC2822 directly talks about adding Resent-* headers and forwarding:

   Note: Reintroducing a message into the transport system and using
   resent fields is a different operation from "forwarding".
   "Forwarding" has two meanings: One sense of forwarding is that a mail
   reading program can be told by a user to forward a copy of a message
   to another person, making the forwarded message the body of the new
   message.  A forwarded message in this sense does not appear to have
   come from the original sender, but is an entirely new message from
   the forwarder of the message.  On the other hand, forwarding is also
   used to mean when a mail transport program gets a message and
   forwards it on to a different destination for final delivery.  Resent
   header fields are not intended for use with either type of
   forwarding.

Please note the last sentence:  the Resent-* headers are not intended
for use with forwarding.

This isn't a SHOULD NOT or a MUST NOT, but don't see how "the specs"
expect Resent-* headers to be added during forwarding. 

-wayne

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 20:00:03 -0400

--On July 13, 2006 6:40:07 PM -0500 wayne <[email-masked]> wrote:

> "Forwarding" has two meanings: One sense of forwarding is that a
> mail reading program can be told by a user to forward a copy of a
> message to another person, making the forwarded message the body of
> the new message.  A forwarded message in this sense does not appear
> to have come from the original sender, but is an entirely new
> message from the forwarder of the message.  On the other hand,
> forwarding is also used to mean when a mail transport program gets
> a message and forwards it on to a different destination for final
> delivery.  Resent header fields are not intended for use with
> either type of forwarding.
>
> Please note the last sentence:  the Resent-* headers are not
> intended for use with forwarding.

The second kind of forwarding is not referring to Resending a 
message, it is referring to user forwarding, for example sendmail 
.forward files.  Note that in the second case the message never 
leaves the transport system (and thus the never ever directly acts on 
it).  Neither of those use or should use Resent.

eric

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Jul 2006 11:37:41 -0400

Scott K

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 13 Jul 2006 08:03:43 -0700 (PDT)

On Thu, 13 Jul 2006, Sandy Wills wrote:

>   Assume that this "new system" you are creating is to be used by people 
> with current MUAs.  Every MUA I am familiar with (the MS series and the 
> Netscape/Mozilla series) does the same thing when your "Person B decides to 
> resend": they create a new message, allowing B to put whatever he/she/it 
> wants to put in it, and appends the original message (optionally allowing B 
> to add, subtract, fold, spindle, and mutilate the original content).
>   This is not a transparent retransmittal of the original message from A as 
> an MTA would do.  Anyone who views this message from B has no way of 
> determining what, if any, modifications B has made to the original content.

Resent- are special form of MUA message forwarding (which you might not be
familiar with if you use only Windows MUAs). In that case new message is
indeed transmitted as you describe but this new message includes in its
entirety the original message with no modifications. New message's subject,
To, From, Date are not encoded as normal message header fields but instead
added to the top (assuming RFC2822 compliance here) as Resent-From,
Resent-To, Resent-Subject, Resent-Date and Resent-Message-ID.

Compliant software is generally expected to treat this as new message and
use new "Resent-" fields in place where it would normally have looked at
From, To, Message-ID. Of course not every mail software is fully compliant
with this (to say the least...).

Now the problem for automated signatures as I see it is that original
message may have come without one but was by a user forwarded (with
Resent- semantics) and this time an MTA on the side of user who did
forwarding ads a signature with domain equivalent to the one added
into Resent-From. If you consider Resent-From to be equivalent to
>From then the verifying side should just say that it is a valid
signature for the user who created the message in its last iteration.
However this opens up a whole where a 3rd party can get away with
becoming a 1st party by just adding Resent fields for new message
(but not for forwarding message and instead for newly created message).

Another scenario is for email message that has both From and Resent-From
but has no signature at all. Sine last party that sent the messge is
the one listed in Resent-From, the SSP check would have to be done
against that if you consider Resent-From to be equivalent to From
as Eric Allman basicly was implying (btw - another issue to consider
is that both From and Resent-From can have multiple addresses).

You need to decide how to deal with these situations and use of
Resent- fields in general and be careful to try to avoid breaking
existing functionality. And either way you go I suspect Resent- case
will have to be specifically mentioned in the documents you produce.

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 17:05:32 -0400

Scott,

Two observations:

First, the point of "MUST NOT be used in the normal processing of 
replies or other such automatic actions on messages" hinges on a 
couple of words, notably "normal" and "such".  I believe the intent 
here was to say that replies should not be directed to addresses in 
Resent header fields, "and other such automatic actions."  In 
particular, for Resent-* to work properly, an MUA must not reply to 
the Resent-* addresses, ever.  Replies are pretty normal.  On the 
other hand, I don't think that looking at who was the person who 
actually sent you this message to make a decision on whether you want 
to read it is the type of automatic action that the authors had in 
mind.

Second, I've proposed dropping all such requirements, which if 
approved will make this thread irrelevant.  I would rather have you 
take the time to reply to that thread than spend the energy arguing 
about whether the PRA algorithm is in some way related to DKIM.

eric