Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
On Wed, 06 Oct 2010 13:23:49 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, October 06, 2010 4:36 AM To: DKIM Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03 Of the points I raised, I see that 4.3 still contains the verifier is requested to discard the message. It is, of course, the receiver that actually does any discarding. I don't agree, at least not in the architecture I have in mind. The verifier (e.g. a mail plugin of some kind, or an internal function of an MTA) is in a position to conduct rejections as it sits very near the SMTP portion of a delivery. The receiver, more likely an MUA or such, is less likely to have any direct influence. You can define the architecture so that the discarding is done by (or close to) the verifier, or that it is done by a separate agent (the receiver). I don't mind either way, but you need to be consistent. Currently, the wording of 5.10 suggests that you are using the second model (the verifier leaves it alone and the receiver looks at the verifification results in the A-R header and decides whether or not to actually discard). The change you have made in response to Dave is an improvement (it solves my immediate problem), but it still leaves in doubt which of the two models you are using. Also, section 5.6 is still entitled Pros and Cons of Signature Removal, and yet the body of that section contains no Cons. The first paragraph describes a pro of leaving them in (i.e., enabling preservation of chain of responsibility), and the second describes a con (i.e., if that's a goal, now the MLM might have to change its behavior to do so). The next paragraph describes a pro of removing them, etc. Well the title was Pros and Cons of ... Removal, so the first paragraph is actually a Con of removal for the case where a signature might still be valid. There is no dispute about that. And then the second paragraph is a Pro for removal in the case where the signature has been invalidated. But what is missing is any Con for removal in the invalidated case (e.g. keeping it for forensic use). Actually, a suggestion to replace the removed signature with an X-Original-Signature would be quite sufficient for forensic purposes. Wuld you be willing to add a suggestion to possibly do that? That second paragraph didn't read like a Con to me. In fact it seems like a further Pro insofar as it recommends a further action which turns out to be -- 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, October 07, 2010 3:03 AM To: DKIM Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03 You can define the architecture so that the discarding is done by (or close to) the verifier, or that it is done by a separate agent (the receiver). I don't mind either way, but you need to be consistent. Currently, the wording of 5.10 suggests that you are using the second model (the verifier leaves it alone and the receiver looks at the verifification results in the A-R header and decides whether or not to actually discard). The change you have made in response to Dave is an improvement (it solves my immediate problem), but it still leaves in doubt which of the two models you are using. I'll review it. Really, though, rejection in some form (bounce, drop, spam-folder) can take place at either location, so maybe it's best to fall back to something more generic and say a module can reject instead of naming one or the other specifically. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
On 10/7/2010 1:00 PM, Murray S. Kucherawy wrote: so maybe it's best to fall back to something more generic and say a module can reject instead of naming one or the other specifically. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
On Mon, 04 Oct 2010 22:16:48 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: This version consolidates all of the minor corrections submitted to date, as well as the more substantive things that appeared to have consensus. Of the points I raised, I see that 4.3 still contains the verifier is requested to discard the message. It is, of course, the receiver that actually does any discarding. Also, section 5.6 is still entitled Pros and Cons of Signature Removal, and yet the body of that section contains no Cons. And also, in 5.7 s/The MLM could re-evaluate exisiting signatures/The MLM could re-evaluate existing signatures/. Evidently, my draft to allow changing the From: has not been incorporated. Would it be worthwhile calling a straw poll on that one? Many of the people opposed to that seem to be imagining that I have proposes an obligatory feature for all MLMs, which my draft carefully avoided doing. Or they oppose it because then prefer their own pet solution, whereas I have proposed an additional tool for use when the pet solutions have been ignored. Also, I am still unaware of any additional security issue raised by my proposal which was not already present without it. -- 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, October 06, 2010 4:36 AM To: DKIM Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03 Of the points I raised, I see that 4.3 still contains the verifier is requested to discard the message. It is, of course, the receiver that actually does any discarding. I don't agree, at least not in the architecture I have in mind. The verifier (e.g. a mail plugin of some kind, or an internal function of an MTA) is in a position to conduct rejections as it sits very near the SMTP portion of a delivery. The receiver, more likely an MUA or such, is less likely to have any direct influence. Also, section 5.6 is still entitled Pros and Cons of Signature Removal, and yet the body of that section contains no Cons. The first paragraph describes a pro of leaving them in (i.e., enabling preservation of chain of responsibility), and the second describes a con (i.e., if that's a goal, now the MLM might have to change its behavior to do so). The next paragraph describes a pro of removing them, etc. And also, in 5.7 s/The MLM could re-evaluate exisiting signatures/The MLM could re-evaluate existing signatures/. Fixed for the next version. Evidently, my draft to allow changing the From: has not been incorporated. Would it be worthwhile calling a straw poll on that one? It didn't appear to have the support of rough consensus, so it wasn't included. You could indeed request such a poll to see if that's changed. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
On 10/6/2010 8:23 AM, Murray S. Kucherawy wrote: Of the points I raised, I see that 4.3 still contains the verifier is requested to discard the message. It is, of course, the receiver that actually does any discarding. I don't agree, at least not in the architecture I have in mind. The verifier (e.g. a mail plugin of some kind, or an internal function of an MTA) is in a position to conduct rejections as it sits very near the SMTP portion of a delivery. The receiver, more likely an MUA or such, is less likely to have any direct influence. The verifier might legitimately not be touching the message, nevermind have the authority to discard the message. Just as signing can be done by an independent service that contracts with the author, sender or the like, so can verifying. I suggest saying the holder of the message is requested to discard it. Also, section 5.6 is still entitled Pros and Cons of Signature Removal, and yet the body of that section contains no Cons. The first paragraph describes a pro of leaving them in (i.e., enabling preservation of chain of responsibility), and the second describes a con (i.e., if that's a goal, now the MLM might have to change its behavior to do so). The next paragraph describes a pro of removing them, etc. I'm not a huge fan of having pro con in a title. Perhaps simply: Signature Removal Issues. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
-Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Wednesday, October 06, 2010 6:12 AM To: Murray S. Kucherawy Cc: DKIM Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim- mailinglists-03 I suggest saying the holder of the message is requested to discard it. That paragraph now reads: Use of restrictive domain policies such as [ADSP] discardable presents an additional challenge. In that case, when a message is unsigned or the signature can no longer be verified, discarding of the message is requested. There is no exception in the policy for a message that may have been altered by an MLM, nor is there a reliable way to identify such mail. Receivers are thus advised to honor the policy and disallow the message. Does that work for people? I'm not a huge fan of having pro con in a title. Perhaps simply: Signature Removal Issues. Done. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
--On 4 October 2010 14:16:48 -0700 Murray S. Kucherawy m...@cloudmark.com wrote: However, the only truly normative thing upon which we appear to agree is that MLMs should sign their mail. I would rather we produce this more complete document at a lower status than a one-paragraph BCP saying only that. Good plan. That would be rather pointless. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
My perception of the rough consensus is that we do want to make some statements about the issues discussed in the draft. However, the only truly normative thing upon which we appear to agree is that MLMs should sign their mail. I would rather we produce this more complete document at a lower status than a one-paragraph BCP saying only that. If we do that, I think that in fairness to people reading it, we should say explicitly which recommendations are based on practice, and which are paper designs a/k/a wild guesses. Unless I've missed some implementations, we have considerable experience with lists signing, and some anedotal experience with damage from ADSP, but everything else falls into the latter category. I'm also scratching my head about the bits that are intended to help people work around faulty DKIM implementations. Are there other IETF documents that do that? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
This version consolidates all of the minor corrections submitted to date, as well as the more substantive things that appeared to have consensus. It did not include the suggestion to add a few points about MUA improvements that would help in the area of DKIM deployment and MLMs. I'd like to revisit the idea of adding a paragraph or two about this in an informative appendix. Do the participants feel this would be a bad or dangerous idea? The main point would be to lobby MUA developers to begin showing the identity authenticated by DKIM (the AUID or the SDID or both), as Daniel suggested. I think this is probably something we'd like to see in general and this is as good a place as any to say so. I also did not convert the status from Informational to BCP, and carefully avoided the standard IETF normative words. There appears to be some dissent about the sum and substance of this document if it were to move to the stronger level. My perception of the rough consensus is that we do want to make some statements about the issues discussed in the draft. However, the only truly normative thing upon which we appear to agree is that MLMs should sign their mail. I would rather we produce this more complete document at a lower status than a one-paragraph BCP saying only that. Feedback welcome. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
