Subject: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)

From: "J.D. Falk" <[email-masked]>
Date: Wed, 10 Jun 2009 08:00:12 +0200

Charles Lindsey wrote:

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

Feel free to use my article on CircleID as a starting point:

http://www.circleid.com/posts/dkim_for_discussion_lists/

It's so simple and obvious (once you move from theory to practice) that I'm 
not sure if it's worth the WG's time.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 10 Jun 2009 09:58:45 -0700

> not sure if it's worth the WG's time.

There is *NO* *REASON* to strip signatures. NONE.

In fact it is HARMFUL.

	Mike

---

From: hector <[email-masked]>
Date: Wed, 10 Jun 2009 14:12:44 -0400

+1

It seems  to defeat the purpose and the chain of trust concept, although 
I can see why some believe the chain of trust is preserved for a list 
system - their own.

---

---

From: Doug Otis <[email-masked]>
Date: Wed, 10 Jun 2009 11:47:54 -0700

On Jun 10, 2009, at 9:58 AM, Michael Thomas wrote:

> J.D. Falk wrote:
>> Charles Lindsey wrote:
>>
>>> 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.
>>

This is true for mailing lists when signature recovery is employed. :^)

In addition, acceptance of indirect A-R records should be handled with  
caution.   Keep in mind that A-R headers themselves are not secure,  
and that trust in "authserv-id" (that recipients may have been asked  
to enter into their MUA to enable annotations) need to have originated  
from their specific trust environment.  Unlike the d= parameter in  
DKIM, administrators of trust environments can assign an arbitrary and  
hopefully unique "authserv-id".  Imagine the fun and mischief this ad- 
hoc assignment permits, especially when identifiers have been  
encoded.  There are no A-R "authserv-id" police, nor is there a means  
to confirm legitimate use of "authserv-id" indirectly.  As such, the  
scope of specific "authserv-ids" should be restricted to the immediate  
receiving account.  To offer improved security,  non-local "authserv- 
id" A-R headers for the account should be removed or defanged to  
inhibit acceptance of possibly deceptive A-R headers.  It is common  
for filtering rules to move messages into folders shared by accounts,  
nor is there assurance that A-R headers have not been reordered when  
multiple A-R headers are discovered.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 10 Jun 2009 12:01:17 -0700

Doug Otis wrote:
>>>> should handle DKIM, and I think that is something that this WG needs 
>>>> to take on board.
>>>

No, it's harmful PERIOD.

	Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Jun 2009 01:59:30 -0700

> multiple A-R headers are discovered.

This still seems blatantly off-topic to me (not to mention already being adequately discussed in RFC5451).

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Jun 2009 11:10:53 +0200

Murray S. Kucherawy wrote:
> This still seems blatantly off-topic to me 

+1

-- 

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

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 11 Jun 2009 13:41:10 +0200

> There is *NO* *REASON* to strip signatures. NONE.

You are clearly *VERY* *PASSIONATE* about this, but would you care to share 
the logic you used to come to this conclusion?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 11 Jun 2009 07:34:19 -0700

> the logic you used to come to this conclusion?

Well for starters, RFC4871 section 3.5:

    The DKIM-Signature header field SHOULD be treated as though it were a
    trace header field as defined in Section 3.6 of [RFC2822], and hence
    SHOULD NOT be reordered and SHOULD be prepended to the message.

And from RFC2822 section 3.6:

    More importantly, the trace header fields and resent
    header fields MUST NOT be reordered, and SHOULD be kept in blocks
    prepended to the message.  See sections 3.6.6 and 3.6.7 for more
    information.

And then RFC4871 section 4.2 goes on to say:

    Verifiers SHOULD ignore failed signatures as though they were not
    present in the message.

So the better question is why you choose to violate the SHOULD's of
rfc4871 and rfc2822? SHOULD does not mean, "if I don't feel like it".

		Mike

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 12 Jun 2009 12:47:35 +0100

> And then RFC4871 section 4.2 goes on to say:

In general +1 to all that, though I am not as passionate as Michael, and  
can accept that hopelessly broken signatures _might_ occasionally be  
removed.

But by and large, I do not want to prevent Forensics.

-- 
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: hector <[email-masked]>
Date: Fri, 12 Jun 2009 10:50:02 -0400

> But by and large, I do not want to prevent Forensics.
Whats odd about all this is that it perpetuates the key differences in 
understanding the purpose of DKIM.  If its for a  domain to assert a 
responsibility for the message, then based on these discussions it is 
only up to a point or the next hop where that responsibility is 
downgraded or rescinded.  As the next hop, be it a relay or list server, 
could take over the responsibility, the chain of trust is presumed 
here.  Hop to Hop, Point to Point, relay to relay, finally the the MDA 
and the user.  This is an fundamental idea that allowed internet email 
and the delivery system to work, but there was never a presumption that 
middle ware will be altering the originality of the mail.   Passthru 
mail was fundamentally sacred and this was covered by US laws to be 
frank.  It's been challenged over the years, but there is still a taboo 
to mess around with it.  List Servers were the exception for the most 
part and  that was covering tagging the subject, adding footers or some 
HTML framing, etc,  all making it much harder for new mail integrity 
technology.

But overall, I hope everyone agrees that  a message MUST begin its 
adventure through its "mail-verse" travels with sound integrity. i.e. it 
can not begin broken.  The first hop must take action and minimize 
initial failures propagating through the net especially where there is 
auto-correction involved. So if the chain of trust is going to be 
presumed to be reliable concept, then the question I have is what 
happens at the first moment it is broken?    Are we too expect the List 
Server to drop incoming invalid DKIM messages to auto correct it and 
redistribute?  If there is going to be an stripping and replacement 
concept,  should only strip successful signatures, not failures?

I never liked any software or idea that screwed around with headers.  It 
was always problematic one way or another, if not for you, maybe for 
others, the downlinks.  I don't see how DKIM can control perfection here.

So in that vain, I'm with Michael 100%, it brings nothing but trouble 
and I consider it more harmful, then not to be screwing around headers 
you didn't create or own.

--

---

From: Douglas Otis <[email-masked]>
Date: Fri, 12 Jun 2009 11:27:02 -0700

On Jun 12, 2009, at 4:47 AM, Charles Lindsey wrote:

> In general +1 to all that, though I am not as passionate as Michael,  
> and can accept that hopelessly broken signatures _might_  
> occasionally be  removed.
>

Agreed.  This concern has was muddled by J.D's suggestion that second- 
hand RFC5451 A-R headers can be used in lieu of DKIM signature  
validation (and even that DKIM signatures could be removed).   Some  
cautionary advice for this is needed.  Mike is right to express concern.

One the fundamental problems would be in respect to not knowing what  
"authserv-ids" are trusted by recipients, and email from different  
sources might be commingled.

To ensure that reliance upon the suggested A-R alternative to valid  
DKIM signatures does not become an easy avenue for exploitation, A-R  
headers should be removed or defanged whenever second-hand  
originations would be in doubt based the message content.  This goes  
beyond just first-party trust environments removing obvious "authserv- 
ids" conflicts.  Inhibiting exploitation requires A-R removal to  
include those headers not confirmed by valid DKIM signatures.

Until A-R filtering become universally adopted and there is consensus  
about header encoding/decoding handling, acceptance of second-hand A-R  
headers should be conditioned upon being contained within a valid and  
trusted DKIM signature, or matching with the immediate trust  
environment.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Sat, 13 Jun 2009 14:46:20 +0200

> HTML framing, etc,  all making it much harder for new mail integrity

Very good point; thanks for discerning the difference.  At its core, I 
think, this is the all-too-common battle between the Platonic Ideal of Email 
and the reality.

In this reality, intermediaries change messages.  Sounds like a few folks on 
this list don't want messages to undergo drastic changes when passing 
through intermediaries, and thus are arguing against any attempt to use DKIM 
to "legitimize" what they view, Quixotically, as illegitimate behavior.  But 
DKIM /will/ be applied in situations where intermediaries change messages, 
because that is a reality of email today.

I'd agree that it's necessary to tilt at a few windmills from time to time 
as a reminder of what the collective ideals might once have been, but this 
particular windmill was rebuilt as a pea soup restaurant decades ago.

---

From: SM <[email-masked]>
Date: Sat, 13 Jun 2009 08:39:22 -0700

>because that is a reality of email today.

There were more than a few people who actually argued for messages 
not to be changed.  If that wasn't done, it would not have been 
worthwhile to deploy DKIM as the amount of "bad" signatures was too 
large compared to "good" signatures.  There's also the case of list 
expanders.  A very large amount of messages generated by sites using 
a particular list expander invalidated DKIM signatures due to 
"webvertized" content injected as footers and some other 
modifications to the message.  This was well before this mailing list 
was DKIM signing its messages.  The problem has not been solved yet 
but it was mitigated by the removal of the DKIM signature header.

For those of you criticizing the owner of this mailing list for the 
"rsa-sha1", I'll point out that there are some operational 
considerations for that.  If it wasn't for SHA1, there would be even 
less people using DKIM.  That doesn't mean that we should encourage 
the use of SHA1.

The people who use DKIM won't even read RFC 4871.  FWIW, it wasn't 
even published when some of the trade-offs were made.  The bottom 
line is that the effort was to figure out how to make the 
specifications work out for us and for the users who are not 
subscribed to this mailing list.

Coming back to the subject of list expanders, I'll skip the A-R angle 
as there are other venues to talk about it.  The question is whether 
to consider the author's signature, the mailing list signature or 
both.  Sometimes you know the author and you'll choose to pass the 
message through.  But if you rely on that alone, then you are only 
doing selective "acceptance" of the mailing list traffic which goes 
against how a mailing list operates.  There's a well-known mailing 
list that suffers from a spam problem.  If the messages are accepted 
based on the mailing list signature alone (that mailing list is not 
using DKIM at the moment), you are allowing spam into your mailbox.

Regards,
-sm

---

From: Michael Thomas <[email-masked]>
Date: Sat, 13 Jun 2009 05:16:04 -0700

> because that is a reality of email today.

   Asking people to not violate rfc 2822 and 4871 is not asking for 
much. It hurts
   nothing to leave trace headers in the message. Nobody's asking that 
intermediaries
   cease doing what they do today. That's a strawman.

   You still haven't addressed my message citing the relevant rfc's on 
why what you're
   suggesting is wrong after asking me directly.

       Mike

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 13 Jun 2009 19:51:07 +0100

> using DKIM at the moment), you are allowing spam into your mailbox.

And that hs precisely the problem. 99.5% of list expanders are competently  
managed, and the list recipients will usually be quite happy that the list  
manager had taken proper note of any incoming signature, and had not  
allowed any bad stuff onto his list. So recipients will be quite satisfied  
if he signs to say this is a genuine message from the list, even if the  
incoming signature has been broken and/or removed.

But there will be a few lists where this is not the case, such as the one  
SM mentions. I don't know whether the spam on that particular list is  
because the list admin is careless, or whether it is inherent in the  
subject matter of the list. EIther way, it is necessary for recipients to  
be watchful.

Maybe their standard spam filters will filter out the spam (though I doubt  
it). So they may well want to take note of any signature placed there by  
the original sender. It is in the nature of that sort of list that the  
list admin can only sign to say that it came from his list, But if he is  
smart, he can help his members by checking and reporting on any in coming  
signatures he receives (e.g. by inserting A-R headers, and not destroying  
original signatures). That way, the ultimate recipients can be reassured  
even if the policy of the list is (for some good reason, let us assume) to  
forward everything submitted to it.

So recipients who care about it are likely to be looking carefully as  
_both_ signatures.

---

From: SM <[email-masked]>
Date: Sat, 13 Jun 2009 13:51:45 -0700

>subject matter of the list. EIther way, it is necessary for recipients to

There's more than one list admin.  The subject matter is 
technical.  The issue is not whether the list admin is 
careless.  There are a lot of mailing lists administered by part time 
administrators.  If we start playing the blame game, it will work against DKIM.

>forward everything submitted to it.

I don't have any solution to suggest.  DKIM is in its infancy and 
there's still a lot of work to be done.  My message was not meant as 
input about whether A-R headers or other headers are to be removed or 
not.  I prefer to see how the information is being used first.

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 13 Jun 2009 20:55:09 -0000

> There's a well-known mailing list that suffers from a spam problem.
> If the messages are accepted based on the mailing list signature
> alone (that mailing list is not using DKIM at the moment), you are
> allowing spam into your mailbox.

Surely we don't have to rehash the bit about DKIM telling you who's
responsible for the mail, not whether it's spam.

In any event, given a choice between adjusting this list so it passes
spam more transparently, and adjusting it to fix its spam leaks, I
know what I'd do.

R's,
John

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 15 Jun 2009 10:58:14 +0100

On Sat, 13 Jun 2009 21:51:45 +0100, SM <[email-masked]> wrote:

>> subject matter of the list. ...
>

And every list will be diferent, so we need to look at real examples. And  
by a strange coincidence, we have just seen a concrete example on a list  
well-known to all of us. Here it is, including all headers that appear  
relevant, so let us now discuss how the list manager handled this  
particular case, and whether he has left enough evidence for us to work  
out how this evident spam got onto the list, and whether he could have  
done things any differently.

Some observations:
1. The list manager has altered the message beyond what might have been  
rescued by any l= tag.
2. Nevertheless, it would seem that the original message could have been  
recovered sufficiently to check the original signature (had it been  
preserved), without too much difficulty.
3. The X-Greylist headers are "interesting".

-------------------------------------------------------------------------------

......
X-Gradwell-Mailfilter: SpamAssassin hits were DATE_IN_PAST_06_12  
HTML_MESSAGE MIME_QP_LONG_LINE RCVD_IN_DNSWL_MED RDNS_NONE [Mon, 15 Jun  
2009 02:16:59 +0100] [rule id 501 (default-spam)]
......
[69.63.178.182])
	by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n5F195Fr007169
	for <[email-masked]>; Sun, 14 Jun 2009 18:09:11 -0700
Date: Sun, 14 Jun 2009 07:33:27 -0700
To: "[email-masked]" <[email-masked]>
From: Deiva Shanmugam <[email-masked]>
(sbh17.songbird.com [127.0.0.1]); Sun, 14 Jun 2009 18:16:15 -0700 (PDT)
Subject: [ietf-dkim] Check out my photos on Facebook
Reply-To: Deiva Shanmugam <[email-masked]>
Sender: [email-masked]
Content-Length: 000000

--===============1186549750==
Content-Type: multipart/alternative;
	boundary="b1_a684852eaaadffd4fda36b4b4efd1703"

--b1_a684852eaaadffd4fda36b4b4efd1703
Content-Type: text/plain; charset = "UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi [email-masked],

I set up a Facebook profile where I can post my pictures, videos and  
events and I want to add you as a friend so you can see it. First, you  
need to join Facebook! Once you join, you can also create your own profile.

...rest of span snipped............

--b1_a684852eaaadffd4fda36b4b4efd1703
Content-Type: text/html; charset = "UTF-8"
Content-Transfer-Encoding: quoted-printable

...HTML version of spam snipped...

--b1_a684852eaaadffd4fda36b4b4efd1703--

--===============1186549750==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1186549750==--

---

From: hector <[email-masked]>
Date: Mon, 15 Jun 2009 07:38:27 -0400

Charles Lindsey wrote:
> well-known to all of us. 
Yup,  I am going to enjoy reading this thread.:-) 

Speaking as a commercial List Server product manufacturer, its simple:

The only time a list server should resign is when it broke an original 
valid signature for the purpose of restoring the mail integrity of the 
original domain message owner and author with an original DOMAIN intent 
to sign mail.  It should never sign a message that a DOMAIN never 
expected to be sign or knew nothing of it and It should NEVER, EVER, 
NEVER  resign  a broken DKIM message.  

The basic overall problem  is we are trying to make  something  with an 
POLICY framework.  It won't work well, just don't see it.
And the 4871 flaw of promoting  FAILURE to never sign status complicates 
the handling issues.  The only time that FLAW  makes sense  is when you 
have POLICY and since SSP was an integral  part of DKIM,  you can see 
the great logic in the BROKEN=NEVER SIGNED mandate in the specification.

But when don't have POLICY than  that  mandate is FLAWED - period.

You need a policy framework to help disseminate what was expected and 
what was not expected.  You are left with a guessing game - is this 
FACEBOOK message a spam or a message vouched by Dave's server?  Should  
people trust it because Dave's broadcasting server signed  it?  Did the 
message have a valid signature and Dave stripped it or was a invalid and 
he stripped and replaced it anywa?  It speaks volumes to the lack of a 
POLICY based framework.   It should NEVER be a source of new SIGNING 
when it was never there to begin with and/or expected to be there by the 
original domain  - bad guys will no doubt exploit this as you just 
seen.  I thought his FACEBOOK  think was legitimate for a second, that 
someone  here was putting together a DKIM social network.   Can imagine  
the layman user?  Is he not a RISK?

IMO, The list server should NOT sign unless the mail was valid with a 
DKIM signature and its going to break it, thus the need to restore a 
DKIM message - not create one.

--

---

From: hector <[email-masked]>
Date: Mon, 15 Jun 2009 07:46:06 -0400

hector wrote:
> The basic overall problem  is we are trying to make  something  with 
> an POLICY framework.  
FWIW,   that should be  - ... work without a policy framework.

--

---

From: <[email-masked]>
Date: Mon, 15 Jun 2009 07:52:48 -0400

Hmmm, could you send me a copy offlist? It appears that my edge device roundfiled that message
In any case,
I receive mail from an author called [email-masked]. It appears to be a compilation of interesting conversations, some more interesting than others. I am not really concerned about how ietf-dkim gathers information to author these missives. That would only be a concern of the author, not me as a consumer.
Thanks,
Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
Sent: Monday, June 15, 2009 5:58 AM
To: DKIM
Subject: Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)

Some observations:

......

---

From: "MH Michael Hammer \(5304\)" <[email-masked]>
Date: Mon, 15 Jun 2009 12:59:53 -0400

Comments inline

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of hector
> Sent: Monday, June 15, 2009 7:38 AM
> To: Charles Lindsey
> Cc: DKIM
> Subject: Re: [ietf-dkim] list expanders (was Re: chained signatures,
was
> l= summary)
> 
> Charles Lindsey wrote:
> > And every list will be diferent, so we need to look at real
examples.
> And

Me too. Popcorn in hand (figuratively speaking).

> NEVER  resign  a broken DKIM message.

So you are absolutely against 3rd party signatures unless the 3rd party
broke a first party signature?

My understanding has always been that anyone who handles a message can
sign and thereby take responsibility (whatever that might mean) for the
message they are signing.

> The basic overall problem  is we are trying to make  something  with
an
> the great logic in the BROKEN=NEVER SIGNED mandate in the
specification.

I have to disagree Hector. For better or for worse, SSP was never an
integral part of DKIM. It is layered on top of DKIM. Those that wish to
publish a policy (whether it was SSP or ADSP) can do so. Those that wish
to check and act against a published policy may do so. Others may choose
to ignore SSP/ADSP whether as a potential publisher or a potential
verifier. While I am a firm believer in the need for organizations to
have the option of publishing policy, I do not view it as "an integral
part of DKIM". To do so would require one to advocate publishing policy
as "MUST" rather than "SHOULD" or "MAY".

> But when don't have POLICY than  that  mandate is FLAWED - period.

BROKEN=NEVER SIGNED mandate in the specification. If an organization
chooses to assert they sign all messages and BROKEN=NEVER SIGNED then
the logical conclusion is obvious.

> FACEBOOK message a spam or a message vouched by Dave's server?  

It appears to be a spam vouched for by Dave's server. 

>Should
> people trust it because Dave's broadcasting server signed  it?  

What does trust have to do with it? All I know is that Dave's server
signed it and Dave thereby takes responsibility for it. So Dave.....
what does your taking responsibility for it mean?

Did the
> the layman user?  Is he not a RISK?

I'm surprised Hector. It really took you a second to decide it wasn't
legitimate? 

> DKIM message - not create one.

Au contraire. What you describe leaves a vector for attack a mile wide.
Break a signature from the original domain and then sign with some
random domain. You cannot accept one signature as a substitute for
another (broken) signature. Each signer stands on their own merits (or
lack thereof.)

Mike

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 16 Jun 2009 14:24:42 +0100

> done things any differently.

Actually, ignoring the embarassing issue of how the spam got through this
list's defences, and concentrating on the evidence left behind in the
headers, one can note that many things were actually done right.

+1. All the trace headers, including A-R and DKIM-Signature, were left in
place, both by the list manager, and by the subsequent sites that
processed it before it was delivered to me. For sure, other headers
inserted by the list manager (all the List-* for example) were inserted
amongst the headers of the original, but that seems to be quite customary.

+2. The list manager observed a valid DKIM signature on the arriving
message and, knowing he was about to break it, recorded its validity in an
A-R header.

+3. The list manager inserted his own Sender header, as is customary (it
remains unknown whether there was an earlier Sender that was removed).

+4. The list manager DKIM-Signed the message as it left him, which seems
to be the expected practice.

+5 His signature covered the customary "important" headers from the
original message (Date:To:From:Message-ID:MIME-Version:Subject:Reply-To)
(not sure that MIME-Version is really "important", though).

+6. His signature covered (most of) the headers he had added, notably
List-*, Sender and Content-Type (which was changed from the original).

So there remain only two things he did _not_ do, which he might have done:

-7. His signature did NOT cover the A-R he had added (so we have to assume
that it was not an artefact by the spammer, although it most certainly
SHOULD have been removed if it was). So we may well "believe" the list
manager had put it there, but it would be nicer to have had some proof.

-8. The list manager did not retain the original (and now broken) original
signature. Tnere are certainly some on this list who would have preferred
to see it left ("for forensics").

---

From: hector <[email-masked]>
Date: Tue, 16 Jun 2009 16:28:21 -0400

Hi Michael,

MH Michael Hammer (5304) wrote:

 > So you are absolutely against 3rd party signatures unless the
 > 3rd party broke a first party signature?

I have an long ethical engineering problem with designing and dealing 
with any mail mover software that alters and/or the original intent of a 
message.  The 1986 US EPCA provisions help model the guidelines for 
hosting systems.  Keep in mind my view point is purely based on security 
and technical consistency and the expectations of the message 
author/owner.  If the intent of the originating author and copy right 
holder of the message was mail integrity and not necessarily message 
owner authenticity, then I see less of a concern with a 3rd party (relay 
or hop) changing the intent and final status as long as its persistent 
and consistent.  The chain of trust applies.  

But if the intent of the originating author was both mail integrity and 
authenticity, then I see a really high potential for security and 
technical problems when there is no  "Helper" involve to assist the 3rd 
party and it just blindly alters the mail.

Assuming the status quo and direction of DKIM-BASE sans policy,  I see a 
less security  problem when the original mail  was signed and valid and 
because of the inherent nature (BCP) of list servers today to alter the 
messaging layer (presentation),  it  keeps the integrity of the altered 
message intent intact  by resigning.   I see problems when the 3rd party 
signs non-signed original mail when policy is still in the mind of this 
project.  If policy was completely out of the picture, then DKIM becomes:

     A system and core protocol allowing a MTA domain (domain) take 
responsibility for the
     transportation of a message to the next  MTA (Hop) .

The model is less focus on the Original Domain expectations for the 
authenticity of the transport.  The facebookemail.com post is a prime 
example of the situation with blind list server or middle ware signings.

> message they are signing.

Although this mindset has prevailed, it was not always like that Mike.  
If it was the primary focus (i.e. policy was never a consideration and 
out of the picture), then I believe we would long finished this project 
.   In the same vain, if people respected the charter out of scope 
guideline for reputation, then possible Policy would of been resolved 
and project over long again. :)

> I have to disagree Hector. For better or for worse, SSP was never
> an integral part of DKIM. It is layered on top of DKIM. 

It was what sold us to even get involve.  All original marketing and 
presentations had SSP as a integral part of the framework.  It was part 
of the charter and and DKIM/SSP original specs was ONE document 
(following Yahoo's Domainkeys specifications) before it was split.

legitimate?

Is 1 second good or bad? I did hit 1/2 century mark this year so I am 
bit slower. :-)

No honestly, I wondered there for a moment if this was a new WG 
participant organizing a wiki/social network DKIM resource.  I just came 
back from a NYC trip visiting daughter and attending Yankees/Mets game, 
and all I heard this weekend was FACEBOOK this, FACEBOOK that. :-)     
So I wondered if this was an spambot and if so, why wasn't it trapped 
with the list subscription confirmation process.

--

---

From: "MH Michael Hammer \(5304\)" <[email-masked]>
Date: Tue, 16 Jun 2009 17:08:51 -0400

Comments inline.

> From: HLS [mailto:[email-masked]] On Behalf Of hector
> Sent: Tuesday, June 16, 2009 4:28 PM
> To: MH Michael Hammer (5304)
> Cc: DKIM
was
> and consistent.  The chain of trust applies.

How does a 3rd party signing a message change the intent of the author
of a message? One might argue that breaking the original signature does
that. My response would be to then avoid breaking the original
signature.

One of the arguments put forward supporting the DKIM effort was that
unlike SPF it is not hop dependent. 

> party and it just blindly alters the mail.

Blindly altering things is generally not a good idea in most
circumstances. I'mnot sure where a "helper" comes into play here.

> example of the situation with blind list server or middle ware
signings.

Daves server signed the message. As I pointed out in my original post,
this implies some level of responsibility for the message. We still
don't know what that means let alone what we should infer in terms of
reputation (for those who want to go there).

> and project over long again. :)

I figure that getting senders signing (or signers signing) and receivers
validating will allow the whole reputation issue to be resolved. The
water is great, jump right in.

> (following Yahoo's Domainkeys specifications) before it was split.

I'll admit that SSP has been one of the selling points but as far as I
recollect it has always been represented as something being layered on
top of DKIM and not a core requirement for someone choosing to sign some
(or all) of their messages. Don't get me wrong, I am a strong believer
in the value of SSP/ADSP and believe that once some real implementations
get out in the wild where receivers are validating and respecting ALL or
discardable assertions, life will get interesting.

> Is 1 second good or bad? I did hit 1/2 century mark this year so I am

But wiser?

> with the list subscription confirmation process.

My hunch is that it was probably an addressbook harvest type scenario.
Various of these social networks offer (insist?/annoy?) users allow them
to harvest email addresses from the users mail so as to allow others the
delight of interacting through the social network. I'm not picking on
Facebook in this respect as it is a fairly common practice.

Mike

---

From: SM <[email-masked]>
Date: Tue, 16 Jun 2009 15:05:33 -0700

Hi Charles,
>headers, one can note that many things were actually done right.

There were similar messages (not the same author) to other mailing lists.

>(not sure that MIME-Version is really "important", though).

If there are any rendering flaws at the receiving end, it might 
become important.

>manager had put it there, but it would be nicer to have had some proof.

At a guess, I'd say that the list manager did not put that header there.

Regards,
-sm

---

From: hector <[email-masked]>
Date: Wed, 17 Jun 2009 03:25:57 -0400

> that. My response would be to then avoid breaking the original

But list servers will naturally do break the message, dkim signed or 
not. no?

I want to minimize issues when adding DKIM considerations to our list 
server - not create more issues.  Today, there is a common practice 
with MLS altering one, all or more of the following:

    - Optional Subject List Name Tags, i.e. [ietf-dkim] subject

    - Reply-To: change to accommodate the current UI of most
      RFC based mail readers with its default button/menu logic:

        [ Reply ]          - Uses Reply-To or From:
        [ Reply to All ]   - Uses all Originator fields
                             To:, Cc: Reply-To

      Some MLS (like ours) will offer a list option to change
      the Reply-To so that the natural behavior of a user clicking
      Reply will go back to the list and not a direct email to
      the author of the message.

    - footers and (headers), with the footers the most common

    - Stripping based on content restrictions (no attachments,
      no html content-types), etc.

The question becomes under what conditions should a MLS-based DKIM
signing take place to eliminate downlinks DKIM verification issues,
including damages to domain reputation.

The only thing I can see if to remove all original domain 
considerations. With no Policy, author domains are less important.

> unlike SPF it is not hop dependent. 

True, but SPF does have RFC 4405 (SUBMITTER) to help address hop 
transition Domain::IP association issues.

For DKIM, the irony is that it might have similar issues from the 
standpoint of the route path and who was last (re)signed.

   MUA -> | MSA/MTA/SIGNS | -> MTA/BREAKS

                               ROUTE #1 -> MTA/RESIGNS -> MTA -> MDA
                               ROUTE #2 -> MTA -> MDA

We had a support incident last year where the MTA took one of two
routes (for some reason).  Depending on the route, a Date was
added to the original message (because it was missing), the other
did not. When the messages reached the customers server (our product),
the customer was complaining about different mail reader display dates.

This proves its possible that is a DKIM ignorants MTAs can have two or 
more different routes for distribution.  So just like SPF, depending 
on the route it takes, things can break.  Does the new MTAs now need 
to learn to use a special route for DKIM messages only? One with 
minimum hops?

Here's an idea:

Can receivers help the process by adding a special MX record 
specifically for DKIM reception to help MTA take a direct path? Maybe 
special by sub-domain? mx1-dkim-receptor.domain.com

I guess the overall issue is why should any MTA, including a list 
server auto-correct a broken message and it is safer to only consider 
resigning when it going to break a valid dkim message?

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 17 Jun 2009 11:00:05 +0100

> At a guess, I'd say that the list manager did not put that header there.

As a matter of interest, could you say why?

AFAICS, this spam actually came from a sleeping member of this list who  
was trying to drum up friends on Facebook, and inadvertently sent it to  
everyone in his address book, including this list (observe the 'whitelist'  
remarks in the X-Greylist header). Indeed, he subsequently apologised on  
this list for his error, and the headers on his apology are exactly  
analagous to those on the spam.

Moreover, if this A-R header HAD been present in the original, it SHOULD  
have been removed by the list manager, according to RFC 5451.

---

From: hector <[email-masked]>
Date: Wed, 17 Jun 2009 07:53:25 -0400

> manager had put it there, but it would be nicer to have had some proof.

+1, I think it makes sense to bind the A-R recording of a stripped 
original signature.

> to see it left ("for forensics").

Or changed to X-DKIM-Signature and bind this also in  the new signature.

---

From: SM <[email-masked]>
Date: Wed, 17 Jun 2009 10:03:46 -0700

>As a matter of interest, could you say why?

Because it's unlikely that Mailman was doing the DKIM 
verification.  I tested Mailman to see how it affected DKIM signatures.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Wed, 17 Jun 2009 10:03:46 -0700

Regards,
-sm

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 19 Jun 2009 12:29:21 +0100

> verification.  I tested Mailman to see how it affected DKIM signatures.

Ah! My use of the term "List Admin" was intended to include the activities
of all the servers etc through which the message passed at that site.

I agree that the A-R was probably added before mailman saw the message,
but it was probably mailman that removed the original (now broken)
signature.

But either way, there is no suspicion that the A-R was added by the
spammer, or any other agent prior to the ML site, so no reason to doubt
the truth of what it attested (except for Conspiracy Theorists who doubt
everything - and the best way to placate Conspiracy Theorists is to give
them the evidence that proves their vivid imaginations are wrong - in this
case by signing the A-R header).

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 19 Jun 2009 12:29:53 +0100

> +1, I think it makes sense to bind the A-R recording of a stripped

+1 to that. It is what I have been saying all along.

> Or changed to X-DKIM-Signature and bind this also in  the new signature.

And +1 to that. It prevents subsequent verifiers from worrying about that
signature any more, but retains the opportunity for Sleuths, Conspiracy
Theorist or just the Plain Curious to work out what had gone wrong, and
possibly even to try to verify that signature by reversing the changes
which had broken it.

But all this tends to cnfirm my view that we need some BCP document to
encourage Mailing Lists to behave in some consistent way.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Jun 2009 09:55:57 -0700

On Jun 19, 2009, at 4:29 AM, Charles Lindsey wrote:

> Ah! My use of the term "List Admin" was intended to include the  
> activities of all the servers etc through which the message passed  
> at that site.
>
> I agree that the A-R was probably added before mailman saw the  
> message, but it was probably mailman that removed the original (now  
> broken) signature.
>
> spammer, or any other agent prior to the ML site, so no reason to  
> doubt the truth of what it attested (except for Conspiracy Theorists  
> who doubt everything - and the best way to placate Conspiracy  
> Theorists is to give them the evidence that proves their vivid  
> imaginations are wrong - in this case by signing the A-R header).

It dangerous to consider A-R headers of unknown origins as somehow  
inherently safe.  After all, it is also unknown what "authserv-id"  
recipients will list usable for annotation.  It would not be hard to  
guess in many cases.  An A-R header from an unknown environment should  
never be assumed to mean there was ever a valid DKIM signature.   
Allowing just any A-R header to be accepted will likely invite rather  
simple strategies for duping victims.

-Doug

---

From: hector <[email-masked]>
Date: Fri, 19 Jun 2009 22:18:18 -0400

Charles Lindsey wrote:

> But all this tends to confirm my view that we need some BCP document to

Yes, DKIM consistency is required for list servers who are "natural 
destroyers" of original mail integrity.

Since POLICY is no longer the emphasis of the WG and won't work well 
with the List server interoperability requirement, and the consensus 
of the group seems to be they don't want it, I have been trying to 
justify a reason how adding DKIM support will not cause problems.

I analyzed the consistent processing DKIM signing requirements and the 
boundary conditions for our list server and produced this summary table:

       Possible List Server Action for DKIM-BASE + Reputation
                    Boundary Conditions
+==================================================================+
| Signed  | Vouched | List Server (Domain Safe?) Action            |
|==================================================================|
| NONE    | NONE    | optional sign, no domain signing presumed    |
| NONE    | YES     | indeterminate state (How is vouch determine?)|
| VALID   | NONE    | resign                                       |
| VALID   | YES     | sign, domain expectations intact             |
| INVALID | NONE    | No sign (don't hide breakage)                |
| INVALID | YES     | Rejected at SMTP receiver                    |
+------------------------------------------------------------------+

You see, we planned on adding receiver verify support first, then add 
signing support until signing was better understood, deemed safe for 
my customers to sign their domains or hosted domains and the DKIM/DNS 
Signing management tools was completed.

By adding verify support first we can at least include it as part our 
existing incoming mail filtering system.  When policy was considered, 
I saw something really useful for many domains, not all but many, if 
not the majority (the larger set of smaller systems, and highly 
exclusive domain organizations not email providers combined).

However, for an integrated list server system such as ours, we are 
forced into a position of how to handle signed list mail that will be 
naturally broken by the list server.  So by supporting DKIM for 
verification, I feel somewhat technically and also ethically obligated 
to require the list server to perform DKIM (re)signing  otherwise 
domains signatures can be harmed.  Either that or hold off on DKIM as 
was done.

About the states above:

RFC 4871 says the invalid signature equals never signed. I have a 
serious problem with that idea and considered it flawed.  The above 
three vouched states, I think, shows the reason for me:

    NONE/VOUCHED       How can this happen when there is no d=?
    VALID/VOUCHED      PERFECT! The golden needle in the haystack!
    INVALID/VOUCHED    REJECT! I hope!

What is the certified signer domain being vouched for? I hope its for 
a valid signature only.  If the certified domain signature is invalid, 
it should rejected (flagged).

But if we can also vouched for a message that had no valid signature, 
then what responsible domain identity do we used?  There is no d= tag. 
There is i= tag.  There is no signature.  Do we fall back to the 
5322.MailForm domain?

So this is a case where INVALID SIGNATURE is not the same as NO SIGNATURE.

Finally, now I see where the deprecated revision 06 DKIM-Overview 
statement which I had suggested to be removed (because reputation was 
not a chartered item) saying:

   2.3.  Filtering

    ...

   Unless a scheme can correlate the DKIM signature with accreditation
   or reputation data, the presence of a DKIM signature SHOULD be
   ignored.

IMO, is now a very important guideline to once again provide.

I don't particularly feel comfortable with supporting a commoditized 
protocol that is only useful when the domain has registered with 
centralized accreditation service, nonetheless whether we do support 
it or not, the guideline should be well noted. Receivers are no longer 
going to be able to depend on chartered Policy framework, hence they 
are going to need "something" and if reputation is going to be it, 
regardless of what the DKIM WG Charter says, then it should be 
highlighted DKIM signed mail is potentially harmless without some 
vouching system associated with the signing domain.

--

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 22 Jun 2009 10:51:30 +0100

> inherently safe......

Inless they are included in a signature.

An A-R record always includes an idication of the domain that purported to  
have place it there. If it is signed by that same domain (as would be the  
case in the scenarios we are discussing), then more reliance can be placed  
on it (depending on your opinion of that signer - but you opinion of the  
manager of a mailing list you have subscribed to is likely to be quite  
high).

I agree that an unsigned A-R is dubious, but even then if it purports to  
have been placed there by a domain which
    a) the message has been passed through, and
    b) you are prepared to trust to have removed any pre-existing bogus A-R
       purporting to have been placed there by that domain
then it should be pretty safe (and this was indeed the case for the  
example we were discussing).

---

From: Douglas Otis <[email-masked]>
Date: Mon, 22 Jun 2009 08:43:39 -0700

On Jun 22, 2009, at 2:51 AM, Charles Lindsey wrote:

> Unless they are included in a signature.

Unverifiable DKIM signatures will not confirm the origin of an A-R  
header.

> An A-R record always includes an idication of the domain that  
> purported to have place it there. If it is signed by that same  
> domain (as would be the case in the scenarios we are discussing),  
> then more reliance can be placed on it (depending on your opinion of  
> that signer - but you opinion of the manager of a mailing list you  
> have subscribed to is likely to be quite high).

There is no assurance that RFC 5451 "authserv-id" have any  
relationship with an RFC 4871 d= values.  There is also no assurance  
that  bogus A-R headers would have been removed.  Amongst  the  
confused advice about retaining A-R headers, there is also not a  
certain practice of not signing A-R headers, even when A-R headers are  
not added.  Do you expect there will be d= requirements imposed upon  
authserv-ids, since that is not how A-R validation works?

> I agree that an unsigned A-R is dubious, but even then if it  
> purports to have been placed there by a domain which
>    b) you are prepared to trust to have removed any pre-existing  
> bogus A-R purporting to have been placed there by that domain

What this would be trusting may not be common practice.  In addition,  
there is no defined relationship between authserv-id and d= values or,  
for that matter, domains in general.

A mailing list might use a signing domain of "foo.tld" and the  
authserv-id of "bar.unique".

By allowing inclusion of A-R headers having unknown origins remains a  
risky practice since a recipient's MUA might trust these headers.

A safe practice would remove all foreign A-R headers.  Exceptions made  
when signed by verified DKIM signatures still requires trusting the  
DKIM signature not to introduce misleading A-R headers.  Again, there  
is no direct relationship between RFC 5451 "authserv-id" and RFC 4871  
d= values.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 29 Jun 2009 18:24:57 -0700

MH Michael Hammer (5304) wrote:
> of a message? One might argue that breaking the original signature does that.
> My response would be to then avoid breaking the original signature.
> 
> One of the arguments put forward supporting the DKIM effort was that unlike
> SPF it is not hop dependent.

A common source of confusion about this is the difference between an MTA Relay 
and a Mailing List Mediator.  A DKIM signature always survives relaying, whereas 
SPF registration cannot any.

Whether a DKIM signature survives the re-submission by a Mediator is a very 
different matter.  "The intent of the author" is something the Mediator might or 
might not choose to pay attention to -- assuming automated software can intuit 
an author's intent -- since Mediators vary quite a lot, including Mailing Lists.

The reality is that after receiving the message, the Mediator owns it and can 
legitimately do whatever it wants.  Or rather, any constraints on its actions 
depend on policies and agreements that are far outside the realm of current 
email protocol standards.

That some Mediators choose to do minimal violence on a message and -- as an 
unintended side-effect -- happen to preserve a DKIM signature is very nice, but 
hardly something that can be legislated (or safely protected assured.)

d/

-- 

   Dave Crocker

---

From: hector <[email-masked]>
Date: Tue, 30 Jun 2009 17:01:42 -0400

> SPF registration cannot any.

Not so, David.

To make the analogy, you need to put both under the same page, same 
mail transport considerations.

First, you are presuming the MTA is a DKIM resigner.  Like wise, SPF 
also has sender MTA rewriter technology and that includes a standard 
protocol as well - RFC 4405 (SUBMITTER SMTP Service Extension).

In other words, SPF can survive a multi-hop route if each MTA supports 
RFC 4405. Like wise, DKIM can ONLY survive the multi-hop route if each 
MTA supports DKIM resigning. Both technologies require middle ware MTA 
support.

So this old marketing benefit does not apply any more.

However, with it comes to a Mailing List Server (MLS), SPF does not 
suffer the problems that DKIM has with a MLS.

> email protocol standards.

IMO, you are minimizing long time telecommunications mail engineering 
considerations, reflected by US laws (and foreign laws based on the US 
model) that help protect user intent and expectations.

Push comes to shove, the question of Mediator ownership is not as 
legitimate as you may think.  It is only has been skewed with a 
renewed direction for centralization (vendor owns the resource). 
However, copyright ownership of author written content is still an 
implicit and natural legal right.  Lost of mail is still a risk a 
responsible mail enterprise can not ignore.

I believe you are advocating a dangerous precedence which will be felt 
when USERS are finally presented with a mixed bag of GOOD VALID 
VOUCHED DKIM MAIL and the many faults left open with this DKIM 
framework - one where the AUTHOR intent has been lost from its 
original basic concept.

--
Hector santos
http://www.santronics.com

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 30 Jun 2009 18:07:25 -0400

On Tue, 30 Jun 2009 17:01:42 -0400 hector <[email-masked]> 
wrote:
> Like wise, SPF 

I know it's OT, but in the interests of correctness, RFC 4405 is tied to 
Microsoft's Sender ID and not at all related to SPF.  Sender Rewriting 
Service/System (SRS) is, I'm pretty sure, what Hector was thinking of.  It 
has never been standardized.

Scott K

---

From: hector <[email-masked]>
Date: Tue, 30 Jun 2009 20:19:45 -0400

> has never been standardized.

Its odd you say this. But lets not mix semantics here and create the 
erroneous idea that SUBMITTER is not related to SPF.

First, RFC4405 is related SPF because SENDERID is the 2822 version of SPF.

The whole purpose of SUBMITTER, which I suggested, promoted and 
instigated during MARID was my repeated concern over and over again in 
the forum and in private emails with MS to address the payload 
overhead associated the 2822 version of SPF - Microsoft SPF version 
called SenderID.  That was my #1 complaint about SenderID and I 
submitted these concerns to the FTC request for comments.

In short, SUBMITTER allows SENDERID to work as a SPF protocol at the 
SMTP LEVEL. It is considered an optimization (the 2822 PAYLOAD is not 
required) as cleared stated is MS marketing and the specification 
security section:

6.  Security Considerations

    This extension provides an optimization to allow an SMTP client
    to identify the responsible submitter of an e-mail message in
    the SMTP protocol, and to enable SMTP servers to perform
    efficient validation of that identity before the message
    contents are transmitted.

The overall problem with SENDERID was its dependency on the payload. 
SUBMITTER helps resolves this problem by keeping the processing at the 
2821 level, in addition, it also helps keep the persistent nature of 
the 2821 return path which was a concern with suggested ideas like SRS.

As stated in 4.2:

4.2.  Processing the SUBMITTER Parameter

    Receivers of e-mail messages sent with the SUBMITTER parameter
    SHOULD select the domain part of the SUBMITTER address value as
    the purported responsible domain of the message, and SHOULD
    perform such tests, including those defined in [SENDER-ID], as
    are deemed necessary to determine whether the connecting SMTP
    client is authorized to transmit e-mail messages on behalf of
    that domain.

    If these tests indicate that the connecting SMTP client is not
    authorized to transmit e-mail messages on behalf of the
    SUBMITTER domain, the receiving SMTP server SHOULD reject
    the message and when rejecting MUST use "550 5.7.1 Submitter
    not allowed."

The operative term here is "connecting SMTP client" and logic to 
reject at the 2821 level.   For the transition to work, the submitter 
domain MUST match that of the client IP.

This is best shown in the examples, in particular

       5.4.  Guest E-Mail Service

where clearly the SUBMITTER is not the Author or PRA but rather the 
Hotel Service, the Responsible Submitter of the email which MUST match 
the connecting IP address according the email.hotel.com SPF record.

--
Hector Santos

---

From: hector <[email-masked]>
Date: Tue, 30 Jun 2009 20:53:34 -0400

One other point Scott, to keep this "On Topic",

Where RFC 4405 described the Responsible Submitter concept, Dave's 
DKIM errata is basically about focusing and describing a
"Responsible Submitter Signer" concept.

In the case of SPF, it is about a broken transition (hop to hop) 
DOMAIN::IP association mismatch and the restoration with SUBMITTER.

In the case of DKIM, it about the possible hop to hop broken mail 
signature integrity and the restoration with DKIM resigning.

So from technical point of view, the same hop to hop protocol support 
requirement is the same. Neither can survive if their basic protected 
information is broken and not restored by compliant MTAs.

hector wrote:

> Scott Kitterman wrote:
> 
>> On Tue, 30 Jun 2009 17:01:42 -0400 hector 
>> <[email-masked]> wrote:
>>> Like wise, SPF also has sender MTA rewriter technology and that 
>>> includes a standard protocol as well - RFC 4405 (SUBMITTER SMTP 
>>> Service Extension).
>>>
>>
>> I know it's OT, but in the interests of correctness, RFC 4405 is tied 
>> to Microsoft's Sender ID and not at all related to SPF.  Sender 
>> Rewriting Service/System (SRS) is, I'm pretty sure, what Hector was 
>> thinking of.  It has never been standardized.
> 
> 
> the forum and in private emails with MS to address the payload overhead 
> associated the 2822 version of SPF - Microsoft SPF version called 
> SenderID.  That was my #1 complaint about SenderID and I submitted these 
> concerns to the FTC request for comments.
> 
> 2821 level, in addition, it also helps keep the persistent nature of the 
> 2821 return path which was a concern with suggested ideas like SRS.
> 
> As stated in 4.2:
> 
> The operative term here is "connecting SMTP client" and logic to reject 
> at the 2821 level.   For the transition to work, the submitter domain 
> MUST match that of the client IP.
>