Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 15/May/11 21:04, Hector Santos wrote: The author can be a human using an MUA (Mail User Agent) or an automated mail robot with an MTA. Both the human and the robot use an MTA (or an MSA.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] New canonicalizations
On 16/May/11 06:15, Murray S. Kucherawy wrote: From: On Behalf Of Barry Leiba 2. We wanted to cover the vast majority of the cases, though we knew there'd always be outlying situations where some mail would get broken because what we had didn't *quite* cover some other case. We decided to accept that. However, relaxed header canonicalization is not MIME compatible. In particular, RFC 2045 says Note that the value of a quoted string parameter does not include the quotes. That is, the quotation marks in a quoted-string are not a part of the value of the parameter, but are merely used to delimit that parameter value. In addition, comments are allowed in accordance with RFC 822 rules for structured header fields. Thus the following two forms Content-type: text/plain; charset=us-ascii (Plain text) Content-type: text/plain; charset=us-ascii are completely equivalent but they are not DKIM-wise equivalent. Fixing this and a couple more nits, we could claim to cover text/plain, which is still not quite the vast majority of the cases. I would add that adding a new canonicalization now has an extremely high cost to the people that want to use it, because signatures using it will go unverified for a very long time until software supporting the new canonicalization is widely deployed. Many MTAs still add a Domainkey-Signature. They could stop that, and add a legacy DKIM-Signature along with a one that features the newer canonicalization instead. Setting the pace in this manner can keep DKIM development alive indefinitely. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] discardable, was Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
I'd propose to put this item ('writeup a definition of 'discardable') on
the to-do list of a successor of RFC5617, if there ever will be one. Or
on another future 'policy' document.
-1
RFC 5617 has a perfectly good definition of discardable:
All mail from the domain is signed with an
Author Domain Signature. Furthermore, if a
message arrives without a valid Author Domain
Signature due to modification in transit,
submission via a path without access to a
signing key, or any other reason, the domain
encourages the recipient(s) to discard it.
I realize there are people who wish it meant something else, typically
simultaneously saying this mail is very important and throw this mail
away, which is absurd, or perhaps if there's no signature, handle it
based on some complicated set of instructions of no benefit to the
receiver, even though the apparent sender probably isn't the actual
sender, because the message is so very important.
The definition in the RFC was hammered out after a great deal of debate,
and I see no evidence that the definition is defective. ADSP has plenty
of problems, but the definition of discardable isn't one of them.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please consider the environment before reading this e-mail. http://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On May 15, 2011, at 9:42 PM, Barry Leiba wrote: The author can be a human using an MUA (Mail User Agent) or an automated mail robot with an MTA. I don't see that automated mail robot with an MTA is right at all. But I see what you're getting at, and I'd support a change such as this: The author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the cron Unix system utility). +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
Thus the following two forms Content-type: text/plain; charset=us-ascii (Plain text) Content-type: text/plain; charset=us-ascii are completely equivalent but they are not DKIM-wise equivalent. I'm sorry, but this is just so wrong. Helpful software can modify mail in a million ways that don't affect the way that a message renders. If the contents of a message are in fact ASCII, these are also equivalent to the headers above: Content-type: text/plain; charset=UTF-8 (a superset of ASCII) Content-type: text/plain; charset=ISO-8859-2 (another superset of ASCII) Content-type: text/enriched; charset=windows-1252 (if there are no enriched codes) The point of relaxed canonicalization was to deal with the kind of small changes that dusty copies of sendmail make, not to handle every possible message mutation that more or less renders the same. In retrospect, it probably would have been better only to provide simple and tell people more firmly to do the signing after and the checking before any local modification. The idea that an MUA can sign if an MTA doesn't is clever, but if anyone's doing that, it's news to me. Perhaps Murray has data that says whether relaxed verifies much more often than simple does. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 5/16/2011 9:00 AM, John R. Levine wrote: The point of relaxed canonicalization was to deal with the kind of small changes that dusty copies of sendmail make, not to handle every possible message mutation that more or less renders the same. The underlying concern here actually is pretty reasonable: Variations that do not affect the appearance or semantics of a message could reasonably still permit a signature to verify. The problem is that the working group was not able to develop a... workable... canonicalization algorithm to achieve this complete robustness. In the extreme, this is a research topic. Certainly it is a delicate engineering tasks, since too much robustness against change can easily introduce security holes. But, then, that's why the working group debate the issue so extensively and the result did gain working group consensus. Since the list of algorithms is defined to be extensible, anyone feeling that an additional algorithm is warranted is free to define it and seek community consensus for it. 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] discardable, was Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 5/16/2011 8:22 AM, John R. Levine wrote:
I'd propose to put this item ('writeup a definition of 'discardable') on
the to-do list of a successor of RFC5617, if there ever will be one. Or
on another future 'policy' document.
-1
...
The definition in the RFC was hammered out after a great deal of debate,
and I see no evidence that the definition is defective.
+1 to the -1.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 16/May/11 15:00, John R. Levine wrote: In retrospect, it probably would have been better only to provide simple and tell people more firmly to do the signing after and the checking before any local modification. That implies hop to hop rather than end to end. What would the advantage over SPF be then? Perhaps Murray has data that says whether relaxed verifies much more often than simple does. Yes, http://www.opendkim.org/stats/report.html#hdr_canon says Header canonicalization use: canonicalizationcount domains passed simple 653688 6786591938 relaxed 3940377 56621 3640854 Although they only differ by 2% (90% simple vs 92% relaxed), such percentages would be superb for tools like Spamassassin. I'd expect at least 99% from a cryptographic tool. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
This was done in in 2006. I took up Stephan's suggestion to write an I-D http://tools.ietf.org/html/draft-santos-dkim-strip-00 It addressed the concerns related to NOFWS and that of which is still present with RELAXED. Dave CROCKER wrote: On 5/16/2011 9:00 AM, John R. Levine wrote: The point of relaxed canonicalization was to deal with the kind of small changes that dusty copies of sendmail make, not to handle every possible message mutation that more or less renders the same. The underlying concern here actually is pretty reasonable: Variations that do not affect the appearance or semantics of a message could reasonably still permit a signature to verify. The problem is that the working group was not able to develop a... workable... canonicalization algorithm to achieve this complete robustness. In the extreme, this is a research topic. Certainly it is a delicate engineering tasks, since too much robustness against change can easily introduce security holes. But, then, that's why the working group debate the issue so extensively and the result did gain working group consensus. Since the list of algorithms is defined to be extensible, anyone feeling that an additional algorithm is warranted is free to define it and seek community consensus for it. d/ -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
The underlying concern here actually is pretty reasonable: Variations that do not affect the appearance or semantics of a message could reasonably still permit a signature to verify. Oh, sure, but we also traded off the cost of handling changes and how common they are. For example, old copies of sendmail often add an extra blank line at the bottom of a message. That's common (or at least, was common), and easy to deal with, and is the kind of thing that relaxed handles. The variety of MIME rewrites is so vast that I don't see any hope of handling a usefully large set of them, so I'm not inclined to try. If you really really really want your signature to verify, after signing the message, turn it info a base64 encoded message/rfc822 mime part, wrap another message around it, and unwrap it before verifying. That works with S/MIME, too. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
In retrospect, it probably would have been better only to provide simple and tell people more firmly to do the signing after and the checking before any local modification. That implies hop to hop rather than end to end. What would the advantage over SPF be then? The fact that most hops don't break even simple signatures. We went through all this in 2006 (RFC 4686) and I don't see any reason to revisit it now. Perhaps Murray has data that says whether relaxed verifies much more often than simple does. Yes, http://www.opendkim.org/stats/report.html#hdr_canon says Header canonicalization use: canonicalization count domains passed simple 6536886786591938 relaxed 3940377 56621 3640854 Although they only differ by 2% (90% simple vs 92% relaxed), such percentages would be superb for tools like Spamassassin. I'd expect at least 99% from a cryptographic tool. This tells me that the benefit from relaxed is at most pretty small. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 5/16/2011 9:36 AM, John R. Levine wrote: If you really really really want your signature to verify, after signing the message, turn it info a base64 encoded message/rfc822 mime part, wrap another message around it, and unwrap it before verifying. That works with S/MIME, too. absent a standards-track specification for it being adopted, it's not interoperable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 16/May/11 15:41, John R. Levine wrote: http://www.opendkim.org/stats/report.html#hdr_canon says Header canonicalization use: canonicalization count domains passed simple 653688 6786591938 relaxed 3940377 56621 3640854 Although they only differ by 2% (90% simple vs 92% relaxed), such percentages would be superb for tools like Spamassassin. I'd expect at least 99% from a cryptographic tool. This tells me that the benefit from relaxed is at most pretty small. OTOH, comparing the count fields of those two lines, 86% relaxed vs 14% simple, says that such kind of benefit is really really wanted. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 16May11, Alessandro Vesely allegedly wrote: On 16/May/11 15:41, John R. Levine wrote: http://www.opendkim.org/stats/report.html#hdr_canon says Header canonicalization use: canonicalization count domains passed simple 6536886786591938 relaxed 3940377 56621 3640854 Although they only differ by 2% (90% simple vs 92% relaxed), such percentages would be superb for tools like Spamassassin. I'd expect at least 99% from a cryptographic tool. This tells me that the benefit from relaxed is at most pretty small. OTOH, comparing the count fields of those two lines, 86% relaxed vs 14% simple, says that such kind of benefit is really really wanted. But that's a perceived benefit, not an actual one. Folk think they need relaxed to significantly increase survivability but that's not the case given the stats above. So yo may be right that folk really really want it, but they don't really really need it. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
Content-type: text/plain; charset=us-ascii (Plain text) Content-type: text/plain; charset=us-ascii are completely equivalent DKIM has never tried to understand the semantics or syntax of each header. First off, doing this properly is very hard as there are a large number of equivalent header variations, but second off, it would make DKIM brittle against future headers that might have the same characteristics you describe. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 16May11, J.D. Falk allegedly wrote: On May 15, 2011, at 9:42 PM, Barry Leiba wrote: The author can be a human using an MUA (Mail User Agent) or an automated mail robot with an MTA. I don't see that automated mail robot with an MTA is right at all. But I see what you're getting at, and I'd support a change such as this: The author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the cron Unix system utility). +1 I've got a few of these left so I may as well use 'em while I have 'em. +1. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] discardable, was Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
At 05:22 16-05-2011, John R. Levine wrote: I realize there are people who wish it meant something else, typically simultaneously saying this mail is very important and throw this mail away, which is absurd, or perhaps if there's no signature, handle it Yes. The definition in the RFC was hammered out after a great deal of debate, and I see no evidence that the definition is defective. ADSP has plenty of problems, but the definition of discardable isn't one of them. I don't see any value in reopening a discussion about the definition. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
Hi Alessandro, At 03:22 16-05-2011, Alessandro Vesely wrote: However, relaxed header canonicalization is not MIME compatible. In particular, RFC 2045 says I don't think that it was ever meant to be MIME compatible. Many MTAs still add a Domainkey-Signature. They could stop that, and add a legacy DKIM-Signature along with a one that features the newer canonicalization instead. Setting the pace in this manner can keep DKIM development alive indefinitely. The MTAs that are still adding a Domainkey-Signature will keep doing that irrespective of what goes on in this working group. I prefer not to keep DKIM development alive indefinitely if the sole purpose is not to produce results. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] discardable, was Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of SM Sent: Monday, May 16, 2011 9:27 AM To: DKIM List Subject: Re: [ietf-dkim] discardable, was Last Call: draft-ietf-dkim- mailinglists-10.txt (DKIM And Mailing Lists) to BCP At 05:22 16-05-2011, John R. Levine wrote: I realize there are people who wish it meant something else, typically simultaneously saying this mail is very important and throw this mail away, which is absurd, or perhaps if there's no signature, handle it Yes. The definition in the RFC was hammered out after a great deal of debate, and I see no evidence that the definition is defective. ADSP has plenty of problems, but the definition of discardable isn't one of them. I don't see any value in reopening a discussion about the definition. Regards, -sm +1 Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 5/16/2011 10:40 AM, Mark Delany wrote: On 16May11, Alessandro Vesely allegedly wrote: On 16/May/11 15:41, John R. Levine wrote: http://www.opendkim.org/stats/report.html#hdr_canon says Header canonicalization use: canonicalization count domains passed simple 6536886786591938 relaxed 3940377 56621 3640854 Although they only differ by 2% (90% simple vs 92% relaxed), such percentages would be superb for tools like Spamassassin. I'd expect at least 99% from a cryptographic tool. This tells me that the benefit from relaxed is at most pretty small. OTOH, comparing the count fields of those two lines, 86% relaxed vs 14% simple, says that such kind of benefit is really really wanted. But that's a perceived benefit, not an actual one. I agree that the above does not give us insight into actual benefit. Rather, it tells us something about beliefs and goals of signers; they chose one or the other because they /believed/ it would be helpful. As to whether it really was, we can't see here. Folk think they need relaxed to significantly increase survivability but that's not the case given the stats above. So yo may be right that folk really really want it, but they don't really really need it. Sorry, but I believe the above also does /not/ help us to understand actual survivability differences. To assess that difference, the experiment needs to send the same set of message twice, one with each type of canonicalization, and then see what the survival differences are. The problem with the above is the biasing factor of signers' choosing to use one or the other, based on criteria we can't know about. Their criteria might have greatly affected actual survival rates. Or might not have... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 05/16/2011 07:40 AM, Mark Delany wrote: On 16May11, Alessandro Vesely allegedly wrote: OTOH, comparing the count fields of those two lines, 86% relaxed vs 14% simple, says that such kind of benefit is really really wanted. But that's a perceived benefit, not an actual one. Folk think they need relaxed to significantly increase survivability but that's not the case given the stats above. So yo may be right that folk really really want it, but they don't really really need it. It was our experience that relaxed body didn't make much difference. Relaxed headers was a different story. I don't have access to all of the ways signatures broke any more, but if you factor out real mailing lists it was pretty low and sort of random, iirc. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 05/16/2011 09:39 AM, Dave CROCKER wrote: Sorry, but I believe the above also does /not/ help us to understand actual survivability differences. To assess that difference, the experiment needs to send the same set of message twice, one with each type of canonicalization, and then see what the survival differences are. The problem with the above is the biasing factor of signers' choosing to use one or the other, based on criteria we can't know about. Their criteria might have greatly affected actual survival rates. Or might not have... My guess is that admins just don't understand any of the subtleties, have heard lore that relaxed is better and just click relaxed wherever they find it. It may also be the case that some implementations don't even have separate nerd knobs for headers and body canonicalization. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 16/May/11 19:00, Michael Thomas wrote: On 05/16/2011 09:39 AM, Dave CROCKER wrote: The problem with the above is the biasing factor of signers' choosing to use one or the other, based on criteria we can't know about. Their criteria might have greatly affected actual survival rates. Or might not have... My guess is that admins just don't understand any of the subtleties, have heard lore that relaxed is better and just click relaxed wherever they find it. It may also be the case that some implementations don't even have separate nerd knobs for headers and body canonicalization. However, Murray's stats show some difference in the choice of relaxed: Header canonicalization use: canonicalizationcount domains passed simple 653688 6786591938 relaxed 3940377 56621 3640854 Body canonicalization use: canonicalizationcount domains passed simple 1187858 11526 1096204 relaxed 3406207 51818 3136588 For the body count, we have 74% relaxed vs 26% simple, while it is 86% relaxed vs 14% simple for the header. There is a 12% difference toward relaxing the header, which implies some thought or testing. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of J.D. Falk Sent: Monday, May 16, 2011 5:35 AM To: IETF list; DKIM List Subject: Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP I don't see that automated mail robot with an MTA is right at all. But I see what you're getting at, and I'd support a change such as this: The author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the cron Unix system utility). +1 Works for me. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
Alessandro Vesely wrote: On 16/May/11 19:00, Michael Thomas wrote: My guess is that admins just don't understand any of the subtleties, have heard lore that relaxed is better and just click relaxed wherever they find it. It may also be the case that some implementations don't even have separate nerd knobs for headers and body canonicalization. However, Murray's stats show some difference in the choice of relaxed: ... For the body count, we have 74% relaxed vs 26% simple, while it is 86% relaxed vs 14% simple for the header. There is a 12% difference toward relaxing the header, which implies some thought or testing. Its hard to imagine and DKIM explorer will do so without some technical forethought and eventual testing; internal but also external. Our auto-responder log shows the testing is active (but mostly by the same people). But I think its important to get a Domain Analysis to see the isolations, if any. I just did a quick C14N analysis of 9000+ DKIM signed messages coming to my system and what it appear clear to me that many are using whatever default settings come with their DKIM package, API and/or straight from the specs. When the volume was reduced to unique domains, there were 208 unique domains with a c= breakdown: 31 c=simple/simple 10 c=simple 23 c=relaxed/simple 8 c=relaxed 134 c=relaxed/relaxed 2 c=simple/relaxed When you fold c=simple with simple/simple and c=relaxed with relaxed/simple 41 c=simple/simple(DKIM default) 31 c=relaxed/simple 134 c=relaxed/relaxed 2 c=simple/relaxed Based on this: 79.4% domains use relaxed for headers 65.4% domains use relaxed for body Since the default is simple/simple, this clearly shows the majority domains (for whatever reason) are conscious of using relaxed. Now looking at the actual 208 list of domains, I can see a pattern where the C14N breaks show a common DKIM package. For example: Among the 10 c=simple, 6 of them are our wcDKIM field testing site domains. Thats because of our default setting DKIM_SIGN_SIMPLE. Among the 31 c=relaxed/simple, many of groups of domains are from the same organizations. Like my wife signing up for food coupons one Red Lobster we can spam from the Corporation for there other franchises: c=relaxed/simple; d=news.longhornsteakhouse.com; s=yesmail1 c=relaxed/simple; d=news.olivegarden.com; s=yesmail1; c=relaxed/simple; d=news.redlobster.com; s=yesmail1; Among the 2 c=simple/relaxed, this appears to be the same organization based on the same selector: c=simple/relaxed; d=bothan.net; s=2011.01.24; c=simple/relaxed; d=drewhess.com; s=2011.01.24; and finally among the largest 134 c=relaxed/relaxed, clearly you can see a district group because the patterns of the signing domain and similar or near similar selector and can see many phishing or appears to variations of signing domains, include groups where the only difference is .com, .net or .org. Here are some selected examples c=relaxed/relaxed; d=couponba.com; s=mail; c=relaxed/relaxed; d=couponble.com; s=mail; c=relaxed/relaxed; d=couponsystems.net; s=mail; c=relaxed/relaxed; d=couponsystems.org; s=mail; c=relaxed/relaxed; d=mcsv178.net;s=k1 c=relaxed/relaxed; d=mcsv78.net; s=k1 c=relaxed/relaxed; d=mcsv83.net; s=k1 c=relaxed/relaxed; d=smartsavingclub.com; s=mail c=relaxed/relaxed; d=smartsavingnow.com; s=mail c=relaxed/relaxed; d=smtpninja.com; s=mail c=relaxed/relaxed; d=smtpninja.net; s=mail c=relaxed/relaxed; d=smtpresults.com; s=mail c=relaxed/relaxed; d=smtpresults.net; s=mail c=relaxed/relaxed; d=selfsaver.net; s=mail c=relaxed/relaxed; d=selfsaver.org; s=mail You can probably assume these 15 domains are really just 5 organization/software and if we presume those with the same selector, its 1 organization using the same public key. I will suggest that relaxed/relaxed is the largest because spammers, eMarketers want to highest possible chance of surviving a header/body integrity check. They don't want any increased complexity or change of having errors when it comes to C14N. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
