Discussion:
draft-ietf-dkim-mailinglists-01 review request
(too old to reply)
Murray S. Kucherawy
2010-07-29 11:52:46 UTC
Permalink
The -01 draft was briefly presented in Maastricht. We'd like to get more review of and feedback about it from people with an ideal in mind of starting a WGLC toward the end of September.

Please take some time to review it and provide comments, even if it's just "I've read it, looks good." We need to record even that sort of thing as part of the rough consensus record before advancing.

You MUST NOT [RFC2119] use this thread for debating the technical or political points of ADSP. Please start a different thread for that or any other tangent. It makes the author's job much harder when trying to locate feedback that needs to be applied.

And thanks to Daniel for the quick feedback!

-MSK
Alessandro Vesely
2010-07-30 10:01:16 UTC
Permalink
Post by Murray S. Kucherawy
You MUST NOT [RFC2119] use this thread for debating the technical or political points of ADSP.
Right, also because the document does not dig deeply into ADSP matter.
In particular, I think most of the issues discussed for
"discardable" hold unchanged for "all", and some of them even for TPA.
I would s/"discardable"/non-default/; for example

Furthermore, authors whose ADSP is published as "discardable" are
advised not to send mail to MLMs as it is likely to be rejected by
ADSP-aware recipients.

would become

Furthermore, authors whose domains publish a non-default ADSP
record are advised not to send mail to MLMs as it may be rejected
or dropped for policy reasons by ADSP-aware recipients.

(My tongue cripples on "non-unknown", but then I'm not an English
speaker.)

I have another couple of points, since I'm at it. On 26/Jul/10 14:02,
Post by Murray S. Kucherawy
----- [5.9]
The second paragraph,
Receivers are advised to ignore all unsigned Authentication-Results
header fields.
is obviously formally wrong.
Why?
Because signing isn't but one of the five points that RFC 5451
proposes for recognizing authentic header fields. In particular, an
A-R written by a border MTA upstream of the receiver may be unsigned
yet trusted.

I think the following paragraph --554 replies-- is much better. But
how about grepping /554 .*ADSP/ from the log files? Consider appending
six words like so:

SMTP servers doing so are also advised to use appropriate wording
in the text portion of the reply, possibly using the term "ADSP"
explicitly.


The final suggestion I have is discussable. Hence I send it as a
separate message, according to the spirit of the prohibition quoted
above. "Yet another alternative mailing list approach" may deserve
being mentioned in the I-D, in case the WG find it's worth.
Murray S. Kucherawy
2010-08-01 22:39:25 UTC
Permalink
-----Original Message-----
Sent: Friday, July 30, 2010 3:01 AM
To: Murray S. Kucherawy
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
In particular, I think most of the issues discussed for
"discardable" hold unchanged for "all", and some of them even for TPA.
I would s/"discardable"/non-default/; for example
Furthermore, authors whose ADSP is published as "discardable" are
advised not to send mail to MLMs as it is likely to be rejected by
ADSP-aware recipients.
would become
Furthermore, authors whose domains publish a non-default ADSP
record are advised not to send mail to MLMs as it may be rejected
or dropped for policy reasons by ADSP-aware recipients.
(My tongue cripples on "non-unknown", but then I'm not an English
speaker.)
Any feelings about this from the rest of the working group? We're possibly in a position to make some editorial remarks here about how "all" and "discardable" should be treated differently, at least by MLMs, if we feel that's prudent.

Personally I'm comfortable with the present text. I haven't see anyone that treats "all" and "discardable" the same so the danger is limited; OpenDKIM for example merely flags a failed "all" in the RFC5451 field while "discardable" is subject to being bounced or dropped. But since all of ADSP is at verifier discretion, there's some merit to this idea. The risk of course is the possibility of later extensions to ADSP that might get created, so maybe changing the advice from being specifically about "discardable" to something more general covering any restrictive policy is better.
I have another couple of points, since I'm at it. On 26/Jul/10 14:02,
----- [5.9]
The second paragraph,
Receivers are advised to ignore all unsigned Authentication-Results
header fields.
is obviously formally wrong.
Why?
Because signing isn't but one of the five points that RFC 5451
proposes for recognizing authentic header fields. In particular, an
A-R written by a border MTA upstream of the receiver may be unsigned
yet trusted.
Ah right, so what it should say is "unsigned externally-applied" instead. I agree there.
I think the following paragraph --554 replies-- is much better. But
how about grepping /554 .*ADSP/ from the log files? Consider appending
SMTP servers doing so are also advised to use appropriate wording
in the text portion of the reply, possibly using the term "ADSP"
explicitly.
I mention "appropriate wording", but suggesting use of the string "ADSP" specifically works for me as well.

Thanks,
-MSK
Rolf E. Sonneveld
2010-08-06 22:11:16 UTC
Permalink
Hi, Murray,
Post by Murray S. Kucherawy
The -01 draft was briefly presented in Maastricht. We'd like to get more review of and feedback about it from people with an ideal in mind of starting a WGLC toward the end of September.
Please take some time to review it and provide comments, even if it's just "I've read it, looks good." We need to record even that sort of thing as part of the rough consensus record before advancing.
You MUST NOT [RFC2119] use this thread for debating the technical or political points of ADSP. Please start a different thread for that or any other tangent. It makes the author's job much harder when trying to locate feedback that needs to be applied.
And thanks to Daniel for the quick feedback!
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
finally got some time to review the -01 draft. Below are my comments.

----

3.2: typo: "... a address..." should be "...an address..."

3.3: in the light of the discussion on message digests, I'd suggest to
add text to this paragraph about MLM's turning multiple messages from
potentially multiple senders/authors into a new message, invalidating
the DKIM signature of the original message(s).

3.3: Just a note on subject tags you may or may not wish to add: some
MLM's offer the choice of appending a postfix (as an alternative to
prepending a prefix).

3.4: "... entire entire..." should be "... entire..."

3.4: "... but this not workable..." should be "... but this is not
workable..."

3.4: in addition to making the recommendation of sending periodic,
automatic mailings to the list, I would suggest to make the (implicitely
present) recommendation for an MLM, to not add header- and footer
sections, more explicit.

4. (and 5.) I would suggest to add one or two lines to the Introduction
paragraph (par. 1.2 or par 1.4, or add a par. 1.5) to explain that there
are different types of MLM's and they each are addressed in this
document, in different sections. Something along the lines of:

"In general there are, in relation to DKIM, two categories of MLMs:
participating and non-participating MLMs. As both types have their own
issues, regarding DKIM signed messages that are handled by them, they
are discussed in two different chapters (possibly a link to chapter 4
and 5)."

4.1 I get confused here: you write "the author is advised to be cautious
when deciding whether or not to sign the message". However, according to
par. 3.1 the author does not sign a message; that is being done by the
signer. Furthermore, if we change this phrase into "the signer is
advised to be cautious when deciding whether or not to sign the message"
then the question is: how can a signer (which is by definition not a
human being) know whether the MLM is non-participating. If the signer is
not a human being, there must be some mechanism by which the signer can
learn from the MLM that is is non-participating, but as the MLM is not
participating, it is difficult to propose a protocol between MLM and
signer to make the signer aware that the MLM is not DKIM aware :-)

The remainder of that paragraph explains things pretty well, but the
first few lines causes some confusion.

4.3 Under [ADSP]. "... Per that specification, when a message is
unsigned or the signature can no longer be verified, the verifier must
discard the message. ...". But this is only true if the author domain
publishes 'discardable'. So I suggest to change this phrase into: "...
Per that specification, when a message is unsigned or the signature can
no longer be verified, the verifier must discard the message in case the
author domain publishes an ADSP policy of discardable. ..."

5.1 Section 2: I wonder whether this paragraph is still required, in the
light of the 'reject policy' described in par. 5.5. After all, why
bother non-posting subscribers with these warnings? As soon as they
start posting, they will get a warning (i.e. a reject) when submitting
their first message and then they can change their policy or post using
another address/(sub)domain. I would suggest to remove this paragraph,
unless I'm overlooking something.

5.4 The title "Pros and Cons of Signature Removal" does not really cover
the contents of the paragraph. I would suggest "Signature Removal" as title.

5.4 I wonder whether there's any wording required here to describe what
an MLM should do in case of sending a digest. For example, MailMan
supports two types of digest, one of them being the multipart/digest
MIME type, where each message is sent as bodypart inside a mail. Should
the MLM try to verify the DKIM signature of all messages within the
digest and put the A-R for all of them in the header? And remove them
all? Presumably the answer is 'yes', but it won't hurt to describe this
explicitely.

5.6 At the end of page 18, beginning of page 19: should there not be
explicitely added "o 5322.
Murray S. Kucherawy
2010-08-10 05:55:38 UTC
Permalink
-----Original Message-----
Sent: Friday, August 06, 2010 3:11 PM
To: Murray S. Kucherawy
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
Hi, Murray,
Hey Rolf,
finally got some time to review the -01 draft. Below are my comments.
----
3.2: typo: "... a address..." should be "...an address..."
Fixed.
3.3: in the light of the discussion on message digests, I'd suggest to
add text to this paragraph about MLM's turning multiple messages from
potentially multiple senders/authors into a new message, invalidating
the DKIM signature of the original message(s).
So to the end of "digesting:" you mean something like: "The DKIM signatures on the original messages might be invalidated by this process." ?
3.3: Just a note on subject tags you may or may not wish to add: some
MLM's offer the choice of appending a postfix (as an alternative to
prepending a prefix).
Added.
3.4: "... entire entire..." should be "... entire..."
Fixed.
3.4: "... but this not workable..." should be "... but this is not
workable..."
Fixed.
3.4: in addition to making the recommendation of sending periodic,
automatic mailings to the list, I would suggest to make the
(implicitely
present) recommendation for an MLM, to not add header- and footer
sections, more explicit.
This section has been removed and merged into various parts of Section 5. Please let me know if you think the -02 draft (when it comes out) does a better job of this.
4. (and 5.) I would suggest to add one or two lines to the Introduction
paragraph (par. 1.2 or par 1.4, or add a par. 1.5) to explain that there
are different types of MLM's and they each are addressed in this
participating and non-participating MLMs. As both types have their own
issues, regarding DKIM signed messages that are handled by them, they
are discussed in two different chapters (possibly a link to chapter 4
and 5)."
Seems reasonable to me; added in Section 1.
4.1 I get confused here: you write "the author is advised to be cautious
when deciding whether or not to sign the message". However, according to
par. 3.1 the author does not sign a message; that is being done by the
signer. Furthermore, if we change this phrase into "the signer is
advised to be cautious when deciding whether or not to sign the message"
then the question is: how can a signer (which is by definition not a
human being) know whether the MLM is non-participating. If the signer is
not a human being, there must be some mechanism by which the signer can
learn from the MLM that is is non-participating, but as the MLM is not
participating, it is difficult to propose a protocol between MLM and
signer to make the signer aware that the MLM is not DKIM aware :-)
The remainder of that paragraph explains things pretty well, but the
first few lines causes some confusion.
Yes, you're right. With some fairly simple wordsmithing, I think we can fix it by saying the author should not send mail to the list when that mail would be signed. Thus if signing is within the author's control, the author can just switch signing off for the list (or better, as the paragraph says, create a separate stream); otherwise, the author will have to find some other way to participate, or not participate at all, or take the risk.
4.3 Under [ADSP]. "... Per that specification, when a message is
unsigned or the signature can no longer be verified, the verifier must
discard the message. ...". But this is only true if the author domain
publishes 'discardable'. So I suggest to change this phrase into: "...
Per that specification, when a message is unsigned or the signature can
no longer be verified, the verifier must discard the message in case the
author domain publishes an ADSP policy of discardable. ..."
I went with:

"Use of restrictive domain policies such as [ADSP] "discardable" presents an additional challenge." After that I think the rest is OK.
5.1 Section 2: I wonder whether this paragraph is still required, in the
light of the 'reject policy' described in par. 5.5. After all, why
bother non-posting subscribers with these warnings? As soon as they
start posting, they will get a warning (i.e. a reject) when submitting
their first message and then they can change their policy or post using
another address/(sub)domain. I would suggest to remove this paragraph,
unless I'm overlooking something.
This stuff has been reworked. Let me know if you still have a concern when -02 comes out.
5.4 The title "Pros and Cons of Signature Removal" does not really cover
the contents of the paragraph. I would suggest "Signature Removal" as title.
You're right about the misnamed section, but I think that speaks more to what's missing from the section than the bad title. The posture of the document is supposed to be a discussion of various implementation choices and their implications in the DKIM world. Although this does touch on what happens if you don't remove signatures, it's vague and only in the first paragraph ("unwarranted filter actions"). I've made this more explicit for -02 by extending the first paragraph to discuss the non-removal case.
5.4 I wonder whether there's any wording required here to describe what
an MLM should do in case of sending a digest. For example, MailMan
supports two types of digest, one of them being the multipart/digest
MIME type, where each message is sent as bodypart inside a mail. Should
the MLM try to verify the DKIM signature of all messages within the
digest and put the A-R for all of them in the header? And remove them
all? Presumably the answer is 'yes', but it won't hurt to describe this
explicitely.
This is an interesting idea. There's nothing saying you couldn't do that. But it's not clear there's demand for it either. It seems complicated, but also completely supported by MIME, AUTH-RESULTS and DKIM in case that might somehow be useful later.

I'm inclined to add a paragraph about it. What do others think?
5.6 At the end of page 18, beginning of page 19: should there not be
explicitely added "o 5322.
John Levine
2010-08-07 02:21:03 UTC
Permalink
I went through -01 again.

Basically, it's fine. There's a few places where it says things that
are out of scope of DKIM. A signature either verifies or it doesn't,
and there's nothing inherently good or bad about that.

RFC 4871 carefully describes the way one verifies a signature, and
that process does't include attempts to guess what alternate form of a
message with a broken signature might have been signed. (Even Mike
admits it's against the rules when he does that.) A broken signature
is the same as no signature.

ADSP has some fairly specific advice about when not to use discardable,
which is relevant here.

Hence:

Sec 3.2 2nd pp on page 9: "most direct conflict operationally with DKIM" ->
"widest range of possible interactions with DKIM" or something like that.
I don't see any confict at all.

Sec 3.3 "the addition of some list-specific text to the top or bottom of
the message body." -> "modification of the message body." Lists do a
lot more than add tag lines, as described in subsequent paragraphs.

under Minor body changes: "pose an immediate problem" -> "will probably cause
any existing signatures not to verify." Broken signatures are not a
problem.

under Major body changes: delete "with little or no hope of
compensation by either the signer or the verifier." There's no
such thing as compensation beyond relaxed canonicanization,
which isn't relevant here

after "human list manager" add "who hand-edits messages" (that would be me)

next pp starting "In general", change first sentence to:
In general, an MLM subscriber cannot expect signatures applied before
the message was processed by the MLM to be valid.

Sec 3.4 2nd pp: delete sentence starting "The shortest path" Personally, I
think the shortest path is for the MLM's MTA to sign its outgoing
mail, but I don't think we have consensus either way, so just take
it out.

Last pp in 3.4: even if there were a new header, few MUAs would interpret
it. Suggest taking out "Rather than ... purpose" since it's not a
realistic alternative.

Section 4.1: There's no reason not to sign all the mail you send to a list.
Even if the MLM breaks the signature, the MLM itself can use the
signature when deciding how to handle the message. The implication
in the first paragraph that a broken signature is worse than no
signature is just wrong according to 4871. Also, [ADSP] says in
Appendix B not to send mail to lists from discardable domains. So
I suggest replacing the first paragraph with a sentence or two
encouraging people to sign mail sent to lists the same way they
sign mail to anyone else. In the second pp, change "If this is cause
for concern" to "For domains that publish strict ADSP policies"

Section 4.2: channelling Dave, standards shouldn't suggest heuristics.
So change the second sentence to something like "Sites whose users
subscribe to non-participating MLMs should be prepared for
legitimate mail to arrive with no valid signature, just as it
always has in the absence of DKIM."

Section 4.3: I'd just delete it. The second pp is OK, but people using
DKIM are supposed to know that already, aren't they?

Section 5.1: I'd strengthen it to say that since people aren't
supposed to send mail to lists from discardable domains in the
first place, lists should reject it or perhaps (for people who've
already subscribed so you know it's not spam blowback) drop the message
and send back a note explaining why.

Section 5.2, second pp: I don't understand the point of creating a
separate signing domain for mail you send to lists. Why would the
reputation of mail that people send to lists be better or worse than
mail they send anywhere else? It's the same people, I don't see the
point of a separate mailstream. ADSP isn't a good reason, since
it says not to use discardable for domains with human senders.

The third pp suggests that you're telling people to separate their
human mailstream from their transactions and their spam blasts. If
that's what you mean, I agree, but I'd encourage you to trim down
the section and reword it to say so more clearly.

In Section 5.4, either delete it or add a sentence at the front that
says THE ADVICE IN THIS SECTION IS SOLELY INTENDED TO WORK AROUND
BRAIN DAMAGE IN FILTERS THAT DO NOT IMPLEMENT DKIM ACCORDING TO THE
SPECIFICATIONS.

(Well, adding an A-R header isn't, but removing signatures that
might be broken sure is.)

In Section 5,5, add a ref to [ADSP] Appendix B.5 which says not to
send discardable mail to lists.

In Section 5.6, first pp: add a sentence noting that recipient system
will likely use the MLM's signature to recognize list mail and
develop a (presumably good) reputation for the list itself.

In Section 5.7 add to the end "if senders misuse ADSP" or the like.

Section 5.9, second pp: change to
Receivers are advised to ignore Authentication-Results
header fields that are not signed by a credible signer.

(Bad guys can sign fake A-R headers.)

Section 5.9, third pp: if a message fails "discardable" the receiver
should discard it, not reject it. This avoids the bouncing off the
list problem, and you're just following orders -- they said it was
discardable, after all.

Sections 6, 7, 8, and 9 are flawless.

R's,
John

PS: If I didn't say so before, thanks for all the work you've put into
this.
Hector Santos
2010-08-09 13:17:26 UTC
Permalink
+1 to John notes here. Afrer reviewing the drafts, I think it hits all
the key points, but there should be a summary somewhere.

I have one comment though to highlight
Post by John Levine
Section 5.9, third pp: if a message fails "discardable" the receiver
should discard it, not reject it. This avoids the bouncing off the
list problem, and you're just following orders -- they said it was
discardable, after all.
If the MLM follows the other guidelines which amounts to prohibiting
restrictive ADSP domains from subscribing and submitting list mail,
then the MLM would not dependent on remote receivers behaving in a
SMTP level rejection mode since any rejection at this point would not
be related to ADSP issue but a typical member delivery issue as it is
today.

This is important in my view because MTAs direction has been more and
more toward using dynamic SMTP level rejections.

An MTA that has shifted towards a DATA rejection would now have to
have DKIM/ADSP exception to issue a false positive acceptance for the
purpose of discard - that means tricky SOFTWARE/INTEGRATION change.

So if the MLM simply follow the guideline to prohibit strict ADSP
domain mail from entering its list environment, the downlink
non-delivery ADSP problems would not be an issue anymore - no
dependency on how downlinks are behaving and have no control over.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Jeff Macdonald
2010-08-09 14:24:41 UTC
Permalink
On Mon, Aug 9, 2010 at 9:17 AM, Hector Santos <***@isdg.net> wrote:
<snip>
Post by Hector Santos
So if the MLM simply follow the guideline to prohibit strict ADSP
domain mail from entering its list environment, the downlink
non-delivery ADSP problems would not be an issue anymore - no
dependency on how downlinks are behaving and have no control over.
+1
--
Jeff Macdonald
Ayer, MA
Murray S. Kucherawy
2010-08-10 06:30:28 UTC
Permalink
-----Original Message-----
Sent: Monday, August 09, 2010 7:25 AM
To: Hector Santos
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
Post by Hector Santos
So if the MLM simply follow the guideline to prohibit strict ADSP
domain mail from entering its list environment, the downlink
non-delivery ADSP problems would not be an issue anymore - no
dependency on how downlinks are behaving and have no control over.
+1
I agree. But I'd also like to cover the case where an MLM elects not to handle ADSP at all, and the receivers have to deal with it. I think failing to do so leaves a fairly obvious hole.

So I'm not sure what the objection is here. Is there something you guys want removed or changed?
Jeff Macdonald
2010-08-10 15:21:53 UTC
Permalink
-----Original Message-----
Sent: Monday, August 09, 2010 7:25 AM
To: Hector Santos
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
Post by Hector Santos
So if the MLM simply follow the guideline to prohibit strict ADSP
domain mail from entering its list environment, the downlink
non-delivery ADSP problems would not be an issue anymore - no
dependency on how downlinks are behaving and have no control over.
+1
I agree.  But I'd also like to cover the case where an MLM elects not to handle ADSP at all, and the receivers have to deal with it.  I think failing to do so leaves a fairly obvious hole.
So I'm not sure what the objection is here.  Is there something you guys want removed or changed?
No objection, just that MLMs MUST take ADSP into consideration.
--
Jeff Macdonald
Ayer, MA
Dave CROCKER
2010-08-10 15:26:05 UTC
Permalink
Post by Jeff Macdonald
No objection, just that MLMs MUST take ADSP into consideration.
The only entities that MUST take ADSP into consideration are those that choose to.

There is neither the expectation nor the leverage to force adoption.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Jeff Macdonald
2010-08-10 16:39:43 UTC
Permalink
Post by Dave CROCKER
Post by Jeff Macdonald
No objection, just that MLMs MUST take ADSP into consideration.
The only entities that MUST take ADSP into consideration are those that choose to.
There is neither the expectation nor the leverage to force adoption.
While I don't want to encourage adoption, I'm viewing this from a
"defensive" perspective. The users of the MLM won't care if it is the
Author's fault for using ADSP and their IT group for honouring it. If
they communicate with that individual directly and the messages are
delivered, yet they are not via a MLM, then they are going to believe
it is the MLMs fault.

I just believe if the MLM author is going to the trouble to do
anything with DKIM, it doesn't make sense to ignore ADSP. After all a
MLM author wants his system to be robust.

Thus I support MLMs rejecting any messages with strong ADSP policy. It
isn't that different than MTAs rejecting connections from MTAs that
don't have rDNS.
--
Jeff Macdonald
Ayer, MA
Dave CROCKER
2010-08-10 16:44:18 UTC
Permalink
Post by Jeff Macdonald
I just believe if the MLM author is going to the trouble to do
anything with DKIM, it doesn't make sense to ignore ADSP. After all a
MLM author wants his system to be robust.
I was not commenting on whether an MLM "should" adopt ADSP, but that there is no
way to mandate adoption.

Explain, encourage, cajole and implore all you want, but there is no MUST than
can be applied to adoption.

Any analysis of the use of a protocol MUST consider scenarios in which it has
not (yet) been adopted. That's especially true for multi-step scenarios with a
poor adoption track record. Such as MLMs...

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Murray S. Kucherawy
2010-08-10 16:59:10 UTC
Permalink
-----Original Message-----
Sent: Tuesday, August 10, 2010 8:22 AM
To: Murray S. Kucherawy
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
So I'm not sure what the objection is here.  Is there something you
guys want removed or changed?
No objection, just that MLMs MUST take ADSP into consideration.
Doesn't the document already do that, and in several places?
Jeff Macdonald
2010-08-10 18:07:52 UTC
Permalink
Post by Murray S. Kucherawy
-----Original Message-----
Sent: Tuesday, August 10, 2010 8:22 AM
To: Murray S. Kucherawy
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
So I'm not sure what the objection is here.  Is there something you
guys want removed or changed?
No objection, just that MLMs MUST take ADSP into consideration.
Doesn't the document already do that, and in several places?
Yes. Count me as a supporter of such language staying in the document.
--
Jeff Macdonald
Ayer, MA
Douglas Otis
2010-08-09 17:52:23 UTC
Permalink
Post by Hector Santos
If the MLM follows the other guidelines which amounts to prohibiting
restrictive ADSP domains from subscribing and submitting list mail,
then the MLM would not dependent on remote receivers behaving in a
SMTP level rejection mode since any rejection at this point would not
be related to ADSP issue but a typical member delivery issue as it is
today.
This is important in my view because MTAs direction has been more and
more toward using dynamic SMTP level rejections.
An MTA that has shifted towards a DATA rejection would now have to
have DKIM/ADSP exception to issue a false positive acceptance for the
purpose of discard - that means tricky SOFTWARE/INTEGRATION change.
So if the MLM simply follow the guideline to prohibit strict ADSP
domain mail from entering its list environment, the downlink
non-delivery ADSP problems would not be an issue anymore - no
dependency on how downlinks are behaving and have no control over.
+1

IMHO, the ADSP assertion "discardable" where messages are silently
discarded may come to represent a bad practice.

The draft should not offer this type of guidance. Preventing
distribution of these domain's submissions, where the list might damage
the Author Domain Signature, better retains email's integrity and
provides a comprehensive solution for the problem this damage might cause.

-Doug
Murray S. Kucherawy
2010-08-10 06:27:22 UTC
Permalink
-----Original Message-----
Sent: Friday, August 06, 2010 7:21 PM
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
Sec 3.2 2nd pp on page 9: "most direct conflict operationally with DKIM" ->
"widest range of possible interactions with DKIM" or something like that.
I don't see any confict at all.
Well the point is to address the fact that a lot of MLM actions disrupt DKIM signature validation. Maybe "conflict" is too strong a word, but "interactions" feels too soft as well. "Friction" feels like the right ballpark, but sounds too negative. How about "foil", "thwart" or "frustrate"?
Sec 3.3 "the addition of some list-specific text to the top or bottom of
the message body." -> "modification of the message body." Lists do a
lot more than add tag lines, as described in subsequent paragraphs.
Done.
under Minor body changes: "pose an immediate problem" -> "will probably cause
any existing signatures not to verify." Broken signatures are not a
problem.
Done.
under Major body changes: delete "with little or no hope of
compensation by either the signer or the verifier." There's no
such thing as compensation beyond relaxed canonicanization,
which isn't relevant here
Done.
after "human list manager" add "who hand-edits messages" (that would be me)
Already changed based on other feedback to:

"... whose workings in preparing a message for distribution could include the above or even some other changes."
In general, an MLM subscriber cannot expect signatures applied before
the message was processed by the MLM to be valid.
OK.
Sec 3.4 2nd pp: delete sentence starting "The shortest path"
Personally, I
think the shortest path is for the MLM's MTA to sign its outgoing
mail, but I don't think we have consensus either way, so just take
it out.
OK.
Last pp in 3.4: even if there were a new header, few MUAs would interpret
it. Suggest taking out "Rather than ... purpose" since it's not a
realistic alternative.
OK.
Section 4.1: There's no reason not to sign all the mail you send to a list.
Even if the MLM breaks the signature, the MLM itself can use the
signature when deciding how to handle the message. The implication
in the first paragraph that a broken signature is worse than no
signature is just wrong according to 4871.
The text now reads, based on other feedback:

"If an author knows that the MLM to which a message is being sent is a non-participating resending MLM, the author is advised to be cautious when deciding whether or not to send to the list when that mail would be signed."

This takes the signing decision away from the user, which I think resolves your concern.

But for the sake of discussion: I don't think the broken signature is worse and I know you don't think that, but we've encountered implementations that do. I think it's reasonable for this document to acknowledge that this (incorrect) choice has been made and exists out there, and sometimes we'll have to deal with it.

The whole point of this draft is to talk about these things about which the general public has little understanding. There's a lot of collective subconscious out there that has equated "bad signature" to "bad message", and perhaps reasonably so. I think it's better to discuss it in this quasi-BCP than pretend it's not there and expect everyone to figure it out.
Also, [ADSP] says in
Appendix B not to send mail to lists from discardable domains. So
I suggest replacing the first paragraph with a sentence or two
encouraging people to sign mail sent to lists the same way they
sign mail to anyone else. In the second pp, change "If this is cause
for concern" to "For domains that publish strict ADSP policies"
Done.
Section 4.2: channelling Dave, standards shouldn't suggest heuristics.
So change the second sentence to something like "Sites whose users
subscribe to non-participating MLMs should be prepared for
legitimate mail to arrive with no valid signature, just as it
always has in the absence of DKIM."
OK.
Section 4.3: I'd just delete it. The second pp is OK, but people using
DKIM are supposed to know that already, aren't they?
I think part of the point of this document is to walk people through some of the thought processes even if they're clearly the wrong ones. And to some degree some of the audience of this draft is people who aren't yet using DKIM, but want to or think they should.
Section 5.1: I'd strengthen it to say that since people aren't
supposed to send mail to lists from discardable domains in the
first place, lists should reject it or perhaps (for people who've
already subscribed so you know it's not spam blowback) drop the message
and send back a note explaining why.
Let me know what you think of -02 when it comes out. I think it gives a better treatment.
Section 5.2, second pp: I don't understand the point of creating a
separate signing domain for mail you send to lists. Why would the
reputation of mail that people send to lists be better or worse than
mail they send anywhere else? It's the same people, I don't see the
point of a separate mailstream. ADSP isn't a good reason, since
it says not to use discardable for domains with human senders.
I believe the thinking was: This stream of mail from me might get mangled, or associated with traffic over which I have no control (and get munged in with the reputations of people on mailing lists to which I subscribe), so I might want to keep those separate.
In Section 5.4, either delete it or add a sentence at the front that
says THE ADVICE IN THIS SECTION IS SOLELY INTENDED TO WORK AROUND
BRAIN DAMAGE IN FILTERS THAT DO NOT IMPLEMENT DKIM ACCORDING TO THE
SPECIFICATIONS.
(Well, adding an A-R header isn't, but removing signatures that
might be broken sure is.)
Minus the caps, I've added a note to indicate something about that.
In Section 5,5, add a ref to [ADSP] Appendix B.5 which says not to
send discardable mail to lists.
Done.
In Section 5.6, first pp: add a sentence noting that recipient system
will likely use the MLM's signature to recognize list mail and
develop a (presumably good) reputation for the list itself.
Done.
In Section 5.7 add to the end "if senders misuse ADSP" or the like.
OK.
Section 5.9, second pp: change to
Receivers are advised to ignore Authentication-Results
header fields that are not signed by a credible signer.
(Bad guys can sign fake A-R headers.)
OK.
Section 5.9, third pp: if a message fails "discardable" the receiver
should discard it, not reject it. This avoids the bouncing off the
list problem, and you're just following orders -- they said it was
discardable, after all.
I've added a paragraph that specifically discusses "discardable". The paragraph you cited was meant to talk about "all", where the receiver has more discretion (via ambiguity) about what to do.
Sections 6, 7, 8, and 9 are flawless.
Excellent!
PS: If I didn't say so before, thanks for all the work you've put into
this.
My pleasure! Thanks for the feedback!

-MSK
Dave CROCKER
2010-08-10 14:42:09 UTC
Permalink
Post by Murray S. Kucherawy
The whole point of this draft is to talk about these things about which the
general public has little understanding. There's a lot of collective
subconscious out there that has equated "bad signature" to "bad message", and
perhaps reasonably so. I think it's better to discuss it in this quasi-BCP
than pretend it's not there and expect everyone to figure it out.
In reviewing your response to John, I'm thinking that part of the initial
'orientation' work of the draft -- probably in section 3.1 -- should add to the
description of the components (origination, MLM, receiver) by documenting the
different scenarios that will be covered, primarily to indicate that basic types
of choices or effects created by having an MLM in the sequence.

The goal would be to give the reader a snapshot of each combination, so that
that will be in there head when they read the details.

I think much of the challenge of this exercise is deciding how to organize
things, so that readers see the problem space partitioned helpfully and,
therefore, get useful chunks of guidance. Otherwise it's all overwhelming.

The following list is much longer than I'd like, but I think each entry is for a
scenario that is distinctive and significant. (For reference, I've left some
combinations off, since they didn't seem compelling to me.)


DKIM:

Broken Broken Signatures:

Origination DKIM -> Non-participating MLM -> Receiving DKIM

Submission enhancement:

Origination DKIM -> Participating MLM

List reputation:

Participating MLM -> Receiving DKIM

End-to-End DKIM:

Origination DKIM -> Participating MLM -> Receiving DKIM

Besides a discussion of each of these on their own, the possible relationship
between Broken Signatures and End-to-End DKIM would be helpful in terms of the
Origination signature. I think that, in fact, they produce the same result,
namely a broken signature.


ADSP:

Broken ADSP:

Origination DKIM+ADSP -> Non-participating MLM -> Receiving DKIM+ADSP

Submission ADSP:

Origination DKIM+ADSP -> Non-participating MLM

End-to-End ADSP:

Origination DKIM+ADSP -> DKIM+ADSP Participating MLM -> Receiving DKIM+ADSP


I don't feel religious about this list. Anything that works is fine. The
combinatorials of this problem space are confusing and I'm simply searching for
a way to divide into smaller bits that are easier to digest.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
John R. Levine
2010-08-10 14:58:15 UTC
Permalink
I've trimmed out all the places where we agree, so this one is mercifully
short.
Post by Murray S. Kucherawy
Post by John Levine
Sec 3.2 2nd pp on page 9: "most direct conflict operationally with DKIM" ->
"widest range of possible interactions with DKIM" or something like that.
I don't see any confict at all.
Well the point is to address the fact that a lot of MLM actions disrupt DKIM signature validation. Maybe "conflict" is too strong a word, but "interactions" feels too soft as well. "Friction" feels like the right ballpark, but sounds too negative. How about "foil", "thwart" or "frustrate"?
Nope. Those all imply that it's important for recipients to validate
the contributors' signatures, which it's not. They really do have the
widest range of interactions, the most complex signup processes, the
mst complex techniques for deciding what to accept, and the most
varied modifications to the messages.
Post by Murray S. Kucherawy
"If an author knows that the MLM to which a message is being sent is a non-participating resending MLM, the author is advised to be cautious when deciding whether or not to send to the list when that mail would be signed."
This takes the signing decision away from the user, which I think resolves your concern.
But for the sake of discussion: I don't think the broken signature is worse and I know you don't think that, but we've encountered implementations that do. I think it's reasonable for this document to acknowledge that this (incorrect) choice has been made and exists out there, and sometimes we'll have to deal with it.
In general, I think it's better to tell people to fix their bugs than to
encoourage the rest of the world to work around them. If the point is
that you may experience trouble delivering to systems with flawed DKIM
code that erroneously penalizes broken signatures, why not just say that,
and make it clear where the fault lies?
Post by Murray S. Kucherawy
I believe the thinking was: This stream of mail from me might get mangled, or associated with traffic over which I have no control (and get munged in with the reputations of people on mailing lists to which I subscribe), so I might want to keep those separate.
Seems awfully convoluted, but again, if that's the thinking, better to
say that.
Post by Murray S. Kucherawy
Post by John Levine
PS: If I didn't say so before, thanks for all the work you've put into
this.
My pleasure! Thanks for the feedback!
Thanks again. Looking forward to the next round.

R's,
John
Murray S. Kucherawy
2010-08-10 17:07:04 UTC
Permalink
-----Original Message-----
Sent: Tuesday, August 10, 2010 7:58 AM
To: Murray S. Kucherawy
Subject: RE: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
Post by Murray S. Kucherawy
Well the point is to address the fact that a lot of MLM actions
disrupt DKIM signature validation. Maybe "conflict" is too strong a
word, but "interactions" feels too soft as well. "Friction" feels like
the right ballpark, but sounds too negative. How about "foil",
"thwart" or "frustrate"?
Nope. Those all imply that it's important for recipients to validate
the contributors' signatures, which it's not. They really do have the
widest range of interactions, the most complex signup processes, the
mst complex techniques for deciding what to accept, and the most
varied modifications to the messages.
I agree with the second part but I'm not sold on the first. I get the statement that an invalid signature is the same as no signature at all, but a signature that can validate has the potential for saying something useful to someone. The author/signer elected to apply DKIM to make a statement that it hoped a receiver would find meaningful or useful. Maybe the receiver would be really happy to get that information. Thus, any intermediary that interferes with that desire is frustrating someone's attempt to say (or hear) something.

If we don't care about this and MLMs clobbering signatures is just a fact of life, why are we even going through this effort?
Dave CROCKER
2010-08-10 17:20:15 UTC
Permalink
Post by Murray S. Kucherawy
Post by John Levine
Sec 3.2 2nd pp on page 9: "most direct conflict operationally with DKIM"
-> "widest range of possible interactions with DKIM" or something like
that. I don't see any confict at all.
Well the point is to address the fact that a lot of MLM actions disrupt DKIM
signature validation. Maybe "conflict" is too strong a word, but
"interactions" feels too soft as well. "Friction" feels like the right
ballpark, but sounds too negative. How about "foil", "thwart" or
"frustrate"?
I'm going to suggest that this sub-thread is pretty silly.

I think the existing wording is exactly correct. The quibbling about language
is based on a larger context of considerations than applies to the sentence in
the draft.

DKIM is a particular service. An MLM will typically destroy a DKIM signature.
If destruction doesn't count as "conflict with" then I don't know what does.

The sentence in the draft is actually quite carefully to say "operationally" and
that is exactly the right description of the problematic effect of MLMs with
respect to the author-to-reader sequence of a DKIM-signed message.

Leave the sentence alone.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
John R. Levine
2010-08-10 17:52:11 UTC
Permalink
Post by Dave CROCKER
DKIM is a particular service. An MLM will typically destroy a DKIM
signature. If destruction doesn't count as "conflict with" then I don't know
what does.
I can live with Murray's language, but I'm seeing what appear to me to be
some fairly basic disagreements about what DKIM does.

My understanding is that it's intended to combine a modest integrity check
of messages in transit with a responsible identity. That's all it does.
In particular, it's not intended to provide long term bullet proof message
protection, and (disregarding ADSP) there's no semantics assigned to the
absence of a valid DKIM signature.

The arguments about the alleged importance of preserving inbound
signatures are silly for a bunch of reasons. One is three decades of
practice in which nobody has worried about recipients verifying the
identities of list contributors. (I can't help but note the absence of
S/MIME or PGP signatures on the mail of people who argue otherwise.)
Another is the observed consistent practice of sorting and I believe
filtering based on the characteristics of the list rather than individual
contributors.

Also, if one believes that we should rewrite MLMs to provide some tortured
way to pass through signatures, or to cater to misimplementations that
penalize broken signatures, why stop there? Many lists are read through
online reformatters like pipermail. Should we demand they all get
rewritten to preserve DKIM signatures? If not, what's the difference?

R's,
John
Dave CROCKER
2010-08-10 17:55:36 UTC
Permalink
Post by John R. Levine
In particular, it's not intended to provide long term bullet proof message
protection
I probably haven't been reading carefully enough (as usual.)

Amidst the current discussions, I missed the postings that seemed to be based on
this different goal for DKIM.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Murray S. Kucherawy
2010-08-10 18:12:48 UTC
Permalink
-----Original Message-----
Sent: Tuesday, August 10, 2010 10:52 AM
Subject: Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-
mailinglists-01 review request
Post by Dave CROCKER
DKIM is a particular service. An MLM will typically destroy a DKIM
signature. If destruction doesn't count as "conflict with" then I
don't know
Post by Dave CROCKER
what does.
I can live with Murray's language, but I'm seeing what appear to me to be
some fairly basic disagreements about what DKIM does.
My understanding is that it's intended to combine a modest integrity check
of messages in transit with a responsible identity. That's all it does.
I don't think we're disagreeing. The premise of the draft states simply that DKIM is a mechanism for attaching a (provable) domain name to a message as a means for taking some responsibility for it, and that some common MLM practices interfere with the delivery of that payload. I don't think there's any express or implied claim in the document that DKIM does more than that.

But what you're saying seems antithetical to most of the document, which goes to some lengths to describe ways that MLMs and DKIM can co-operate better. So should we not bother?
The arguments about the alleged importance of preserving inbound
signatures are silly for a bunch of reasons. One is three decades of
practice in which nobody has worried about recipients verifying the
identities of list contributors. (I can't help but note the absence of
S/MIME or PGP signatures on the mail of people who argue otherwise.)
Though I don't claim to be able to predict the future, I can speculate that this could become an important thing as domain reputation gets rolled out. So it might not matter now, but it could matter soon.
B***@cox.com
2010-08-10 18:26:13 UTC
Permalink
Having reread the document I go with steps 4&5 on page 15. Most of the wording is fine
Post by Murray S. Kucherawy
-----Original Message-----
Sent: Tuesday, August 10, 2010 10:52 AM
Subject: Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-
mailinglists-01 review request
Post by Dave CROCKER
DKIM is a particular service. An MLM will typically destroy a DKIM
signature. If destruction doesn't count as "conflict with" then I
don't know
Post by Dave CROCKER
what does.
I can live with Murray's language, but I'm seeing what appear to me to be
some fairly basic disagreements about what DKIM does.
My understanding is that it's intended to combine a modest integrity check
of messages in transit with a responsible identity. That's all it does.
I don't think we're disagreeing. The premise of the draft states simply that DKIM is a mechanism for attaching a (provable) domain name to a message as a means for taking some responsibility for it, and that some common MLM practices interfere with the delivery of that payload. I don't think there's any express or implied claim in the document that DKIM does more than that.
But what you're saying seems antithetical to most of the document, which goes to some lengths to describe ways that MLMs and DKIM can co-operate better. So should we not bother?
The arguments about the alleged importance of preserving inbound
signatures are silly for a bunch of reasons. One is three decades of
practice in which nobody has worried about recipients verifying the
identities of list contributors. (I can't help but note the absence of
S/MIME or PGP signatures on the mail of people who argue otherwise.)
Though I don't claim to be able to predict the future, I can speculate that this could become an important thing as domain reputation gets rolled out. So it might not matter now, but it could matter soon.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
SM
2010-08-10 19:59:23 UTC
Permalink
Post by Murray S. Kucherawy
The whole point of this draft is to talk about these things about
which the general public has little understanding. There's a lot of
collective subconscious out there that has equated "bad signature"
to "bad message", and perhaps reasonably so. I think it's better to
discuss it in this quasi-BCP than pretend it's not there and expect
everyone to figure it out.
Agreed.

I think that more experience is needed before the working group
delves into a BCP. There isn't any RFC 2119 terminology in
draft-ietf-dkim-mailinglists-02. Even if it had such language, that
doesn't make it a BCP.
Post by Murray S. Kucherawy
Some time ago we discussed this and the consensus seemed to be (to
me, at least) to produce an Informational document on our first pass
through this process with an eye towards doing a BCP (in the formal
IETF sense) afterwards. I think some people have been calling this
a BCP because it generally espouses what we think of as best
practices, but that term has some special status meanings in the
IETF so perhaps that caused some confusion.
Yes.
Post by Murray S. Kucherawy
If we have changed our consensus and want to take a run at a full
BCP document, I'll happily go through and start using RFC2119
language. Finding ways to avoid using those magic words, even in
all-lowercase, can be a little time-consuming.
Yes. The Abstract Section already says:

"As the industry has now gained some deployment experience, the goal
for this document is to explore the use of DKIM for scenarios that
include intermediaries, such as Mailing List Managers (MLMs)."
Post by Murray S. Kucherawy
Naturally I'm fine citing RFC5863 and ensuring this document's
definitions match the ones found there, but do we really want to
cite a Wikipedia article?
No. It's not a good reference unless we are want to track perceived
consensus in real-time.

Regards,
-sm
Dave CROCKER
2010-08-09 22:39:41 UTC
Permalink
Murray, et al,


I think the Introduction's first paragraph is the best summary of DKIM that's
been written for any of our document's, so far.

Throughout the document, there is a tendency to offer advice without
justification. While I, of course, think the advice is good, the fact that it
is cast as advice means it needs to carry a statement of efficacy. Why do
things this way? Why not do them some other way? Advice requires a context of
tradeoffs.



SUBSTANTIVE
===========
When should an author, or its organization, use DKIM for mail sent
to mailing lists?
The word "should" implies an intent to make a normative statement. This
conflicts with the stated goal of Informational status. So does the distinction
between Normative and Informative references.

Either the goal should be BCP (or even Proposed) or perhaps the language for
this type of statement needs to be softened to something like "Under what
circumstances does..."

My own guess is that this document should target BCP. However on further
reading I came to the conclusion that this might be two documents, one BCP per
its original goal and one Proposed, defining value-added semantics. See below.
What are the tradeoffs regarding having an MLM verify and use DKIM
identifiers?
This might not need "fixing" but I found myself asking what it means for an MLM
to "use DKIM identifiers"? Perhaps in an Introduction it's ok to say this
without prior setup. Dunno.

Of the four bullets, aren't the latter three the details for the first one?
Terminology
This is a philosophical question: Given a document making normative statements,
aren't the definitions upon which it bases those statements themselves
normative? How can foundational language for normative statements not, itself,
be normative?
2.4. Message Streams
The concept of streams is discussed in the Deployment doc (RFC 5863):

<http://tools.ietf.org/html/rfc5863>

and the DKIM Wikipedia article:

<http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail>

I suggest citing them. We should make sure this doc conforms to their
definition of explains its variation.

By my reading, your text does conform, but your definitional sentence probably
offers a more explicit and complete definition than the other docs.

However...
partition
them somehow (most commonly via DNS subdomains, and/or the "d=" tag
value in the context of DKIM)
If the reference to subdomains isn't for d=, then what does it refer to? If it
does mean the d= value, then the sentence wording is a bit confusing.

More conceptually, what way other than d= subdomains is within the scope of the
DKIM signing specification, for distinguishing among streams?
author: The agent that actually constructed the message
I've been finding myself distinguishing between responsibility for content
versus responsibility for initial handling, and using the term "author" for the
former. "Sender" or "originator" seem to refer to the latter. Your use of
Originator seems to match this.

I've gotten diligent about using the word "content" since that seems to be a
magic way to get people to focus on substance rather than matters of form. That
is, it's where "responsibility" gets much more serious.
There reportedly still exist a few scattered mailing lists in
operation that are actually run manually by a human list manager.
This sentence hangs there, without a label and without context. What is the
reader to do with it?
3.4. Alternatives of Participation and Conformance
While the content of this section seems useful, it doesn't really discuss either
of these as "alternatives". In fact, I initially thought the title meant them
as alternatives to each other! Only by reading later sections did it occur to
me that you meant each to have a "non-" form offered as the alternative.
As DKIM becomes more entrenched, it is highly desirable that MLM
software adopt more DKIM-friendly processing.
It occurs to me that the term "DKIM-friendly" would be far more useful if it
were first defined. I suggest that up in Terminology it be introduced. No
doubt, the details for the term will be subject to some debate. Best conduct
that debate during definition, rather than in the middle of its substantive use...

(It's only used other time, up in Section 1, but my sense is that as a group
we've been using the term more and that it might be worth making it a real
technical term of art.)
considerations (see Section 3.5 of [DKIM]). Its use is therefore
discouraged.
That sounds very much like a SHOULD NOT. Assuming the doc is really going to be
normative, then now's the time to start using the right language.
There is currently no header field proposed for relaying general list
policy details, apart from what [LIST-URLS] already supports. This
sort of information is what is commonly included in appended footer
text or prepended header text. Rather than anticipating or proposing
a new field here for that purpose, the working group recommends
List policy details? Huh?

1) I don't really know what that means

2) I'm not sure why this is being mentioned here

3) Any use of the word "policy" usually works against doing productive work
in these groups.

Seriously. Show me an IETF "policy" specification that's been successful. Show
me a second one.

And "for that purpose"? What purpose? Again, I've missed the context.

Has this morphed into a more general MLM BCP? (I assume this is what the
earlier discussion of such a BCP, sometime back, was about.)
If an author knows that the MLM to which a message is being sent is a
non-participating resending MLM, the author is advised to be cautious
when deciding whether or not to sign the message.
This is the sort of guidance that is comforting to the writer, but has no
practical benefit. Never mind whether an author is ever going to know the
required information. The guidance "be cautious" has no meaning or, at least,
no meaning in a technical specification seeking substance and precision. The
later text, two paragraphs down in the document, acknowledges this problem.
incumbent upon site administrators to consider how support of users
wishing to participate in mailing lists might be accomplished as DKIM
achieves wider adoption.
This text suffers the same problem. Site administrators can't be expected to
have enough knowledge or time "to consider" much about this topic. Rather, this
document should give simple and direct guidance for their choices. Language
like the following "A common suggestion" is exactly what they need an direct,
prescriptive form.

With respect to the guidance being given, there is a gaping hole that is implied
but not cited, although we've already seen it in the wild:

If an organization insists that all mail be signed under the same domain
name that is in the From: header field and it publishes a strict ADSP record,
then it is not possible for mail from that organization to go through a mailing
list. Ever.

Messing with d= is of course irrelevant to this problem.
In general, the
more strict practices and policies are likely to be successful only
for the mail streams subject to the most end-to-end control by the
originating organization. That typically excludes mail going through
MLMs.
And my point is that this language is too soft, modulo debating what "more
strict" means. The document should make a simple statement of the condition and
a simple statement of the result, since I think we understand both.
4.2. Verification Outcomes at Receivers
I think everything said in this section is probably correct, but I am not sure
what it is referring to, within the scope of DKIM. What technical actions do
"Verification Outcomes" refer to?
For example, an MLM might be designed to accomodate a list of
possible signing domains (the "d=" portion of a DKIM signature) for a
given author, and determine at verification time if any of those are
present.
This sounds reasonable, but I'm hard-pressed to believe it's practical.

I think the danger, here, is that listing impractical alternatives gives the
impression of having resolved something that actually remains unresolved.
Per the discussion in [AUTH-RESULTS], there is no a priori reason for
the final receivers to put any faith in the veracity of that header
field when added by the MLM. Thus, the final recipients of the
This is off-topic, but I keep wondering whether there isn't an opportunity for a
value-added function in the form of a header-field, which says something like
"the presence of this header field, when signed by DKIM, means that the contents
cited in this header field are asserted to be 'valid'...

So, for example:

DKIM-Valid: From, Date, Subject, Body

could mean that the signer claims all of that information is "correct", not just
carried correctly. Of course, the signer's DKIM h= also have to cite those
fields, as well as DKIM-Valid.

I think the hard part, here, is deciding whether the signer's d= has any
constraints, and what a receiver might or might not do, depending on who did the
signing.

but as I say, this is off-topic...
A signing MLM is, as any other MLM, free to omit redistribution of a
message from an author if that message was not signed in accordance
with its own local configuration or policy. However, selective
signing is discouraged; essentially that would create two message
streams from the MLM, one signed and one not, which can confuse DKIM-
aware verifiers and receivers.
I don't think I understand what this means. What is "selective signing" and
where is the basis for giving directions about it? This is being used as a term
of art, but I don't think it's been defined and I think that there isn't
community consensus about it. And I'm not sure that anything about it is
dependent upon MLMs.
A recipient that trusts signatures from an MLM may wish to extend
that trust to an [AUTH-RESULTS] header field signed by that MLM. The
"Trust"??? What does that mean, exactly, here? It needs to be defined. Seriously.
Receivers are advised to ignore all unsigned Authentication-Results
header fields.
Oh boy. No doubt this really is good advice, but ultimately it's based on a
value-added semantic that isn't written down anywhere, nevermind "approved"...

Again, I think this document really has two heads -- and possibly three -- and
probably needs to be split into two or three documents. One of them is a BCP
per the original goal. Another the other is a value-added technical
specification for Intermediaries that support DKIM. The third is that generic
MLM doc that folks have been mentioning.

The alternative is to go back and redefine the semantic of a DKIM signature. I
suspect that would cause some existing signers to stop using DKIM, since their
basis for using DKIM entails a much lower level of meaning that is being implied
here.

To be clear, I'm not saying that the value-added semantic is a bad idea. Merely
that it needs to be defined explicitly and, hopefully, in a generic fashion, so
that a receiver does not have to wander all over the header fields trying to
asses assorted interdependencies, before being able to determine what a
signature or a header field means.
Upon DKIM and ADSP evaluation, a receiver may decide to reject a
message during an SMTP session. If this is done, use of an [SMTP]
DKIM and ADSP evaluation are not performed during an SMTP session, unless the
session is delayed after the crlf.crlf, and that's not supposed to happen.
Upon DKIM and ADSP evaluation, a receiver may decide to reject a
message during an SMTP session. If this is done, use of an [SMTP]
Although this is useful text, it isn't in a form that's appropriate for a BCP.
I'm not sure what to suggest.
MLMs are encouraged to apply these or other DKIM failure reporting
mechanisms as a method for providing feedback about issues with DKIM
MLMs SHOULD apply a DKIM failure reporting mechanism, for providing feedback
about...




NITS OR UNCONTROVERSIAL
=======================
to make a claim of responsibility for a message by
affixing a domain-level digital signature to the message
...to make a claim of responsibility by affixing a validated domain-level
identifier to the message...
Although not the only possibility, this is most
commonly done as a message passes through a Mail Transport Agent
(MTA) as it departs an Administrative Mail Domain (ADMD) toward the
general Internet.
Given the short history of DKIM use and the fact that this document will live a
long time, making normative assertions is a bit risky. Perhaps:

One configuration of DKIM use attaches the DKIM signature as a message
passes through a...
Good list. I suggest adding two figures that show a before and after example of
a message, reflecting these modifications.
The above list is not exhaustive, but instead only lists common
modifications. It also does not consider changes the MTA might make
independent of what changes the MLM chooses to apply.
First sentence really is redundant. Perhaps instead:

However note that MLM's vary widely in their behavior, as well as often
allowing subscribers to specify individual treatment. The above list also does
not...
The DKIM specification documents deliberately refrain from the notion
I think the signature doc is the only "DKIM specification document". Singular.
Given how often people say DKIM when they mean ADSP, we'll do better to refer
to them separately. Especially for this statement, since ADSP does not refrain
from the notion...
of tying the signing domain (the "d=" tag in a DKIM signature) to any
This isn't a comment on this draft. It's a broader question: I think I'm
seeing "signing domain" used as the common reference for d=, rather than the
newly-minted SDID term. Does that match other folks' perception?
identifier within a message; any ADMD could sign any message
ADMD could sign any message -> ADMD handling a message can sign it
As such, there is no
specification of any additional value if the content of the "d=" tag
in the DKIM signature and the value of (for example) the RFC5322.From
field match, nor is there any obvious...
Awkward wording. Might not be understood if the reader does not already know
this point. Perhaps:

In particular, DKIM does not define any meaning to the occurrence of a
match between the content of the "d=" tag in the DKIM-Signature: header field
and the value of (for example) a domain name in the RFC5322.
Graham Murray
2010-08-10 05:59:42 UTC
Permalink
Post by Dave CROCKER
DKIM and ADSP evaluation are not performed during an SMTP session, unless the
session is delayed after the crlf.crlf, and that's not supposed to happen.
Anyone using the opendkim sendmail/postfix milter will be doing this
checking during the SMTP session.
Murray S. Kucherawy
2010-08-10 06:56:41 UTC
Permalink
-----Original Message-----
Sent: Monday, August 09, 2010 11:00 PM
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
Anyone using the opendkim sendmail/postfix milter will be doing this
checking during the SMTP session.
For that matter, anyone implementing any kind of filtering using the milter API is specifically doing so during SMTP.

And I think that goes for non-milter implementations that do things with forward-to-pipe mechanisms, which at least Sendmail supports; I'm fairly certain the post-DATA reply only happens when the pipe completes, so that an appropriate SMTP reply can be returned in case the piped-to program fails.

It's pretty universal.
Dave CROCKER
2010-08-10 14:08:19 UTC
Permalink
Post by Murray S. Kucherawy
It's pretty universal.
wow. I had managed to miss this, particularly given the frequent comments from
folk that they wished DKIM could operate at SMTP time. (No doubt, they'd much
rather have it be useful before data transfer, rather than after. Still, during
SMTP is better than later.)

This tidbit probably needs to be touted more. Not sure how.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Hector Santos
2010-08-10 14:39:25 UTC
Permalink
Post by Dave CROCKER
Post by Murray S. Kucherawy
It's pretty universal.
wow. I had managed to miss this, particularly given the frequent
comments from folk that they wished DKIM could operate at SMTP time.
(No doubt, they'd much rather have it be useful before data transfer,
rather than after. Still, during SMTP is better than later.)
This tidbit probably needs to be touted more. Not sure how.
Probably helps to read a wider range of people comments rather than a
selected few. This has been discussed for at least a number of years,
here and in IETF-SMTP and it was discussed immensely during the Thread
Analysis and the SSP Requirements drafting helping to provide
guideline as to when a POLICY was necessary.

Keep in mind that DKIM verification is not always required when ADSP
is supported making a simple DNS lookup useful at the SMTP Level.

For example, the payload is transferred with:

From: ***@paypal.com
DKIM-Signature: d=someother.com

before the response is provided, the author domain, paypal.com ADSP
lookup shows DKIM=DISCARDABLE. Since the DKIM-signature domain is not
paypal.com
no need for any DKIM verification at this point because it would be a
100% zero-false positive condition for instant rejection.

On the other hand it was a 1st party header:

From: ***@paypal.com
DKIM-Signature: d=paypal.com

a valid 1st verification is short-circuits the need for a POLICY
lookup as it would be only possible to get a valid 1st party DKIM
signature with proper 1st party public keys.

As outlined in the SSP requirements, only when the signature failures,
can a POLICY lookup come into play.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Ian Eiloart
2010-08-17 11:08:01 UTC
Permalink
Post by Graham Murray
Post by Dave CROCKER
DKIM and ADSP evaluation are not performed during an SMTP session,
unless the session is delayed after the crlf.crlf, and that's not
supposed to happen.
Anyone using the opendkim sendmail/postfix milter will be doing this
checking during the SMTP session.
Yes, out Exim/Spamassassin installation does DKIM (but not ADSP) evaluation
during the SMTP session.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
Michael Thomas
2010-08-17 13:51:56 UTC
Permalink
Post by Ian Eiloart
Post by Graham Murray
Post by Dave CROCKER
DKIM and ADSP evaluation are not performed during an SMTP session,
unless the session is delayed after the crlf.crlf, and that's not
supposed to happen.
Anyone using the opendkim sendmail/postfix milter will be doing this
checking during the SMTP session.
Yes, out Exim/Spamassassin installation does DKIM (but not ADSP) evaluation
during the SMTP session.
I'm not positive, but I believe that Ironport does it that way too.

Is there anybody who *doesn't* do DNS lookups at SMTP time these days?
That's all DKIM really amounts to, and the entire mail infrastructure would
seize if we weren't (cf, blacklists).

Mike
Hector Santos
2010-08-18 05:53:01 UTC
Permalink
Post by Ian Eiloart
Yes, out Exim/Spamassassin installation does DKIM (but not
ADSP) evaluation during the SMTP session.
I'm not positive, but I believe that Ironport does it that
way too.
Is there anybody who *doesn't* do DNS lookups at SMTP time these
days? That's all DKIM really amounts to, and the entire mail
infrastructure would seize if we weren't (cf, blacklists).
In the past, I followed how implementations of SPF was being done - at
SMTP or post acceptance. I recall it was interestingly spread out
depending on the software being used. Most of the MTAs that allowed
embedded hooking with programming scripts had scripts available and
others used general 2822 text file mail bot SPF scripts.

But I've also followed other MTAs such as YAHOO, AOL, MSN.COM,
gmail.com and so on, where you definitely saw a shift towards DATA
level rejections than in the past.

The only issue overall between the two was how the ENVELOPE
information was read or written into the 2822 file for post smtp to
read. In general, you could get this from the top Received: line
stamped by the MTA (a requirement), but other MTA add specific syntax
envelope info at the top before the 2822 blocks.

At the SMTP level, you don't need to work about that but generally,
the scripting language is proprietary to the MTA engine in use.

So POST SMTP scripts tend to be more general and made to work with for
most MTAs, with no or little change.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy
2010-08-10 06:53:32 UTC
Permalink
A couple of points before I drop for the night from all these edits. I'll pick it up tomorrow, probably after posting an -02 incorporating the editorial feedback so far. Since Dave suggests a fissioning of this document into two or more, I'll hold off applying his until after that's done and some discussion about it has been had.
-----Original Message-----
Sent: Monday, August 09, 2010 3:40 PM
To: Murray S. Kucherawy; DKIM IETF WG
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
When should an author, or its organization, use DKIM for mail sent
to mailing lists?
The word "should" implies an intent to make a normative statement.
This
conflicts with the stated goal of Informational status. So does the distinction
between Normative and Informative references.
Either the goal should be BCP (or even Proposed) or perhaps the language for
this type of statement needs to be softened to something like "Under what
circumstances does..."
My own guess is that this document should target BCP. However on further
reading I came to the conclusion that this might be two documents, one BCP per
its original goal and one Proposed, defining value-added semantics.
See below.
Some time ago we discussed this and the consensus seemed to be (to me, at least) to produce an Informational document on our first pass through this process with an eye towards doing a BCP (in the formal IETF sense) afterwards. I think some people have been calling this a BCP because it generally espouses what we think of as best practices, but that term has some special status meanings in the IETF so perhaps that caused some confusion.

This is why I have been avoiding use of the RFC2119 words in this document to date. So I'm inclined to change it to "Under what circumstances..." as you suggested.

If we have changed our consensus and want to take a run at a full BCP document, I'll happily go through and start using RFC2119 language. Finding ways to avoid using those magic words, even in all-lowercase, can be a little time-consuming.
What are the tradeoffs regarding having an MLM verify and use DKIM
identifiers?
This might not need "fixing" but I found myself asking what it means for an MLM
to "use DKIM identifiers"? Perhaps in an Introduction it's ok to say this
without prior setup. Dunno.
The document goes into what that means, particularly in terms of verifying signatures inbound to the MLM and then signing mail outbound from the MLM. And it seems to me "use DKIM" means exactly the same thing as "use DKIM identifiers", since the carrying of a verified identifier is precisely the point of applying DKIM.
2.4. Message Streams
<http://tools.ietf.org/html/rfc5863>
<http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail>
I suggest citing them. We should make sure this doc conforms to their
definition of explains its variation.
Naturally I'm fine citing RFC5863 and ensuring this document's definitions match the ones found there, but do we really want to cite a Wikipedia article?

(cf: http://www.theonion.com/articles/wikipedia-celebrates-750-years-of-american-indepen,2007/)
There is currently no header field proposed for relaying general
list
policy details, apart from what [LIST-URLS] already supports.
This
sort of information is what is commonly included in appended
footer
text or prepended header text. Rather than anticipating or
proposing
a new field here for that purpose, the working group recommends
List policy details? Huh?
1) I don't really know what that means
2) I'm not sure why this is being mentioned here
3) Any use of the word "policy" usually works against doing productive work
in these groups.
Seriously. Show me an IETF "policy" specification that's been
successful. Show
me a second one.
It's not an effort at talking about any policy stuff in the IETF normative sense. I'm talking about MLM configuration features, which are themselves expressions of the list admin's policies. It's way outside of what I think you're talking about.
4.2. Verification Outcomes at Receivers
I think everything said in this section is probably correct, but I am not sure
what it is referring to, within the scope of DKIM. What technical actions do
"Verification Outcomes" refer to?
Weren't you the one that suggested this title? :-)
This is off-topic, but I keep wondering whether there isn't an
opportunity for a
value-added function in the form of a header-field, which says
something like
"the presence of this header field, when signed by DKIM, means that the contents
cited in this header field are asserted to be 'valid'...
DKIM-Valid: From, Date, Subject, Body
could mean that the signer claims all of that information is "correct", not just
carried correctly. Of course, the signer's DKIM h= also have to cite those
fields, as well as DKIM-Valid.
Didn't we toss out that argument when debating whether "i=" had any practical use, because any assertion it claimed by the signer couldn't be independently verified?
A recipient that trusts signatures from an MLM may wish to extend
that trust to an [AUTH-RESULTS] header field signed by that MLM.
The
"Trust"??? What does that mean, exactly, here? It needs to be defined. Seriously.
[AUTH-RESULTS] talks extensively about trusting (or not) the content of the header field. As it's a normative reference, is the term used unreasonably here?
Dave CROCKER
2010-08-10 14:06:08 UTC
Permalink
Post by Murray S. Kucherawy
Since Dave suggests a fissioning of this document into two or more, I'll hold
off applying his until after that's done and some discussion about it has
been had.
I'm a fan of getting the mix and balance of documents right. Extra documents
are a hassle, but a single document that mixes agendas is too. I was a bit
surprised to make the suggestion that this doc get split.

1. Are there different topics? If so, what are they and which should be
pursued? The working groups needs to comment on this.

I think I saw 3 different topics, and that there has already been a bit of
discussion about this. The topics are:

a. Handling DKIM messages transiting a Mailing List Manager

b. Trust-based enhancements for Mailing List Managers based on DKIM

c. Best practices for Mailing List Managers

The first is/was the official goal of the current work.

The latter two have emerged. Neither is formally within scope of the working
group, although b. is a natural addition. Note, however, that it is formal
protocol specification work and we need to worry about adoption first -- who
needs to adopt it and why do we think they will?

c. is not reasonably in scope; I do not see any way to justify it within this
working group, in spite of there having been some good discussion.


2. If a split is appropriate, how should the existing content be divided?

I vote for letting Murray handle this. (You're welcome, Murray.)

So, the first question is intended to get some working group consensus, before
Murray puts in the effort of dividing things up.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Stephen Farrell
2010-08-10 14:32:50 UTC
Permalink
So it seems reasonable for folks to discuss this for a few days
and if a consensus is clear we can go from there. Otherwise maybe
we can poll about in next week or so. (Other suggestions welcome,
particularly from Murray as editor.)

S.
Post by Dave CROCKER
Post by Murray S. Kucherawy
Since Dave suggests a fissioning of this document into two or more, I'll hold
off applying his until after that's done and some discussion about it has
been had.
I'm a fan of getting the mix and balance of documents right. Extra documents
are a hassle, but a single document that mixes agendas is too. I was a bit
surprised to make the suggestion that this doc get split.
1. Are there different topics? If so, what are they and which should be
pursued? The working groups needs to comment on this.
I think I saw 3 different topics, and that there has already been a bit of
a. Handling DKIM messages transiting a Mailing List Manager
b. Trust-based enhancements for Mailing List Managers based on DKIM
c. Best practices for Mailing List Managers
The first is/was the official goal of the current work.
The latter two have emerged. Neither is formally within scope of the working
group, although b. is a natural addition. Note, however, that it is formal
protocol specification work and we need to worry about adoption first -- who
needs to adopt it and why do we think they will?
c. is not reasonably in scope; I do not see any way to justify it within this
working group, in spite of there having been some good discussion.
2. If a split is appropriate, how should the existing content be divided?
I vote for letting Murray handle this. (You're welcome, Murray.)
So, the first question is intended to get some working group consensus, before
Murray puts in the effort of dividing things up.
d/
MH Michael Hammer (5304)
2010-08-10 15:59:29 UTC
Permalink
a and b. c is well outside the scope. Stick with informational for now.
-----Original Message-----
Sent: Tuesday, August 10, 2010 10:33 AM
Cc: DKIM IETF WG
Subject: Re: [ietf-dkim] Splitting the mailing list document?
So it seems reasonable for folks to discuss this for a few days
and if a consensus is clear we can go from there. Otherwise maybe
we can poll about in next week or so. (Other suggestions welcome,
particularly from Murray as editor.)
S.
Post by Dave CROCKER
Post by Murray S. Kucherawy
Since Dave suggests a fissioning of this document into two or more,
I'll hold
Post by Dave CROCKER
Post by Murray S. Kucherawy
off applying his until after that's done and some discussion about
it
has
Post by Dave CROCKER
Post by Murray S. Kucherawy
been had.
I'm a fan of getting the mix and balance of documents right. Extra
documents
Post by Dave CROCKER
are a hassle, but a single document that mixes agendas is too. I
was a
bit
Post by Dave CROCKER
surprised to make the suggestion that this doc get split.
1. Are there different topics? If so, what are they and which
should
be
Post by Dave CROCKER
pursued? The working groups needs to comment on this.
I think I saw 3 different topics, and that there has already
been a
bit of
Post by Dave CROCKER
a. Handling DKIM messages transiting a Mailing List Manager
b. Trust-based enhancements for Mailing List Managers based on
DKIM
Post by Dave CROCKER
c. Best practices for Mailing List Managers
The first is/was the official goal of the current work.
The latter two have emerged. Neither is formally within scope of
the
working
Post by Dave CROCKER
group, although b. is a natural addition. Note, however, that it is
formal
Post by Dave CROCKER
protocol specification work and we need to worry about adoption
first --
who
Post by Dave CROCKER
needs to adopt it and why do we think they will?
c. is not reasonably in scope; I do not see any way to justify it
within
this
Post by Dave CROCKER
working group, in spite of there having been some good discussion.
2. If a split is appropriate, how should the existing content be
divided?
Post by Dave CROCKER
I vote for letting Murray handle this. (You're welcome, Murray.)
So, the first question is intended to get some working group
consensus,
before
Post by Dave CROCKER
Murray puts in the effort of dividing things up.
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Murray S. Kucherawy
2010-08-10 16:56:16 UTC
Permalink
-----Original Message-----
Sent: Tuesday, August 10, 2010 7:06 AM
To: DKIM IETF WG
Subject: [ietf-dkim] Splitting the mailing list document?
c. Best practices for Mailing List Managers
If the document has indeed wandered off into this more general area (and I'd have to re-read it to find the parts you're talking about), we should reel it back in. I don't want to maintain a general treatise on how MLMs should behave unless perhaps I manage to enlist some co-authors of major current MLMs to do so.

I think the other two are within scope and would probably be fine to include in a single document.
The latter two have emerged. Neither is formally within scope of the working
group, although b. is a natural addition. Note, however, that it is formal
protocol specification work and we need to worry about adoption first -
- who
needs to adopt it and why do we think they will?
Is that really true? The document is informational and is deliberately avoiding being normative about anything. Its posture is intended to convey experience of the industry so far in deploying DKIM and MLMs in tandem, and provide some suggestions of how that co-operation could be improved.
Dave CROCKER
2010-08-10 17:09:16 UTC
Permalink
Post by Murray S. Kucherawy
Post by Dave CROCKER
The latter two have emerged. Neither is formally within scope of the
working group, although b. is a natural addition. Note, however, that it
is formal protocol specification work and we need to worry about adoption
first - - who needs to adopt it and why do we think they will?
Is that really true? The document is informational and is deliberately
avoiding being normative about anything. Its posture is intended to convey
experience of the industry so far in deploying DKIM and MLMs in tandem, and
provide some suggestions of how that co-operation could be improved.
The comment was about b, which specified additional semantics and a set of
conventions (that is, a protocol) for achieving it. This is the extra
header-field I suggested. The current draft touches this realm, but clearly
it's beyond the scope of your current project. Rather, the current effort is
prompting us to note some related issues.

As for Informational, I'll repeat that the core of your draft -- the part that
is entirely withing the direct scope as I understand it -- contains normative
language. And I think that's appropriate. But that makes it not Informational,
but probably a BCP.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
B***@cox.com
2010-08-10 14:16:23 UTC
Permalink
Should DKIM transit a mailing list?
if a message arrives at a list manager the author/sender theoretically should be a pre-qualified by whatever means used to be a member of that list. Any recipient that has subscribed to that list has a reasonable expectation that any message addressed to the list would be interesting. With that in mind all signatures should be discarded, resigned by the dkim aware mailing list then forwarded on as if it is a "new" mail message. Now whether a dkim aware mailing list should follow adsp practices is worth discussing.
thanks,
Bill Oxley
Post by Dave CROCKER
Post by Murray S. Kucherawy
Since Dave suggests a fissioning of this document into two or more, I'll hold
off applying his until after that's done and some discussion about it has
been had.
I'm a fan of getting the mix and balance of documents right. Extra documents
are a hassle, but a single document that mixes agendas is too. I was a bit
surprised to make the suggestion that this doc get split.
1. Are there different topics? If so, what are they and which should be
pursued? The working groups needs to comment on this.
I think I saw 3 different topics, and that there has already been a bit of
a. Handling DKIM messages transiting a Mailing List Manager
b. Trust-based enhancements for Mailing List Managers based on DKIM
c. Best practices for Mailing List Managers
The first is/was the official goal of the current work.
The latter two have emerged. Neither is formally within scope of the working
group, although b. is a natural addition. Note, however, that it is formal
protocol specification work and we need to worry about adoption first -- who
needs to adopt it and why do we think they will?
c. is not reasonably in scope; I do not see any way to justify it within this
working group, in spite of there having been some good discussion.
2. If a split is appropriate, how should the existing content be divided?
I vote for letting Murray handle this. (You're welcome, Murray.)
So, the first question is intended to get some working group consensus, before
Murray puts in the effort of dividing things up.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Murray S. Kucherawy
2010-08-10 17:49:30 UTC
Permalink
-----Original Message-----
Sent: Tuesday, August 10, 2010 7:16 AM
Subject: [ietf-dkim] dkim and mailing lists
Should DKIM transit a mailing list?
if a message arrives at a list manager the author/sender theoretically
should be a pre-qualified by whatever means used to be a member of that
list. Any recipient that has subscribed to that list has a reasonable
expectation that any message addressed to the list would be
interesting. With that in mind all signatures should be discarded,
resigned by the dkim aware mailing list then forwarded on as if it is a
"new" mail message. Now whether a dkim aware mailing list should follow
adsp practices is worth discussing.
Bill,

Have you read the draft?

A lot of this is already discussed in there. If you have specific feedback about the text that's in there already, that would be really helpful.
Charles Lindsey
2010-08-11 20:22:48 UTC
Permalink
Post by B***@cox.com
Should DKIM transit a mailing list?
if a message arrives at a list manager the author/sender theoretically
should be a pre-qualified by whatever means used to be a member of that
list.
Not necessarily so. There exist lists to which anyone may post (and in
which actual subscription is by invitation).
Post by B***@cox.com
Any recipient that has subscribed to that list has a reasonable
expectation that any message addressed to the list would be interesting.
With that in mind all signatures should be discarded, resigned by the
dkim aware mailing list then forwarded on as if it is a "new" mail
message.
I agree about the "new" mail message, but how do subsequent agents as the
forwarded mail is propagated "know" that it is new, unless the From: is
changed? To them, it is indistinguishable from a mail from someone at the
original discardable domain.

Note than you cannot assume the ultimate recipient is in a position to
identify special cases that apparently are unsigned emissions from a
discardable domain. Our normal expecation is that will be done by his
boundary ISP (where his mailbox is likely to be kept).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 
   Web: http://www.cs.man.ac.uk/~chl
Email: ***@clerew.man.ac.uk      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
Murray S. Kucherawy
2010-08-20 18:40:37 UTC
Permalink
-----Original Message-----
Sent: Tuesday, August 10, 2010 7:06 AM
To: DKIM IETF WG
Subject: [ietf-dkim] Splitting the mailing list document?
I think I saw 3 different topics, and that there has already been a bit of
a. Handling DKIM messages transiting a Mailing List Manager
b. Trust-based enhancements for Mailing List Managers based on DKIM
c. Best practices for Mailing List Managers
[...]
2. If a split is appropriate, how should the existing content be divided?
I vote for letting Murray handle this. (You're welcome, Murray.)
So, the first question is intended to get some working group consensus, before
Murray puts in the effort of dividing things up.
Ah, the deafening silence...

After thinking about it for a while, I believe it would be fine to fork the document as described. Given the working group's scope and charter, and in the absence of any objection, I propose the following:

1) The current document covers what you have as (a) above with no change to name, and an intended status change to BCP.

2) The parts of the current document suggesting possible enhancements become a new WG document with a similar name. The status of this document would be Informational.

3) A general BCP for lists irrespective of DKIM is probably something the email world should have. I'd be fine with this being either Informational or BCP status. I would take this up as an individual submission and probably move it through the APPS area, but I would really like to hear from some of the MLM maintainers, past and present, on this list willing to help with that work before I agree to add it to my queue.

None of this will happen before the start of September in any case, but I thought I should finally reply to this.

-MSK
John Levine
2010-08-09 22:57:14 UTC
Permalink
Post by Dave CROCKER
Upon DKIM and ADSP evaluation, a receiver may decide to reject a
message during an SMTP session. If this is done, use of an [SMTP]
DKIM and ADSP evaluation are not performed during an SMTP session, unless the
session is delayed after the crlf.crlf, and that's not supposed to happen.
Why not? My MTA usually does a whole spamassassin run between the end
of data and the ack. It adds maybe five seconds, at a point where 5321
says the timeout should be ten minutes.

R's,
John
Dave CROCKER
2010-08-09 23:37:38 UTC
Permalink
Post by John Levine
Post by Dave CROCKER
DKIM and ADSP evaluation are not performed during an SMTP session, unless the
session is delayed after the crlf.crlf, and that's not supposed to happen.
Why not? My MTA usually does a whole spamassassin run between the end
of data and the ack. It adds maybe five seconds, at a point where 5321
says the timeout should be ten minutes.
It's considered bad form to hold up senders that way. For one thing, it adds
non-determinacy at a point which can produce retransmissions.

I'm sure you're not the only one doing it, but as I recall, the standards to no
institutionalize anything that forces it.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Ian Eiloart
2010-08-17 11:06:22 UTC
Permalink
Post by Dave CROCKER
Post by John Levine
Post by Dave CROCKER
DKIM and ADSP evaluation are not performed during an SMTP session,
unless the session is delayed after the crlf.crlf, and that's not
supposed to happen.
Why not? My MTA usually does a whole spamassassin run between the end
of data and the ack. It adds maybe five seconds, at a point where 5321
says the timeout should be ten minutes.
It's considered bad form to hold up senders that way. For one thing, it
adds non-determinacy at a point which can produce retransmissions.
Yep. My experience is that MS Outlook MUA does this, but I think I've only
ever seen one incident where an MTA did so.

My belief is that best practice is to queue password authenticated email
submissions, and bounce later if necessary (but not to bounce to a
non-local domain). Unauthenticated mail should be scanned at SMTP time, and
rejected at SMTP time if necessary.

Mail that's authenticated by DKIM, could, perhaps, be treated as
bounceable. However, I think one might only want to apply that rule when
there's some clear relationship between the RETURN PATH address and the
signing domain. For example, if the return path address matches the From
header address, and the
Murray S. Kucherawy
2010-08-10 05:29:58 UTC
Permalink
My replies inline. In a few places I've argued in favour of leaving the current text as-is, but I'm open to further debate of course.
-----Original Message-----
Sent: Thursday, July 29, 2010 4:21 AM
Subject: draft-ietf-dkim-mailinglists-01 review
1. Introduction
(moderate importance)
After much discussion and editing I think these questions need to be
rebalanced based on content presented.
question 1 - the discussion of this draft covers the "When and how"
related to
an author domain so I think this question should start the same way.
The "how"
is the message streams suggestion.
question 2&4 aren't really discussed as trade-offs but more "How can a
MLM be
constucted in DKIM friendly way?" and I think this should be the
question.
I think in some ways it is definitely the question, but taking up a posture of "How can MLMs fix themselves to work in the DKIM world?" is not the right way to put it. As I'm sure others will be quick to point out, a lot of the things MLMs do are entrenched, perhaps reasonably so, and it will take a lot of hard arguing to convince them to change and for everyone to roll out those changes and participate, affecting countless users.

The softer approach taken here is to evaluate the impact of not changing and contrasting it to what things would be like if they did, and let them decide for themselves.
1.3. Feedback Loops And Other Bi-Lateral Agreements
(minor)
Add reference to section 6 DKIM Reporting
Done.
2.3. Feedback Loop References
(very minor) Better title = "Feedback Loop Formats"?
The 2.x sections are just introducing terminology and references to other documents where such terminology is discussed rather than discussing the material there.
1.1 and 3.3 duplicate content with respect to what MLM modifications
occur
(minor) is this too much(?)
You're right. 1.1 can just refer to 3.3.
3.3.
(minor)" There reportedly still exist a few scattered mailing lists in
operation that are actually run manually by a human list manager
"
I suspect this is true but its relevance to DKIM MLM isn't discussed.
True; I suppose I thought what was said there was enough to evoke people's imaginations, but I'll make that more explicit.
3.4 Alternatives of Participation and Conformance
(moderate importance)
[...]
Actually on re-reading, Section 3.4 doesn't really fit in with the rest of Section 3, which just lays out the current story. Thanks for these suggestions.
4.3. Handling Choices at Receivers
(moderate imprtance)
I'm not convinced there is a filtering solution described in 4.1 as
stated.
You're right; "filtering" there should refer to the sign/don't-sign decision 4.1 discusses. I'll fix that.
5.2 Author-Related Signing
(moderate importance)
Paragraphs 2 and 3 are related to author stream signing more that
Participating MLMs.
The title of Section 5 is meant to cover a number of sub-issues that come into play when considering activity to, from or through a participating MLM. Certainly the author stream is part of that.
While a small section of the paragraph 1 and 5.3 is
relevant to the correlation between domains perhaps ordering and
relableing it
5.2 DKIM Authentication
current paragraph 1.
merge with 5.3 (except last paragraph)
I agree with the repositioning of the first paragraph, but I think the section headings are fine.
5.2.1 DKIM Verification and message streams
substantially the 2&3 paragtraphs from 5.2 with less duplication of the
section 2.4 defination.
I've done some other rearranging in there now. Let me know what you think once -02 is published.
5.3 Verification Outcomes at MLMs
(moderate)
Last paragraph on Authenticaticated results is a separate topic to the
verification of the message for the MLM purposes. As such I think it
should be
in its own section 5.Z Authenticated Results.
Since the rest of Section 5 is a walk-through of the various steps of the processing of a signed message as it arrives at and transits an MLM, I think this text is in the right place.
5.4. Pros and Cons of Signature Removal
(minor)
1&2 Refer to 5.2 Author-Related Signing (or DKIM Authentication if
renamed as
suggested)
3. Refer to 5.Z Authenticated Results
5. Affix a new DKIM signature as per 5.X MLM Signatures
Done, but only for the last one; I think the back-reference to adjacent sections is a bit redundant.
5.5. DKIM Author Domain Signing Practices
(moderate)
This is essentially a duplication/expansion of 5.1 Subscriptions.
Suggest
merging these two. A warning could be appended here that rejecting a
subscription based on ADSP=discardable could be overly harsh as the
subscriber
may only intend to receive email from the list.
Did some reworking of these as well.
5.6 MLM Signatures
(serious)
"
A DKIM-aware resending MLM is encouraged to sign the entire message
as it arrived (i.e. the "MLM Input" from Section 3.2), especially
including the original signatures.
"
I'm not sure of the purpose here. This is going to be adding a
signature that
will never pass validation outside the ADMD of the MLM. It also may be
substantially the same (with few parameter diffences aside) as the
original
signature. So why? Is this solely here to support input/output
difference
comparison?
You're right, this is incorrect. What should be signed is the MLM Output.
(serious)
"Operators of non-DKIM-aware MLMs could arrange to submit MLM mail
through an MSA that is DKIM-aware so that its mail will be signed."
While I totally agree with the advice here I suspect this could be
better
placed in a new section '4.X Wrapping a Non-Participating MLM'. Futher
more,
to this section could be added a set of themes associated with 5.1/5.2.
e.g Messages to list subscription addresses could receive a warning if
they
contain a ADSP=discardable similar to section 5.X. Message to a MLM
resending
address with a ADSP of discardable could be rejected as per section
(ref).
I think that's probably a good idea. I've added a "Wrapping..." section at the end of Section 4.
New section 4.X Wrapping a Non-Participating MLM and 5.WRejection of
DKIM
signature failures
(for discussion)
Though in controvention of the current advice of treating DKIM-
signature
failures the same as no signature, I dare to propose something
different based
1. MLM are the predominate signature breaking software
2. MLM are rarely chained as this creates a inconsistant subscriber
lists [...]
As such I suspect that a MLM-Input will always receive an DKIM
signature
intact. My dare of a proposal is that a deployment option for a
participating
MLM or a Wrapped Non-Paricipating MLM could be to reject DKIM signature
failures on its input. Thoughts? disagreements? Did I suggest this
before? if
so - sorry.
I don't think this is necessarily a bad idea -- indeed, early data from OpenDKIM suggests this may even be likely -- but I don't know that this document should recommend or suggest it. It certainly is something an MLM implementer could decide to do.

On the other hand if the data collected by the WG shows that signature survival rates are generally pretty high, maybe this isn't such a crazy idea.
5.7. Verification Outcomes at Final Receiving Sites
(serious)
This isn't particular to participating MLMs and there I think it
deserves a
single number top level heading. Merge with 5.9. Handling Choices at
Receivers
on a new top level number.
I think it fits within the overall Section 5 (Participating MLMs) story, so it's OK where it is.
5.8. Use With FBLs
(minor/clarification)
An "FBL operator" is a receiver?
Yes.
"Where the FBL" which party of the FBL is this?
Yes, this needs clarification. I'll do so in -02.
8.1. Authentication Results When Relaying
(new)
[...]
I've used your text in a bit of a simpler form.

Thanks for your feedback! I'll watch for your "MUA Considerations" text.

-MSK
Daniel Black
2010-08-31 06:36:16 UTC
Permalink
Post by Murray S. Kucherawy
I've done some other rearranging in there now. Let me know what you think
once -02 is published.
Section 5 looks a lot better. Well done.

5.3 Subscriptions

(minor) "disallow or" suggest removal

I think disallow is going to far. The subscription to a list doesn't imply an
intent to post. Depending on the list type of couse this may not be possible.
Post by Murray S. Kucherawy
Though in controvention of the current advice of treating DKIM-
signature
failures the same as no signature, I dare to propose something
different based
1. MLM are the predominate signature breaking software
2. MLM are rarely chained as this creates a inconsistant subscriber
lists [...]
As such I suspect that a MLM-Input will always receive an DKIM
signature
intact. My dare of a proposal is that a deployment option for a
participating
MLM or a Wrapped Non-Paricipating MLM could be to reject DKIM signature
failures on its input. Thoughts? disagreements? Did I suggest this
before? if
so - sorry.
I don't think this is necessarily a bad idea -- indeed, early data from
OpenDKIM suggests this may even be likely -- but I don't know that this
document should recommend or suggest it. It certainly is something an MLM
implementer could decide to do.
On the other hand if the data collected by the WG shows that signature
survival rates are generally pretty high, maybe this isn't such a crazy
idea.
how are the stats looking?
Post by Murray S. Kucherawy
Thanks for your feedback! I'll watch for your "MUA Considerations" text.
reworked based on feedback:

ANNEX A - MUA Considerations

The main body of this document describes a number of MLM behaviours that break
DKIM signatures. These behaviours are, in some cases, features required by MLM
operators to forfill technical, policy or legal requirements. Some of these
behaviours operate in such a way that breaks DKIM signatures and have
alternate implementations that will also meet the needs of MLM operators.

Header Footer additions

Header/Footer additions on MLM can include unsubscribe information describing
to the user how to unsubscriber from a MLM

MLM are recommended by LIST-ID to include a List-Unsubscribe header field. In
the presence of MUA support this would depreciate the necessity of
Header/Footer additions for unsubscribe information.

MUAs are recommended to present to the user the List-Unsubscribe header field
URL in such a way that they can utilize this URL easily to unsubcribe from the
email list.

Subject Header Modifications

A reasonable number of MLM list subscribers potentially still recognise and
filter messages based on the subject line. The subject line modification is as
effective as a List-ID filtering and MLMs are recommended to include this
header field.

A MUA could implement the following features to reduce the need for signature
modifications:
* Display of the List-ID header field is used present the name of the list to
the user.
* functionality to create a filter based on based on the List-ID header field.

Authenticated Results

[AUTH-RESULTS] describes how a MUA could use the Authenticated-Results header
field to present DKIM validation information to the user. This is particularly
important where the presence of broken author domain signatures are present
and the presence of MLM dkim signatures may be used for alternative
authenticity or filtering determinations.

A MUA could use the Authenticated-Results header field to:
* Display what authentication was performed by the verifier
* Create a display and filtering options based where on common domains occur
in list-post header fields and DKIM signatures (recommended in section 5.7)

The security considerations of AUTH-RESULTS need to be carefully addressed by
the MUA to prevent deliberate exploitation of user perceived integrity
information.
J.D. Falk
2010-08-31 22:37:36 UTC
Permalink
Post by Daniel Black
ANNEX A - MUA Considerations
Is a draft about mailing lists the right place to make recommendations to MUA developers? Seems like those should probably be in a separate document.

(This is not to say that I disagree with the recommendations themselves, of course.)
Hector Santos
2010-08-31 23:14:03 UTC
Permalink
Post by J.D. Falk
Post by Daniel Black
ANNEX A - MUA Considerations
Is a draft about mailing lists the right place to make
recommendations to MUA developers? Seems like those should probably
be in a separate document.
(This is not to say that I disagree with the recommendations
themselves, of course.)
Ideally, we need another "bible" like the classic RFC 1123:

Requirements for Internet Hosts -- Application and Support
http://www.ietf.org/rfc/rfc1123.txt

which put it all together for Internet Hosting systems. RFC 1123 was
especially helpful for integrated operations and systems.

Too many documents, too many of one altering or updating the other and
unfortunately sometimes incoherently and inconsistently.

While I personally believe the current documents on the WG table
should be "fixed" to codify the engineering semantics, if that can't
happen (and doubt it will), a document that puts it all together like
a RFC 1103 for DKIM operations on both the HOST and CLIENT side would
be very valuable.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Daniel Black
2010-08-31 23:01:03 UTC
Permalink
Post by J.D. Falk
Post by Daniel Black
ANNEX A - MUA Considerations
Is a draft about mailing lists the right place to make recommendations to
MUA developers? Seems like those should probably be in a separate
document.
Seems as though the draft is touching on authors, signers and verifiers
touching on the receiver and their considerations and view of dkim and mailing
lists would just complete the picture. just my humble opinion.
Post by J.D. Falk
(This is not to say that I disagree with the recommendations themselves, of course.)
thanks.
John Levine
2010-08-10 22:49:24 UTC
Permalink
Post by Murray S. Kucherawy
But what you're saying seems antithetical to most of the document,
which goes to some lengths to describe ways that MLMs and DKIM can
co-operate better. So should we not bother?
Oh no. (That is. we shouldn't not bother.) There's plenty of good
stuff in your draft, but on reflection I think the key is for the DKIM
camp to be modest in its claims and goals. Mailing lists do what they
have done for 30 years, and they're not going to change in any major
way. To the extent that DKIM can help them do what they're going to
do anyway, it's useful.

The discussion of different kinds of lists is certainly helpful, but
we risk going into the weeds when we start getting into complex
analyses and advice for scenarios that seem (to me at least) pretty
far fetched.

So, for example, one of the things that lists have always done is send
mail to people who have subscribed and presumably want it. Signing
the outgoing mail should help receipients recognize the mail they
want, so it makes sense to recommend that.

On the other hand, providing per-contributor reputation clues to
subscribers (beyond what's on the From: line) is something that lists
have never done, so I think it's a poor idea to try to invent ways to
do that.

Does that make sense?

R's,
John
B***@cox.com
2010-08-10 23:08:10 UTC
Permalink
+1
Post by John Levine
Post by Murray S. Kucherawy
But what you're saying seems antithetical to most of the document,
which goes to some lengths to describe ways that MLMs and DKIM can
co-operate better. So should we not bother?
Oh no. (That is. we shouldn't not bother.) There's plenty of good
stuff in your draft, but on reflection I think the key is for the DKIM
camp to be modest in its claims and goals. Mailing lists do what they
have done for 30 years, and they're not going to change in any major
way. To the extent that DKIM can help them do what they're going to
do anyway, it's useful.
The discussion of different kinds of lists is certainly helpful, but
we risk going into the weeds when we start getting into complex
analyses and advice for scenarios that seem (to me at least) pretty
far fetched.
So, for example, one of the things that lists have always done is send
mail to people who have subscribed and presumably want it. Signing
the outgoing mail should help receipients recognize the mail they
want, so it makes sense to recommend that.
On the other hand, providing per-contributor reputation clues to
subscribers (beyond what's on the From: line) is something that lists
have never done, so I think it's a poor idea to try to invent ways to
do that.
Does that make sense?
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Murray S. Kucherawy
2010-08-11 04:54:44 UTC
Permalink
-----Original Message-----
Sent: Tuesday, August 10, 2010 3:49 PM
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-
mailinglists-01 review request
On the other hand, providing per-contributor reputation clues to
subscribers (beyond what's on the From: line) is something that lists
have never done, so I think it's a poor idea to try to invent ways to
do that.
Does that make sense?
Sure. I got the impression this was something we should be saying based on earlier conversation about whether the list should sign coupled with whether the list should drop author signatures. Part of that chatter had to do with combined reputation of the list and the author. If that's a real concern, then on one hand a list/you can gain from the reputation of the other, but on the other hand you can both suffer because of other traffic on the list. This seemed to be a logical extension of that discussion.

If we feel that's too much of a leap, I can just remove that paragraph.
Douglas Otis
2010-08-11 14:27:16 UTC
Permalink
Post by Murray S. Kucherawy
-----Original Message-----
Sent: Tuesday, August 10, 2010 3:49 PM
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-
mailinglists-01 review request
On the other hand, providing per-contributor reputation clues to
subscribers (beyond what's on the From: line) is something that lists
have never done, so I think it's a poor idea to try to invent ways to
do that.
Does that make sense?
Sure. I got the impression this was something we should be saying based on earlier conversation about whether the list should sign coupled with whether the list should drop author signatures. Part of that chatter had to do with combined reputation of the list and the author. If that's a real concern, then on one hand a list/you can gain from the reputation of the other, but on the other hand you can both suffer because of other traffic on the list. This seemed to be a logical extension of that discussion.
If we feel that's too much of a leap, I can just remove that paragraph.
DKIM does not confirm the identity of individuals, only the
administrative domain of the signer. The recipient would need to trust
the Authentication-Results header, before any information would be
meaningful beyond what is known about the list itself, such as whether
it provides List-ID headers, confirms the email-address of subscribers,
removes deceptive A-R headers, etc.

-Doug
Dave CROCKER
2010-08-11 16:49:41 UTC
Permalink
Post by Murray S. Kucherawy
Sure. I got the impression this was something we should be saying based on
earlier conversation about whether the list should sign coupled with whether
the list should drop author signatures. Part of that chatter had to do with
combined reputation of the list and the author. If that's a real concern,
then on one hand a list/you can gain from the reputation of the other, but on
the other hand you can both suffer because of other traffic on the list.
This seemed to be a logical extension of that discussion.
If we feel that's too much of a leap, I can just remove that paragraph.
I think that the underlying sentiments of this sub-section are reasonable. But
I am concerned that it's focus and details are muddled. Unfortunately I think
that's because our group sense of the topic is still muddled, rather than
anything as simple to fix as Murray's writing. Certainly mine is muddled.

So I can't immediately offer modified text. The best I can suggest is some
further scrutiny. To that end:

1. "unexpected"

An author usually knows they are sending to an MLM. While they might not
know the actual recipient list, I would not class it as "unexpected". Worse,
I'm not sure this issue is relevant to the underlying concern here. Or, to the
extent it is, I'm not clear how. This might warrant explication.


2. "coupled with other messages"

This implies that a digest message might affect the reputation associated
with an author of a message in the digest. Do we really think this is
plausible? How?


3. "insulate one's reputation from influence by the unknown results"

This is a hugely substantive topic and frankly scares me. It seems to be at
the heart of this sub-section but I suspect it is a much, much bigger topic.
For starters, is it realistic to pursue this goal at all?


4. "authors may be well-advised to create a mail stream specifically used for"

This raises the very basic question of whether an author can create/define a
mail stream? If so, how? If not, then the premise of this advice is defeated.
For that matter, since mail streams are defined by signing sub-domains, are we
sure that that is relevant to this problem? If the original signature is
broken, the benefit of having different d= values is lost.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Murray S. Kucherawy
2010-08-11 17:03:05 UTC
Permalink
-----Original Message-----
Sent: Wednesday, August 11, 2010 9:50 AM
To: Murray S. Kucherawy
Subject: Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-
mailinglists-01 review request
I think that the underlying sentiments of this sub-section are
reasonable. But
I am concerned that it's focus and details are muddled. Unfortunately I think
that's because our group sense of the topic is still muddled, rather than
anything as simple to fix as Murray's writing. Certainly mine is muddled.
[...]
I suspect some of the cause of that is that this sort of work necessarily contains some "forward-looking statements" (to borrow from the financial sector). As John likes to point out, we've never filtered email based on this criterion in the past x years, but in part that's because we've never been able to do so before. It's possible this will create a mechanism people will find more useful or accurate. I don't want to stifle that possibility before anyone even has a chance to try it.

We have at best an educated guess about how different signature patterns on a message, or on a digest of messages, will affect the reputations of the signers. I'm torn between describing such a guess in an informational document and saying nothing at all, if only to get the readers thinking about it as well.

We've decided the industry wants or needs guidance, so we want to give some. But the work starts to suffer when the thinking drifts into navel-gazing. I don't have any problem admitting that I can be guilty of it; I'd rather be thinking about it than not.

Anyhow, this is what reviewers are for. :-)

-MSK
John Levine
2010-09-01 09:18:02 UTC
Permalink
Post by J.D. Falk
Post by Daniel Black
ANNEX A - MUA Considerations
Is a draft about mailing lists the right place to make recommendations
to MUA developers? Seems like those should probably be in a separate
document.
No, but the entire document is riddled with advice that has no basis
in experience and is unlikely ever to be implemented.

We have a serious problem that people in this group have deeply
incompatible ideas of what DKIM does. A lot of the arguments seem to
be from people who believe that a DKIM signature can or should
identify the individual author of a message, and that subscribers to
mailing lists need assurances about the identity of list authors
beyond the minimal level that has been adequate for the past twenty
years. I have trouble understanding how anyone who is familiar with
DKIM or with the operation of mailing lists could hold these
positions, but it is quite obvious that some do.

At this point, unless we can cut back the MLM document to stick to
items that we have consensus about, e.g., that it is typical for
signatures applied to incoming mail not to verify after a message
passes through an MLM, and that it would be nice if a list or its MTA
signed its outgoing mail, I don't think we will produce anything that
is useful to anyone.

R's,
John
Scott Kitterman
2010-09-01 11:55:34 UTC
Permalink
Post by John Levine
Post by J.D. Falk
Post by Daniel Black
ANNEX A - MUA Considerations
Is a draft about mailing lists the right place to make recommendations
to MUA developers? Seems like those should probably be in a separate
document.
No, but the entire document is riddled with advice that has no basis
in experience and is unlikely ever to be implemented.
We have a serious problem that people in this group have deeply
incompatible ideas of what DKIM does. A lot of the arguments seem to
be from people who believe that a DKIM signature can or should
identify the individual author of a message, and that subscribers to
mailing lists need assurances about the identity of list authors
beyond the minimal level that has been adequate for the past twenty
years. I have trouble understanding how anyone who is familiar with
DKIM or with the operation of mailing lists could hold these
positions, but it is quite obvious that some do.
At this point, unless we can cut back the MLM document to stick to
items that we have consensus about, e.g., that it is typical for
signatures applied to incoming mail not to verify after a message
passes through an MLM, and that it would be nice if a list or its MTA
signed its outgoing mail, I don't think we will produce anything that
is useful to anyone.
If that's all we can say, I'd say don't bother. I don't see much value in the
DKIM working group saying it thinks mail should be signed by DKIM.

Scott K
Murray S. Kucherawy
2010-09-01 21:43:10 UTC
Permalink
-----Original Message-----
Sent: Wednesday, September 01, 2010 4:56 AM
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
Post by John Levine
At this point, unless we can cut back the MLM document to stick to
items that we have consensus about, e.g., that it is typical for
signatures applied to incoming mail not to verify after a message
passes through an MLM, and that it would be nice if a list or its MTA
signed its outgoing mail, I don't think we will produce anything that
is useful to anyone.
If that's all we can say, I'd say don't bother. I don't see much value in the
DKIM working group saying it thinks mail should be signed by DKIM.
I also submit that a two-paragraph document saying "Lists should sign mail" and "Lists should reject traffic from ADSP discardable domains" is not worth the effort to push through to publication as an RFC. If that's the kind of clear-cutting we agree on, let's just make them new paragraphs or sections in a revision to the deployment document whenever we get around to it, and declare this document dead.

Personally I do see use in the document's current form. Although I realize MLMs haven't done the work to preserve signatures in the past, I get the feeling there's desire out there for that to start to happen; receivers want it, for whatever reason, and I don't hear a lot of people coming out against the idea. Are we really on solid ground telling them "You don't need/don't want/can't have it?"

I find the "Nobody's ever wanted this, why should it change now?" argument about MLM behavior antithetical to the whole DKIM premise. The same logic there would sound like "Nobody's ever had a reliable identifier on a message before, what makes you think it's needed now?"

Maybe if people say they want preserved author signatures, and we encourage MLMs in the direction of preserving author signatures, and they're willing to give it a go, then it is indeed worth making a more meaty statement about it.
Alessandro Vesely
2010-09-02 17:35:16 UTC
Permalink
Post by Murray S. Kucherawy
Personally I do see use in the document's current form. Although I
realize MLMs haven't done the work to preserve signatures in the
past, I get the feeling there's desire out there for that to start
to happen; receivers want it, for whatever reason, and I don't hear
a lot of people coming out against the idea. Are we really on
solid ground telling them "You don't need/don't want/can't have
it?"
+1: if DKIM works it should also work for MLMs.

However, the other issue is to break or remove author domain
signatures. John has pointed this out since a long time, for FBL
reasons. Doug has brought out the same issue for replaying attacks
aimed at breaking reputation, because replaying is definitely out of
control in case of publicly distributed messages.

Mutually exclusive as they may seem, those two issues together simply
beg for the ability to take just the extent of responsibility that a
signer deems correct, given the recipients for the message at hands.

I repeat the two proposals that have been made, and ask once more
whether there are further ways to achieve similar results.

Charles' From-%-rewriting.
It seems the WG disagrees with it. However, it has also been
mentioned that some MLMs already change the From. Should it be
forbidden? If not, I see no reason not to document it.

Joint Signatures.
I haven't seen many opinions on this proposal of mines. Anyone? Here
are some pointers:
last paragraph in
http://mipassoc.org/pipermail/ietf-dkim/2010q3/014008.html
http://mipassoc.org/pipermail/ietf-dkim/2010q3/013881.html
http://mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html
Murray S. Kucherawy
2010-09-02 17:42:16 UTC
Permalink
-----Original Message-----
Sent: Thursday, September 02, 2010 10:35 AM
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
However, the other issue is to break or remove author domain
signatures. John has pointed this out since a long time, for FBL
reasons. Doug has brought out the same issue for replaying attacks
aimed at breaking reputation, because replaying is definitely out of
control in case of publicly distributed messages.
What's the danger of replaying legitimate mail, other than to cause volume detection alarms to go off?
Alessandro Vesely
2010-09-02 18:11:42 UTC
Permalink
Post by Murray S. Kucherawy
Post by Alessandro Vesely
However, the other issue is to break or remove author domain
signatures. John has pointed this out since a long time, for FBL
reasons. Doug has brought out the same issue for replaying attacks
aimed at breaking reputation, because replaying is definitely out of
control in case of publicly distributed messages.
What's the danger of replaying legitimate mail, other than to cause
volume detection alarms to go off?
If this message were replayed to all mailboxes in the world, the
number of complaints might be overwhelming; the more successful spam
reporting, the more scaring this possibility. And if anyone uses that
for tracking domain reputation, it might drop below small integer
ranges. In such scenario, one may consider it safer to only sign mail
destined to trusted recipients.
Murray S. Kucherawy
2010-09-02 18:43:46 UTC
Permalink
-----Original Message-----
Sent: Thursday, September 02, 2010 11:12 AM
To: Murray S. Kucherawy
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
If this message were replayed to all mailboxes in the world, the
number of complaints might be overwhelming; the more successful spam
reporting, the more scaring this possibility. And if anyone uses that
for tracking domain reputation, it might drop below small integer
ranges. In such scenario, one may consider it safer to only sign mail
destined to trusted recipients.
Isn't reputation specifically out of scope though?

I don't see that this is an issue this WG can address, unless we want to tackle the issue of doing something DKIM-like at the connection level.
Alessandro Vesely
2010-09-03 09:51:26 UTC
Permalink
Post by Murray S. Kucherawy
Post by Alessandro Vesely
If this message were replayed to all mailboxes in the world, the
number of complaints might be overwhelming; the more successful spam
reporting, the more scaring this possibility. And if anyone uses that
for tracking domain reputation, it might drop below small integer
ranges. In such scenario, one may consider it safer to only sign mail
destined to trusted recipients.
Isn't reputation specifically out of scope though?
No, that's true for the /development/ of reputation systems.
Post by Murray S. Kucherawy
I don't see that this is an issue this WG can address, unless we want to tackle the issue of doing something DKIM-like at the connection level.
In part, the issue is being addressed in draft-ietf-dkim-mailinglists
already. I'm questioning whether we can get away with saying that a
MLM "is /likely/ to invalidate any or all of" a message's signatures.
Reputation considerations suggest that author domains may want MLMs
to behave consistently in this respect.

Crypto stuff at connection time is a different ongoing task, which may
be useful in countering replay attacks in general. Joint signatures
and From-%-rewriting are two easier and more specific techniques for
describing how responsibility is transferred when a message transforms
into another. I mentioned them in this thread because I deem they are
worth being considered, each in its niche of suitable use cases.
Hector Santos
2010-09-03 14:15:37 UTC
Permalink
Post by Alessandro Vesely
Crypto stuff at connection time is a different ongoing task, which may
be useful in countering replay attacks in general. Joint signatures
and From-%-rewriting are two easier and more specific techniques for
describing how responsibility is transferred when a message transforms
into another. I mentioned them in this thread because I deem they are
worth being considered, each in its niche of suitable use cases.
I think you need to better appreciate and understand how fundamental
the "Message"
Alessandro Vesely
2010-09-03 19:06:09 UTC
Permalink
Post by Alessandro Vesely
Crypto stuff at connection time is a different ongoing task, which
may be useful in countering replay attacks in general. Joint
signatures and From-%-rewriting are two easier and more specific
techniques for describing how responsibility is transferred when a
message transforms into another. I mentioned them in this thread
because I deem they are worth being considered, each in its niche of
suitable use cases.
[Importance of From] said, I believe what you speaking of is when a mail bot
completely take over a message from an authorized or intentional
design basis. i.e. a newsletter, a newspaper article, a read only
forum, whatever, etc, messaging usages were the From: is less
important and more of a "global entity."
Yes, I'm speaking of cases where the
Douglas Otis
2010-09-03 19:32:49 UTC
Permalink
Post by Alessandro Vesely
[Importance of From] said, I believe what you speaking of is when a mail bot
completely take over a message from an authorized or intentional
design basis. i.e. a newsletter, a newspaper article, a read only
forum, whatever, etc, messaging usages were the From: is less
important and more of a "global entity."
Yes, I'm speaking of cases where the
John R. Levine
2010-09-04 23:33:14 UTC
Permalink
Post by Alessandro Vesely
In part, the issue is being addressed in draft-ietf-dkim-mailinglists
already. I'm questioning whether we can get away with saying that a
MLM "is /likely/ to invalidate any or all of" a message's signatures.
Reputation considerations suggest that author domains may want MLMs
to behave consistently in this respect.
They may want that, but if we're documenting what MLMs do, I don't think
they can have what they want. The conditions under which an MLM will
break a signature are very hard to describe.

As a typical example, many MLMs add a subject line tag, but if the tag is
already present it leaves the line alone. So one message might arrive
with a broken signature, and the next, a response to the first message
which already has the tag in its subject line, might arrive with a valid
signature.

So "is likely to invalidate" is as specific as we can reasonably be.

R's,
John
Alessandro Vesely
2010-09-05 07:42:22 UTC
Permalink
Post by John R. Levine
I'm questioning whether we can get away with saying that a MLM
"is /likely/ to invalidate any or all of" a message's
signatures. Reputation considerations suggest that author domains
may want MLMs to behave consistently in this respect.
They may want that, but if we're documenting what MLMs do, I don't
think they can have what they want. The conditions under which an
MLM will break a signature are very hard to describe.
Correct. Still, signatures can be removed, which --by symmetry-- is
tantamount to breaking them. Similar effects can also be achieved
using slightly more sophisticated techniques...
Post by John R. Levine
[...example snipped...]
So "is likely to invalidate" is as specific as we can reasonably be.
Yes, under the assumption that we're documenting what MLMs do. This
brings us back to the informative vs. normative dilemma.

Rolf E. Sonneveld
2010-09-02 18:23:56 UTC
Permalink
Hi, Murray,
Post by Murray S. Kucherawy
-----Original Message-----
Sent: Thursday, September 02, 2010 10:35 AM
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
However, the other issue is to break or remove author domain
signatures. John has pointed this out since a long time, for FBL
reasons. Doug has brought out the same issue for replaying attacks
aimed at breaking reputation, because replaying is definitely out of
control in case of publicly distributed messages.
What's the danger of replaying legitimate mail, other than to cause volume detection alarms to go off?
I think Doug was not talking about replaying legitimate mail but illegit
mail. I believe Doug described this scenario in one of his previous
messages either on domainrep or here on this list (Doug, excuse me if
this summary lacks the nuances):

Someone sends a spam-type message from a large ESP to a mailbox he owns,
somewhere on the Internet. The message is DKIM signed by the ESP. The
spammer then takes the entire message including complete headers, and
replays it using different envelope To: addresses and (optionally)
different envelope
Murray S. Kucherawy
2010-09-02 18:45:20 UTC
Permalink
Hi Rolf,
-----Original Message-----
Sent: Thursday, September 02, 2010 11:24 AM
To: Murray S. Kucherawy
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
Someone sends a spam-type message from a large ESP to a mailbox he owns,
somewhere on the Internet. The message is DKIM signed by the ESP. The
spammer then takes the entire message including complete headers, and
replays it using different envelope To: addresses and (optionally)
different envelope
Douglas Otis
2010-09-02 23:09:27 UTC
Permalink
Post by Rolf E. Sonneveld
Hi, Murray,
Post by Murray S. Kucherawy
Post by Alessandro Vesely
However, the other issue is to break or remove author domain
signatures. John has pointed this out since a long time, for FBL
reasons. Doug has brought out the same issue for replaying attacks
aimed at breaking reputation, because replaying is definitely out of
control in case of publicly distributed messages.
What's the danger of replaying legitimate mail, other than to cause volume detection alarms to go off?
I think Doug was not talking about replaying legitimate mail but illegit
mail. I believe Doug described this scenario in one of his previous
messages either on domainrep or here on this list (Doug, excuse me if
Someone sends a spam-type message from a large ESP to a mailbox he owns,
somewhere on the Internet. The message is DKIM signed by the ESP. The
spammer then takes the entire message including complete headers, and
replays it using different envelope To: addresses and (optionally)
different envelope
Hector Santos
2010-09-02 18:54:55 UTC
Permalink
Post by Murray S. Kucherawy
-----Original Message-----
Alessandro Vesely
However, the other issue is to break or remove author domain
signatures. John has pointed this out since a long time, for FBL
reasons. Doug has brought out the same issue for replaying attacks
aimed at breaking reputation, because replaying is definitely out of
control in case of publicly distributed messages.
What's the danger of replaying legitimate mail, other than
to cause volume detection alarms to go off?
I think the issue is that we don't know what the assessors do, if
anything. We won't know how stripping or keeping broken signatures
will *warm* up these heuristic/reputation based assessors with
indeterminate DKIM messages.

BTW, it really has nothing to do with ADSP because it applies to
reputation services as well.

Here is a possible scenario:

A ISP begins to offer a 3rd signing service to its email hosting
domains, The ISP is intent to get its signing domain registered with
every known reputation and domain certification service bureau
existing or startups.

So I sign up (at $5, $10 extra per month or free perhaps) and now all
my mail is signed by the 3rd party ISP domain.

I forget about all that and one day I see this great list I want to
subscribe to. I do and unbeknowst to me, the list is blindly
resigning the mail.

Unless the LIST domain is part of the same "registration" the ISP did
with all the new reputation and domain certification services out
there, I now lost my $5, $10 value of using my ISP's 3rd party
signing service - thru this list stream.

Either way, it all goes back to a centralization concept of some form,
network of reputation services or a self-asserting DNS domain policy.

Until we have a understanding of how the many assessors will work,
separately or in concert, we have no idea how indetermine DKIM mail
will warm up these systems with stripped or kept broken signatures.

In the mean time, the better solution possible today is to allow the
self-asserting domain to declare it expectation and policies for mail
distribution if only for one reason - to maintain a high benefit of
1st party signatures while you guys figure out how LIST systems ought
to work.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
J.D. Falk
2010-09-02 23:26:45 UTC
Permalink
Post by Hector Santos
I think the issue is that we don't know what the assessors do
Some of us have a pretty good idea. The people who design reputation systems don't do so in a vacuum; they're constantly reacting to spammers' latest tricks. If massive unauthorized replaying of unmodified DKIM-signed messages ever becomes a real issue, they'll adjust accordingly.
Douglas Otis
2010-09-02 23:37:19 UTC
Permalink
Post by J.D. Falk
Some of us have a pretty good idea. The people who design reputation systems don't do so in a vacuum; they're constantly reacting to spammers' latest tricks. If massive unauthorized replaying of unmodified DKIM-signed messages ever becomes a real issue, they'll adjust accordingly.
Were DKIM domains to become a primary basis for message acceptance, then
replayed messages will become a real issue. The question is "Then what
strategy is needed next without expecting the world to change how
applications handle email." One answer might be TPA-Labels applied at
the transport level during message exchange. :^)

-Doug
Hector Santos
2010-09-03 13:57:48 UTC
Permalink
Post by Douglas Otis
Post by J.D. Falk
Some of us have a pretty good idea. The people who design
reputation systems don't do so in a vacuum; they're constantly
reacting to spammers' latest tricks. If massive unauthorized
replaying of unmodified DKIM-signed messages ever becomes a real
issue, they'll adjust accordingly.
Were DKIM domains to become a primary basis for message acceptance, then
replayed messages will become a real issue. The question is "Then what
strategy is needed next without expecting the world to change how
applications handle email." One answer might be TPA-Labels applied at
the transport level during message exchange. :^)
This might be related.

Let me use my bellsouth, now AT&T service provider cell phone accounts
as an example.

Over the years, they tried to move customers over to electronic
billing or statements. (Note: My first company, OptiSoft, developed
and sold turnkey ODSAR (Optical Document Scanning and Retrieval)
systems, so I know a little about the logistics, cost savings, etc for
the "paperless" market place.).

Anyway, I continue to refuse to sign up and be associated with any
online or email based billing/statement for security reasons. But
eventually, I guess because people were not signing up on their own
(OPT IN), they began to send the billing statement via email anyway
with marketing URL hooks to "turn on it on".

I have continued to ignore it but I occasionally check the headers to
see what they are using. I was expecting them to be more proactive
with DKIM (or Domainkeys) but at first I didn't see it. I asked Tony
Hansen about it. He indicated they will support POLICY once adopted
but did not say much beyond that. But I recalled a few times when it
did become to have DKEY or DKIM, don't recall which.

Now I just got my new statement and there is no DKIM/DKEY but it has
one of those X-YMailISG header lines.

I know AT&T begun to outsource their U-VERSE and perhaps entire email
users to YAHOO.

But it always me wonder why did not use at the very least a 1st party
signature. That alone would of gave me more "trust" in these
electronic statements.

Now there is no trust whatsoever as anyone can spoof YAHOO and that
X-YMailSG header.

It seems to me they are relying on users using the online interface
where this would be more trust worthy and view Offline copies (via
POP3 pickups) to be less trust worthy in their eyes, I guess.

It seems to be what they did was promote replay spoofs. So why not use
a 1st party signature?

If AT&T is my cell provider, and they are sending billing statements
with URL hooks to join 'Something' and other stuff, they should be
more concern about what 3rd party clearing house (YAHOO does a long
time PR problem as a source for spam) they use and understand not all
users are online.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Hector Santos
2010-09-03 00:01:22 UTC
Permalink
Post by J.D. Falk
Post by Hector Santos
I think the issue is that we don't know what the assessors do
Some of us have a pretty good idea. The people who design reputation
systems don't do so in a vacuum; they're constantly reacting
to spammers' latest tricks. If massive unauthorized
replaying of unmodified DKIM-signed messages ever becomes a real
issue, they'll adjust accordingly.
Of course. But what do you (I guess one system speaking for the
myriad of assessors) want DKIM mail breaking resigners to do?

A) Strip Signature
B) Keep Invalid Signatures

How do MLM developers help you guys do a better job? How do we warm
you up with reduced false positives? Give us a purpose, a reason to
do this stuff, and do so correctly?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
B***@cox.com
2010-09-01 11:57:27 UTC
Permalink
+1
Post by John Levine
Post by J.D. Falk
Post by Daniel Black
ANNEX A - MUA Considerations
Is a draft about mailing lists the right place to make recommendations
to MUA developers? Seems like those should probably be in a separate
document.
No, but the entire document is riddled with advice that has no basis
in experience and is unlikely ever to be implemented.
We have a serious problem that people in this group have deeply
incompatible ideas of what DKIM does. A lot of the arguments seem to
be from people who believe that a DKIM signature can or should
identify the individual author of a message, and that subscribers to
mailing lists need assurances about the identity of list authors
beyond the minimal level that has been adequate for the past twenty
years. I have trouble understanding how anyone who is familiar with
DKIM or with the operation of mailing lists could hold these
positions, but it is quite obvious that some do.
At this point, unless we can cut back the MLM document to stick to
items that we have consensus about, e.g., that it is typical for
signatures applied to incoming mail not to verify after a message
passes through an MLM, and that it would be nice if a list or its MTA
signed its outgoing mail, I don't think we will produce anything that
is useful to anyone.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
John Levine
2010-09-01 12:23:19 UTC
Permalink
Post by Scott Kitterman
Post by John Levine
At this point, unless we can cut back the MLM document to stick to
items that we have consensus about, e.g., that it is typical for
signatures applied to incoming mail not to verify after a message
passes through an MLM, and that it would be nice if a list or its MTA
signed its outgoing mail, I don't think we will produce anything that
is useful to anyone.
If that's all we can say, I'd say don't bother. I don't see much value in the
DKIM working group saying it thinks mail should be signed by DKIM.
"e.g." means "such as" or "for example."

I expect there's a fair amount we agree on. Maybe it's enough to be
worth documenting, maybe not, but I think it would be more productive
to see what we agree on rather than trying to force our pet projects
into the document.

I'll cheerfully give up references to S/MIME, if other people will
give up on telling software developers how to rewrite MLMs to do
things they've never done before.

Don't forget that an experimental RFC is the accepted way to document
a paper design to see if it gets any traction, as the EAI group did
with various ways to represent non-ASCII e-mail addresses.

R's,
John
Scott Kitterman
2010-09-01 14:06:15 UTC
Permalink
Post by John Levine
Post by Scott Kitterman
Post by John Levine
At this point, unless we can cut back the MLM document to stick to
items that we have consensus about, e.g., that it is typical for
signatures applied to incoming mail not to verify after a message
passes through an MLM, and that it would be nice if a list or its MTA
signed its outgoing mail, I don't think we will produce anything that
is useful to anyone.
If that's all we can say, I'd say don't bother. I don't see much value in
the DKIM working group saying it thinks mail should be signed by DKIM.
"e.g." means "such as" or "for example."
I expect there's a fair amount we agree on. Maybe it's enough to be
worth documenting, maybe not, but I think it would be more productive
to see what we agree on rather than trying to force our pet projects
into the document.
I'll cheerfully give up references to S/MIME, if other people will
give up on telling software developers how to rewrite MLMs to do
things they've never done before.
Don't forget that an experimental RFC is the accepted way to document
a paper design to see if it gets any traction, as the EAI group did
with various ways to represent non-ASCII e-mail addresses.
Since things to do to get signatures to survive on mailing lists doesn't seem
to be on your list of stuff we agree on, what else is? I know you said e.g.,
but given what I understand you to not agree on, I'm not sure what else is
left.

Scott K
Michael Thomas
2010-09-01 14:24:52 UTC
Permalink
Post by John Levine
I'll cheerfully give up references to S/MIME, if other people will
give up on telling software developers how to rewrite MLMs to do
things they've never done before.
Frankly, the best possible advice we can give is to tell people to
sign all their mail, set ADSP to discardable and let mailing list
mail get to sent to the trash can. If that doesn't get the hidebound
traditionist over-entitled mailing list developers and operators
attention, they pretty much deserve dying along with their 1970's
view of what the internet is.

Mike
Steve Atkins
2010-09-01 20:47:28 UTC
Permalink
Post by Michael Thomas
Post by John Levine
I'll cheerfully give up references to S/MIME, if other people will
give up on telling software developers how to rewrite MLMs to do
things they've never done before.
Frankly, the best possible advice we can give is to tell people to
sign all their mail, set ADSP to discardable and let mailing list
mail get to sent to the trash can. If that doesn't get the hidebound
traditionist over-entitled mailing list developers and operators
attention, they pretty much deserve dying along with their 1970's
view of what the internet is.
ADSP is badly flawed, but those flaws don't have much impact in the case of junk mail sent directly from senders to the MXes of consumer ISPs. Junk mail sent to consumers is also the main place where the theoretical benefit of ADSP is likely to be of value (assuming that's still anti-phishing).

If your goal is to have MLM developers rewrite their perfectly working code to work around the fundamental flaws in ADSP - a protocol nobody other than bulk mailers is interested in, and which in any even marginally sane deployment would never interact with mailing lists at all - I think you're going to be disappointed.

If you don't want to be disappointed you'd be better saying something like this ...

1. Don't publish ADSP for domains that are used for sending any mail other than junk mail

2. If you pay attention to ADSP use it to discard mail, not reject it

3. If you run a mailing list, consider refusing submissions from any domain publishing an ADSP record

4. If you run a mailing list, consider DKIM signing the mail you send

... rather than hoping MLM software developers will remove all the features they offer that might break a DKIM signature.

Cheers,
Steve
Murray S. Kucherawy
2010-09-01 21:49:01 UTC
Permalink
-----Original Message-----
Sent: Wednesday, September 01, 2010 1:47 PM
To: DKIM List
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
If your goal is to have MLM developers rewrite their perfectly working
code to work around the fundamental flaws in ADSP - a protocol nobody
other than bulk mailers is interested in, and which in any even
marginally sane deployment would never interact with mailing lists at
all - I think you're going to be disappointed.
Setting aside ADSP for a second, I think there are still some people that would like to see MLMs preserve author signatures for the purposes of reputation evaluation.
... rather than hoping MLM software developers will remove all the
features they offer that might break a DKIM signature.
Maybe we should let the MLM developers, some of whom are here (or were, maybe they've been scared off) comment?
Steve Atkins
2010-09-01 22:15:15 UTC
Permalink
Post by Murray S. Kucherawy
-----Original Message-----
Sent: Wednesday, September 01, 2010 1:47 PM
To: DKIM List
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
If your goal is to have MLM developers rewrite their perfectly working
code to work around the fundamental flaws in ADSP - a protocol nobody
other than bulk mailers is interested in, and which in any even
marginally sane deployment would never interact with mailing lists at
all - I think you're going to be disappointed.
Setting aside ADSP for a second, I think there are still some people that would like to see MLMs preserve author signatures for the purposes of reputation evaluation.
I'm sure there are people who'd think that'd be nice (if there were no cost to doing so, I'd be one of them) - but I'm also fairly sure that they'd find other approaches which do not cripple MLMs an acceptable alternative.
Post by Murray S. Kucherawy
... rather than hoping MLM software developers will remove all the
features they offer that might break a DKIM signature.
Maybe we should let the MLM developers, some of whom are here (or were, maybe they've been scared off) comment?
OK.

I develop code that receives email to one address and forwards it on to another address. It's not intended for use as an MLM, but it does have a number of optional features in common - modifying the subject line to add a tag, rewriting from / reply-to, modifying the body content, adding or removing MIME elements.

It will break DKIM signatures (any that sign the subject line, at the very least) much of the time. I've no intention of removing those features in order to make it not break DKIM signature as, well, they're features that were added because users wanted them.

DKIM signing the mail sent by the MLM is something I support doing. Checking DKIM signature on the inbound is something I don't do now, as there's not been much call for it, but it's something I'd like to add eventually. Recording that inbound authentication data in a header of the forwarded email is something I see as not terribly useful, nor particularly desired by the users I've talked to, but pretty much harmless.

Lets say we set aside ADSP, as you suggest, and just consider reputation evaluation. Do you believe there are any people who'd not find that that level of authentication tunneling entirely adequate for their needs?

Cheers,
Steve
Hector Santos
2010-09-01 22:27:54 UTC
Permalink
Post by Steve Atkins
Lets say we set aside ADSP, as you suggest, and just consider
reputation evaluation. Do you believe there are any people
who'd not find that that level of authentication tunneling
entirely adequate for their needs?
But ADSP is in scope of the charter work, and Reputation work is out
of scope. Unfortunately, we allowed this type of external reputation
working mindset to alter, twist and turn the DKIM WG drafts creating
confusion and consensus chaos making it hard to completing the
chartered goals.

Accept POLICY as a WG work item and maybe we can come to complete this
work and maybe many more systems can begin to get more DKIM/ADSP adoption.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Alessandro Vesely
2010-09-02 17:39:31 UTC
Permalink
Post by Steve Atkins
I develop code that receives email to one address and forwards it
on to another address. It's not intended for use as an MLM, but it
does have a number of optional features in common - modifying the
subject line to add a tag, rewriting from / reply-to, modifying the
body content, adding or removing MIME elements.
I think that software is included in the broad definition of
"resending MLM" given in draft-ietf-dkim-mailinglists.

Are senders aware that the messages they send to that address will be
forwarded the way you say? In case they are not, is that a feature or
would the software let the sender know, e.g. by answering "251 User
not local; will forward to <forward-path>"?

May I also ask how does the admin specify that forward-path? Has the
final recipient's MTA to be aware of the forwarding, e.g. for
whitelisting? Have you considered SMTP-AUTH as a whitelisting means?
Post by Steve Atkins
It will break DKIM signatures (any that sign the subject line, at
the very least) much of the time. I've no intention of removing
those features in order to make it not break DKIM signature as,
well, they're features that were added because users wanted them.
Fine, IMHO.
Post by Steve Atkins
DKIM signing the mail sent by the MLM is something I support doing.
Checking DKIM signature on the inbound is something I don't do now,
as there's not been much call for it, but it's something I'd like
to add eventually. Recording that inbound authentication data in a
header of the forwarded email is something I see as not terribly
useful, nor particularly desired by the users I've talked to, but
pretty much harmless.
It should quite straightforward for the hosting MTA to add an A-R field.
Steve Atkins
2010-09-02 18:01:38 UTC
Permalink
Post by Steve Atkins
I develop code that receives email to one address and forwards it
on to another address. It's not intended for use as an MLM, but it
does have a number of optional features in common - modifying the
subject line to add a tag, rewriting from / reply-to, modifying the
body content, adding or removing MIME elements.
I think that software is included in the broad definition of "resending MLM" given in draft-ietf-dkim-mailinglists.
Yes. It's quite a stretch, but "resending MLM" is a fairly broad category.
Are senders aware that the messages they send to that address will be forwarded the way you say?
No. The inbound mail is a mixture of 1:1 mail sent to role accounts, ARF reports, replies to email and all sorts of other miscellaneous junk including in some cases asynchronous bounces.
In case they are not, is that a feature or would the software let the sender know, e.g. by answering "251 User not local; will forward to <forward-path>"?
It's a feature, I guess. The sender won't be notified of the forwarding in any mechanical way - they generally can't be in the way you mention, as typically the inbound mail will be store-and-forward.
May I also ask how does the admin specify that forward-path?
A set of forwarding rules, ranging from very specific ("Any email sent To _this_ address,
Alessandro Vesely
2010-09-02 18:32:42 UTC
Permalink
Post by Steve Atkins
Post by Alessandro Vesely
May I also ask how does the admin specify that forward-path?
A set of forwarding rules, ranging from very specific ("Any email sent To _this_ address,
Hector Santos
2010-09-01 22:16:12 UTC
Permalink
Post by Murray S. Kucherawy
-----Original Message-----
Maybe we should let the MLM developers, some of whom are here
(or were, maybe they've been scared off) comment?
Already did. We a FULL TIME commercial vendor with Mailing List
Components since 1996. The engineering I proposed came in th DSAP I-D
stating the same issues. Many also agreed here and to talk about it
other discussion areas.

There is NOTHING new here. It is about unrestricted 3rd party signers
and allowing them to exist without issues and the only reason there is
a revival of the issue it is now YOU with the MLM considerations -
anyone else would have been ignored like all these years.

But the issue is too fundamental to common sense engineering - it can
not go away on its own and not just by some saying "DON'T SUPPORT IT!"

At the end of the day, it is about the piece of C/C++ or whatever
language code that is going either blinding resign (something new) all
new era dkim messages (something new) or be restricted using domain
POLICY.

While POLICY is still on the table as a draft standard, no engineer
worth their salt should be IGNORING it. If he does, he has a BUG in
his software and whether he agrees or not, someone will throw it in
this face - you are violating RFC 5016..

Your MLM has it right Murray. It has all the information a MLM author
needs to go with to do this right.

You guys needs to make your minds regarding policy.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Michael Thomas
2010-09-01 22:26:25 UTC
Permalink
Post by Murray S. Kucherawy
Post by Steve Atkins
If your goal is to have MLM developers rewrite their perfectly working
code to work around the fundamental flaws in ADSP - a protocol nobody
other than bulk mailers is interested in, and which in any even
marginally sane deployment would never interact with mailing lists at
all - I think you're going to be disappointed.
"No Mr. Bond, I want you to die".
Post by Murray S. Kucherawy
Setting aside ADSP for a second, I think there are still some people that would like to see MLMs preserve author signatures for the purposes of reputation evaluation.
The implicit argument being made amongst the more vocal set here is that
since mailing lists coexisted with cavemen and dinosaurs, that their very
antiquity puts them beyond the scope of evolution. That if it wasn't
intelligently designed in o those 5000 years ago, that they have no
responsibility for the current internet's trials and tribulations.

The fact of the matter is that mailing lists survival or extinction
is utterly irrelevant to the internet at large; if we did harm to them,
nobody using the internet at large would care. Hence all of this hand
wringing about whether mailing list developers or operators will
petulantly stamp their feet and take their marbles home presumes they
have power they do not actually hold.

This draft shouldn't be starting from the perspective of what reactionary
old fogies will or won't do. It should be starting from the perspective
of what's right for email as it's actually used today. If what's right
is that unsigned mail should become a pariah -- which I suspect is the
right thing -- then all of the howls of indignation should just be ignored.
And as is always the case, the whiners will figure something out if the,
uh, laser is positioned correctly.

Mike
Hector Santos
2010-09-01 22:40:14 UTC
Permalink
Maybe way to reduce the rhetoric is to hmmmmm, huh, maybe following
the engineering molded into the WG RFC draft standards and to correct
the non-WG created DKIM Deployment RFC by not allowing it to suggest
implementators can break the WG RFC draft standards?

That might help.
Post by Michael Thomas
Post by Murray S. Kucherawy
Post by Steve Atkins
If your goal is to have MLM developers rewrite their perfectly working
code to work around the fundamental flaws in ADSP - a protocol nobody
other than bulk mailers is interested in, and which in any even
marginally sane deployment would never interact with mailing lists at
all - I think you're going to be disappointed.
"No Mr. Bond, I want you to die".
Post by Murray S. Kucherawy
Setting aside ADSP for a second, I think there are still some people that would like to see MLMs preserve author signatures for the purposes of reputation evaluation.
The implicit argument being made amongst the more vocal set here is that
since mailing lists coexisted with cavemen and dinosaurs, that their very
antiquity puts them beyond the scope of evolution. That if it wasn't
intelligently designed in o those 5000 years ago, that they have no
responsibility for the current internet's trials and tribulations.
The fact of the matter is that mailing lists survival or extinction
is utterly irrelevant to the internet at large; if we did harm to them,
nobody using the internet at large would care. Hence all of this hand
wringing about whether mailing list developers or operators will
petulantly stamp their feet and take their marbles home presumes they
have power they do not actually hold.
This draft shouldn't be starting from the perspective of what reactionary
old fogies will or won't do. It should be starting from the perspective
of what's right for email as it's actually used today. If what's right
is that unsigned mail should become a pariah -- which I suspect is the
right thing -- then all of the howls of indignation should just be ignored.
And as is always the case, the whiners will figure something out if the,
uh, laser is positioned correctly.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Hector Santos
2010-09-01 23:15:39 UTC
Permalink
Michael,

I take some level resentment to the "old frog" statements.

List based operations is still a viable part of our market place. As a
commercial vendor of a integrated mail system that includes a MLS
component, it is clearly something that is used as an everything thing
for many use cases. While some old frogs are mostly list operators
and use LIST systems predominantly one way, the old frog software
people have to create it with features for a wide range of
implementations usages.

This old frog is saying is that we are asked to do something new
(DKIM) for our MLS software, then it has to be engineered right to
support ADSP as well. It can't be ignored.

But I can see other old FROG operators are stuck with a plug and play
situation where they can only sign mail blindly. We can't do anything
about legacy operations and you are correct that we should not allow
the legacy Old Frog list operator dictate what can't be done or done
as a standard for all list usages.

We can do something with new technology being incorporated by active
systems. We can create consistent protocol engineered drafting among
the standard and informational RFC and I-Ds.

That is really all this old frog is looking for. No "Rippet" mas!
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Post by Michael Thomas
Post by Murray S. Kucherawy
Post by Steve Atkins
If your goal is to have MLM developers rewrite their perfectly working
code to work around the fundamental flaws in ADSP - a protocol nobody
other than bulk mailers is interested in, and which in any even
marginally sane deployment would never interact with mailing lists at
all - I think you're going to be disappointed.
"No Mr. Bond, I want you to die".
Post by Murray S. Kucherawy
Setting aside ADSP for a second, I think there are still some people that would like to see MLMs preserve author signatures for the purposes of reputation evaluation.
The implicit argument being made amongst the more vocal set here is that
since mailing lists coexisted with cavemen and dinosaurs, that their very
antiquity puts them beyond the scope of evolution. That if it wasn't
intelligently designed in o those 5000 years ago, that they have no
responsibility for the current internet's trials and tribulations.
The fact of the matter is that mailing lists survival or extinction
is utterly irrelevant to the internet at large; if we did harm to them,
nobody using the internet at large would care. Hence all of this hand
wringing about whether mailing list developers or operators will
petulantly stamp their feet and take their marbles home presumes they
have power they do not actually hold.
This draft shouldn't be starting from the perspective of what reactionary
old fogies will or won't do. It should be starting from the perspective
of what's right for email as it's actually used today. If what's right
is that unsigned mail should become a pariah -- which I suspect is the
right thing -- then all of the howls of indignation should just be ignored.
And as is always the case, the whiners will figure something out if the,
uh, laser is positioned correctly.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Steve Atkins
2010-09-01 22:52:59 UTC
Permalink
Post by Michael Thomas
Post by Murray S. Kucherawy
Post by Steve Atkins
If your goal is to have MLM developers rewrite their perfectly working
code to work around the fundamental flaws in ADSP - a protocol nobody
other than bulk mailers is interested in, and which in any even
marginally sane deployment would never interact with mailing lists at
all - I think you're going to be disappointed.
"No Mr. Bond, I want you to die".
Post by Murray S. Kucherawy
Setting aside ADSP for a second, I think there are still some people that would like to see MLMs preserve author signatures for the purposes of reputation evaluation.
The implicit argument being made amongst the more vocal set here is that
since mailing lists coexisted with cavemen and dinosaurs, that their very
antiquity puts them beyond the scope of evolution. That if it wasn't
intelligently designed in o those 5000 years ago, that they have no
responsibility for the current internet's trials and tribulations.
The fact of the matter is that mailing lists survival or extinction
is utterly irrelevant to the internet at large; if we did harm to them,
nobody using the internet at large would care. Hence all of this hand
wringing about whether mailing list developers or operators will
petulantly stamp their feet and take their marbles home presumes they
have power they do not actually hold.
This draft shouldn't be starting from the perspective of what reactionary
old fogies will or won't do. It should be starting from the perspective
of what's right for email as it's actually used today. If what's right
is that unsigned mail should become a pariah -- which I suspect is the
right thing -- then all of the howls of indignation should just be ignored.
And as is always the case, the whiners will figure something out if the,
uh, laser is positioned correctly.
You want to optimize email for sending bulk mail. That's one of the main things DKIM is good for, and it's pretty much the sole domain of ADSP.

You're not the only one who wants to do that, not by a long way. And the vast majority of email, by messages sent, is bulk email so doing some work to make that work better (such as DKIM, say) isn't a bad idea.

But when you go on to try and optimize the email system for junk B2C email at the expense of communication between individuals and groups then I think that's harmful to the ecosystem.

The 95% of emails that are B2C bulk mail are not more important than the 5% that are communication between individuals.

Cheers,
Steve
John R. Levine
2010-09-02 09:35:56 UTC
Permalink
Post by Michael Thomas
of what's right for email as it's actually used today. If what's right
is that unsigned mail should become a pariah -- which I suspect is the
right thing -- then all of the howls of indignation should just be ignored.
And as is always the case, the whiners will figure something out if the,
uh, laser is positioned correctly.
So I take it you agree that lists should sign their outgoing mail?

R's,
John
Douglas Otis
2010-09-01 23:44:38 UTC
Permalink
Post by Murray S. Kucherawy
Post by Steve Atkins
If your goal is to have MLM developers rewrite their perfectly
working code to work around the fundamental flaws in ADSP - a
protocol nobody other than bulk mailers is interested in, and which
in any even marginally sane deployment would never interact with
mailing lists at all - I think you're going to be disappointed.
Setting aside ADSP for a second, I think there are still some people
that would like to see MLMs preserve author signatures for the
purposes of reputation evaluation.
Because DKIM does not affirm either the destination or return path of a
message, it would offer an extremely vulnerable basis for establishing
reputations based upon receipt of unsolicited messages. It would be
far better to develop cryptographic methods to authenticate SMTP clients
instead. This would then mean MLM developers do not need to change any
of their code. The need for a cryptographic SMTP client authentication
mechanism will quickly become more apparent as more email is exchanged
over IPv6 networks.
Post by Murray S. Kucherawy
Post by Steve Atkins
... rather than hoping MLM software developers will remove all the
features they offer that might break a DKIM signature.
Maybe we should let the MLM developers, some of whom are here (or
were, maybe they've been scared off) comment?
Such a change would be a move in the wrong direction. It would make
messages distributed by mailing lists visually identical to those from
individuals, where they become more dangerous from a phishing
perspective. Avoiding false positive phishing detection was a reason
for DKIM, and anti-phishing was the reason for ADSP, after all. Few see
the DKIM signature, know what portion of the message body was signed, or
whether the
Hector Santos
2010-09-02 02:27:46 UTC
Permalink
Post by Murray S. Kucherawy
Steve Atkins
If your goal is to have MLM developers rewrite their perfectly working
code to work around the fundamental flaws in ADSP - a protocol nobody
other than bulk mailers is interested in, and which in any even
marginally sane deployment would never interact with mailing lists at
all - I think you're going to be disappointed.
Setting aside ADSP for a second, I think there are still some
people that would like to see MLMs preserve author signatures
for the purposes of reputation evaluation.
Yes.

But two things:

1) What is forgotten is what the author domain wants and,

2) The unknown world of reputations services or
non-standard assessment engines being used.
John R. Levine
2010-09-02 09:33:55 UTC
Permalink
Post by Murray S. Kucherawy
Maybe we should let the MLM developers, some of whom are here (or were, maybe they've been scared off) comment?
Hi. That would include me, one of the people who do occasional
development on majordomo2.

I have added code to mj2 to pass the list domain to the shim I use for
outbound signing, so my outbound list mail has a signature from the list
domain, along with the MTA signature that all the mail has. mj2 has an
unusually complex set of options for handling incoming mail, and I haven't
yet decided what, if anything, to do with incoming signatures. I might
remember the signature on a user's signup and confirmation mail, and add a
variable that people can test to see if an incoming message has the same
signature as the remembered one, so they can use it to bypass some of the
checks, e.g., large messages or some kinds of MIME parts, although it is
far from clear whether anyone would use it.

In the decade I've been using mj and mj2, I cannot ever remember anyone
ever expressing any concern about recipients verifying the identity of
contributors. (For that matter, I don't recall anyone asking about MTA
verification of contributors beyond the usual from: address.)

I haven't decided whether to strip of incoming DKIM signatures, but that'd
be easy, just add a line to the existing configurable list of headers it
strips already.

I don't currently do anything about ADSP. Unless a lot more people use it
than I expect, I probably won't. If I do, it'll just be to discard mail
from discardable domains. mj2 doesn't run at SMTP time so there's no way
to reject it.

R's,
John
Wietse Venema
2010-09-01 12:57:26 UTC
Permalink
Post by Scott Kitterman
Post by John Levine
Post by J.D. Falk
Post by Daniel Black
ANNEX A - MUA Considerations
Is a draft about mailing lists the right place to make recommendations
to MUA developers? Seems like those should probably be in a separate
document.
No, but the entire document is riddled with advice that has no basis
in experience and is unlikely ever to be implemented.
We have a serious problem that people in this group have deeply
incompatible ideas of what DKIM does. A lot of the arguments seem to
be from people who believe that a DKIM signature can or should
identify the individual author of a message, and that subscribers to
mailing lists need assurances about the identity of list authors
beyond the minimal level that has been adequate for the past twenty
years. I have trouble understanding how anyone who is familiar with
DKIM or with the operation of mailing lists could hold these
positions, but it is quite obvious that some do.
At this point, unless we can cut back the MLM document to stick to
items that we have consensus about, e.g., that it is typical for
signatures applied to incoming mail not to verify after a message
passes through an MLM, and that it would be nice if a list or its MTA
signed its outgoing mail, I don't think we will produce anything that
is useful to anyone.
If that's all we can say, I'd say don't bother. I don't see much
value in the DKIM working group saying it thinks mail should be
signed by DKIM.
If we want to increase adoption of DKIM today, then I think there
is value in a document that explains in plain words what DKIM
actually does, in terms of what mailing lists actually do, and in
terms of how MUAs actually work, common traps and pitfalls included.

If we want to increase adoption of DKIM in some distant future,
then we would need to speculate about what that future would look
like, and that is not useful.

Wietse
Loading...