On Tue, Jun 10, 2014 at 9:19 AM, Hector Santos <[email protected]> wrote:
> >> The person on this list that actually represents a mailing list so far >> seems to like the idea, and has explained why to some extent. I think >> that's much more valuable feedback. >> > > More valuable than other feedback? > [...] > Feedback that shows insight and detail is useful. Feedback that says "Your idea won't work" without details explaining why is mostly useless, and thus easy to ignore. It doesn't matter to me who says it, it's quality of the comment that matters. > A proposal like this one might introduce new requirements, sure, but >> if they solve a huge problem and people are willing to implement it, >> then so what? They're worth the work in that case. >> > > We do need to extract them, talk about them, but there are certain ones > that simply do not apply -- they are show stoppers, a "waste of time," not > a "global common" with cooperative competition in mind among all parties. > I think we identified a few of these already. Yes indeed. > We need to have all the parameters available in the mail process > environment to see the entire framework in action with two-way reversible, > verification methods. The DKIM-Delegate suggestion is more complex when > it comes to code change, more complex than just doing a simple DNS lookup > and honoring the policies. When ignored, eventually problems occur as it > did happen now with higher volume impact players enabling the technology. > The problem was always there. LSP are just feeling the pains of their > early ignorance of the technology. > I don't agree that DNS is a cheaper solution than a handful of comparisons of strings you already have locally. > DKIM-Delegate establishes a requirement >> that mailing lists sign the modified message in full. >> > > Where would the requirement be established? Is it a policy lookup or just > the presences of the header signifies a higher level of expectations? > As it says in the draft, it's presence of the header field that matters. > This is a change for multiple mail software components so it needs to > justify why this change is better than just doing a DNS lookup and > processing the policy. In fact, one of the specific benefits of DKIM-Delegate over ATPS and TPA-Labels and any sort of whitelisting scheme is that there is no DNS lookup. > In a lot of cases, list software does that already; often it's >> the case that other software even does that for them, so how >> much of a burden is this really? >> > > I am not sure what you mean about this, detecting a list processed message? No. I'm saying MLMs already seem to sign the mail, either by doing it themselves or because outbound mail is automatically signed anyway. > > The burden is actually on signers (who need to add DKIM-Delegate >> fields) and on verifiers (who need to look for them and know what to >> do with them), not on the lists themselves. >> > > Right, a change is required. So why not just a lookup? A lookup > eliminates the need for additional complex mail header processing ideas. > It also introduces additional latency and you have to deal with timeouts. String comparisons are much cheaper. > > Do you believe DKIM-delegate reduces the need to do a lookup while still > satisfying all author domain related security requirements? Can bad guys > use the DKIM-Delegate to bypass non-list related mail in an attempt to show > a valid 3rd party signer? Or is DKIM-Delegate just a means to dynamically > scale authorized 3rd party signer? > > I am just wondering how do you verify it and avoid the fraudulent > facsimiles of such DKIM-Delegate stamped messages. > In order: Yes, that's what the proposal suggests. It might be right or wrong; that's what we need to determine somehow. Yes, that's a risk, and it's acknowledged in the draft already. The question is whether that risk is worth the gain. Yes. Nobody says the proposal is final as-is. Useful feedback is welcome. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
