Subject: [ietf-dkim] New Issue: Problems with Scenario 4: Resent

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Sep 2006 19:45:23 -0700

Usage scenario #4 describes a requirement pertaining to "resent" mail,
but does not define exactly what resent means.

Is this simply mail that goes through MTA relaying, mail that is 
redirected via an MTA address alias, mail that is redirected by a 
recipient alias, mail that is re-posted such as by a mailing list, or what?

Text in the rest of the opening paragraph appears to intend resent to 
mean mail that is re-posted, that is, fully delivered to its initial 
addressee and then submitted again by the receiving user agent.  There 
are a number of scenarios that re-post mail, including the user-level 
"forward" command.  As such, the scenario, here, should describe 
precisely which specific scenario it means.

More generally, I cannot quite tell what this scenario is trying to 
demonstrate.  As nearly as I can tell, all of the discussion about 
signing by Alice is irrelevant, since the later focus seems to be on 
signing by the re-poster, Bob.

At any rate, the language "a published practice of signing all messages 
sent from Alice's domain to Bob's mailing list" seems to suggest 
publishing per-recipient practices.  I suspect that's not what was intended.

Possible alternate language:

      For example, Alice sends a message to Bob.  Alice's rfc2822.From
      field domain is used to sign the message and that domain publishes
      a statement that all mail with that domain in the From field is
      signed.

Lastly, the statement

      "Bob merely wants to assert his part in the chain of accountability
      for the benefit of the ultimate receivers. It would be useful for
      this practice to be encouraged as it gives a more accurate view of
      who handled the message"

implies that a long string of signatures by every node that handled the 
message would be a good idea.

Does the working group really believe that?  I suspect there are some 
serious performance impact issues, here.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 21 Sep 2006 08:41:27 +0200

Dave Crocker wrote:

> or what?

It's about mail with one or more Resent-From or Resent-Sender
header fields as far as I'm concerned.

> all of the discussion about signing by Alice is irrelevant,
> since the later focus seems to be on signing by the
> re-poster, Bob.

Whatever SSP does (and the more interesting case is a "Bob" who
is completely DKIM-unaware), the mail should not be rejected
by the next receiver(s) no matter what Alice's SSP says.  Bob
is perfectly entitled to resend a mail he got using the header
fields specified in STD 11 or 2822.

Where "reject" is of course the least problematic outcome, but
"annotate as suspicious", the weasel words for "delete", would
be wrong.

Frank

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 09:53:43 -0700

>"annotate as suspicious", the weasel words for "delete", would
I agree, and I'd appreciate some help on how to make this clear. The
corresponding requirement is actually in the form of a negative in
requirement #12.

Maybe I just need some forward references in the scenarios to the
fundamental corresponding requirements?

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Sep 2006 10:10:26 -0700

> fundamental corresponding requirements?

This line of discusses re-enters the model in which we believe the 
sender is telling the receiver how to process in-coming mail.  That is, 
essentially, intruding on the SMTP specification and the rather wide 
range of individual receive-side operational policies.

I (again) suggest that we do not want to do that.

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 10:18:11 -0700

Dave Crocker wrote:

> sender is telling the receiver how to process in-coming mail.  That 
> is, essentially, intruding on the SMTP specification and the rather 
> wide range of individual receive-side operational policies.
>

I'm pretty sure I'm not doing that. Requirement #12 sez:

12.  Given the considerations in scenario 4, the protocol MUST NOT
        provide a mechanism which impugns the mere existence of third
        party signatures in a message.  A corollary of this requirement
        is that the protocol MUST NOT in any way tie practices of first
        party signers with third party signers.

           [INFORMATIVE NOTE: the main thrust of this requirement is
           that practices should only be published for that which the
           publisher has control, and should not restate what is
           ultimately the local policy of the receiver.]

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Sep 2006 10:25:19 -0700

Michael Thomas wrote:
>>>> by the next receiver(s) ...

>        party signers with third party signers.

I do not see how this language pertains to directives about rejecting or 
not rejecting a message.  That is, I think there is confusion about 
dictating the processing of a signature with the acceptance or rejection 
of a message.

The former is within our purview.  The latter is not.

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 10:39:31 -0700

Dave Crocker wrote:

> I do not see how this language pertains to directives about rejecting 
> or not rejecting a message.  That is, I think there is confusion about 
> dictating the processing of a signature with the acceptance or 
> rejection of a message.
>

Dave, I'm completely confused. The constraint of requirement 12 is a 
constraint on
the protocol design in the form of "don't provide this". It's not 
telling the receiver to do
anything.

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 22 Sep 2006 10:21:43 -0700

>>>>>> Whatever SSP does (and the more interesting case is a "Bob"
>>>>>> who is completely DKIM-unaware), the mail should not be 
>>>>>> rejected by the next receiver(s) ...
> 
> constraint on the protocol design in the form of "don't provide 
> this". It's not telling the receiver to do anything.

Definitely a good distinction to make clear.

Unfortunately, I do not see how the language "the mail should not be
rejected" is a constraint on protocol design, only.  It strikes me as an
explicit directive to an operational receiver.

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 22 Sep 2006 13:31:21 -0700

Dave Crocker wrote:

>>>>>>> who is completely DKIM-unaware), the mail should not be rejected 

I'm fairly certain that we're in violent agreement here, with the likely
confusion being in Frank's phrasing ("should not be rejected" was his
words, not the draft's). The draft definetely doesn't phrase this in terms
of the receiver doing anything. Indeed, the draft's requirement here was
intended to reinforce that the protocol is an information service, not a
"Dear Abby" advice line.

       Mike