Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
MH Michael Hammer (5304) wrote: How does a 3rd party signing a message change the intent of the author of a message? One might argue that breaking the original signature does that. My response would be to then avoid breaking the original signature. But list servers will naturally do break the message, dkim signed or not. no? I want to minimize issues when adding DKIM considerations to our list server - not create more issues. Today, there is a common practice with MLS altering one, all or more of the following: - Optional Subject List Name Tags, i.e. [ietf-dkim] subject - Reply-To: change to accommodate the current UI of most RFC based mail readers with its default button/menu logic: [ Reply ] - Uses Reply-To or From: [ Reply to All ] - Uses all Originator fields To:, Cc: Reply-To Some MLS (like ours) will offer a list option to change the Reply-To so that the natural behavior of a user clicking Reply will go back to the list and not a direct email to the author of the message. - footers and (headers), with the footers the most common - Stripping based on content restrictions (no attachments, no html content-types), etc. The question becomes under what conditions should a MLS-based DKIM signing take place to eliminate downlinks DKIM verification issues, including damages to domain reputation. The only thing I can see if to remove all original domain considerations. With no Policy, author domains are less important. One of the arguments put forward supporting the DKIM effort was that unlike SPF it is not hop dependent. True, but SPF does have RFC 4405 (SUBMITTER) to help address hop transition Domain::IP association issues. For DKIM, the irony is that it might have similar issues from the standpoint of the route path and who was last (re)signed. MUA - | MSA/MTA/SIGNS | - MTA/BREAKS ROUTE #1 - MTA/RESIGNS - MTA - MDA ROUTE #2 - MTA - MDA We had a support incident last year where the MTA took one of two routes (for some reason). Depending on the route, a Date was added to the original message (because it was missing), the other did not. When the messages reached the customers server (our product), the customer was complaining about different mail reader display dates. This proves its possible that is a DKIM ignorants MTAs can have two or more different routes for distribution. So just like SPF, depending on the route it takes, things can break. Does the new MTAs now need to learn to use a special route for DKIM messages only? One with minimum hops? Here's an idea: Can receivers help the process by adding a special MX record specifically for DKIM reception to help MTA take a direct path? Maybe special by sub-domain? mx1-dkim-receptor.domain.com I guess the overall issue is why should any MTA, including a list server auto-correct a broken message and it is safer to only consider resigning when it going to break a valid dkim message? -- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
On Tue, 16 Jun 2009 23:05:33 +0100, SM s...@resistor.net wrote: -7. His signature did NOT cover the A-R he had added (so we have to assume that it was not an artefact by the spammer, although it most certainly SHOULD have been removed if it was). So we may well believe the list manager had put it there, but it would be nicer to have had some proof. At a guess, I'd say that the list manager did not put that header there. As a matter of interest, could you say why? AFAICS, this spam actually came from a sleeping member of this list who was trying to drum up friends on Facebook, and inadvertently sent it to everyone in his address book, including this list (observe the 'whitelist' remarks in the X-Greylist header). Indeed, he subsequently apologised on this list for his error, and the headers on his apology are exactly analagous to those on the spam. Moreover, if this A-R header HAD been present in the original, it SHOULD have been removed by the list manager, according to RFC 5451. -- 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] Modified Introduction text for rfc4871-errata (resend)
Well it would be nice if i=author.net and d=3rd.party.signer.isp.com but no one agreed so I'll shut up now :-) -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Tuesday, June 16, 2009 6:14 PM To: DKIM WG Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend) On Jun 16, 2009, at 2:35 PM, Michael Thomas wrote: 1) People saying that d= is THE IDENTIFIER are overloading the value: d= a routing label to a particular DNS subtree. Whether it has anything to do with THE IDENTIFIER is purely coincidental. The assumption that these two functions are identical is bogus. i= was supposed to be this stable value detached from the mechanical DNS routing function. Are you confusing the d= value and the DNS node (including selectors and suchlike) that the public key lives at? The d= value has been the persistent identifier for the signer since day one, while the i= value is a more specific value that the signer can optionally use. Given that the RHS of i= is either identical or a subdomain of d= it's nonsensical to consider i= more stable than d=, as i= must change if d= does. Cheers, Steve ___ 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] list expanders (was Re: chained signatures, was l= summary)
Charles Lindsey wrote: So there remain only two things he did _not_ do, which he might have done: -7. His signature did NOT cover the A-R he had added (so we have to assume that it was not an artefact by the spammer, although it most certainly SHOULD have been removed if it was). So we may well believe the list manager had put it there, but it would be nicer to have had some proof. +1, I think it makes sense to bind the A-R recording of a stripped original signature. -8. The list manager did not retain the original (and now broken) original signature. Tnere are certainly some on this list who would have preferred to see it left (for forensics). Or changed to X-DKIM-Signature and bind this also in the new signature. -- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)
+1 -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Tuesday, June 16, 2009 5:53 PM To: Cullen Jennings; dcroc...@bbiw.net Cc: pasi.ero...@nokia.com; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend) tThis update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature and specifies their relationship. More specifically, it clarifies that the identifier intended for delivery to the assessor -- such as one that consults a white list -- is the value of the d= tag. However, this does not prohibit message filtering engines from using the i= tag, or any other information in the message's header, for filtering decisions. /t Look, this is clear as mud - What I am getting is that the old document was unclear if you should use the d= or the i= and this document clarifies it to be you should use, uh, I'm totally lost here, I use the d= for white lists, which are a form a filtering, but I can also use the i= for filtering. I'm just unclear on what one is supposed to use and when. And honestly it does not matter if I am confused in the slightest, but it does matter if people implementing this stuff are unclear on this. Evidently there is enough confusing about this that it is worth writing an RFC to fix it - that I believe. However, people outside the WG other than me seem like they too have a hard time reading this and figuring out how this clarifies what to do. This does seem like a bit of a problem. Think about it in terms of an API specification. The intent here, I believe, is to specify that d= is mandatory output of a DKIM verifier module. i= (and everything else, frankly) is optional. Thus, a compliant verifier implementation will give you a yes/no on the signature and the name of the domain in d=. There may be other stuff there, but that's what you need for minimal compliance and interoperability. A consumer of such a minimal specification could conceivably interchange DKIM implementations and still keep working as before. However, there are no guarantees if such a consumer decides to try to make use of optional stuff like i= or x= or l= or whatever, because some other DKIM verifier implementation might not give that to you. But if you code for yes/no and d= only, then any compliant verifier will give you what you need to interoperate. If you as a consumer of such an API feel that you'd rather use i= for particular applications or types of messages, then either create or use an implementation that makes that value available. There's nothing wrong with that either. (If any of that language resolves the concern, feel free to use it.) -MSK ___ 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] Modified Introduction text forrfc4871-errata (resend)
+1 -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Tuesday, June 16, 2009 5:53 PM To: Cullen Jennings; dcroc...@bbiw.net Cc: pasi.ero...@nokia.com; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend) tThis update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature and specifies their relationship. More specifically, it clarifies that the identifier intended for delivery to the assessor -- such as one that consults a white list -- is the value of the d= tag. However, this does not prohibit message filtering engines from using the i= tag, or any other information in the message's header, for filtering decisions. /t Look, this is clear as mud - What I am getting is that the old document was unclear if you should use the d= or the i= and this document clarifies it to be you should use, uh, I'm totally lost here, I use the d= for white lists, which are a form a filtering, but I can also use the i= for filtering. I'm just unclear on what one is supposed to use and when. And honestly it does not matter if I am confused in the slightest, but it does matter if people implementing this stuff are unclear on this. Evidently there is enough confusing about this that it is worth writing an RFC to fix it - that I believe. However, people outside the WG other than me seem like they too have a hard time reading this and figuring out how this clarifies what to do. This does seem like a bit of a problem. Think about it in terms of an API specification. The intent here, I believe, is to specify that d= is mandatory output of a DKIM verifier module. i= (and everything else, frankly) is optional. Thus, a compliant verifier implementation will give you a yes/no on the signature and the name of the domain in d=. There may be other stuff there, but that's what you need for minimal compliance and interoperability. A consumer of such a minimal specification could conceivably interchange DKIM implementations and still keep working as before. However, there are no guarantees if such a consumer decides to try to make use of optional stuff like i= or x= or l= or whatever, because some other DKIM verifier implementation might not give that to you. But if you code for yes/no and d= only, then any compliant verifier will give you what you need to interoperate. If you as a consumer of such an API feel that you'd rather use i= for particular applications or types of messages, then either create or use an implementation that makes that value available. There's nothing wrong with that either. (If any of that language resolves the concern, feel free to use it.) -MSK ___ 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] Modified Introduction text forrfc4871-errata (resend)
MH Michael Hammer (5304) wrote: +1 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- Hmmm. Noting two quick +1s to Murray's text and in the interest of still trying to bring this quick errata/update effort to a close, I'm inclined to suggest adding his explanatory text to the existing proposed addition. While it's entirely plausible that Murray can formulate a superior version of the basic text for the addition, I think that the existing +1s for the existing text and the +1s for Murray's commentary offers us something quicker. So, here's a suggested merging of the two: tThis currently leaves signers and assessors with the potential for making different interpretations between the two identifiers and may lead to interoperability problems. A signer could intend one to be used for assessment, and have a non-reputation intent in setting the value in the other. However the verifier might choose the wrong value to deliver to the assessor, thereby producing an unintended (and inaccurate) assessment./t tThis update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature and specifies their relationship. More specifically, it clarifies that the identifier intended for delivery to the assessor -- such as one that consults a white list -- is the value of the d= tag. However, this does not prohibit message filtering engines from using the i= tag, or any other information in the message's header, for filtering decisions. /t tFor signers and verifiers that have been using the i= tag as the primary value that is delivered to the assessor, a software change to using the d= tag is intended. /t tSo, this Update clarifies the formal interface to DKIM, after signature verification has been performed. It distinguishes DKIM's internal signing and verification activity, from its standardized delivery of data to that interface./t tThe focus of the Update is on the portion of DKIM that is much like an API definition. If DKIM is implemented as a software library for use by others, it needs to define what outputs are provided, that is, what data that an application developer who uses the library can expect to obtain as a result of invoking DKIM on a message./t tThis Update draft defines the output of that library to include the yes/no result of the verification and the d= value. In other words, it says what (one) identifier was formally specified for use by the signer and whether the use of that identifier has been validated. For a particular library, other information can be provided at the discretion of the library developer, since developers of assessors -- these are the consumers of the DKIM library -- well might want more information than the standardized two pieces of information. However that standardized set is the minimum that is required to be provided to a consuming module, in order to be able to claim that the library is DKIM compliant./t tThis does not state what the implicit value of i= is, relative to d=. In this context, that fact is irrelevant./t tAnother example is the difference between the socket interface to TCP versus the TCP protocol itself. There is the activity within the protocol stack, and then there is the activity within in the software libraries that are actually used./t Comments? (And yes, quick +1s are eagerly sought.) 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] Modified Introduction text forrfc4871-errata (resend)
+1 -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Wednesday, June 17, 2009 11:08 AM To: MH Michael Hammer (5304) Cc: ietf-dkim@mipassoc.org; pasi.ero...@nokia.com; dcroc...@bbiw.net Subject: Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend) Importance: High MH Michael Hammer (5304) wrote: +1 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- Hmmm. Noting two quick +1s to Murray's text and in the interest of still trying to bring this quick errata/update effort to a close, I'm inclined to suggest adding his explanatory text to the existing proposed addition. While it's entirely plausible that Murray can formulate a superior version of the basic text for the addition, I think that the existing +1s for the existing text and the +1s for Murray's commentary offers us something quicker. So, here's a suggested merging of the two: tThis currently leaves signers and assessors with the potential for making different interpretations between the two identifiers and may lead to interoperability problems. A signer could intend one to be used for assessment, and have a non-reputation intent in setting the value in the other. However the verifier might choose the wrong value to deliver to the assessor, thereby producing an unintended (and inaccurate) assessment./t tThis update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature and specifies their relationship. More specifically, it clarifies that the identifier intended for delivery to the assessor -- such as one that consults a white list -- is the value of the d= tag. However, this does not prohibit message filtering engines from using the i= tag, or any other information in the message's header, for filtering decisions. /t tFor signers and verifiers that have been using the i= tag as the primary value that is delivered to the assessor, a software change to using the d= tag is intended. /t tSo, this Update clarifies the formal interface to DKIM, after signature verification has been performed. It distinguishes DKIM's internal signing and verification activity, from its standardized delivery of data to that interface./t tThe focus of the Update is on the portion of DKIM that is much like an API definition. If DKIM is implemented as a software library for use by others, it needs to define what outputs are provided, that is, what data that an application developer who uses the library can expect to obtain as a result of invoking DKIM on a message./t tThis Update draft defines the output of that library to include the yes/no result of the verification and the d= value. In other words, it says what (one) identifier was formally specified for use by the signer and whether the use of that identifier has been validated. For a particular library, other information can be provided at the discretion of the library developer, since developers of assessors -- these are the consumers of the DKIM library -- well might want more information than the standardized two pieces of information. However that standardized set is the minimum that is required to be provided to a consuming module, in order to be able to claim that the library is DKIM compliant./t tThis does not state what the implicit value of i= is, relative to d=. In this context, that fact is irrelevant./t tAnother example is the difference between the socket interface to TCP versus the TCP protocol itself. There is the activity within the protocol stack, and then there is the activity within in the software libraries that are actually used./t Comments? (And yes, quick +1s are eagerly sought.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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] Modified Introduction text forrfc4871-errata (resend)
On Wed, Jun 17, 2009 at 9:07 PM, bill.ox...@cox.com wrote: +1 +1 tFor signers and verifiers that have been using the i= tag as the primary value that is delivered to the assessor, a software change to using the d= tag is intended. /t s/intended/required/ possibly? Otherwise I'm good with this change. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
API Definition? The socket example? Come on. BTW, What is the definition of an Application Programming Interface and what portion of DKIM is like an API definition. This is incomprehensible, overdone to get some simple concept across that only needs 1 or 2 paragraphs. Dave, these paragraphs is really obscure. You can do better and get this API angle out. If you going to this level, you need to be more specific with software engineering terminologies and how it applies to SMTP. Murray's API is not going to be same as MY API or that guys API and it may not be just in C or C++, but in multiple of languages, and the API be COM interface, a .NET interface, including a JAVA interface. It may come in the form of shims, hooks, callouts, triggers, events or what have you. If the functional model is attempted be described, a simple paragraph that ALL developers with SMTP knowledge will understand might be: DKIM Verification and Assessors Processing can be done during the SMTP session or post acceptance level. In order to provide assessors the available data it might need, the DKIM verification result, the RFC 5321 envelope fields and RFC 5322 payload SHOULD be made available for internal and external Assessor processing. At a minimum, the DKIM verification result and the DKIM-Signature signing domain identity (D=) value MUST be made available to assessors. How the information is provided to Assessors is implementation dependent and not in scope of this document. Simple? Huh? --- Dave CROCKER wrote: MH Michael Hammer (5304) wrote: +1 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- Hmmm. Noting two quick +1s to Murray's text and in the interest of still trying to bring this quick errata/update effort to a close, I'm inclined to suggest adding his explanatory text to the existing proposed addition. While it's entirely plausible that Murray can formulate a superior version of the basic text for the addition, I think that the existing +1s for the existing text and the +1s for Murray's commentary offers us something quicker. So, here's a suggested merging of the two: tThis currently leaves signers and assessors with the potential for making different interpretations between the two identifiers and may lead to interoperability problems. A signer could intend one to be used for assessment, and have a non-reputation intent in setting the value in the other. However the verifier might choose the wrong value to deliver to the assessor, thereby producing an unintended (and inaccurate) assessment./t tThis update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature and specifies their relationship. More specifically, it clarifies that the identifier intended for delivery to the assessor -- such as one that consults a white list -- is the value of the d= tag. However, this does not prohibit message filtering engines from using the i= tag, or any other information in the message's header, for filtering decisions. /t tFor signers and verifiers that have been using the i= tag as the primary value that is delivered to the assessor, a software change to using the d= tag is intended. /t tSo, this Update clarifies the formal interface to DKIM, after signature verification has been performed. It distinguishes DKIM's internal signing and verification activity, from its standardized delivery of data to that interface./t tThe focus of the Update is on the portion of DKIM that is much like an API definition. If DKIM is implemented as a software library for use by others, it needs to define what outputs are provided, that is, what data that an application developer who uses the library can expect to obtain as a result of invoking DKIM on a message./t tThis Update draft defines the output of that library to include the yes/no result of the verification and the d= value. In other words, it says what (one) identifier was formally specified for use by the signer and whether the use of that identifier has been validated. For a particular library, other information can be provided at the discretion of the library developer, since developers of assessors -- these are the consumers of the DKIM library -- well might want more information than the standardized two pieces of information. However that standardized set is the minimum that is required to be provided to a consuming module, in order to be able to claim that the library is DKIM compliant./t tThis does not state what the implicit value of
Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
On Jun 17, 2009, at 8:08 AM, Dave CROCKER wrote: So, here's a suggested merging of the two: This currently leaves signers and assessors with the potential for making different interpretations between the two identifiers and may lead to interoperability problems. A signer could intend one to be used for assessment, and have a non-reputation intent in setting the value in the other. However the verifier might choose the wrong value to deliver to the assessor, thereby producing an unintended (and inaccurate) assessment. Can you provide examples of interoperability problems? Any reputation assessment system should not: 1) limit what is to be assessed. 2) allow inclusion of un-assessed information used to provide annotation! The change being recommended reduces intended protections. This update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature and specifies their relationship. More specifically, it clarifies that the identifier intended for delivery to the assessor -- such as one that consults a white list -- is the value of the d= tag. However, this does not prohibit message filtering engines from using the i= tag, or any other information in the message's header, for filtering decisions. This statement is wrong because: 1) Any white-listing practice based upon replayable signatures _will_ be abused. 2) Use of the i= value is being defined as permission to discard email! This is creating an operational problem by having email is accepted and then having it discarded. This creates a disincentive for signers to offer additional intra-domain information. So, this Update clarifies the formal interface to DKIM, after signature verification has been performed. It distinguishes DKIM's internal signing and verification activity, from its standardized delivery of data to that interface. What interface, the presentation layer? The focus of the Update is on the portion of DKIM that is much like an API definition. If DKIM is implemented as a software library for use by others, it needs to define what outputs are provided, that is, what data that an application developer who uses the library can expect to obtain as a result of invoking DKIM on a message. This Update draft defines the output of that library to include the yes/no result of the verification and the d= value. It would be inherently unsafe to intentionally ignore information used for presentation. As such, the i= value (or its default) SHOULD be assessed. It can be and I'll be happy to describe an API that meets the requirement. Such an API can avoid the inter-operational problems your change will create. This does not state what the implicit value of i= is, relative to d=. In this context, that fact is irrelevant. The i= value clarifies the entity on whose behalf the signature was added, and directs annotation process. The d= value is irrelevant to an assessment of behavior history, especially when the d= value might combine the behaviors of millions. This change to DKIM is simply wrong, since the goal of DKIM is to defend against spoofing. This change invites massive intra-domain spoofing. Another example is the difference between the socket interface to TCP versus the TCP protocol itself. There is the activity within the protocol stack, and then there is the activity within in the software libraries that are actually used. The TCP socket does not acknowledge TCP packets and then discard them before being presented, and yet this is the change being advocated. :^( Measures that email must take to fend off massive abuse should not then result in email becoming even more unreliable. Public MTAs (port 25) should explicitly declare an intent to issue email. It may not be too late to resurrect your CVS effort. Once public MTAs can be identified and consolidated, the overall size of public MTA assessments is likely around 8 million. This would exclude servers that depend upon email for monitoring purposes. These sources will likely require specific ACLs. Anti-abuse schemes that attempt to redirect assessments to customers of public MTAs will not scale, especially when they involve dozens of transactions. Each transaction or cryptographic operation will be abused a million fold. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)
Are you trying to say? DKIM_RESULT = DKIM_VERIFY(ENVELOPE, PAYLOAD) FINAL_RESULT = DKIM_ASSESSOR(DKIM_RESULT, DKIM_TAG_QUERY(D) ) -- minimum requirement? I don't fully understand your notation, but I think what I'm saying is that a minimal DKIM implementation provides what's in parentheses on the second line. It might provide more, but to claim to be compliant (after approval of the errata document) it has to provide at least that much. What does the verification process entail? You've shown it in the first line above. Think of another example, like the socket interface to TCP vs. the TCP protocol itself. There's what's going on in the protocol stack and then there's what's going on in the C libraries we actually use. How about higher layer wrappers and classes for sockets which have different models, sync vs async for example? g Also good examples: None of them offer you direct access to data in the TCP headers, for example. They could, but they don't. All you need as an application writer is the payload (if any) and a return status from an operation. The internal bits are generally not your concern. If you really want the internal stuff, you can switch to raw sockets or an API with more switches and knobs. The libc function gethostbyname() is another example: you give it a hostname and it gives you back one or more IP addresses (or an error). If you want more control over the query and the reply, switch to the res_*() functions. If you want even more control over stuff like timeouts and the actual transport, use res_mkquery() and manage the sockets yourself. The underlying protocol is the same in all cases. (I could be wrong but for the sake of example, let's say:) POSIX specifies gethostbyname() will give you back what you want plus an error status in a global variable called h_errno. Let's also say some implementation decides to do invisibly do DNSSEC, and for that implementation you get another global called h_dnssec that tells you whether or not the reply was secure. Both the standard implementation and this one are POSIX-compliant, but this one has some extensions. And maybe everyone desires that extension and installs this version of the resolver and uses it. It may even become wildly popular, but the extension is officially not interoperable in terms of what the standard says. The DKIM errata document, to me, simply declares a minimal interface that you MUST export in order to be able to say you are compliant. I got that impression too when it was first put out. But I think it was odd since implementators will do what is necessary to make whatever is necessary. Any API interface and I/O will be defined by the ASSESSOR. It will define what is needed to do its work. The input is simple - RFC 2822 payload. If you are saying the basic model for an accessor is BOOL DKIM_ASSESSOR(BOOL DKIM_RESULT, STRING D_TAG_VALUE) thats cool. But why limit yourself? Nobody's saying you have to limit yourself. On the contrary, what I believe the errata document is trying to do is specify clearly that you have to do at least X, but doesn't constrain you from doing more. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
BTW, What is the definition of an Application Programming Interface and what portion of DKIM is like an API definition. I'm quite comfortable with drawing an implicit you must be this tall line and assuming someone reading this, i.e. an implementer (e.g. YOU), will know what an API is. Or would you rather require even the definitions of words like framework, authentication, email, public key, verification, source, messages and transfer, all of which appear in the first sentence of the abstract of RFC4871, be included? Let's not be absurd here. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
So, here's a suggested merging of the two: tThis currently leaves signers and assessors with the potential for making different interpretations between the two identifiers and may lead to interoperability problems. A signer could intend one to be used for assessment, and have a non-reputation intent in setting the s/a non-reputation/some unspecified/ value in the other. However the verifier might choose the wrong value to deliver to the assessor, thereby producing an unintended (and inaccurate) assessment./t tThis update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature and specifies their relationship. More specifically, it clarifies that the identifier intended for delivery to the assessor -- such as one that consults a white list -- is the value of the d= tag. However, this does not prohibit message filtering engines from using the i= tag, or any other information in the message's header, for filtering decisions. /t tFor signers and verifiers that have been using the i= tag as the primary value that is delivered to the assessor, a software change to using the d= tag is intended. /t tSo, this Update clarifies the formal interface to DKIM, after signature verification has been performed. It distinguishes DKIM's internal signing and verification activity, from its standardized delivery of data to that s/,// interface./t tThe focus of the Update is on the portion of DKIM that is much like an API definition. If DKIM is implemented as a software library for use by others, it needs to define what outputs are provided, that is, what data that an application developer who uses the library can expect to obtain as a result of invoking DKIM on a message./t tThis Update draft defines the output of that library to include the yes/no result of the verification and the d= value. In other words, it says what (one) identifier was formally specified for use by the signer and whether the use of that identifier has been validated. For a particular library, other information can be provided at the discretion of the library developer, since developers of assessors -- these are the consumers of the DKIM library -- well might want more information than the standardized two pieces of information. However that standardized set is the minimum that is required to be provided to a consuming module, in order to be able to claim that the library is DKIM compliant./t tThis does not state what the implicit value of i= is, relative to d=. In this context, that fact is irrelevant./t tAnother example is the difference between the socket interface to TCP versus the TCP protocol itself. There is the activity within the protocol stack, and then there is the activity within in the software libraries that are actually used./t s/used/made visible to consumers/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
If you going to this level, you need to be more specific with software engineering terminologies and how it applies to SMTP. Murray's API is not going to be same as MY API or that guys API and it may not be just in C or C++, but in multiple of languages, and the API be COM interface, a .NET interface, including a JAVA interface. It may come in the form of shims, hooks, callouts, triggers, events or what have you. I don't think the proposed text defines any property of the API other than the fact that it must export two things: the verification result and the d= value. The text does not stipulate what language has to be used, nor does it specify what that interface must look like. So it already satisfies your requirement. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
Any reputation assessment system should not: 1) limit what is to be assessed. The proposed text does not put any limits on what gets assessed. If an assessor wants more information, it is free to use a verifier that provides more information. 2) allow inclusion of un-assessed information used to provide annotation! That's out of scope, since the annotation is not placed by the verifier, which is what we're discussing. This statement is wrong because: 1) Any white-listing practice based upon replayable signatures _will_ be abused. That also seems to be out of scope to me, since it's not in the realm of the verifier. 2) Use of the i= value is being defined as permission to discard email! That also seems to be out of scope to me, since it's not in the realm of the verifier. What interface, the presentation layer? A DKIM API, which I suppose would live in the presentation layer. It would be inherently unsafe to intentionally ignore information used for presentation. As such, the i= value (or its default) SHOULD be assessed. It can be and I'll be happy to describe an API that meets the requirement. Such an API can avoid the inter-operational problems your change will create. So you are seeking to make delivery of i= a third mandatory output for a compliant DKIM verifier? I believe there is already consensus against the mandatory part of that. The TCP socket does not acknowledge TCP packets and then discard them before being presented, and yet this is the change being advocated. :^( That would be a protocol detail that's hidden from the user, and thus not relevant to an API specification such as the one we're discussing. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] General Feedback loop using DKIM
Franck Martin wrote: I'm worried that sending an email when the signature fails could be triggered by forged emails rather than by emails that contains dkim errors. DKIM being clearly defined, a DKIM signed email should be correct/wrong regardless of the destination. Easy to test the DKIM signature pass on a couple of DKIM reflectors. Therefore reports due to a failed signature would indicate only forged emails. I'm not sure what information a sender gains by knowing someone is forging its signature? Financial institutions tend to be very interested in finding out when their domain is used in phishing attempts, or similar forgeries. However, that's the only type of feedback you've mentioned which is related to DKIM. I'm not sure it makes sense to tie the rest to a DKIM key record. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
Murry, How else can this be said? Think SMTP and think how a SMTP system will provide the process environment variables to either embedded filtering system or external SMTP filtering system. Most SMTP servers with an ACL or similar concept, including SendMail with its mfilters, our ours with WCX hooks, etc do not limit the external interface prototyping to just one or two variables. The process variables are fixed: 2821 (envelope) 2822 (payload) How these are provided to the filters differ from SMTP to SMTP system, by in general, both are available. Here's the problem. You have generalize ASSESSORS to have two minimum inputs: BOOLEAN (DKIM verification result) STRING (DKIM D= value) 1) Why? Do you have a specific ASSESSOR in mind that is only privy to certain people? 2) How does a DKIM implementation generalize the fixed prototype to satisfy newer ASSESSOR that require different input? You are going to need some protocol that defines the input requirements for the specific and different assessor. The more general function prototype is to provide the entire process environment variables, this is 1000% better for the general population of developers of accessor routines: ASSESSOR_RESULT is a function of SMTP data + DKIM result this allows for example,a SMTP system to run a wildcard filter FOR EACH ASSESSOR in ASSESSORS.LIST RESULT = EXECUTE( ACCESSOR, ENVELOPE, PAYLOAD) IF NOT RESULT THROW EXCEPTION, RETURN FALSE or whatever END IF END FOR That is general fit all never fail model. I'm pretty sure it applies to everyone, even you. In short, it is the unspoken ASSESSOR API limited to two fields that needs to change to better fit a generalize global SMTP/DKIM model. If don't your suggested way, then its becomes harder to program because it will look like this: FOR EACH ASSESSOR in ASSESSORS.LIST PARAMETERS = QUERY_ASSESSOR_REQUIRED_DATA(ACCESSOR) RESULT = EXECUTE( ACCESSOR, PARAMETERS) IF NOT RESULT THROW EXCEPTION, RETURN FALSE or whatever END IF END FOR EXECUTE will now have to create the proper function prototype stack with the variable list parameters in order to satisfy specific ASSESSOR APIs with different functional prototypes. Just providing feedback on years experience of developing an a high end SDK/API for C/C++, DELPHI, JAVA, PHP, VB, .NET languages and three basic API models; native, COM and .NET. -- HLS Murray S. Kucherawy wrote: BTW, What is the definition of an Application Programming Interface and what portion of DKIM is like an API definition. I'm quite comfortable with drawing an implicit you must be this tall line and assuming someone reading this, i.e. an implementer (e.g. YOU), will know what an API is. Or would you rather require even the definitions of words like framework, authentication, email, public key, verification, source, messages and transfer, all of which appear in the first sentence of the abstract of RFC4871, be included? Let's not be absurd here. ___ 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] Modified Introduction text forrfc4871-errata (resend)
Murray S. Kucherawy wrote: All the errata is saying is that all DKIM APIs must return, at a minimum, the d= and the evaluation result. There are no other limits imposed. The concern I have is that an SMTP vendor may erroneous model his Assessor hook by recording two data points on the design presumption the assessor functional signature is: bool dkim_accessor(bool dkim_result, string d_tag_value); When new assessors emerge, the potential is very high a different signature is required thus the new accessor will not be compatible with SMTP servers that do this. For example, using our system, when we first produced our WCSAP product back in 2003 which evaluates the SMTP envelope using SPF and DNSRBL originally, the API prototype was fixed: BOOL Call_WCSAP( IP, // client connecting ip address CDN, // client domain name (HELO/EHLO) RP) // Return Path, (MAIL FROM) The Assessors here were locked for SPF and DNSRBL lookups and it return a TRUE and FALSE result. TRUE continue with DATA, FALSE, a 550 reply code was issued. The functionality was locked based on existing well known standard technologies at the time. That is what I see here. What happen is that over time, it evolved where we needed to pass more SMTP session and server information when a new assessor scripting rules were added: IP // client connecting ip address CDN// client domain name (HELO/EHLO) RP // Return Path, (MAIL FROM) FP_LIST// Forwarding Path (RCPT TO) SRV// Server Host domain SRVIP // Server Host IP AUTHID // ID of AUTHenticated user and the return status was no long TRUE or FALSE but a 64 bit double word: HIWORD - ACCEPT, REJECT, REJECT_BUT_KEEP LOWORD - REPLY_CODE After this change, its been stable and there was no need to change in 3-4 years. So in my view, the SMTP system can potentially design the DKIM assessor two fields signature hook and lock himself in. Now only specific assessors are compatible with it. Since we don't have any real experience of what assessors will need, I believe we can preempt the potential problem for SMTP servers and Assessor Developers by suggesting all information SHOULD be made available, and therefore Assessor Developers will have a persistent and consistent protocol to work with all DKIM compliant SMTP systems. You're not the only developer on this list with decades of professional experience in multiple environments, Hector. Let's leave the resumes off the list, please. We're here to co-operate, not compete. Of course, there was no suggestion otherwise, but it shows there are multiple valid viewpoints and I believe in general the RFC should minimize implementation API discussions here, especially the socket paragraph (get rid of it). I think it is not correct as stated and could cause problems. I just don't think its necessary. The fact you did state they can add more information, it should not be a subjective thing. We are talking about the Assessor Interface, it should be a fixed consistent interface that all Assessor developers can depend on. Anyway, I think this thread has run its course. :-) -- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
On Jun 17, 2009, at 2:24 PM, Murray S. Kucherawy wrote: You have generalize ASSESSORS to have two minimum inputs: BOOLEAN (DKIM verification result) STRING (DKIM D= value) Correct. 1) Why? There is use in specifying an API here. Every other protocol we've named so far as examples have an API, whether de facto from lots of experience, or implicit from the spec that defines it the protocol, or something actually explicit defining the API. There's no evidence that this is a bad idea. This has already been defined by RFC 4871 as the i= value, and when that is not available, this defaults to @d= value. The i= information is intended to provide guidance for annotating messages, whereas the d= value simply indicates where the key is published. A modification to RFC 4871 that has the i= parameter routinely excluded from assessment then fails to offer the intended guidance AND fails to fully consider the source of the message. The described use of your API even suggests that by offering i= value guidance, that the related message might become discarded. There is ample evidence that discarding accepted email is deleterious, and in general, a bad idea. The fact that users will not see discarded messages does not make this any better. Some of the loudest complaints stem from missing messages. 2) How does a DKIM implementation generalize the fixed prototype to satisfy newer ASSESSOR that require different input? You are going to need some protocol that defines the input requirements for the specific and different assessor. Yep, and nothing that's been said so far precludes this idea. Defining a minimum does not also automatically define a maximum or establish other constraints. Yes it does curtail the alternative. By limiting assessments to just the d= value, and then suggesting that the i= values can be used for subsequent discard, creates a significant impediment to even offering the intended information. In addition, by not assessing the intended on-behalf-of identifier, the i= value may overlook deceptive sources that might have been replayed and impractical to recall. A service that offers an assessment of the i= value will ensure the information used to annotate a message is not from known deceptive or abusive sources. If the service wishes to ignore a portion of the the i= value, it can. But ignoring a portion of the i= value has a potential for creating inter-operability issues. The imaginary inter-operability issue becomes real with this change. :^( -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
Suresh Ramasubramanian wrote: tFor signers and verifiers that have been using the i= tag as the primary value that is delivered to the assessor, a software change to using the d= tag is intended. /t s/intended/required/ possibly? while you are right, practically speaking, that sounds normative, and this text needs to avoid any hint of trying to be normative. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
