[ietf-dkim] Final Montreal minutes...
Folks, The attached are the final minutes from Montreal for the record. There're only trivial changes from the earlier draft minutes. Cheers, S. Title: IETF-66 FINAL DKIM Meeting Notes IETF-66 FINAL DKIM Meeting Notes (-01) Charter: http://www.ietf.org/html.charters/dkim-charter.html Chairs: Barry Leiba, Stephen Farrell We met twice. Thanks to the jabber scribes! Tuesday: 67 attendees, jabber: Jim Fenton, http://www.ietf.org/meetings/ietf-logs/dkim/2006-07-11.html Wednesday: 63 attendees, jabber: Pete Resnick, http://www.ietf.org/meetings/ietf-logs/dkim/2006-07-12.html Audio logs: http://videolab.uoregon.edu/events/ietf/ Agenda, slides etc: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 search/scroll down to "DKIM" Minutes: Stephen Farrell Highlights The WG chairs had asked for help from the DNS directorate about whether or not DKIM needs to define a new RR or is ok to use the current approach of a TXT record for the public key. The feedback is that although there's some unhappiness with the TXT approach, in this case it appears to work. So the WG approach for base will be to include the TXT record definition and not to define a new RR for public keys. (More detail below.) The base spec is in WGLC, ending on Friday 21st July. Almost all issues are closed or should hopefully be closed in a -04 draft to be posted this week. The main issue remaining is whether or not the "relaxed" body canonicalization should remain in the base document or not, where we don't yet have clear consensus. We plan to try determine that on the list. We started discussion of SSP which is intended to allow signers to announce their DKIM related practices. A couple of drafts exist that outline proposals. Discussion here is just at the very start and there were some requests that we try to establish concrete requirements before going futher. We now have a draft of the DKIM overview document (intended to be informational) which is also up for discussion. Tuesday Eric Allman - base issues Eric went through all of the issues with the base spec from the tracker. base spec: http://www.ietf.org/internet-drafts/draft-ietf-dkim-base-03.txt tracker: 1287: Leave as is, CLOSED 1288: CLOSED 1289: CLOSED 1293: Doug - its about downgrade attacks. Decided already. CLOSED 1294: CLOSED 1308: Doug - DNS security considerations needed. Paul Hoffmann, DKIM is the same as anyone else. Peter Koch, don't use DNS to deduce organisational relationship from DNS structure. Paul thinks he and Peter agree in fact. Jim Fenton we should add language RECOMENDING use of "t=s" to make such problems less likely. PHB volunteers to write text. Bellovin on the DNS directorate issue: question about TXT vs other RR for _domainkey. Spent 45 minutes at DNS directorate. Steve not chair, but consensus. Quoting: "The DNS directorate is unhappy with using TXT records this way. Some of the reasoning is spelled out in draft-iab-dns-choices-03.txt. At the least, a registry of _ names is needed, with provision for subtyping, but subtyping RRs has long been known to be bad . In general, TXT overloading can be likened to using HTTP as the universal transport protocol; see RFC 3205 for why that's a bad idea. A more specific problem for this situation is the issue of wildcards. Briefly, you can't have a wildcard _domainkeys record; given that email is the major place where wildcards are used, this is a serious issue." DNSSEC signing records at least may be found below _domainkeys and other RRs deliberately or by accident. Olafur: If doc says "do not use wildcards" that'd be good. Proposes an experiment to acquire a new type if the WG want to try that (a fast process apparently). Doug - eai may expand record as well as longer keys. Suggests that alternative to TXT might be good for that. Crocker: Question to Bellovin: Would DNS directorate assert a DISCUSS. Bellovin: No-one said DISCUSS, but unhappiness. On the plus side, its a special record and we don't have to contend with other TXT records. Way forward: WG will only specify a TXT for keys for now. Back to issues: 1316: multiple issues in one. a couple of minor things before we can close this. #1 multibyte. EAI etc. Can't predict every future protocol. Doug - UTF8 would affect g= in key - we could b64 that in the key record. Eric: No problem so long as they stick with UTF8. Tony Hansen: does base- define plain text. Eric: it will (ACTION) #2, == 1323 #3, max length. none. #4 == #1 #5 answered (no) #6 nope & ok #7 looking for reference #8 fixed, API stuff on list #9 == #1 #10 yes #11 answer=unchanged #12 relaxed -> New01 #13 l=0;bh= done on list #14, new text from Jim #15, no #16, done #17, new wording fine, Dave Crocker: what about additional services. Delete substantially? Dave C offered words to put in jabber. #18 = 1325 #19, done #20 = 1322 #21 done #22, Eric ACTION to add a
[ietf-dkim] Clarification: Requirement #8
8. The Protocol is not required to publish a Practice of any/all unreleated third parties that MUST NOT sign on the domain holder's behalf. [INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository.] Spelling issue: unreleated = unrelated also This might be a semantics issue but, does this mean that, while it is not required, it is still an option to be able to publish who MUST NOT sign? And if it _is_ still an option, does this mean that the unrelated parties sig should be ignored or is it suggested that it be treated with prejudice? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarification: Requirement #8
Damon wrote: 8. The Protocol is not required to publish a Practice of any/all unreleated third parties that MUST NOT sign on the domain holder's behalf. [INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository.] Spelling issue: unreleated = unrelated also This might be a semantics issue but, does this mean that, while it is not required, it is still an option to be able to publish who MUST NOT sign? As I read it, it says that the (SSP) protocol MUST NOT have that feature. Some other protocol might. Personally I think this is right since I can't think of any reason why the presence of a signature would in itself be a negative. I guess that 5.3, req #9 also more-or-less says this. I (and others, I expect) would argue strongly that it would be wrong to do otherwise. We had a related discussion about whether mail is required to be routed directly or not, but that should IMO be separate from this and doesn't currently seem to be in the document, which again I think is probably correct, though others may differ. Stephen. PS: The above is with chair hat off, of course. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Issue: 5.3, req#2 additional note...
As I read the document, if I indicate a "DKIM signing complete"
policy, but never actually send any (signed or unsigned) mail,
then I have achieved the goal set out in requirement #2 from
section 5.3 ("doesn't send mail").
Now I don't object to the requirement itself, but would like
to suggest adding a note something like:
"INFORMATIVE NOTE: The Protocol could achieve this by
publishing a "DKIM signing complete" practice. If such
a practice is published, but no (legitimate) mail is
ever sent, then the resulting system meets this
requirement."
The reasons being that:-
a) I remain worried that since this practice is nothing to
do with signing, there is a real possibility that we may
overlap with some other technology (e.g. SPF or whatever
else) with potentially bad results,
b) I think that having as few policy-knobs as possible is
best (based on experience with X.509 where there are too
many IMO) and this seems like a case where we can usefully
fold two requirements into one such policy-knob, and,
c) I'm fine with the WG deciding later on whether to use
one or two bits for these practices so I don't see a need to
strike the requirement itself (which I agree is a real
requirement, expressed in the way users/operators might
find easiest).
Cheers,
Stephen.
PS: Chair hat is still off - its on the chair beside me:-)
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarification: Requirement #8
On 8/9/06, Stephen Farrell <[EMAIL PROTECTED]> wrote: Damon wrote: > 8. The Protocol is not required to publish a Practice of any/all >unreleated third parties that MUST NOT sign on the domain >holder's behalf. > > [INFORMATIVE NOTE: this is essentially saying that the > protocol doesn't have to concern itself with being a > blacklist repository.] > > Spelling issue: unreleated = unrelated > > also > > This might be a semantics issue but, does this mean that, while it is > not required, it is still an option to be able to publish who MUST NOT > sign? As I read it, it says that the (SSP) protocol MUST NOT have that feature. Some other protocol might. Personally I think this is right since I can't think of any reason why the presence of a signature would in itself be a negative. I guess that 5.3, req #9 also more-or-less says this. I (and others, I expect) would argue strongly that it would be wrong to do otherwise. We had a related discussion about whether mail is required to be routed directly or not, but that should IMO be separate from this and doesn't currently seem to be in the document, which again I think is probably correct, though others may differ. Stephen. PS: The above is with chair hat off, of course. I am thinking that the purpose of the original discussion was to keep the OA's reputation from being tarnished by the subsequent signers. Like it or not, the sig is likely going to be tied to reputation somehow anyway. Are there any thoughts on how to avoid this? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarification: Requirement #8
- Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Damon" <[EMAIL PROTECTED]> Cc: "DKIM List" Sent: Wednesday, August 09, 2006 11:38 AM Subject: Re: [ietf-dkim] Clarification: Requirement #8 > Damon wrote: > > 8. The Protocol is not required to publish a Practice of any/all > >unreleated third parties that MUST NOT sign on the domain > >holder's behalf. > > > > [INFORMATIVE NOTE: this is essentially saying that the > > protocol doesn't have to concern itself with being a > > blacklist repository.] > > > > Spelling issue: unreleated = unrelated > > > > also > > > > This might be a semantics issue but, does this mean that, while it is > > not required, it is still an option to be able to publish who MUST NOT > > sign? > > As I read it, it says that the (SSP) protocol MUST NOT have that > feature. Some other protocol might. Small nit. "The protocol is not required" to me, means it is optional. The informative note seems to connotate this "doesn't have to concern itself" which mean I could if I wanted to. Correct? Maybe changing to: "The protocols does not need.." or just remove #8 altogether. Don't need to mention it, -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Requirements comment: Bigbank example description
I went through the draft and marked it up. I'll break these up into individual messages for each comment. I'll start with a context diff of the draft and proposed changes and then give a discussion of why... *** 321,328 unsigned outweights the risk of illegitimate mail being delivered in the eyes of the sender. !1. A purportedly sends to B with a missing or broken DKIM signature !from A 2. B would like to know whether that is an acceptable state of affairs. --- 321,328 unsigned outweights the risk of illegitimate mail being delivered in the eyes of the sender. !1. Mail with a RFC2822.From A is sent to B with a missing or broken !DKIM signature 2. B would like to know whether that is an acceptable state of affairs. *** I think that saying mail with an RFC2822.From A is clearer than A purportedly sends. Also, Purported is used in Sender ID PRA (Purported Responsible Address) and so use of that word in this context might be confusing for some. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Requirements clarification/addition: DKIM Signing Complete should include designated third parties
*** 350,356 previous scenario. A receiver, on the other hand, may be able to take advantage of the knowledge the domain's practice of signing all mail in order to use it to bias filters against the unexpected !arrival of a piece of unsigned or damaged in transit mail. 4.3. Scenario 3: Outsourced First Party Signing --- 350,357 previous scenario. A receiver, on the other hand, may be able to take advantage of the knowledge the domain's practice of signing all mail in order to use it to bias filters against the unexpected !arrival of a piece of unsigned, damaged in transit mail, or mail !signed by an entity not described in the RFC2822.From sender policy. 4.3. Scenario 3: Outsourced First Party Signing *** If we are going to include a list of designated signing third parties, the lack of a signature from one of those parties is an equally useful input into bias filters. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Clarification: Section 5.4.6
6. Practices and Expectations MUST be presented as an information service from the sender to be consumed as an added factor to the receiver's local policy. In particular a Practice or Expectation MUST NOT specify any particular disposition stance that the receiver should follow. Should the last sentence say: "Expectation MUST NOT specify any particular disposition stance that the receiver MUST follow."? In my opinion, if the Expectation is set, it is stating a suggested usage. Or in other words, what the receiver should follow. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Requirement clarification: NS delegation
*** *** 368,374 That said, DKIM uses DNS to store selectors. Thus there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to a third party of the domain holder's !choosing. That is, the domain holder can always set a NS record for _domainkey.example.com to, say, an email provider who manages that namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain how --- 369,375 That said, DKIM uses DNS to store selectors. Thus there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to a third party of the domain holder's !choosing. That is, the domain holder may be able to set a NS record for _domainkey.example.com to, say, an email provider who manages that namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain how *** *** 377,382 --- 378,387 the third party to only be able to sign messages on behalf of the benefits subdomain. +[INFORMATIVE NOTE: Not all DNS providers support separate +NS records for subdomains, so this approach is not universally +available.] + There have been concerns expressed about how well this would scale when the third party is, say, a large ISP that signs for thousands of domains. There has been concern about how well this would work for *** Since this scenario is aimed primarily at small non-technical domain owners (who would be the most likely to outsource DNS services also) I think it is important to point out that not all DNS providers support subdomain NS delegation (personally, I mostly use two providers - one supports it, the other doesn't). It is another reason why NS delegation is not a complete solution. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Requirements clarification: DNS Exchange determinism
*** *** 465,471 1. Discovery mechanism MUST be rooted in DNS. !2. Discovery mechanism MUST converge in a deterministic number of exchanges. [Informative Note: this, for all intents and purposes is a --- 470,476 1. Discovery mechanism MUST be rooted in DNS. !2. Discovery mechanism MUST converge in a deterministic maximum number of exchanges. [Informative Note: this, for all intents and purposes is a *** The point is to have a reliable maximum. As written the requirement would seem to require a standard number of exchanges, not just a maximum. We shouldn't prohibit efficiencies if we can find them. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Requirements clarification: Standard for resource record name space collision
*** *** 474,480 expectation is "few".] 3. Discovery mechanism MUST NOT overload semantics of existing DNS !resource records where name space collisions are possible. 5.2. Transport requirements --- 479,485 expectation is "few".] 3. Discovery mechanism MUST NOT overload semantics of existing DNS !resource records where name space collisions are reasonably likely. 5.2. Transport requirements *** Making name space collision impossible (the written requirement) is a high bar. Higher than was used for DKIM base. Reasonably likely seems like a better standard. Impossible would seem to require a new RR. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Requirements clarification: Specification of domain holder
*** 508,514 5.3. Practice and Expectation Requirements In this section, a Practice is defined as a true statement according !to the domain holder of its intended externally viewable behavior. An Expectation combines with a Practice to convey what the domain holder considers the likely outcome of the survivability of the Practice at a receiver. For example, a Practice that X is true when --- 513,519 5.3. Practice and Expectation Requirements In this section, a Practice is defined as a true statement according !to the RFC2822.From domain holder of its intended externally viewable behavior. An Expectation combines with a Practice to convey what the domain holder considers the likely outcome of the survivability of the Practice at a receiver. For example, a Practice that X is true when *** The proposed wording is less subject to misinterpretation. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Requirements addition: Policy/Practice record for first party signatures
*** *** 537,549 for signing its messages to a non-related domain in such a way that it does not require active participation by the non-related domain. That is, the published information MUST have a way to ! specify the domains that are allowed to sign on its behalf. 6. Practices and Expectations MUST be presented as an information service from the sender to be consumed as an added factor to the receiver's local policy. In particular a Practice or ! Expectation MUST NOT specify any particular disposition stance ! that the receiver should follow. 7. If the Discovery process would be shortened by publication of a "null" practice, the protocol SHOULD provide a mechanism to --- 542,556 for signing its messages to a non-related domain in such a way that it does not require active participation by the non-related domain. That is, the published information MUST have a way to ! specify the domains that are allowed to sign on its behalf. ! Signatures by such delagatees SHOULD be treated like First Party ! DKIM signatures. 6. Practices and Expectations MUST be presented as an information service from the sender to be consumed as an added factor to the receiver's local policy. In particular a Practice or ! Expectation MUST NOT require any particular disposition stance ! that the receiver MUST follow. 7. If the Discovery process would be shortened by publication of a "null" practice, the protocol SHOULD provide a mechanism to *** This addition is suggested for a couple of reasons... 1. Completeness. I think there is some value in providing a reasonably complete list of Practices. There will likely be effective uses for policy information by receivers that we haven't thought of yet. An incomplete set of practices may hamstring this kind of innovation. 2. RFC 2821 discovery - This is the requirement change a alluded to yesterday in the signalling DKIM support before DATA thread. I won't rehash that here. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Please disregard - Requirements addition: Policy/Practice record for first party signatures
The message I just sent with this subject was in error. I'll send it again, correctly, in a few minutes. Sorry, Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] requirements clarifications: Listed third parties treated like first party and must not require/specify
*** 537,549 for signing its messages to a non-related domain in such a way that it does not require active participation by the non-related domain. That is, the published information MUST have a way to ! specify the domains that are allowed to sign on its behalf. 6. Practices and Expectations MUST be presented as an information service from the sender to be consumed as an added factor to the receiver's local policy. In particular a Practice or ! Expectation MUST NOT specify any particular disposition stance ! that the receiver should follow. 7. If the Discovery process would be shortened by publication of a "null" practice, the protocol SHOULD provide a mechanism to --- 542,556 for signing its messages to a non-related domain in such a way that it does not require active participation by the non-related domain. That is, the published information MUST have a way to ! specify the domains that are allowed to sign on its behalf. ! Signatures by such delagatees SHOULD be treated like First Party ! DKIM signatures. 6. Practices and Expectations MUST be presented as an information service from the sender to be consumed as an added factor to the receiver's local policy. In particular a Practice or ! Expectation MUST NOT require any particular disposition stance ! that the receiver MUST follow. 7. If the Discovery process would be shortened by publication of a "null" practice, the protocol SHOULD provide a mechanism to *** If we are going to have a list of designate third parties, they should be treated like first party (that's the point of the list). I'd make it a MUST, except that would be specifying receiver policy. Additionally, while I agree that receiver policy should not be required by the protocol, I think that not specifying a desired receiver policy goes to far. I'd suggest that we MUST NOT require instead of MUST NOT specify. That achieves the goal of not having receiver policy cause protocol failures, but allows more freedom in design to communicate sender expectations. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-requirements-00.txt available
I've finished my first cut at comments and I'd like to add my thanks to Mike for putting together such a good draft in such a short amount of time. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Corrected copy - Requirements addition: Policy/Practice record for first party signatures
*** 574,580 blacklist repository.] 9. The Protocol MUST NOT be required to be invoked if a valid first ! party signatures is found. 10. [PROVISIONAL] A domain holder MUST be able to publish a Practice which enumerates the acceptable cryptographic algorithms for --- 581,594 blacklist repository.] 9. The Protocol MUST NOT be required to be invoked if a valid first ! party signatures is found, [PROVISIIONAL] but the Protocol SHOULD ! support publishing Practices for First Party DKIM signatures. ! ![INFORMATIVE NOTE: the provisional requirement to support First !Party Practices is intended as an aid to the receiver. While !SSP lookups aren't required for First Party DKIM signatures, !there may be utility to receivers to determine Practices !associated with First Party DKIM signatures.] 10. [PROVISIONAL] A domain holder MUST be able to publish a Practice which enumerates the acceptable cryptographic algorithms for *** This addition is suggested for a couple of reasons... 1. Completeness. I think there is some value in providing a reasonably complete list of Practices. There will likely be effective uses for policy information by receivers that we haven't thought of yet. An incomplete set of practices may hamstring this kind of innovation. 2. RFC 2821 discovery - This is the requirement change a alluded to yesterday in the signalling DKIM support before DATA thread. I won't rehash that here. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements addition: Policy/Practice record for first party signatures
--- 542,556 for signing its messages to a non-related domain in such a way that it does not require active participation by the non-related domain. That is, the published information MUST have a way to ! specify the domains that are allowed to sign on its behalf. ! Signatures by such delagatees SHOULD be treated like First Party ! DKIM signatures. --- 542,556 for signing its messages to a non-related domain in such a way that it does not require active participation by the non-related domain. That is, the published information MUST have a way to ! specify the domains that are allowed to sign on its behalf. ! Signatures by such delagatees SHOULD be treated like First Party ! DKIM signatures. I am thinking that the SHOULD might be a MUST. ! specify the domains that are allowed to sign on its behalf. ! Signatures by such delagatees MUST be treated like First Party ! DKIM signatures. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements addition: Policy/Practice record for first party signatures
On Wednesday 09 August 2006 13:26, Damon wrote: > > --- 542,556 > > for signing its messages to a non-related domain in such a way > > that it does not require active participation by the non-related > > domain. That is, the published information MUST have a way to > > ! specify the domains that are allowed to sign on its behalf. > > ! Signatures by such delagatees SHOULD be treated like First > > Party ! DKIM signatures. > > > > --- 542,556 > > for signing its messages to a non-related domain in such a way > > that it does not require active participation by the non-related > > domain. That is, the published information MUST have a way to > > ! specify the domains that are allowed to sign on its behalf. > > ! Signatures by such delagatees SHOULD be treated like First > > Party ! DKIM signatures. > > I am thinking that the SHOULD might be a MUST. > > > ! specify the domains that are allowed to sign on its behalf. > > ! Signatures by such delagatees MUST be treated like First Party > > ! DKIM signatures. > Conceptually I agree. If there is one place in the requirements where there should be a MUST for receiver policy, this is it. However, there seems to be a reasonable consensus for not specifying receiver policy. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] issue: requirement #10 Publishing Hashing (cryptographic algorithms) methods...
On Aug 8, 2006, at 6:36 PM, Hector Santos wrote: | 10. [PROVISIONAL] A domain holder MUST be able to publish a Practice | which enumerates the acceptable cryptographic algorithms for | signatures purportedly from that domain. | | [INFORMATIVE NOTE: this is to counter a bid down attack; some | comments indicated that this need only be done if the | algorithm was considered suspect by the receiver; I'm not | sure that I've captured that nuance correctly] My input: This is a implementation and "Product Feature" concept. Having this available will offer implementations the ability for DKIM domains to predetermine the failure or survivability of a message being send to a target. It also allows for any need for a domain to explore and offer new more secure hashing methods. SMTP is not an end-to-end protocol. The store-and-forward feature of SMTP means _any_ email-address may not be the final destination for a message. Mechanisms generally needed for compatibility MUST NOT be excluded in response to a verifier's policy assertion of supported mechanisms. The exclusion of these mechanisms by the signing domain may result in messages being lost or rejected at subsequent domains. This may create a exploitable conflict for generating bounces, or may cause important messages, where added security matters, to be lost or rejected. I personally see this as a "highly desirable" feature that would add a few stars to a software package. I also see this as something very desirable in a social, vendor or business network. The final destination of a message must be considered unknown. A practical method for preventing a bid down attack that is compatible with SMTP would be for the signer (not the verifier) to assert the deprecated mechanism. This signer information can be combined with either the deprecated key or other signer related policy assertions. A message could then safely offer both deprecated and non-deprecated signatures, where the deprecated mechanism can be avoided once the final verifier supports the non-deprecated mechanism. Where this might matter would likely be for a signer that represents a financial enterprise issuing transactional messages. The criticality of the required protection will be known by this signer long before most verifiers have upgraded. By the signer indicating what is deprecated, adopters of a new mechanism obtain protection during what is likely a fairly prolonged period. A moderate percentage of lost or rejected messages will prevent a deprecated mechanism from not being offered. The WG however has decided that avoiding a bid-down attack does not represent a problem that the WG needs to currently consider. A mode of operation for excluding a deprecated mechanism has not been defined by the DKIM-base. Until such time when the WG decides that a mechanism is needed to avoid a bid-down attack, inclusion of information related to this problem should be excluded from a policy assertion. In addition to be a scheme for avoiding a bid down attack, assertions of acceptable mechanisms by the verifier are not consistent with the general architecture of SMTP. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements clarification/addition: DKIM Signing Complete should include designated third parties
--- 350,357 previous scenario. A receiver, on the other hand, may be able to take advantage of the knowledge the domain's practice of signing all mail in order to use it to bias filters against the unexpected !arrival of a piece of unsigned, damaged in transit mail, or mail !signed by an entity not described in the RFC2822.From sender policy. (Scott's ideas incorporated too) !! arrival of a piece of unsigned, damaged in transit mail, or if a RFC2822.From sender policy exists which specifies authoritative domain(s), a mail signed by an entity other than described in the sender policy. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarification: Section 5.4.6
Damon wrote: 6. Practices and Expectations MUST be presented as an information service from the sender to be consumed as an added factor to the receiver's local policy. In particular a Practice or Expectation MUST NOT specify any particular disposition stance that the receiver should follow. Should the last sentence say: "Expectation MUST NOT specify any particular disposition stance that the receiver MUST follow."? In my opinion, if the Expectation is set, it is stating a suggested usage. Or in other words, what the receiver should follow. I think that this is a question of whether the "should" (or "MUST" in yours) is actually normative. I don't think it is. It might read better as: "In particular, a Practice or Expectation MUST NOT mandate any disposition stance on the receiver." Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirement clarification: NS delegation
Change 1: done. Change 2: folded into the next paragraph which has other concerns about the NS approach. Mike Scott Kitterman wrote: *** *** 368,374 That said, DKIM uses DNS to store selectors. Thus there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to a third party of the domain holder's !choosing. That is, the domain holder can always set a NS record for _domainkey.example.com to, say, an email provider who manages that namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain how --- 369,375 That said, DKIM uses DNS to store selectors. Thus there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to a third party of the domain holder's !choosing. That is, the domain holder may be able to set a NS record for _domainkey.example.com to, say, an email provider who manages that namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain how *** *** 377,382 --- 378,387 the third party to only be able to sign messages on behalf of the benefits subdomain. +[INFORMATIVE NOTE: Not all DNS providers support separate +NS records for subdomains, so this approach is not universally +available.] + There have been concerns expressed about how well this would scale when the third party is, say, a large ISP that signs for thousands of domains. There has been concern about how well this would work for *** Since this scenario is aimed primarily at small non-technical domain owners (who would be the most likely to outsource DNS services also) I think it is important to point out that not all DNS providers support subdomain NS delegation (personally, I mostly use two providers - one supports it, the other doesn't). It is another reason why NS delegation is not a complete solution. Scott K ___ 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] Requirements clarification: Specification of domain holder
Done. Scott Kitterman wrote: *** 508,514 5.3. Practice and Expectation Requirements In this section, a Practice is defined as a true statement according !to the domain holder of its intended externally viewable behavior. An Expectation combines with a Practice to convey what the domain holder considers the likely outcome of the survivability of the Practice at a receiver. For example, a Practice that X is true when --- 513,519 5.3. Practice and Expectation Requirements In this section, a Practice is defined as a true statement according !to the RFC2822.From domain holder of its intended externally viewable behavior. An Expectation combines with a Practice to convey what the domain holder considers the likely outcome of the survivability of the Practice at a receiver. For example, a Practice that X is true when *** The proposed wording is less subject to misinterpretation. Scott K ___ 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] Requirements clarification: Standard for resource record name space collision
At 1:02 PM -0400 8/9/06, Scott Kitterman wrote: *** *** 474,480 expectation is "few".] 3. Discovery mechanism MUST NOT overload semantics of existing DNS !resource records where name space collisions are possible. 5.2. Transport requirements --- 479,485 expectation is "few".] 3. Discovery mechanism MUST NOT overload semantics of existing DNS !resource records where name space collisions are reasonably likely. 5.2. Transport requirements *** Making name space collision impossible (the written requirement) is a high bar. Higher than was used for DKIM base. Reasonably likely seems like a better standard. Impossible would seem to require a new RR. Actually, that's not true. For -base, there was no chance that a host name (as compared to a domain name) would collide with a name that had the chosen label. I think saying "impossible" is reasonable if you clarify the difference. It would be really nice not to revisit the wars that erupted when the IDN WG picked a label prefix. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarification: Section 5.4.6
Following myself up with a clarification: Michael Thomas wrote: "In particular, a Practice or Expectation MUST NOT mandate any disposition stance on the receiver." The reason that I've written it in this way was purposeful on my part: the sender's expectation is that there should be a valid signature. I don't really think we need to go further than that because if a receiver knows that the sender expects a message to arrive with a valid signature, that's really all it needs to know that there's something seriously amiss. What it actually does when something is amiss it's its business, and I really don't think we need to give helpful hints as it's not really rocket science at that point, and we really don't want to prejudice any particular action. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements comment: Bigbank example description
Scott Kitterman wrote: > I went through the draft and marked it up. I'll break these up into > individual messages for each comment. I'll start with a context diff of the > draft and proposed changes and then give a discussion of why... > > *** 321,328 > unsigned outweights the risk of illegitimate mail being delivered in > the eyes of the sender. > > !1. A purportedly sends to B with a missing or broken DKIM signature > !from A > > 2. B would like to know whether that is an acceptable state of > affairs. > --- 321,328 > unsigned outweights the risk of illegitimate mail being delivered in > the eyes of the sender. > > !1. Mail with a RFC2822.From A is sent to B with a missing or broken > !DKIM signature > > 2. B would like to know whether that is an acceptable state of > affairs. > *** > > I think that saying mail with an RFC2822.From A is clearer than A purportedly > sends. Also, Purported is used in Sender ID PRA (Purported Responsible > Address) and so use of that word in this context might be confusing for some. -1 I want companies such as eCard senders or News Agencies to be able to 1) send a message on my behalf while 2) marking themselves as the sender and 3) being able to sign the message. This minimally requires support for RFC2822.Sender as well as RFC2822.From. I *would* support changing it to 1. Mail with a RFC2822.From or RFC2822.Sender A is sent to B with a missing or broken DKIM signature This has nothing to do with PRA and its support for Resent-From and/or Resent-Sender. Tony Hansen [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements clarification/addition: DKIM Signing Complete should include designated third parties
Damon wrote: >> --- 350,357 >> previous scenario. A receiver, on the other hand, may be able to >> take advantage of the knowledge the domain's practice of signing all >> mail in order to use it to bias filters against the unexpected >> !arrival of a piece of unsigned, damaged in transit mail, or mail >> !signed by an entity not described in the RFC2822.From sender policy. >> > > (Scott's ideas incorporated too) > > !! arrival of a piece of unsigned, damaged in transit mail, or if > a RFC2822.From sender policy exists which specifies authoritative > domain(s), a mail signed by an entity other than described in the sender > policy. add RFC2822.Sender Tony Hansen [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements clarification: Specification of domain holder
Scott Kitterman wrote: > *** 508,514 > 5.3. Practice and Expectation Requirements > > In this section, a Practice is defined as a true statement according > !to the domain holder of its intended externally viewable behavior. > An Expectation combines with a Practice to convey what the domain > holder considers the likely outcome of the survivability of the > Practice at a receiver. For example, a Practice that X is true when > --- 513,519 > 5.3. Practice and Expectation Requirements > > In this section, a Practice is defined as a true statement according > !to the RFC2822.From domain holder of its intended externally viewable > behavior. > An Expectation combines with a Practice to convey what the domain > holder considers the likely outcome of the survivability of the > Practice at a receiver. For example, a Practice that X is true when > *** > > The proposed wording is less subject to misinterpretation. Add RFC2822.Sender. Tony Hansen [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] issue: requirement #10 Publishing Hashing (cryptographic algorithms) methods...
- Original Message - From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]> > SMTP is not an end-to-end protocol. The store-and-forward > feature of SMTP means _any_ email-address may not be the > final destination for a message. As far as the initial author concern it is. You are referring to a relay forwarding of an email address to another address. But to get to this node, the initial path did reach its destination. The author had no clue that a forwarding of the address would be taken place. Same wave length? If so, a DKIM verify domain who would be receiving an email targeted for its MDA would verify the message, and need be, then forward it hopefully to another DKIM ready domain. > This may create a exploitable conflict for generating bounces, or may > cause important messages, where added security matters, to be lost or > rejected. For this particular item, how so? An example of an exploit would be nice. > > I personally see this as a "highly desirable" feature that would > > add a few stars to a software package. I also see this as > > something very desirable in a social, vendor or business network. > > The final destination of a message must be considered unknown. See above. I am not sure Doug if you were describing a new solution or explaining why it won't work. I just need to see why it won't work. --- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarification: Section 5.4.6
I was thinking about this and wasn't sure if it was worth bringing up. I mean, in DSAP we have failure-handling statements, but I can go either way. But let me throw out the idea of the domain wishing to express a disclaimer that is something failures, it is HIGHLY desirable that you not retain this message. I provided an example in DSAP: _dsap._domainkey.bank.example. IN TXT "v=dsap1.0; a=rsa-sha256; op=always; 3p=never; n=We only send DKIM signed email, do not trust anything else such as notices allegedly from [EMAIL PROTECTED] Please report all such abuse to; [EMAIL PROTECTED];" Where using the N= note tag, the domain making an disclaimer statement to the verifier not to trust the message. So maybe just adding a new requirement? Protocol MUST allow for a informational text note for the policy. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com - Original Message - From: "Michael Thomas" <[EMAIL PROTECTED]> To: "Michael Thomas" <[EMAIL PROTECTED]> Cc: "DKIM List" Sent: Wednesday, August 09, 2006 2:33 PM Subject: Re: [ietf-dkim] Clarification: Section 5.4.6 > Following myself up with a clarification: > > Michael Thomas wrote: > > > "In particular, a Practice or Expectation MUST NOT mandate any > >disposition stance on the receiver." > > The reason that I've written it in this way was purposeful on my part: the > sender's expectation is that there should be a valid signature. I don't > really > think we need to go further than that because if a receiver knows that the > sender expects a message to arrive with a valid signature, that's really > all > it needs to know that there's something seriously amiss. What it actually > does when something is amiss it's its business, and I really don't think we > need to give helpful hints as it's not really rocket science at that > point, > and we really don't want to prejudice any particular action. > >Mike > ___ > 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
[ietf-dkim] RFC2822.Sender
Tony Hansen wrote: Damon wrote: --- 350,357 previous scenario. A receiver, on the other hand, may be able to take advantage of the knowledge the domain's practice of signing all mail in order to use it to bias filters against the unexpected !arrival of a piece of unsigned, damaged in transit mail, or mail !signed by an entity not described in the RFC2822.From sender policy. (Scott's ideas incorporated too) !! arrival of a piece of unsigned, damaged in transit mail, or if a RFC2822.From sender policy exists which specifies authoritative domain(s), a mail signed by an entity other than described in the sender policy. add RFC2822.Sender I'm not the chair, but I've seen considerably less consensus about anything other than rfc2822.from. I'm frankly not sure I understand it very well. There's of course nothing that prevents a receiver from checking SSP for any address/domain it wants to, but do we now have a mandate to make assertions about any kind of origination address? How do those assertions interact with each other? What does a strong practice for ListID and a weak practice for Sender mean if they're in the same message? Finally, is this something that can wait? Ie, are we harmed if we don't do it now? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] 2822.From or 2822.Sender and 2822.From was:Requirements comment: Bigbank example description
On Wednesday 09 August 2006 14:34, Tony Hansen wrote: > -1 > > I want companies such as eCard senders or News Agencies to be able to 1) > send a message on my behalf while 2) marking themselves as the sender > and 3) being able to sign the message. This minimally requires support > for RFC2822.Sender as well as RFC2822.From. > > I *would* support changing it to > > 1. Mail with a RFC2822.From or RFC2822.Sender A is sent to B with a > missing or broken DKIM signature > > This has nothing to do with PRA and its support for Resent-From and/or > Resent-Sender. > Agree it has nothing to do with PRA, that's why I say don't use the word purported. Since many popular MUAs do not display Sender, including Sender defeats nearly the entire purpose of the Bigbank example. I think what you would want then is the DKIM signing complete practice. I think we went around several times on From or From/Sender and there was (in my opinion, which I know counts for exactly nothing) a reasonable rough consensus that From was what we should focus on. Keep in mind that the Big Bank example is explicitly about phishing targets that are willing to accept breakage of some legitimate e-mail functionality. That doesn't sound like your case. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] How much bogosity on the part of filter writers to cope with?
I have been thinking about the problem of how to write instructions to filter writers that give them useful clues. I suspect that it is an impossible task and we should just accept the fact that there will be stupid filters out there, not least because there are plenty of filters that are simply AI programs with adled feedback mechanisms just blindly applying broken Bayesian logic schemes. The reson I say this is because we have debated endlessly how to stop someone interpreting 'always sign' in bad ways. I have just been looking at a filter rule that essentially says 'junk all mail that has paypal.com in the from address'. OK you can certainly stop a lot of spam but that does not make it an acceptable or useful rule for an ISP. Some people will shoot themselves in the foot no matter what we do. An even larger number will hire a clueless AI bot to shoot them in the face. Lets just accept this and move on. We are designing systems for people with a clue and Darwin can take out the rest. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements clarification: Standard for resource record name space collision
Paul Hoffman wrote: At 1:02 PM -0400 8/9/06, Scott Kitterman wrote: *** *** 474,480 expectation is "few".] 3. Discovery mechanism MUST NOT overload semantics of existing DNS !resource records where name space collisions are possible. 5.2. Transport requirements --- 479,485 expectation is "few".] 3. Discovery mechanism MUST NOT overload semantics of existing DNS !resource records where name space collisions are reasonably likely. 5.2. Transport requirements *** Making name space collision impossible (the written requirement) is a high bar. Higher than was used for DKIM base. Reasonably likely seems like a better standard. Impossible would seem to require a new RR. Actually, that's not true. For -base, there was no chance that a host name (as compared to a domain name) would collide with a name that had the chosen label. I think saying "impossible" is reasonable if you clarify the difference. It would be really nice not to revisit the wars that erupted when the IDN WG picked a label prefix. I agree with Scott that impossible is probably too high a barrier -- mainly because there doesn't exist any way to reserve part of the namespace. Note that the requirement didn't say anything about hosts. The main thing I'm trying to get across here is that overloading TXT, say, at the top level like SPF did is a no-no. I think it's probably fine if a candidate protocol carves out a piece of the namespace like DKIM did, as well as using its own custom top level RR. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corrected copy - Requirements addition: Policy/Practice record for first party signatures
Scott --- Scott -- I think it's both explicit and specific in other requirements that the protocol must publish that data, and some of those are MUST strength. I really don't see why we need to restate that here. That and I don't think there is any explicit or implicit proscription here on when the protocol ought not be invoked. The restriction on was forcing new behavior for a DKIM verifier, not on how the protocol could be used. Mike Scott Kitterman wrote: *** 574,580 blacklist repository.] 9. The Protocol MUST NOT be required to be invoked if a valid first ! party signatures is found. 10. [PROVISIONAL] A domain holder MUST be able to publish a Practice which enumerates the acceptable cryptographic algorithms for --- 581,594 blacklist repository.] 9. The Protocol MUST NOT be required to be invoked if a valid first ! party signatures is found, [PROVISIIONAL] but the Protocol SHOULD ! support publishing Practices for First Party DKIM signatures. ! ![INFORMATIVE NOTE: the provisional requirement to support First !Party Practices is intended as an aid to the receiver. While !SSP lookups aren't required for First Party DKIM signatures, !there may be utility to receivers to determine Practices !associated with First Party DKIM signatures.] 10. [PROVISIONAL] A domain holder MUST be able to publish a Practice which enumerates the acceptable cryptographic algorithms for *** This addition is suggested for a couple of reasons... 1. Completeness. I think there is some value in providing a reasonably complete list of Practices. There will likely be effective uses for policy information by receivers that we haven't thought of yet. An incomplete set of practices may hamstring this kind of innovation. 2. RFC 2821 discovery - This is the requirement change a alluded to yesterday in the signalling DKIM support before DATA thread. I won't rehash that here. Scott K ___ 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] Clarification: Section 5.4.6
As always, a requirements document is a set of MINIMUM requirements. I'd just assume we not get too far down in the details of things that we can just as easily discuss in the design phase. This seems like one that could wait to me. Mike Hector Santos wrote: I was thinking about this and wasn't sure if it was worth bringing up. I mean, in DSAP we have failure-handling statements, but I can go either way. But let me throw out the idea of the domain wishing to express a disclaimer that is something failures, it is HIGHLY desirable that you not retain this message. I provided an example in DSAP: _dsap._domainkey.bank.example. IN TXT "v=dsap1.0; a=rsa-sha256; op=always; 3p=never; n=We only send DKIM signed email, do not trust anything else such as notices allegedly from [EMAIL PROTECTED] Please report all such abuse to; [EMAIL PROTECTED];" Where using the N= note tag, the domain making an disclaimer statement to the verifier not to trust the message. So maybe just adding a new requirement? Protocol MUST allow for a informational text note for the policy. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com - Original Message - From: "Michael Thomas" <[EMAIL PROTECTED]> To: "Michael Thomas" <[EMAIL PROTECTED]> Cc: "DKIM List" Sent: Wednesday, August 09, 2006 2:33 PM Subject: Re: [ietf-dkim] Clarification: Section 5.4.6 Following myself up with a clarification: Michael Thomas wrote: "In particular, a Practice or Expectation MUST NOT mandate any disposition stance on the receiver." The reason that I've written it in this way was purposeful on my part: the sender's expectation is that there should be a valid signature. I don't really think we need to go further than that because if a receiver knows that the sender expects a message to arrive with a valid signature, that's really all it needs to know that there's something seriously amiss. What it actually does when something is amiss it's its business, and I really don't think we need to give helpful hints as it's not really rocket science at that point, and we really don't want to prejudice any particular action. Mike ___ 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] Corrected copy - Requirements addition: Policy/Practice record for first party signatures
On Wednesday 09 August 2006 16:53, Michael Thomas wrote: > Scott --- > > Scott -- I think it's both explicit and specific in other requirements > that the protocol > must publish that data, and some of those are MUST strength. I really > don't see why > we need to restate that here. > > That and I don't think there is any explicit or implicit proscription > here on when the > protocol ought not be invoked. The restriction on was forcing new > behavior for a > DKIM verifier, not on how the protocol could be used. > OK. You've spent a lot more time with the document than I have. I'll accept that. I'll keep an eye on it when we get to design. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC2822.Sender
Michael Thomas wrote: Tony Hansen wrote: add RFC2822.Sender I'm not the chair, but I've seen considerably less consensus about anything other than rfc2822.from. I'm frankly not sure I understand it very well. I know I don't understand it! Maybe a more detailed use-case would help? (Tony?) There's of course nothing that prevents a receiver from checking SSP for any address/domain it wants to, but do we now have a mandate to make assertions about any kind of origination address? How do those assertions interact with each other? What does a strong practice for ListID and a weak practice for Sender mean if they're in the same message? All good questions. And maybe not too easy to be confident in any answers at this stage? Finally, is this something that can wait? Ie, are we harmed if we don't do it now? Again, I dunno. I believe we do have consensus that at least rfc2822.From needs to be handled now. If more folks want rfc2822.Sender to be handled now as well, then they should say so I guess. S. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: requirements clarifications: Listed third parties treated like first party and must not require/specify
Scott Kitterman wrote: > I'd suggest that we MUST NOT require instead of MUST NOT > specify. That achieves the goal of not having receiver > policy cause protocol failures, but allows more freedom in > design to communicate sender expectations. In other words it cannot say "receiver SHOULD reject", but it could say "if receivers decide to reject they SHOULD [...]", where that helps. I still miss a similar detail lost on the way to 4408 2.5.4 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: Clarification: Section 5.4.6
Hector Santos wrote: > Protocol MUST allow for a informational text note for the > policy. I always hated the exp= explanations in SPF. A "disclaimer" n=convoluted_legalese isn't better, IMO receivers won't care about it. You'd also get I18N issues with such "disclaimers". Frank ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] issue: requirement #10 Publishing Hashing (cryptographic algorithms) methods...
On Aug 9, 2006, at 11:43 AM, Hector Santos wrote: From: "Douglas Otis" <[EMAIL PROTECTED]> SMTP is not an end-to-end protocol. The store-and-forward feature of SMTP means _any_ email-address may not be the final destination for a message. As far as the initial author concern it is. No. The author does not know where the final verifier resides, or where signature verification and policy might ultimately be applied. When the author sends a message using SMTP, it should be well understood the email-address used to initiate delivery may have no direct relationship with where the message is ultimately destine. You are referring to a relay forwarding of an email address to another address. But to get to this node, the initial path did reach its destination. The author had no clue that a forwarding of the address would be taken place. A verifier may be located in both MUAs and MTAs that forward messages. For the very reason that the author has "no clue" would be the reason that removal of a mechanism commonly essential for assured DKIM verification may create significant problems. Same wave length? If so, a DKIM verify domain who would be receiving an email targeted for its MDA would verify the message, and need be, then forward it hopefully to another DKIM ready domain. "DKIM ready" will not remain a static definition. Avoiding a deprecated mechanism when possible is the goal of an anti-bid-down mechanism. When a signing domain creates a policy fostering an expectation that all messages have valid DKIM signatures, this necessitates including signatures with mechanisms a DKIM verifier is commonly expected to support. There is no reasonable way within SMTP to negotiate with the ultimate destination. The signing domain however may warn what signature should and should not be used. Don't expect that the final verifier is able to indicate what it supports or that this information would be useful for avoiding the bid-down. This may create a exploitable conflict for generating bounces, or may cause important messages, where added security matters, to be lost or rejected. For this particular item, how so? An example of an exploit would be nice. A message using "strict" policy is sent to [EMAIL PROTECTED] that publishes a "verifier" policy indicating SHA-256 is supported. The message is then signed using only SHA-256. When the message gets forwarded to [EMAIL PROTECTED], that domain only handles the required SHA-1. The "strict" policy is noticed, the message is not considered signed, and it is bounced. A bad actor finds that example.com publishes an ability to handle SHA-256 signatures and is known for forwarding email-addresses discovered using exploratory attacks with bounces to a covert address. A bounce may cause any signature to become invalid. To make the message interesting, an invalid signature might be added to appear to be from the bounce victim's domain. There is no requirement a DKIM signing domain have the same domain as that of the 2821.MAIL_FROM, or that invalid signatures be removed. Example.com found a valid signature, and merry-men.com trusted example.com. An anti-bid-down mechanism can not depend upon the signer acting reliably in response to a "verifier" policy. I personally see this as a "highly desirable" feature that would add a few stars to a software package. I also see this as something very desirable in a social, vendor or business network. The final destination of a message must be considered unknown. See above. I am not sure Doug if you were describing a new solution or explaining why it won't work. A reasonable solution would be for the signing domain to indicate what should and should not be used when they offer multiple signatures. If you want to trust your financial institution's signature, follow their advice about which is the better signature. When your verifier does not support their recommended signature, annotate the message and look to upgrade. The verifier on its own can not know the signer's capabilities for deciding whether a deprecated mechanism is the best that should be expected from a domain. This problem should be handled correctly rather than handled in the manner you are suggesting. Do it right, or don't do it. The only reason for considering an anti-bid-down mechanism would be to define how this mechanism could be used in the future. It is my understanding that the WG has concluded that solutions for the bid- down attack are not to be considered at this time. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: Requirements comment: Bigbank example description
Tony Hansen wrote: > This has nothing to do with PRA and its support for > Resent-From and/or Resent-Sender. If there is an SSP for "A", why apply it to Sender "[EMAIL PROTECTED]", but not Resent-From "[EMAIL PROTECTED]" ? Can you use an SSP for "B" and 2822-From "[EMAIL PROTECTED]", if the mail was actually Resent-From "[EMAIL PROTECTED]" ? Frank ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] issue: requirement #10 Publishing Hashing (cryptographic algorithms) methods...
Doug, Too many words, and trending away from resolution of pretty much anything. I suggest you try to come to agreement between yourselves offlist, and then share your conclusions afterwards, Thanks, Stephen. Douglas Otis wrote: On Aug 9, 2006, at 11:43 AM, Hector Santos wrote: From: "Douglas Otis" <[EMAIL PROTECTED]> SMTP is not an end-to-end protocol. The store-and-forward feature of SMTP means _any_ email-address may not be the final destination for a message. As far as the initial author concern it is. No. The author does not know where the final verifier resides, or where signature verification and policy might ultimately be applied. When the author sends a message using SMTP, it should be well understood the email-address used to initiate delivery may have no direct relationship with where the message is ultimately destine. You are referring to a relay forwarding of an email address to another address. But to get to this node, the initial path did reach its destination. The author had no clue that a forwarding of the address would be taken place. A verifier may be located in both MUAs and MTAs that forward messages. For the very reason that the author has "no clue" would be the reason that removal of a mechanism commonly essential for assured DKIM verification may create significant problems. Same wave length? If so, a DKIM verify domain who would be receiving an email targeted for its MDA would verify the message, and need be, then forward it hopefully to another DKIM ready domain. "DKIM ready" will not remain a static definition. Avoiding a deprecated mechanism when possible is the goal of an anti-bid-down mechanism. When a signing domain creates a policy fostering an expectation that all messages have valid DKIM signatures, this necessitates including signatures with mechanisms a DKIM verifier is commonly expected to support. There is no reasonable way within SMTP to negotiate with the ultimate destination. The signing domain however may warn what signature should and should not be used. Don't expect that the final verifier is able to indicate what it supports or that this information would be useful for avoiding the bid-down. This may create a exploitable conflict for generating bounces, or may cause important messages, where added security matters, to be lost or rejected. For this particular item, how so? An example of an exploit would be nice. A message using "strict" policy is sent to [EMAIL PROTECTED] that publishes a "verifier" policy indicating SHA-256 is supported. The message is then signed using only SHA-256. When the message gets forwarded to [EMAIL PROTECTED], that domain only handles the required SHA-1. The "strict" policy is noticed, the message is not considered signed, and it is bounced. A bad actor finds that example.com publishes an ability to handle SHA-256 signatures and is known for forwarding email-addresses discovered using exploratory attacks with bounces to a covert address. A bounce may cause any signature to become invalid. To make the message interesting, an invalid signature might be added to appear to be from the bounce victim's domain. There is no requirement a DKIM signing domain have the same domain as that of the 2821.MAIL_FROM, or that invalid signatures be removed. Example.com found a valid signature, and merry-men.com trusted example.com. An anti-bid-down mechanism can not depend upon the signer acting reliably in response to a "verifier" policy. I personally see this as a "highly desirable" feature that would add a few stars to a software package. I also see this as something very desirable in a social, vendor or business network. The final destination of a message must be considered unknown. See above. I am not sure Doug if you were describing a new solution or explaining why it won't work. A reasonable solution would be for the signing domain to indicate what should and should not be used when they offer multiple signatures. If you want to trust your financial institution's signature, follow their advice about which is the better signature. When your verifier does not support their recommended signature, annotate the message and look to upgrade. The verifier on its own can not know the signer's capabilities for deciding whether a deprecated mechanism is the best that should be expected from a domain. This problem should be handled correctly rather than handled in the manner you are suggesting. Do it right, or don't do it. The only reason for considering an anti-bid-down mechanism would be to define how this mechanism could be used in the future. It is my understanding that the WG has concluded that solutions for the bid-down attack are not to be considered at this time. -Doug ___ NOTE WELL: This list operates according tohttp://mipassoc.org/dkim/ietf-list-rules.html ___
Re: [ietf-dkim] Re: Requirements comment: Bigbank example description
Frank, Frank Ellermann wrote: Tony Hansen wrote: This has nothing to do with PRA and its support for Resent-From and/or Resent-Sender. If there is an SSP for "A", why apply it to Sender "[EMAIL PROTECTED]", but not Resent-From "[EMAIL PROTECTED]" ? Can you use an SSP for "B" and 2822-From "[EMAIL PROTECTED]", if the mail was actually Resent-From "[EMAIL PROTECTED]" ? Can I suggest making concrete proposals, aimed at moving towards consensus, rather then asking open ended questions that lead to lots of repetition and lots and lots of mail? Really - it'll lead to less hassle for us all, Thanks, Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarification: Section 5.4.6
- Original Message - From: "Michael Thomas" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]> >>So maybe just adding a new requirement? >> >>Protocol MUST allow for a informational text note for the policy. >> > As always, a requirements document is a set of MINIMUM requirements. I'd > just assume we not get too far down in the details of things that we can > just as easily discuss in the design phase. This seems like one that could > wait to me. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: Requirements comment: Bigbank example description
Stephen Farrell wrote: > Can I suggest making concrete proposals, aimed at moving > towards consensus It won't help if I reject three proposals "add 2822-Sender" only because I don't understand it. It also won't help if I'd support it, but have no clue why Resent-* are excluded. Frank ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Requirements comment: Bigbank example description
On Wednesday 09 August 2006 20:32, Frank Ellermann wrote: > Stephen Farrell wrote: > > Can I suggest making concrete proposals, aimed at moving > > towards consensus > > It won't help if I reject three proposals "add 2822-Sender" > only because I don't understand it. It also won't help if > I'd support it, but have no clue why Resent-* are excluded. > Here is a concrete proposal In this round, we only specify sender policy for 2822.From. To the extent we have consensus that SSP is a good thing, we have consensus that it should cover 2822.From. Once you get beyond that, consensus is elusive at best. There is a requirement that the protocol be extensible. Later, if there is a demand, something else could be added. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Requirements comment: Bigbank example description
- Original Message -
From: "Stephen Farrell" <[EMAIL PROTECTED]>
To: "Frank Ellermann" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, August 09, 2006 7:52 PM
Subject: Re: [ietf-dkim] Re: Requirements comment: Bigbank example
description
>
> Frank,
>
> Frank Ellermann wrote:
> > Tony Hansen wrote:
> >
> >> This has nothing to do with PRA and its support for
> >> Resent-From and/or Resent-Sender.
> >
> > If there is an SSP for "A", why apply it to Sender "[EMAIL PROTECTED]",
> > but not Resent-From "[EMAIL PROTECTED]" ?
> >
> > Can you use an SSP for "B" and 2822-From "[EMAIL PROTECTED]", if the
> > mail was actually Resent-From "[EMAIL PROTECTED]" ?
>
> Can I suggest making concrete proposals, aimed at moving
> towards consensus, rather then asking open ended questions
> that lead to lots of repetition and lots and lots of mail?
>
> Really - it'll lead to less hassle for us all,
If this may help, and Michael can comment and clarify, an old pseudo-code
presented here (or in the old list) did include consideration for the
2822.Sender header:
$outsideheaders = "From, Sender";
$from = ; // 2822 From: address in msg
dkim_bindToOutsideHdrs () {
foreach ($hdr in $outsideheaders) {
if (dkim_bindToHdr ($hdr) == BIND) {
if ($hdr != "From") {
$policy = dkim_signerPolicy (domainpart ($from));
if ($policy == strict || $policy == nomail)
return FAIL;
else
return PASS;
} else
return PASS;
}
}
return NEUTRAL;
}
In layman terms (pending Michael's confirmation)
The SSP policy was ALWAYS done on the 2822.From domain
but ONLY when the DKIM-Signature d= tag was bound to
the 2822.Sender domain.
It was my contention that the SSP should ALWAYS be done against the
2822.From regardless of how DKIM-Signature domain was bounded.
It was from my analysis of Michael's initial pseudo-code that started my
efforts in producing the Policy vs. Verification Result tables and the
genesis of the more restrictive policy concepts.
Hope this provide some insight.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Requirements comment: Bigbank example description
On Wednesday 09 August 2006 21:29, Hector Santos wrote: > It was my contention that the SSP should ALWAYS be done against the > 2822.From regardless of how DKIM-Signature domain was bounded. > +1 Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC2822.Sender
Stephen Farrell wrote: > > Michael Thomas wrote: >> Tony Hansen wrote: >>> add RFC2822.Sender >>> >> I'm not the chair, but I've seen considerably less consensus about >> anything other than rfc2822.from. I'm frankly not sure I understand >> it very well. > > I know I don't understand it! > > Maybe a more detailed use-case would help? (Tony?) I want to make certain that what we're building with policies doesn't prevent eCard senders or News agencies from doing what they currently do. They should be able to 1) send a message to someone on my behalf while 2) marking themselves as the sender and 3) being able to sign the message. According to 2822, this minimally requires support for RFC2822.Sender as well as RFC2822.From. For example, consider these scenarios: From: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] DKIM-Signature: ... d=hallmark.com; ... Subject: Happy birthday from Tony or From: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] DKIM-Signature: ... d=newyorktimes.com; ... Subject: some news story These need to be validated against the sender. Yes, there are a variety of issues. And to properly deal with this issue, we also need to deal with Sender/d= above being "@bigbadguy.com". DKIM is not sufficient in and of itself, as we all know. But we need to be able to support these scenarios somehow. If we don't let this be done using Sender:, then we need to have some other way of doing it. My choice is to support the 2822 way of doing it, which says we need to support Sender:. Tony Hansen [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Issue: Requirements #9 NOT REQUIRED for 1st party valid signatures.
- Original Message - From: "Scott Kitterman" <[EMAIL PROTECTED]> > Here is a concrete proposal > > In this round, we only specify sender policy for 2822.From. > To the extent we have consensus that SSP is a good thing, we > have consensus that it should cover 2822.From. Once you get > beyond that, consensus is elusive at best. > > There is a requirement that the protocol be extensible. > Later, if there is a demand, something else could be added. As shown in the pseudo-code posted in my last message, I believe the original thinking was basically only do to a 2822.From policy lookup when there was a 3rd party domain signature binding. h, in fact, re-reading requirement #9, the mentality might still reflect this original thinking: The Protocol MUST NOT be required to be invoked if a valid first party signatures is found. I ask for the author's confirmation or clarification on this. Since day one, I had some concerns with this logic as it revealed some issues regarding other possible domain Practices possible and as well as exploitations possible. Hence the reason for the Policy vs. Verification tables, showing why the SSP should always be done on the 2822.From and the beginnings of the DSAP drafts to document the reasons, method to resolve this, and illustrating a reliable verification chart. Also, I think by introducing 2822.Sender: this will inevitably begin to touch base with 2821.MailFrom considerations as well and I think that will take up into a new level of 2821 vs. 2822 issues and debates, or something think you guys call a "Rat Hole?" I'm not saying it is bad idea. I am just saying I think it might force some other considerations as well for which if we want to do this, it might probably be worth the effort. So maybe if we can easily construct this to be able to add Sender: as an extended implementation option without breaking the minimum requirements, I would put my +1 to this. But it now seems, that requirement #9 might actually reflect the original logic intended. I would like to know if that's true. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Identity selection related requirements (Re: [ietf-dkim] RFC2822.Sender)
That this thread is being discussed brings up a requirement that policy record syntax should be capable of supporting multiple identities. A subquestion of that is if policy record identity should or should not be part of the query selection process (i.e. _from._policy if DNS). That BTW brings up a separate issue about how policy record queries are to be done, which is a protocol-related requirement and those appear to not be mentioned in the requirements document right now. The question that you're actually discussing in the thread about 'RFC2822.Sender' is is what identit[y|ies] you actually want to define for initial use and how. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC2822.Sender
On Wednesday 09 August 2006 22:30, Tony Hansen wrote: > Stephen Farrell wrote: > > Michael Thomas wrote: > >> Tony Hansen wrote: > >>> add RFC2822.Sender > >> > >> I'm not the chair, but I've seen considerably less consensus about > >> anything other than rfc2822.from. I'm frankly not sure I understand > >> it very well. > > > > I know I don't understand it! > > > > Maybe a more detailed use-case would help? (Tony?) > > I want to make certain that what we're building with policies doesn't > prevent eCard senders or News agencies from doing what they currently > do. They should be able to 1) send a message to someone on my behalf > while 2) marking themselves as the sender and 3) being able to sign the > message. According to 2822, this minimally requires support for > RFC2822.Sender as well as RFC2822.From. > > For example, consider these scenarios: > > From: [EMAIL PROTECTED] > Sender: [EMAIL PROTECTED] > DKIM-Signature: ... d=hallmark.com; ... > Subject: Happy birthday from Tony > or > From: [EMAIL PROTECTED] > Sender: [EMAIL PROTECTED] > DKIM-Signature: ... d=newyorktimes.com; ... > Subject: some news story > > These need to be validated against the sender. > > Yes, there are a variety of issues. And to properly deal with this > issue, we also need to deal with Sender/d= above being "@bigbadguy.com". > DKIM is not sufficient in and of itself, as we all know. But we need to > be able to support these scenarios somehow. > > If we don't let this be done using Sender:, then we need to have some > other way of doing it. My choice is to support the 2822 way of doing it, > which says we need to support Sender:. > > Tony Hansen > [EMAIL PROTECTED] I think that this scenario is already supported by the "Signing Complete" practice and explicitly not desireable for the First Party (as extended by a possible list) Expected Practice. I think that the current requirements are correct for this use case. This is exactly the kind of scenario First Party Expected should not support. Signing Complete deals with the case where a domain desires to support Sender with an associated signature and no policy record (or signs sometimes if we end up with such a practice) supports Sender with or without a signature. First Party Expected supports the case where a domain does not want to allow 2822.Sender signatures/policies to over-ride the 2822.From. My vote is no change needed to the current draft for this. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements clarification/addition: DKIM Signing Complete should include designated third parties
Tony Hansen wrote: >> !! arrival of a piece of unsigned, damaged in transit mail, or if >> a RFC2822.From sender policy exists which specifies authoritative >> domain(s), a mail signed by an entity other than described in the sender >> policy. > > add RFC2822.Sender Let's try an exercise: Why? How is the information expected to get used? Why do we believe it will be useful? Do we have any indication that it will actually get used (that way, or any other)? -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC2822.Sender
Tony, Then your domain (att.com) will need to declare a relaxed 3rd party signature concept. For example: Using SSP-01 this is defined as default policy or o=~. Using a DSAP framework, you would declare: OP=OPTIONAL; 3P=OPTIONAL; In both cases, you are using a NEUTRAL policy. You are no longer protecting the authorization of the signature because you essentially don't care who signs the message. But you want to allow the 3rd party to have the message authenticity and integrity power of DKIM. Now, with DSAP, you can be restrictive on which 3rd party would be allowed to sign: OP=OPTIONAL; 3P=OPTIONAL; 3PL=*.hallmark.com;*.newyorktimes.com which Michael's document covers with requirement #5 covers. So in my technical view, we don't need the 2822.Sender because it is already covered with requirement #5. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com - Original Message - From: "Tony Hansen" <[EMAIL PROTECTED]> To: "DKIM List" Sent: Wednesday, August 09, 2006 10:30 PM Subject: Re: [ietf-dkim] RFC2822.Sender > Stephen Farrell wrote: > > > > Michael Thomas wrote: > >> Tony Hansen wrote: > >>> add RFC2822.Sender > >>> > >> I'm not the chair, but I've seen considerably less consensus about > >> anything other than rfc2822.from. I'm frankly not sure I understand > >> it very well. > > > > I know I don't understand it! > > > > Maybe a more detailed use-case would help? (Tony?) > > I want to make certain that what we're building with policies doesn't > prevent eCard senders or News agencies from doing what they currently > do. They should be able to 1) send a message to someone on my behalf > while 2) marking themselves as the sender and 3) being able to sign the > message. According to 2822, this minimally requires support for > RFC2822.Sender as well as RFC2822.From. > > For example, consider these scenarios: > > From: [EMAIL PROTECTED] > Sender: [EMAIL PROTECTED] > DKIM-Signature: ... d=hallmark.com; ... > Subject: Happy birthday from Tony > or > From: [EMAIL PROTECTED] > Sender: [EMAIL PROTECTED] > DKIM-Signature: ... d=newyorktimes.com; ... > Subject: some news story > > These need to be validated against the sender. > > Yes, there are a variety of issues. And to properly deal with this > issue, we also need to deal with Sender/d= above being "@bigbadguy.com". > DKIM is not sufficient in and of itself, as we all know. But we need to > be able to support these scenarios somehow. > > If we don't let this be done using Sender:, then we need to have some > other way of doing it. My choice is to support the 2822 way of doing it, > which says we need to support Sender:. > > Tony Hansen > [EMAIL PROTECTED] > ___ > 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] RFC2822.Sender
On Wed, Aug 09, 2006 at 10:30:21PM -0400, Tony Hansen allegedly wrote: > Stephen Farrell wrote: > > > > Michael Thomas wrote: > >> Tony Hansen wrote: > >>> add RFC2822.Sender > >>> > >> I'm not the chair, but I've seen considerably less consensus about > >> anything other than rfc2822.from. I'm frankly not sure I understand > >> it very well. > > > > I know I don't understand it! > > > > Maybe a more detailed use-case would help? (Tony?) > > I want to make certain that what we're building with policies doesn't > prevent eCard senders or News agencies from doing what they currently > do. They should be able to 1) send a message to someone on my behalf > while 2) marking themselves as the sender and 3) being able to sign the > message. According to 2822, this minimally requires support for > RFC2822.Sender as well as RFC2822.From. Why does DKIM need to support these directly? They can continue to send like this just fine and rely on their domain reputation or the good graces of receivers. Better yet, eCard senders could put their own From: address in and put your email in the content: From: [EMAIL PROTECTED] Howdy. mailto:[EMAIL PROTECTED] allegedly sent this card to your for your birthday... It seems bizarre to me that we want to explicitly allow an unauthenticated 2822.From to be treated as authenticated. One option: att.com could advertise that hallmark.com can put @att.com in the 2822.From: and have it authenticated via hallmark.com. Is that what you're asking for? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
