Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
At 11:03 23-05-2011, Dave CROCKER wrote: Then you are using criteria that go beyond the requirements of a BCP. From RFC 2026: 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. ... The BCP subseries creates a smoothly structured way for these management entities to insert proposals into the consensus-building machinery of the IETF while gauging the community's view of that issue. Nothing in the definition of BCPs require that it be limited to covering existing practice. This creates debates along the lines of the RFC says so or the IETF says that this should be the practice. Perhaps the wording is a bit more coarse than one would like, but at base, telling the community what to do is what standards-track and BCP documents do, whether based on existing practice or not. A RFC is a way of telling the community what you did and how you did it. If people believes it is a good idea, they will pick it up. I'll diverge from the topic. Let's say that you are writing a proposal and there is a controversial issue. You are technically correct in your arguments but there are several people who disagrees with you on the issue. Your options are: (i) Don't make a change (assuming the IESG is fine with that) (ii) Make a change to gain goodwill (they will implement your proposal) I leave it to the IETF to determine which option to pick. Not really. The latter paragraph merely notes that there are receivers that do not understand what a DKIM signature means. I'll stick to my previous comments on this to avoid further distractions to the draft. You country has one of those, too? No, but I came across abuse reports where the people mentions that they will contact one of those about the matter. :-) Again, we seem to have an attempt to impose a more stringent requirement on qualifying for BCP status than exists in IETF formal documentation. At 11:43 23-05-2011, John Levine wrote: But since this argument seems to be all about proving that we've followed the official process rather than about publishing something accurate and useful rather than speculative and misleading, who cares? Now that I understand the rules, I plan to publish all of my experiments as BCPs. One little gem from an I-D which will be published as a BCP is that the information is intended to reflect consensus on the ground. A RFC is not worth a pinch of salt if it override that. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Dave CROCKER wrote: ? In Section 5.8: DKIM-aware authoring MLMs MUST sign the mail they send according to the regular signing guidelines given in [DKIM]. One concern is that having an MLM apply its signature to unsigned mail might cause some verifiers or receivers to interpret the signature as conferring more authority or authenticity to the message content than is defined by [DKIM]. This is an issue beyond MLMs and primarily entails receive-side processing outside of the scope of [DKIM]. It is nevertheless worth noting here. Removing the MUST and saying: DKIM-aware authoring MLMs signs the messages they send according to the regular signing guidelines given in [DKIM] gives more weight to the last two paragraphs, especially with the note about the concern. Not really. The latter paragraph merely notes that there are receivers that do not understand what a DKIM signature means. Something is amiss if after 6 years of development, after countless repeated explanations and messages over the years, it still seems very a difficult feat to describe in one or two sentences to the layman what DKIM is suppose to do for them, today or in the some distance future. The fact is DKIM has many conflictive semantics. While the above says its out of scope, it says the opposite in RFC 46751bis 6.3: Once the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/ whitelist and reputation system) and/or to the end user. If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader. See the SHOULD? See the technical association highlighted between the signer domain (SDID) and the the originating, copyright holder/author of the Message? Now, look at the conflict in the Abstract and repeated again in Section 1.2 defining the Signing Identity: DKIM separates the question of the identity of the signer of the message from the purported author of the message. What question is that? RFC4871 never quite clearly defined thee question. Lets think about what that question may be. Answer this: Do Electronic Mail Author Domains have any security rights and controls over who DKIM signs their mail? Be nice for someone to answer that question. Then of course, we have augmented RFC productions, such as RFC5585 that describes the DKIM Service Architecture and the illustration has that Author Domain Checking Signing Practices process component displayed in the diagram: |- RFC5322 Message V ++++ | Private|| ORIGINATING OR RELAYING ADMD | | Key+...| Sign Message with SDID| | Store |+---++ ++| (paired) [Internet] ++| +---+ | Public |++| Remote| | Key|| RELAYING OR DELIVERING ADMD || Sender| | Store || Message Signed? || Practices | ++---++-++-++-+-+ . |yes |no . . V|. .+-+|. +...| Verify ++ |. | Signature || |. +--+--+| |. pass| fail| |. V | |. +-+| |. | || |. +...| Assessments || |. .| |V V. .+-+--++ +---+ . . | | / Check \+ . | +/ Signing \ . | / Practices \..+ . | +---+---+ . . | | . . | V . +++ |+---+ +--+-+ |Reputation/ | || Message | | Local Info | |Accreditation| +---| Filtering | | on Sender | |Info | | Engine| | Practices | +-+ +---+ ++ Figure 1: DKIM Service Architecture Then you have the RFC5863 Development guide with a few dedicated sections, but not the only sections: 7.3. Author Domain Signing
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
2. Should this be Informational or BCP? a: BCP, making it clear when we're insufficiently certain about something. Last Call will sort out any objections. Well, I couldn't afford to go, so I can't say you're wrong, and I don't know why I didn't see that on the list. I guess on procedural grounds, you win, even though we all know that there's nothing B or C about this document. I cannot comment on the process issues, but I'm afraid I have to agree with John's technical assessment of this document. Ned ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On Thu, May 12, 2011 at 8:38 PM, John Levine jo...@iecc.com wrote: I'd suggest publishing it as Informational or Experimental rather than BCP. As DKIM chair, I'd like to reply to this and other messages in this thread that discuss the status of the subject document: There was extensive discussion in the DKIM working group about what the status here should be. The charter item covering this is here: 5. Consider issues related to mailing lists, beyond what is already documented. This includes considerations for mailing list software that supports or intends to support DKIM, as well as considerations for DKIM/ADSP deployment in the presence of mailing lists that do not have such support. Include recommendations in the informational documents, or produce a new informational document about mailing-list considerations. Despite that this says new informational document, the working group has long referred to it as the mailing list BCP. The language was originally written as informational, and was changed to normative language, and BCP status, after discussion and consensus. Clearly, it was rough consensus, not unanimity. There is, indeed, much in the document that isn't so much current practice as recommended practice. Some of it is our best current recommendation, and that might change over time (as implementations change in general) and experience (as we find what actually works best). Personally, I think what this amounts to is a proposed standard for how to deal with maling list managers that have not yet been changed to support DKIM. Whether that is published as BCP or Proposed Standard, it's definitely not experimenta so much as proposed. As chair, I can say that consensus was to make this normative, not experimental. Barry, DKIM working group chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
As chair, I can say that consensus was to make this normative, not experimental. With the best will in the world, I was there, and I saw no such consensus. The closest thing I can find in a quick search of the archive is this note, which says that the group agreed on one thing (that lists should sign their mail) but not on anything else: http://mipassoc.org/pipermail/ietf-dkim/2010q4/014630.html This document does not describe existing signing practice. It makes a variety of highly speculative recommendations unsupported by experience. It is an experiment. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
As chair, I can say that consensus was to make this normative, not experimental. With the best will in the world, I was there, and I saw no such consensus. We discussed it live at IETF 80, and I posted the following minutes to the mailing list on 28 March: 3. Discussion of mailinglists document: Murray listed some questions he has... 1. Should we include an appendix discussing what we see as useful changes to MUAs? a: No; out of scope. Perhaps an MUA BCP done at another time. 2. Should this be Informational or BCP? a: BCP, making it clear when we're insufficiently certain about something. Last Call will sort out any objections. 3. Should we remove discussion about dealing with broken DKIM implementations? a: No. 4. Should we put advice in about what header fields re-signing MLMs should sign? a: No. 5. Should explicitly reference ESPs? They're different from MLMs. a: No. 6. Should we change advice about subdomains, creating streams? a: No. That reflects strong consensus in the room in Prague, and there was no objection on the mailing list after the minutes were posted. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
2. Should this be Informational or BCP? a: BCP, making it clear when we're insufficiently certain about something. Last Call will sort out any objections. Well, I couldn't afford to go, so I can't say you're wrong, and I don't know why I didn't see that on the list. I guess on procedural grounds, you win, even though we all know that there's nothing B or C about this document. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 15/May/11 21:04, Hector Santos wrote: The author can be a human using an MUA (Mail User Agent) or an automated mail robot with an MTA. Both the human and the robot use an MTA (or an MSA.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On May 15, 2011, at 9:42 PM, Barry Leiba wrote: The author can be a human using an MUA (Mail User Agent) or an automated mail robot with an MTA. I don't see that automated mail robot with an MTA is right at all. But I see what you're getting at, and I'd support a change such as this: The author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the cron Unix system utility). +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 16May11, J.D. Falk allegedly wrote: On May 15, 2011, at 9:42 PM, Barry Leiba wrote: The author can be a human using an MUA (Mail User Agent) or an automated mail robot with an MTA. I don't see that automated mail robot with an MTA is right at all. But I see what you're getting at, and I'd support a change such as this: The author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the cron Unix system utility). +1 I've got a few of these left so I may as well use 'em while I have 'em. +1. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of J.D. Falk Sent: Monday, May 16, 2011 5:35 AM To: IETF list; DKIM List Subject: Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP I don't see that automated mail robot with an MTA is right at all. But I see what you're getting at, and I'd support a change such as this: The author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the cron Unix system utility). +1 Works for me. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Saturday, May 14, 2011 5:00 PM To: ietf-dkim@mipassoc.org Cc: i...@ietf.org Subject: Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP Nits and Comments: In Section 3.1. author: The agent that provided the content of the message being sent through the system. The author delivers that content to the originator in order to begin a message's journey to its intended final recipients. The author can be a human using an MUA (Mail User Agent) or a common system utility such as cron, etc. What is cron? and how does it interface with the originator defined as the MSA? is cron an MTA or MUA? It's a daemon that runs on UNIX systems which can be told to run specific programs at specific periodic times. It is neither an MTA nor an MUA; it is an example of something that is an author in this context but is not also a human. I suggest to remove the or a common .. text since we already know what MUA implies - a mail creation application or replace the text with: or any other message creation application [with an MTA component]. That doesn't make sense in the case of cron because it doesn't have an MTA component. It invokes a local MTA. I personally say take it out. Not needed. Thats an *nix idea. Windows people generally do not know what that is. I think it's best to have an example. cron seems to be an ideal one, though I'd be happy to add a second, Windows-specific, example if there is one. If not, changing 'such as cron' to 'such as the cron UNIX utility' seems a better change to me. In Section 3.1. verifier: Any agent that conducts DKIM signature analysis. I know this is a semantical nit, but RFC4671 uses verification, never analysis and it (analysis) is only stated as an out of scope boundary layer concept (in section 3.11). Perhaps the intent is to suggest the verifier does both: verifier: Any agent that conducts DKIM signature validation and perhaps [results|TRUST and ADSP] analysis. The verifier does not do both. An external module deals with ADSP and trust or other evaluation of the delivered domain name. I would be fine with changing analysis to validation though, to make that clear. In Section 3.1 for receiver, it is very clear with stating the agent for final delivery, so why not add the MDA labeled terminology as it was done with originator with MSA? receiver: . This agent can be often referred to as the Mail Delivery Agent (MDA). Works for me. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
I think it's best to have an example. cron seems to be an ideal one, though I'd be happy to add a second, Windows-specific, example if there is one. If not, changing 'such as cron' to 'such as the cron UNIX utility' seems a better change to me. Anyone who's ever managed a Unix or linux system knows what cron is. It's a fine example. Indeed, on my own servers, there are cron scripts that push out daily digests which are DKIM signed on the way out. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On May 13, 2011, at 3:40 PM, Rolf E. Sonneveld wrote:
I'd propose to put this item ('writeup a definition of 'discardable') on
the to-do list of a successor of RFC5617, if there ever will be one. Or
on another future 'policy' document.
+1
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Murray S. Kucherawy wrote: What is cron? and how does it interface with the originator defined as the MSA? is cron an MTA or MUA? It's a daemon that runs on UNIX systems which can be told to run specific programs at specific periodic times. It is neither an MTA nor an MUA; it is an example of something that is an author in this context but is not also a human. It was a rhetorical question. I don't think its necessary and IMO, unprecedented. That doesn't make sense in the case of cron because it doesn't have an MTA component. It invokes a local MTA. Exactly my point Murray. For the level of knowledge this document needs, people are presumed to be aware what is a MUA, MSA, MTA, MDA and how they are used and invoked is independence of specific OS details. I personally say take it out. Not needed. Thats an *nix idea. Windows people generally do not know what that is. I think it's best to have an example. cron seems to be an ideal one, though I'd be happy to add a second, Windows-specific, example if there is one. If not, changing 'such as cron' to 'such as the cron UNIX utility' seems a better change to me. In principle, examples are good, but IMO this particular one seems out of place. Think in terms of the context of where it is applied to author: author: The agent that provided the content of the message being sent through the system. The author delivers that content to the originator in order to begin a message's journey to its intended final recipients. The author can be a human using an MUA (Mail User Agent) or a common system utility such as cron, etc. If the intent is to suggest to the readers there is something special cron when it comes to the author, i.e. may not be real author or not exist, then I can see it may apply. Bu I don't think that is what you were trying to say here. I think what you are essentially saying here is the distinction between a Human (UI) Agent and Automated (no UI) Mail Agent. So perhaps the last sentence could be restated : The author can be a human using an MUA (Mail User Agent) or an automated mail robot with an MTA. I just think for this MLM I-D which already requires a high-level of intelligence, makes that part unnecessary. Perhaps you can also state also like you did with originator (and may for verifier): author: The agent that provided the content of the message being sent through the system. The author delivers that content to the originator in order to begin a message's journey to its intended final recipients. This authoring process is often referred to as the Mail User Agent (MUA) or MTA sending mail to the MSA or MDA. Anyway, its a nit and just thought it was not necessary nor correctly applied here. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
I'd be very surprised to find that mention of cron in an RFC is unprecedented. Maybe I'll download the RFC set, have Google do a word index on it, and see. RFCs 2123, 2839, 4833, and 5427 refer to cron and cron jobs. There may be others, but I found those with a simple grep. (If anyone was planning to ask what grep is, don't.) I don't see that automated mail robot with an MTA is right at all. But I see what you're getting at, and I'd support a change such as this: The author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the cron Unix system utility). There's no need to change the current language. RFCs have been referring to cron jobs since 1997. R's, John___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Hi Barry, At 19:42 15-05-2011, Barry Leiba wrote: I'd be very surprised to find that mention of cron in an RFC is unprecedented. Maybe I'll download the RFC set, have Google do a word index on it, and see. From RFC 3834: The auto-generated keyword: - SHOULD be used on messages generated by automatic (often periodic) processes (such as UNIX cron jobs) which are not direct responses to other messages Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Barry Leiba wrote: It was a rhetorical question. �I don't think its necessary and IMO, unprecedented. I'd be very surprised to find that mention of cron in an RFC is unprecedented. Maybe I'll download the RFC set, have Google do a word index on it, and see. What did you find? It is unprecedented to see such specific product or special tools like this for general global oriented technical documents like protocols or mail software based RFCs, and if so, it a good and fair document would cover all audiences, not just unix. Unless the RFC is specifically for some environment, it would be unprecedented for a document like this MLM I-D. But thats me, it would be my style to consider the whole and not just the part of it. Like the first google search: http://www.google.com/search?hl=enrlz=1C1CHMG_enUS291US310q=cron+RFC+IETFaq=faqi=aql=oq= with RFC3164 showing cron/at. I don't see that automated mail robot with an MTA is right at all. But I see what you're getting at, and I'd support a change such as this: � � � The author can be a human using an MUA (Mail User Agent) or � � � an automated process that may send mail (for example, the cron Unix system utility). I was hoping to use something more general, like automated process, but somehow got lost in this need to specialize (hmmm, maybe they will like the word mailbot). I still fail to see how cron is related to mail? its a scheduling tool, like at in Windows. At least show both. But I still fail to see why here, for author, and nothing else. In theory the same scheduling idea applies to verifiers and/or signers, i.e. scheduled a process/thread to eyeball queues to batch sign and/or verify mail. We can also do event drive work that runs spawns processes/threads to process mail queues. Talk about slippery slopes. Anywho, I just don't get it. Very different mindsets/thinking here. But hey, if people think it helps unix people -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
John R. Levine wrote: There's no need to change the current language. RFCs have been referring to cron jobs since 1997. But this is 2011 for G-d sake! -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
SM wrote: Hi Barry, At 19:42 15-05-2011, Barry Leiba wrote: I'd be very surprised to find that mention of cron in an RFC is unprecedented. Maybe I'll download the RFC set, have Google do a word index on it, and see. From RFC 3834: The auto-generated keyword: - SHOULD be used on messages generated by automatic (often periodic) processes (such as UNIX cron jobs) which are not direct responses to other messages But its not directly related to MAIL - its for scheduling automatic jobs, and the above case Often Periodic. That has nothing to do with mail per see or the Mail AUTHOR as the MLM I-D sentence implies: The author can be a human using an MUA (Mail User Agent) or a common system utility such as cron, etc. This is not correct. The author is not a common system utility or anything close to the scheduling tool unless you are saying the RFC5322 author is also the OS logged in username which cron uses as a default as an environment variable for any mail scripting events. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Sunday, May 15, 2011 9:05 PM To: SM Cc: Barry Leiba; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP But its not directly related to MAIL - its for scheduling automatic jobs, and the above case Often Periodic. That has nothing to do with mail per see or the Mail AUTHOR as the MLM I-D sentence implies: The author can be a human using an MUA (Mail User Agent) or a common system utility such as cron, etc. cron sends mail, if the periodic job it executes has any output, to the user that requested the job. The UNIX at utility is the same. The job it executes might also send mail of its own accord. In both cases, there's mail generated by a non-human author. This is not correct. The author is not a common system utility or anything close to the scheduling tool unless you are saying the RFC5322 author is also the OS logged in username which cron uses as a default as an environment variable for any mail scripting events. Precisely. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Murray S. Kucherawy wrote: -Original Message- cron sends mail, if the periodic job it executes has any output, to the user that requested the job. The UNIX at utility is the same. The job it executes might also send mail of its own accord. In both cases, there's mail generated by a non-human author. All scheduling tools have a mail component, but why not say such as php, perl, etc like any other tool or language, at least these are portable tools and more universal than cron This is not correct. The author is not a common system utility or anything close to the scheduling tool unless you are saying the RFC5322 author is also the OS logged in username which cron uses as a default as an environment variable for any mail scripting events. Precisely. But you didn't say that. You didn't say or any automated mail sending tool where the author is used for sending mail to an originator. Do you hate windows or know that Windows is still a major OS? or that even other OSes may exist with the same scheduling tools ideas? MLM is not exclusive to Unix systems. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Hi Murray, At 11:17 13-05-2011, Murray S. Kucherawy wrote: By my read, the bulk of your comments fall into these categories: (1) Remove the normative language, publish as Informational As I said to John, I'd be fine with this. The document started out as Informational but there was working group momentum in the direction of a BCP instead, hence the conversion to use of RFC2119 language. I personally don't have strong feelings about that so if the preferred course of action is to go back to that, I'd be fine. Ok. Yes, I believe they are consistent. The citation you made from RFC5451 directs implementations to delete forgeries (the MUST) and optionally delete everything else as well (the MAY). The citation from this document does not dispute the MUST, and provides further guidance for this particular application (which is also consistent with other parts of RFC5451) in terms of how to deal with what's left after the MUST part is done. Ok. 3.6.2 applies to relays, not recipients. A relay might try DKIM validation and ADSP evaluation, but that's not the model this document discusses. However, if that doesn't matter, unfortunately this makes the distinction we're trying to make impossible without using enhanced status codes, which aren't universally used. But to be conformant, I suppose 550 5.7.0 would be appropriate. You can use 550 5.7.1. The enhanced status code used in the draft is appropriate. Thanks for the quick response. BTW, I forgot to the best current practices in Section 8. It's an editorial nit. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 13/May/11 20:17, Murray S. Kucherawy wrote: From: On Behalf Of SM By my read, the bulk of your comments fall into these categories: (1) Remove the normative language, publish as Informational My reading of SM's comments is for replacing Best Current Practices, not normative language in general (but in particular, where it is redundant.) I consider his thoughts in accord with what another John noted: When we make that sort of recommendation in a BCP, we expose ourselves to the criticism that the recommendation is neither best (as distinct from a bad compromise), nor current (as distinct from a recommendation about future behavior), nor actively practiced. As I said to John, I'd be fine with this. The document started out as Informational but there was working group momentum in the direction of a BCP instead, hence the conversion to use of RFC2119 language. I personally don't have strong feelings about that so if the preferred course of action is to go back to that, I'd be fine. -1, I'd favor AS/PS or even experimental over BCP, but still prefer BCP over informational. As for the idea of using PS instead, that doesn't seem appropriate to me given we're not standardizing a protocol here, and at best we don't have enough implementation experience to back up the claims. How about running a test? I guess many of us can configure their MTAs for signing/verifying as it requires... (3) RFC5451 discussion This falls under policy decision. The usage of a 554 code is inappropriate. From Section 3.6.2 of RFC 5321: If it [SMTP server] declines to relay mail to a particular address for policy reasons, a 550 response SHOULD be returned. 3.6.2 applies to relays, not recipients. A relay might try DKIM validation and ADSP evaluation, but that's not the model this document discusses. Yes, my understanding of that SMTP snippet is that it concerns responses to RCPT TO:particular address, while DKIM and ADSP can only be evaluated after CRLF.CRLF. (In this respect, mentioning user unknown in the MLM spec may cause some confusion in readers not familiar with SMTP.) However, if that doesn't matter, unfortunately this makes the distinction we're trying to make impossible without using enhanced status codes, which aren't universally used. +1 for keeping 554 as is. But to be conformant, I suppose 550 5.7.0 would be appropriate. Conformant to what? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Alessandro Vesely wrote: SM wrote: (3) RFC5451 discussion This falls under policy decision. The usage of a 554 code is inappropriate. From Section 3.6.2 of RFC 5321: If it [SMTP server] declines to relay mail to a particular address for policy reasons, a 550 response SHOULD be returned. Which is not always used. RFC2554 (ESMTP AUTH) allows the usage of 530 when you want to show an unauthorized state considition applicable to RCPT TO: 530 Authentication is required for relaying. A quick log grep of RCPT TO relay rejections show a unique set of these: 501 530 550 550 5.1.1 550 5.1.2 550 5.4.1 550 5.7.1 551 553 554 5.7.1 554 571 3.6.2 applies to relays, not recipients. A relay might try DKIM validation and ADSP evaluation, but that's not the model this document discusses. For the record, unauthorized relay rejects can be done at the data level as well. RFC5321 3.3: However, in practice, some servers do not perform recipient verification until after the message text is received. Yes, my understanding of that SMTP snippet is that it concerns responses to RCPT TO:particular address, while DKIM and ADSP can only be evaluated after CRLF.CRLF. (In this respect, mentioning user unknown in the MLM spec may cause some confusion in readers not familiar with SMTP.) However, if that doesn't matter, unfortunately this makes the distinction we're trying to make impossible without using enhanced status codes, which aren't universally used. +1 for keeping 554 as is. +1 But to be conformant, I suppose 550 5.7.0 would be appropriate. Conformant to what? Well RFC5321 does has open-ended 550 text that includes policy semantics: 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) But 554 or 552 is technically correct for a DATA EOD reject. You can clearly see this in section 4.2.2 showing Reply Codes by Function Groups. The wo codes next to each other: 354 Start mail input; end with CRLF.CRLF 554 Transaction failed (Or, in the case of a connection-opening response, No SMTP service here) And you also have section 4.3.2 DATA I: 354 - data - S: 250 E: 552, 554, 451, 452 E: 451, 554, 503 552 and 554 are the technically correct permanent reject codes for the end of data state. Since 552 is related to storage, 554 is the more appropriate response. Ideally, if Murray wishes to support Jeff McDonald's Anti-Spam ID that is intended to update RFC3463, he might use (since this is all new anyway): 554 5.8.0 Undefined Policy detail 554 5.8.1 Message refused by local policy or perhaps Murray can propose to Jeff to add a 5.8.27 status code specifically for ADSP related policy rejects: 554 5.8.27 Message refused by ADSP From.Domain=IDENTITY-ODID -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Saturday, May 14, 2011 3:22 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP My reading of SM's comments is for replacing Best Current Practices, not normative language in general (but in particular, where it is redundant.) I consider his thoughts in accord with what another John noted: [...] If the document status changes to Informational, which is what I expect, I don't think we can use normative language at all. 3.6.2 applies to relays, not recipients. A relay might try DKIM validation and ADSP evaluation, but that's not the model this document discusses. Yes, my understanding of that SMTP snippet is that it concerns responses to RCPT TO:particular address, while DKIM and ADSP can only be evaluated after CRLF.CRLF. (In this respect, mentioning user unknown in the MLM spec may cause some confusion in readers not familiar with SMTP.) I don't think it refers to any specific phase of SMTP; could be post-DATA (per DKIM), could be RCPT for some other method. But to be conformant, I suppose 550 5.7.0 would be appropriate. Conformant to what? RFC5321, as cited. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Saturday, May 14, 2011 5:14 AM To: ietf-dkim@mipassoc.org Cc: IETF General Discussion Mailing List; Alessandro Vesely Subject: Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP Ideally, if Murray wishes to support Jeff McDonald's Anti-Spam ID that is intended to update RFC3463, he might use (since this is all new anyway): 554 5.8.0 Undefined Policy detail 554 5.8.1 Message refused by local policy or perhaps Murray can propose to Jeff to add a 5.8.27 status code specifically for ADSP related policy rejects: 554 5.8.27 Message refused by ADSP From.Domain=IDENTITY-ODID I don't have an opinion on that draft yet, but I don't want to delay MLM's publication by referring to Jeff's, whose future is indeterminate right now. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Murray S. Kucherawy wrote: But to be conformant, I suppose 550 5.7.0 would be appropriate. Alessandro Replied: Conformant to what? RFC5321, as cited. See section 4.3.2 DATA I: 354 - data - S: 250 E: 552, 554, 451, 452 E: 451, 554, 503 I don't see 550 there. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Hector Santos wrote: Murray S. Kucherawy wrote: But to be conformant, I suppose 550 5.7.0 would be appropriate. Alessandro Replied: Conformant to what? RFC5321, as cited. See section 4.3.2 DATA I: 354 - data - S: 250 E: 552, 554, 451, 452 E: 451, 554, 503 I don't see 550 there. Correction, I was looking at 2821. 5321 updated it to: DATA I: 354 - data - S: 250 E: 552, 554, 451, 452 E: 450, 550 (rejections for policy reasons) E: 503, 554 550 would be correct for update software. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Hi Hector, At 11:43 14-05-2011, Hector Santos wrote: See section 4.3.2 DATA I: 354 - data - S: 250 E: 552, 554, 451, 452 E: 451, 554, 503 From http://www.rfc-editor.org/rfc/rfc5321.txt DATA I: 354 - data - S: 250 E: 552, 554, 451, 452 E: 450, 550 (rejections for policy reasons) E: 503, 554 Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Nits and Comments: In Section 3.1. author: The agent that provided the content of the message being sent through the system. The author delivers that content to the originator in order to begin a message's journey to its intended final recipients. The author can be a human using an MUA (Mail User Agent) or a common system utility such as cron, etc. What is cron? and how does it interface with the originator defined as the MSA? is cron an MTA or MUA? I suggest to remove the or a common .. text since we already know what MUA implies - a mail creation application or replace the text with: or any other message creation application [with an MTA component]. I personally say take it out. Not needed. Thats an *nix idea. Windows people generally do not know what that is. In Section 3.1. verifier: Any agent that conducts DKIM signature analysis. I know this is a semantical nit, but RFC4671 uses verification, never analysis and it (analysis) is only stated as an out of scope boundary layer concept (in section 3.11). Perhaps the intent is to suggest the verifier does both: verifier: Any agent that conducts DKIM signature validation and perhaps [results|TRUST and ADSP] analysis. In Section 3.1 for receiver, it is very clear with stating the agent for final delivery, so why not add the MDA labeled terminology as it was done with originator with MSA? receiver: . This agent can be often referred to as the Mail Delivery Agent (MDA). -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
At 08:02 12-05-2011, The IESG wrote: The IESG has received a request from the Domain Keys Identified Mail WG (dkim) to consider the following document: - 'DKIM And Mailing Lists' draft-ietf-dkim-mailinglists-10.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-05-26. Exceptionally, comments may be From Abstract Section: Based on deployment experience with DKIM, this Best Current Practices document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). Although one can extrapolate from experience and provide some guidance, I would not call it Best Current Practices. I suggest a change to that sentence: Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). Quoting the Introduction Section: The goal for this document is to explore the use of DKIM for scenarios that include intermediaries, and recommend Best Current Practices based on acquired experience. The Intended Status of this document is BCP. I cannot support a recommendation for Best Current Practices that is not based on existing practices. If the IETF wants a stick to tell the outside world what to do, it can publish this document as a BCP. If the IETF would like to provide guidance, leave it to the outside world to adopt that and then document the current practice, it should not publish this document as a BCP. From Section 2.5: Each of these could have different security policies imposed against them, or there might be a desire to insulate one from the other (e.g., a marketing campaign that gets reported by many spam filters could cause the marketing stream's reputation to degrade without automatically punishing the transactional or user streams). Shouldn't that be sending policies instead of security policies? If we go a stretch further, a marketing campaign might end up be labelled as a terrorist act and that falls under the Security Area. I'll translate that paragraph for a wider audience. Some companies send out spam; it keeps businesses happy if it is called a marketing campaign. These companies also send out messages that the receiver actually wants to read. On the receiving side, there is a lot of zealotry that goes on. One way to mitigate the effects of that zealotry is to provide the receiver a means to separate the spam from other mail. In Section 3.3: Some lists prepend or append a few lines to each message to remind subscribers of an administrative URL for subscription issues, or of list policy, etc. It's funny to see how some MUAs adapted to that by hiding these lines thereby rolling back that fix. In Section 4.1: In an idealized world, if an author knows that the MLM to which a message is being sent is a non-participating resending MLM, the author SHOULD be cautious when deciding whether or not to send a signed message to the list. The author generally does not have any control over that decision as DKIM signing is not done at the MUA level. The usage of a key word is somewhat excessive here as the ideal world is out of scope for RFC 2119. This problem can be compounded if there are receivers that apply signing policies (e.g., [ADSP]) and the author publishes any kind of strict policy, i.e., a policy that requests that receivers reject or otherwise deal severely with non-compliant messages. The definition of insanity is doing the same thing over and over and expecting different results. There are parallels between ADSP and SPF. In Section 5.1: It is RECOMMENDED that periodic, automatic mailings to the list are sent to remind subscribers of list policy. This is currently being done by the IETF under the guise of mailman day. In Section 5.5: In that case, authors SHOULD create a mail stream specifically used for generating signatures when sending traffic to MLMs. I suggest using DKIM signatures. This suggestion can be made more general. Shouldn't that be recommendation? In Section 5.8: DKIM-aware authoring MLMs MUST sign the mail they send according to the regular signing guidelines given in [DKIM]. One concern is that having an MLM apply its signature to unsigned mail might cause some verifiers or receivers to interpret the signature as conferring more authority or authenticity to the message content than is defined by [DKIM]. This is an issue beyond MLMs and primarily entails receive-side processing outside of the scope of [DKIM]. It is nevertheless worth noting here. Removing the MUST and saying: DKIM-aware authoring MLMs signs the messages they send according to the regular signing guidelines given in [DKIM] gives more weight to the last two
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Friday, May 13, 2011 12:16 AM To: i...@ietf.org Cc: ietf-dkim@mipassoc.org Subject: Re: Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP Hi SM, By my read, the bulk of your comments fall into these categories: (1) Remove the normative language, publish as Informational As I said to John, I'd be fine with this. The document started out as Informational but there was working group momentum in the direction of a BCP instead, hence the conversion to use of RFC2119 language. I personally don't have strong feelings about that so if the preferred course of action is to go back to that, I'd be fine. As for the idea of using PS instead, that doesn't seem appropriate to me given we're not standardizing a protocol here, and at best we don't have enough implementation experience to back up the claims. (2) Editorial changes I'd be fine with all of the changes you proposed. (3) RFC5451 discussion In Section 5.11: Receivers SHOULD ignore or remove all unsigned externally-applied Authentication-Results header fields, and those not signed by an ADMD that can be trusted by the receiver. Quoting Section 5 of RFC 5451: For security reasons, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims to have been added within its trust boundary and that did not come from another trusted MTA. For simplicity and maximum security, a border MTA MAY remove all instances of this header field on mail crossing into its trust boundary. The MUST and the MAY are aggregated into a SHOULD. Is that intentional? Yes, I believe they are consistent. The citation you made from RFC5451 directs implementations to delete forgeries (the MUST) and optionally delete everything else as well (the MAY). The citation from this document does not dispute the MUST, and provides further guidance for this particular application (which is also consistent with other parts of RFC5451) in terms of how to deal with what's left after the MUST part is done. From Section 5.11: Upon DKIM and ADSP evaluation during an SMTP session (a common implementation), an agent MAY decide to reject a message during an SMTP session. If this is done, use of an [SMTP] failure code not normally used for user unknown (550) is preferred; therefore, 554 SHOULD be used. This falls under policy decision. The usage of a 554 code is inappropriate. From Section 3.6.2 of RFC 5321: If it [SMTP server] declines to relay mail to a particular address for policy reasons, a 550 response SHOULD be returned. 3.6.2 applies to relays, not recipients. A relay might try DKIM validation and ADSP evaluation, but that's not the model this document discusses. However, if that doesn't matter, unfortunately this makes the distinction we're trying to make impossible without using enhanced status codes, which aren't universally used. But to be conformant, I suppose 550 5.7.0 would be appropriate. Quoting two sentences from the same section to provide better context: In such cases where the submission fails that test, the receiver or verifier SHOULD discard the message but return an SMTP success code, i.e. accept the message but drop it without delivery. An SMTP rejection of such mail instead of the requested discard action causes more harm than good. I would remove the SHOULD as the argument (second sentence) is clear. The usage of the SHOULD raises the question about whether this is a SMTP receiver action and whether it is appropriate to create a black hole (silent drop of message). If we are leaving the normative language in (for BCP, should that status stay) then I think the SHOULD is appropriate in the sentence that defines the normative action. Thanks for the review! -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 13/May/11 09:15, SM wrote: In Section 4.1: In an idealized world, if an author knows that the MLM to which a message is being sent is a non-participating resending MLM, the author SHOULD be cautious when deciding whether or not to send a signed message to the list. The author generally does not have any control over that decision as DKIM signing is not done at the MUA level. The usage of a key word is somewhat excessive here as the ideal world is out of scope for RFC 2119. +1, should be lowercase. This problem can be compounded if there are receivers that apply signing policies (e.g., [ADSP]) and the author publishes any kind of strict policy, i.e., a policy that requests that receivers reject or otherwise deal severely with non-compliant messages. The definition of insanity is doing the same thing over and over and expecting different results. There are parallels between ADSP and SPF. As a corollary, it is sane to do slightly different things over and over until one catches the one that works. SPF is slightly better than ADSP, though. In Section 5.1: It is RECOMMENDED that periodic, automatic mailings to the list are sent to remind subscribers of list policy. This is currently being done by the IETF under the guise of mailman day. Yes, the time-distributed database... In Section 5.8: DKIM-aware authoring MLMs MUST sign the mail they send according to the regular signing guidelines given in [DKIM]. Removing the MUST [...] +1, the MUST is in DKIM's specs and thus is redundant here. In Section 5.10: An FBL operator might wish to act on a complaint from a user about a message sent to a list. Shouldn't that be FBI? :-) +1 (smiley not taken), FBL is a specific mechanism. As much of the advice is also valid for other mechanisms, I suggest to change the title to Abuse Reporting Issues or similar. From Section 5.11: Upon DKIM and ADSP evaluation during an SMTP session (a common implementation), an agent MAY decide to reject a message during an SMTP session. If this is done, use of an [SMTP] failure code not normally used for user unknown (550) is preferred; therefore, 554 SHOULD be used. This falls under policy decision. The usage of a 554 code is inappropriate. From Section 3.6.2 of RFC 5321: If it [SMTP server] declines to relay mail to a particular address for policy reasons, a 550 response SHOULD be returned. -1, although it is a policy question, it has nothing to do with relaying. In such cases where the submission fails that test, the receiver or verifier SHOULD discard the message but return an SMTP success code, i.e. accept the message but drop it without delivery. An SMTP rejection of such mail instead of the requested discard action causes more harm than good. I would remove the SHOULD as the argument (second sentence) is clear. The usage of the SHOULD raises the question about whether this is a SMTP receiver action and whether it is appropriate to create a black hole (silent drop of message). This should have been explained more clearly in RFC 5617. Perhaps, we should say that discardable means droppable in general? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 5/13/11 8:12 PM, Alessandro Vesely wrote:
[...]
In such cases where the submission fails that test, the receiver or
verifier SHOULD discard the message but return an SMTP success code,
i.e. accept the message but drop it without delivery. An SMTP
rejection of such mail instead of the requested discard action
causes more harm than good.
I would remove the SHOULD as the argument (second sentence) is
clear. The usage of the SHOULD raises the question about whether
this is a SMTP receiver action and whether it is appropriate to
create a black hole (silent drop of message).
This should have been explained more clearly in RFC 5617. Perhaps, we
should say that discardable means droppable in general?
The problem what 'discardable' means has been introduced in RFC5617 and
I don't think draft-ietf-dkim-mailingslists-10.txt has to 'fix' that
problem. The meaning of 'discardable' has been discussed on this list at
least two times (see for example
http://mipassoc.org/pipermail/ietf-dkim/2008q1/009557.html) and this has
AFAIK not resulted in one unambiguous conclusion. Furthermore, as it's
not primarily an MLM issue (but an ADSP issue), I don't think we should
re-open the discussion again. Don't get me wrong, I agree with you that
it's important to define what we mean with discardable, but not here,
not now.
I'd propose to put this item ('writeup a definition of 'discardable') on
the to-do list of a successor of RFC5617, if there ever will be one. Or
on another future 'policy' document.
/rolf
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Rolf E. Sonneveld wrote: On 5/13/11 8:12 PM, Alessandro Vesely wrote: [...] In such cases where the submission fails that test, the receiver or verifier SHOULD discard the message but return an SMTP success code, i.e. accept the message but drop it without delivery. An SMTP rejection of such mail instead of the requested discard action causes more harm than good. I would remove the SHOULD as the argument (second sentence) is clear. The usage of the SHOULD raises the question about whether this is a SMTP receiver action and whether it is appropriate to create a black hole (silent drop of message). This should have been explained more clearly in RFC 5617. Perhaps, we should say that discardable means droppable in general? The problem what 'discardable' means has been introduced in RFC5617 and I don't think draft-ietf-dkim-mailingslists-10.txt has to 'fix' that problem. Nothing wrong with DKIM=DISCARDABLE. What is wrong is trying to dictate to others MLM should ignore ADSP. As a MLM vendor, I have technical and ethical engineering obligation not to cause problems when taking on a new inherently incompatible technology that doesn't naturally fit with a MLM. Hence, there are two general solutions for the MLM: MLM-LEVINE: Ignore all DKIM ADSP restrictive policies MLM-SANTOS: Preempt all DKIM ADSP restrictive policies I know as a matter of fact MLM-SANTOS is a better DKIM mail integration fit because we implemented it. Also, you can't dictate to receivers they should ACCEPT and DROP. Although that could be feasible solution to solve MLM ignorance to support ADSP, its a very difficult issue when increasing receiver practice is rejecting bad mail at the DATA level. What I had proposed is is method (rule) at the DATA filter: if message fails ADSP and has a LIST-ID, then respond 250 and discard the message if message fails ADSP and has no LIST-ID, then reject with 55x The problem is the MLM that is *ignoring* ADSP and passing on the buck to ADSP ready member receivers adding the overhead to receivers and also creating new MLM problems for itself. A repeated SMTP level rejection will cause harm to list member by the MLM sender creating false automated unsubscribing notifications when the attempts are exhausted. So if the receivers can detect its a MLM sender incorrectly sending ADSP protected mail, then the only recourse, in the name of not causing problems and backing up the ignorant MLM, is to accept (250) and then drop the message. But the real solution is for the MLM to follow proper DKIM mail integration considerations when adding something new it hasn't done in 40 years. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Hector Santos wrote: Nothing wrong with DKIM=DISCARDABLE. What is wrong is trying to dictate to others MLM should ignore ADSP. As a MLM vendor, I have technical and ethical engineering obligation not to cause problems when taking on a new inherently incompatible technology that doesn't naturally fit with a MLM. Hence, there are two general solutions for the MLM: MLM-LEVINE: Ignore all DKIM ADSP restrictive policies MLM-SANTOS: Preempt all DKIM ADSP restrictive policies I know as a matter of fact MLM-SANTOS is a better DKIM mail integration fit because we implemented it. Keep in mind that I recognize MLM-LEVINE solution but that is based on ignoring all originating DKIM information - pass, fail or unknown. The theory is based on: A) The Member is already authorized based on being a list member already, CONCUR B) No expectation of getting fraud submissions, and if so, a negligible amount, CONCUR C) Ignorance for DKIM failure promoting a relaxed atmosphere of DKIM unknown signer mail, OBJECT. D) Trust the single signer domain at the SYSTEM LEVEL (global), OBJECT. Assuming this MLM-LEVINE is the acceptable solution, then the optimized, lower overhead receiver operation is to first check to see if the signer(s) are known before even trying to verify any signature. What I had proposed is method (rule) at the DATA filter: if message fails ADSP and has a LIST-ID, then respond 250 and discard the message if message fails ADSP and has no LIST-ID, then reject with 55x Note, by fails ADSP, it is presumed the policy is DKIM=DISCARDABLE To complete the logic for always accept systems: if message fails ADSP then discard the message You got to understand there is a split of how systems operate; many systems for scalability reasons, especially in earlier days, always accepted the message and then applies any mail filters. As hardware and software (multi-threaded OSes) improved, and also to address the bounce problem, more systems began to do more dynamic rejections at the DATA level. The technical responsibility to issues bounces is very strong. The idea of discarding was largely frown upon. This multi-decade BOUNCE requirement mindset, which touches base with 1986 US EPCA provisions for avoid censorship claims, has changed for the first time in RFC5321 with new semantics that recognizes the contemporary needs to drop mail when reasonable non-frivolous new considerations are appropriate. I pushed for this recognition known new technology like Sender-ID and ADSP was on the horizon. In short, Levine did a good thing by technically legalizing discarding of mail. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
