Re: [ietf-dkim] SMTP DATA EOD Reject Code for MLMs
On 14/May/11 22:16, Hector Santos wrote: SM wrote: 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) Ok. I recommend (prefer) text that reflects receiver w/o RFC3463 support. +1, and we have to mandate a precise format for the text, I mean a production rule including %x41.44.53.50, or forget this whole idea that a receiver could make a better job by signaling ADSP violations. Practically coding, a DKIM aware MLM adding this conditional check might look for three or five triggers: 554 5.7.0 5.8.0 or 5.8.1 ADSP or POLICY or some other recommended work that could be used. Indeed, a gateway on a Mac that forwards by means of the AppleTalk Data Stream Protocol, may signal a failure of the latter stack by 554 ADSP failure. -- http://www.all-acronyms.com/ADSP ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
Hi Hector, At 15:20 14-05-2011, Hector Santos wrote: Shouldn't the MLM I-D say something regarding C14N and CR/LF related mutations? No. +1 to the No. I have my reservations about the draft, but this is not one of them. 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] MLM and C14N
John R. Levine wrote: Hi Hector, At 15:20 14-05-2011, Hector Santos wrote: Shouldn't the MLM I-D say something regarding C14N and CR/LF related mutations? No. +1 to the No. I have my reservations about the draft, but this is not one of them. In general, I would say NO too because I don't like kludges. My point is that the draft is already peppered with scenarios about how MLM can break things and it properly classifies the known simple list-like type of alias address expanders that in general, the messages is not altered. Of course, we all know its not the only kind; a real List Server always provides list admin options to not alter things like the IETF-SMTP list seems to be been setup (with mailman?). But here, it appears it does add a extra CRLF after the headers. So my question is about whether we should provide an informative implementator insight that there may be an extra CRLF generated by non-DKIM aware list. It can make all the difference in a valid versus invalid DKIM signed submission to a non-DKIM aware MLM, which BTW, I did add logic to my verifier to check for this extra CRLF when a BODY_HASH error first occurs and redo the hash without it. It works! But I am probably going to add a condition based on LIST-ID to enable this check. I fail to see why we would not be interested in giving verifiers some insight into this real live scenario. Is it because its a more general DKIM issue and ideally belongs in RFC4671bis (too late)? -- 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] MLM and C14N
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine Sent: Sunday, May 15, 2011 6:44 AM To: SM Cc: DKIM List Subject: Re: [ietf-dkim] MLM and C14N Hi Hector, At 15:20 14-05-2011, Hector Santos wrote: Shouldn't the MLM I-D say something regarding C14N and CR/LF related mutations? No. +1 to the No. +1 to the No. This is a software problem, not something that needs to be solved by creating a protocol extension. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine Sent: Sunday, May 15, 2011 6:44 AM To: SM Cc: DKIM List Subject: Re: [ietf-dkim] MLM and C14N Hi Hector, At 15:20 14-05-2011, Hector Santos wrote: Shouldn't the MLM I-D say something regarding C14N and CR/LF related mutations? No. +1 to the No. +1 to the No. This is a software problem, You mean the MLM who is ignorant of DKIM meta data for the past 40 years? not something that needs to be solved by creating a protocol extension. Isn't that what you are doing in this MLM I-D, creating a DKIM protocol extension for MLMs? IMV, this MLM I-D is 100% about a MLM and VERIFIER mail integration protocol inconsistency, i.e. software problems, in dictating whats MLM and Verifier Software need to be considered and change to retrofit DKIM and ADSP into a MLM and MLM related issues with verifiers. IMV, the issue equally falls in the same MLM chaotic environment in how there long legacy behavior and different ways it can break transparent meta data we call DKIM. The extra CRLF preexisted DKIM - we can tell these software to not do this or that for the sake of DKIM, but is that realistic? I don't think so - the burden is on DKIM. -- 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] MLM and C14N
-Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Sunday, May 15, 2011 9:25 AM To: Murray S. Kucherawy Cc: DKIM List Subject: Re: [ietf-dkim] MLM and C14N This is a software problem, You mean the MLM who is ignorant of DKIM meta data for the past 40 years? Yes, that's what I mean. not something that needs to be solved by creating a protocol extension. Isn't that what you are doing in this MLM I-D, creating a DKIM protocol extension for MLMs? No, that's not what that document does. Creating a new canonicalization is a protocol extension. It creates a slippery slope wherein we are constantly creating or adjusting canonicalization algorithm(s) to deal with new cases we find and want to accommodate. It's a bad idea. ___ 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] MLM and C14N
Hi Hector, At 21:40 14-05-2011, Hector Santos wrote: Can't share the wisdom why? It's merely an opinion. Please see Murray's comment about a slippery slope. 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 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] MLM and C14N
On May 15, 2011, at 8:44 AM, John R. Levine wrote: Hi Hector, At 15:20 14-05-2011, Hector Santos wrote: Shouldn't the MLM I-D say something regarding C14N and CR/LF related mutations? No. +1 to the No. +1 to the No. -- 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] MLM and C14N
SM wrote: Hi Hector, At 21:40 14-05-2011, Hector Santos wrote: Can't share the wisdom why? It's merely an opinion. Please see Murray's comment about a slippery slope. I understand the point. But we are doing all this already like section 3.3 Current MLM Effects On Signatures; Minor body changes. It says: Minor body changes: 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. The sentence can include or be extended: In addition, some list changes are not obvious and may be just an extra line between the header and start of the body. This a MLM mail integrity deviation just like all the other obscure MLM mail integrity issues we can have. I personally would like to extend it to say: This is an C14N issue that is out of scope but its possible invalid signatures can be valid when the extra line is removed from the hashing. Again, this is a real live MLM stream scenario. Why doesn't anyone care about addressing these types of MLM streams? This is suppose to be an informative guide about the issues retrofitting an MLM with DKIM. Not the other way around. Why not provide the insights, all the issues and let the verifier decide? Why not let the MLM developer learn what his software might be doing so he might fix it? -- 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
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] MLM and C14N
+1. No. John R. Levine jo...@iecc.com wrote: No. +1 to the No. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
Do you know what is being asked? A real live LIST organism (stream) is adding an extra line (two bytes, CRLF) after the header and before the body probably all its life and this new thing, this new document called: DKIM And Mailing Lists has no interest in adding another note in section 3.3 titled Current MLM Effects On Signatures regarding a real living, walking and running MLM behavior? This is surreal. Don't shoot the messenger, listen to the message! -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Dave Crocker wrote: +1. No. John R. Levine jo...@iecc.com wrote: No. +1 to the No. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
Do you know what is being asked? I think everyone understands what you're asking. They just disagree, and so do I. When all this started, before DKIM came to the IETF, and then again afterward, we spent a *lot* of time looking at the canonicalization algorithms -- and they were changed a bit after the work came into the IETF. We didn't come by them casually. Throughout it, there were a few goals in choosing canonicalization algorithms: 1. We didn't want more than one or two. This obviously never did nor never should take precedence over a true need for another one, but the idea is that the bar needs to be very high for a new one. The combinatorics get messy. 2. We wanted to cover the vast majority of the cases, though we knew there'd always be outlying situations where some mail would get broken because what we had didn't *quite* cover some other case. We decided to accept that. 3. We absolutely did *not* want to go adding new algorithms for this or that piece of software that was getting something wrong. Canonicalization algorithms were *not* designed to work around broken software. They're meant to deal primarily with legitimate, if sometimes unfortunate, changes that get made to the mail along the way, and secondarily with *very common* situations that creep into the questionable area. A real live LIST organism (stream) is adding an extra line (two bytes, CRLF) after the header and before the body probably all its life It's an outlier, off in the weeds. This is not a common situation all around the Internet. And in any case, the MLM document isn't the place to define a new algorithm. This is surreal. Don't shoot the messenger, listen to the message! There's nothing surreal here, and, again, I ask you to stop being extreme and inflammatory. Calm discussion, please. Anyway, we *are* listening to the message. It seems that at least five people have listened, and responded. Their response is simply one of disagreement. Listening is not the same as agreeing. Six. I also disagree. 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
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] MLM and C14N
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Barry Leiba Sent: Sunday, May 15, 2011 7:56 PM To: Hector Santos Cc: DKIM List Subject: Re: [ietf-dkim] MLM and C14N Do you know what is being asked? 1. We didn't want more than one or two. This obviously never did nor never should take precedence over a true need for another one, but the idea is that the bar needs to be very high for a new one. The combinatorics get messy. 2. We wanted to cover the vast majority of the cases, though we knew there'd always be outlying situations where some mail would get broken because what we had didn't *quite* cover some other case. We decided to accept that. 3. We absolutely did *not* want to go adding new algorithms for this or that piece of software that was getting something wrong. Canonicalization algorithms were *not* designed to work around broken software. They're meant to deal primarily with legitimate, if sometimes unfortunate, changes that get made to the mail along the way, and secondarily with *very common* situations that creep into the questionable area. I would add that adding a new canonicalization now has an extremely high cost to the people that want to use it, because signatures using it will go unverified for a very long time until software supporting the new canonicalization is widely deployed. We shouldn't underestimate what all of that means just to handle one or two corner cases that are actually more likely broken software than an actual universal problem mandating a protocol extension. The same goes for new signing algorithms. ECC, whenever DKIM is extended to cover it, will be an interesting experiment. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
Barry Leiba wrote: Do you know what is being asked? A real live LIST organism (stream) is adding an extra line (two bytes, CRLF) after the header and before the body probably all its life It's an outlier, off in the weeds. This is not a common situation all around the Internet. And in any case, the MLM document isn't the place to define a new algorithm. I winged out two things; mentioning the MLM behavior which is real, live, current and if you like, a recommendation a kludge for verifiers to consider. I already said I don't like kludges, but I fail to see why it can't be mentioned that MLM exists that can add the extra line. Minor body changes: 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, including some lists adding an extra line after the header and before the body. Six. I also disagree. Fine, but did you ever see the movie 12 Angry Men? :) No, I have no interesting continuing this but for the record, I do find it very inconsistent to ignore a real scenario for an MLM I-D who's main purpose is to provide information about the real MLM/DKIM incompatibility issues and intentionally wants to hide this insight that could promote changes. -- 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
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
