Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict
Charles Lindsey wrote: > There is no SHOULD|MUST about what recipients do. At most, it is a matter > of Best Common Practice, which this WG might well choose to incorporate in > a BCP RFC. But what would such a BCP document say? I agree, but at some point implementators will need to transform the functional specification into a technical one. i.e. Software logic with options etc. > It might say that all invalid DISCARDABLE email "SHOULD" be discarded. > > It might say that all invalid DISCARDABLE email "SHOULD" be marked as such > and sent on. Currently the specification says to discard. I personally think it would rubber against the specs if an implementor added an option: [X] Do not discard invalid DISCARDABLE mail. Mark it only. Possible, sure. But IMV go against the specs. At least it would be enabled by default. However, I can see that for the more ambiguous ALL policy: [_] Discard invalid ALL mail. Here it is off by default and invalid ALL mail is marked only. Here I think, the intentional ambiguous ALL policy leaves it open ended and allows for local policy to decide. No problem here. > It might say that invalid DISCARDABLE email "SHOULD" be treated in some > different way if accompanied by a signed A-R record as I have suggested. > > It might say that Listadmins "SHOULD" treat mail addressed to their list > just like any other recipient "SHOULD" treat it. > > It might say that Listadmins "SHOULD", as a special case, take actions > different from other recipients (whether by adding A-R records, or > something else). > > It might (or might not) make special recommendations for other forwarders, > such as acm.org. > > None of these possibilities is, a priori, preordained. None of them is > contrary to anything currently on the Standards Track. I agree with your overall notes, but I do think that the exception is that there is a clear MUST Discard for invalid discardable mail that is independent from any anything else. The main reason of course is that it must cover legacy transactions (mail without any additional and related DKIM DNA) > All of them are a proper subject of discussion, should this WG decide to > embark on such a BCP (and the misunderstandings repeatedly displayed here > seem to suggest that something of the sort is needed). IMV, the only issue is that it adds more complexity. IMV, before we can even come up with an algorithm, we need have some basic framework that is presumed everyone will follow or rather be consistent. IMV, unrestricted resigners conflicts with the very notion of what ADSP attempts to protect again. So there has to be a decision of resigners SHOULD|MUST follow it. Only then, IMV, can software developers and operators using scripts, or ACL, can create a consistent framework. Otherwise we will continue to see these debates and issues come up. Seriously, I am stuck. For our WCSMTP receiver, I can easily see where it can be optional. No Sweat. We will support it, but I can see where lack of support here is not going to break anything other than not help protect spoofed domains. But not when the mail is for our WCLISTSERVE and it has (re)signer features. Ignoring the idea that a domain has ADSP is problematic here. We could go ahead and just honor ADSP and be the only system that does so. I guess that would work. Heck, that might even be a marketing advantage! But it would surely be nice if there was a network "expectation" to play by the same rules so that domains can be protected at these other systems as well. == ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict
J.D. Falk wrote: > Charles Lindsey wrote: > >> All of them are a proper subject of discussion, should this WG decide to >> embark on such a BCP (and the misunderstandings repeatedly displayed here >> seem to suggest that something of the sort is needed). > > Agreed, except for one thing: until there's a larger set of users of ADSP, > no practice can be said to be common. > > A "considerations for use" document might help, though I'm not sure what it > could say that the RFC doesn't already cover. The issue is about codifying the existing but conflictive semantics to prevent problems and maybe even help to lay the ground for wider adoption across the board. One part says "THAT is possible." Another part says "THIS is possible." Whats missing in THIS is: "Oh by the way, if you do THIS, you need to maybe check THAT because THIS will break THAT and THAT will break THIS." That is all I am noting here and IMO, the "correction" will allow for wider consideration and new implementations to at least be consistent and please note, I am speaking of only about intermediaries. If that was agreed and added, at lease from this small lonely developer perspective, I will be comfortable, enabled our compiler directives "#define SUPPORT_DKIM", recompile and instantly offer DKIM/ADSP support in our next updates. At least few thousand operators will instantly have the feature offerings. I will be comfortable because when an ADSP standard violation happens by some other system, we can then pass the buck and throw the book at them. :) -- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict
On 10/15/2009 01:02 PM, J.D. Falk wrote: > Charles Lindsey wrote: > >> All of them are a proper subject of discussion, should this WG decide to >> embark on such a BCP (and the misunderstandings repeatedly displayed here >> seem to suggest that something of the sort is needed). > > Agreed, except for one thing: until there's a larger set of users of ADSP, > no practice can be said to be common. > > A "considerations for use" document might help, though I'm not sure what it > could say that the RFC doesn't already cover. Better would be what not to do/expect, and I think that the RFC is sort of skimpy on that point. That said, I doubt we could ever come to consensus. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict
Charles Lindsey wrote: > All of them are a proper subject of discussion, should this WG decide to > embark on such a BCP (and the misunderstandings repeatedly displayed here > seem to suggest that something of the sort is needed). Agreed, except for one thing: until there's a larger set of users of ADSP, no practice can be said to be common. A "considerations for use" document might help, though I'm not sure what it could say that the RFC doesn't already cover. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] brand protection, was Is anyone using ADSP?
>> No, ADSP adds the ability for senders to make unverified assertions >> about their signing practices. Unless you already have some >> knowledge about the domain, you have no idea whether it would be >> useful to believe it. >On the contrary, it adds the ability for domain owners to make those >asertions. Assuming that the domain owner has control of his own DNS >records, those assertions are as reliable as the reputation of the >relevant Domain Registrar (you can argue about how reliable that is, >if you wish). Huh? Maybe things are different where you live, but in this part of the world, registrars like Godaddy have millions of customers and know nothing more about them than that their credit card charge for $8 was approved. It's hard to imagine how anyone could think that a registrar would know anything at all about its customers mailing practices. To put it concretely, your registrar is JANET, which is a fairly reputable organization. Are you claiming that means that ADSP published by random ac.uk subdomains are all going to be accurate and useful? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict
On Wed, 14 Oct 2009 13:31:48 +0100, hector
wrote:
> Charles Lindsey wrote:
>
>>> But what [if] its not there?DKIM=DISCARDABLE provides a Domain
>>> Policy that mail must be signed and valid.
>>
>> If a valid signature is absent, then indeed the listadmin should discard
>> it (maybe even with 'ALL'). But the case of most interest is when the
>> message arrives with a valid signature. In that case, the listadmin
>> should
>> do his best to forward it, but what does he do if the list policy is to
>> munge? That is what we are discussing.
>>
>> So he adds Authentication-Results and signs it. At least then the final
>> recipient can see that and decide to ignore the failure of the original
>> signature ("DISCARDABLE" or not), assuming he trusts the listadmin.
>
>
> It was decided in all the documents that have the semantics, and its
> there if you check it, that the ANCHOR for policy is the 5322.From
> domain.
>
> IOW, we can't use a random AR header that can be forged for this. The
> From: is a traditional header that MUST be there and it represents the
> traditional constitution for the Authorship and Original Domain.
The reliability, or forgeabbility of what I am proposing is a matter we
can indeed discuss. But I would claim it is at least better than doing
nothing about this issue.
>
>> But if the final recipient sees that there was NO valid original
>> signature
>> (nor any Authentication-Results in that case), then he should of course
>> Discard it (even if the original listadmin had not).
>
> The issue at hand as a I posted, is whether a intermediary
> (signer/resigner) which technically is also a receiver as well,
> SHOULD|MUST also follows the same rules all receivers is expected to do.
There is no SHOULD|MUST about what recipients do. At most, it is a matter
of Best Common Practice, which this WG might well choose to incorporate in
a BCP RFC. But what would such a BCP document say?
It might say that all invalid DISCARDABLE email "SHOULD" be discarded.
It might say that all invalid DISCARDABLE email "SHOULD" be marked as such
and sent on.
It might say that invalid DISCARDABLE email "SHOULD" be treated in some
different way if accompanied by a signed A-R record as I have suggested.
It might say that Listadmins "SHOULD" treat mail addressed to their list
just like any other recipient "SHOULD" treat it.
It might say that Listadmins "SHOULD", as a special case, take actions
different from other recipients (whether by adding A-R records, or
something else).
It might (or might not) make special recommendations for other forwarders,
such as acm.org.
None of these possibilities is, a priori, preordained. None of them is
contrary to anything currently on the Standards Track.
All of them are a proper subject of discussion, should this WG decide to
embark on such a BCP (and the misunderstandings repeatedly displayed here
seem to suggest that something of the sort is needed).
--
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Assessing Policy Vs Reputation Assertions
Charles Lindsey wrote: > On Wed, 14 Oct 2009 14:27:01 +0100, John R. Levine wrote: >> No, ADSP adds the ability for senders to make unverified assertions >> about their signing practices. Unless you already have some >> knowledge about the domain, you have no idea whether it would be >> useful to believe it. > > On the contrary, it adds the ability for domain owners to make those > assertions. Assuming that the domain owner has control of his own DNS > records, those assertions are as reliable as the reputation of the > relevant Domain Registrar (you can argue about how reliable that is, if > you wish). +1. I sounds like everyone is saying the same thing in different ways. I like to view it as a failure to detect a positive assertion. For Policy, the classic "Expect Only Signatures From Me" and you don't see one as the same as some Reputation concept that says "Mail Signed by Acme.Com can be trusted" but you also don't see that signature. In both cases, its failure detection of Policy and/or Reputation assertions. -- Hector Santos, CTO http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] brand protection, was Is anyone using ADSP?
On Wed, 14 Oct 2009 14:27:01 +0100, John R. Levine wrote: >> OK. What ADSP adds is the ability to assign reputation to a specific >> email >> claiming to originate from a specific domain. Except for "unknown". > > No, ADSP adds the ability for senders to make unverified assertions about > their signing practices. Unless you already have some knowledge about > the > domain, you have no idea whether it would be useful to believe it. On the contrary, it adds the ability for domain owners to make those asertions. Assuming that the domain owner has control of his own DNS records, those assertions are as reliable as the reputation of the relevant Domain Registrar (you can argue about how reliable that is, if you wish). -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict
On Tuesday 13 October 2009 20:54:40 Charles Lindsey wrote: > On Tue, 13 Oct 2009 02:24:56 +0100, hector > > wrote: > > The deployment guide section 6.5 writes: > > > >Any forwarder that modifies messages in ways that will break > >preexisting DKIM signatures SHOULD always sign its forwarded > >messages. > > But it should in addition say that it SHOULD also add an > Authentication-Results header for the signature it is about to break AND > include that A-R header within what it then signs. That will provide much > more information to the ultimate recipient. This is good. > > Before any forwarder attempts to modifies messages and add > > a new signature to the message, it SHOULD look at the > > ADSP record for the 5322.From domain. If the domain has > > an ADSP record with "dkim=all" or "dkim=discardable", the > > forwards SHOULD NOT forward the message. > > No, I think that would lose too much genuinely wanted mail. I'm not convinced there would be much genuinely wanted email in this case. I believe there are sufficient mailing lists out there that break DKIM signatures sufficient for the DKIM WG to consider them fully the DKIM standardization suite. My quick assertion is: "The input to these mailing lists is, in every sane case that I can think of, direct from the author." THE INSANE CHAIN of MAIL LISTS The insane case I can recall is (with names anonymised): A group of server administrators of a software mirror site maintained a mailman list with all their email addresses as a subscribers. They got convinced to mirror a linux distribution on their mirror. This linux distro had another email list for communicating amongst mirror admins. Our group of server admins subscribed their mailing list address to the mailing list for mirror admins. The impact of this was a mirror admin would email to the mirror admin list. This would distribute an email to our group of server admins via their list. Our server admin list would reject the email back to the mirror list saying "please confirm email" and this email was sent to every mirror admin. The end result was our group of server admins was force-ably unsubscribed from the mirror list and told to subscribe sensibly (sanely). What has this got to do with DKIM? well it highlights that chaining email lists that require subscribers or email confirmation won't work because they don't share common subscribers. These are the kind of email lists that break DKIM signatures. The current in-operability of chained email lists make this already a rare (and insane) configuration. The world of spam was made the "require subscribers or email confirmation" a common type of DKIM signature breaking email list. Had the server admin list been a simple alias expander then there would of been no problem. As Dave has already said further down this thread, alias expanders aren't a problem with DKIM and the same applies here. PLEA: if ANYONE has a reason why a email forwarder that breaks DKIM signatures would receive a broken DKIM signature in a fairly common case please share this now! ALTERNATE: If there are cases here, or perhaps if we just want to be more liberal, then perhaps email forwarders need to see if there is any Third Party authorizations from the Author Domain delegating authority to a third party to sign on their behalf (don't look at Doug's draft yet - an updated one will be coming out soon). SUPPORT +1 Short of a quantification from the words above if needed, I'm totally in support of Hector's proposal to reduce the conflict in the deployment guide, and encourage forwarders that break signatures to consider the Author Domain's wishes up front (in not forwarding broken signatures when ADSP=ALL/DISCARDABLE), as they are unlikely to receive a valid message with a broken signature. Daniel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
