On Wed, Apr 16, 2014 at 10:50 PM, Vlatko Salaj <[email protected]>wrote:
> > One way of viewing DMARC is that it seeks to allow a domain owner to have > > better control of how its domain is used, so I don't know what this would > > accomplish. If alignment is optional, what does DMARC do policy-wise that > > DKIM and SPF don't already do? > > let me ask u: how exactly r u allowing a domain owner to have better > control > of how its domain is used, when u do not allow it to say: i do not want > alignment? i imagine, domain owners may actually prefer to send their email > through 3rd party infrastructure. DMARC has no provisions for such > practice. > "I do not want alignment" is exactly the same as "I don't use DMARC" since DMARC is pretty much all about alignment. So, again, I don't understand why that's a useful thing to add. > and it's a common practice, absolutely. whether it's formal or informal. > What's an example? >> include an option in dmarc dns policy, so that domain owners could turn > >> dmarc processing logic either to OR or AND. > > That might be useful, but isn't that more restrictive, and not less > > restrictive? > > as i said: combined, alignment OFF and AND processing logic would work > great > in cases where alignment isn't possible, yet email is fully legitimate. > and in such case, considering alignment requirement is gone, it's actually > less restrictive, while still providing better authentication. and blah > blah, > u can see the benefit, i'm sure. > For the "off" case, isn't that just the same as "p=none"? For the "and" case, yes, that's possible to add if there's enough demand to add it. So far the people that have tried this are satisfied with the "or" logic. What do others think? > also, it should be strict AND, meaning, all dmarc mechanism must exist and > pass, for DMARC to pass, making such DMARC evaluation almost as reliable as > alignment-based one, if not more, while still encompassing much wider > range of > email usage cases, in situation where it works better than alignment-based > one. > Sure, if that's what the community wants to do. This is the first time I've heard anyone say this would be a useful thing to support. If anyone else agrees that it's needed, DMARC can easily be extended to include this capability. It's built that way. > also, there may be other algorithms in the future which will become part of > DMARC. allowing domain owners to have control of how these get evaluated is > a right thing to do. my proposal is even stronger if u consider that some > of > these algorithms may get exploited in the future, which would completely > annihilate OR-based DMARC, with no remedy. having AND-based option would > fix > that in advance. > Yes, that extensibility is already built into DMARC. > > How would it help your use case, for example? > > it would do wonders for me. my personal email stream would pass DMARC. > By turning off alignment, I bet it would. > DMARC policy "reject", alignment OFF, logic AND, reporting ON and "fo=d:s" > would actually fix many of customer domains that i service, which use > google > or yahoo mail for their domain-based email. considering both google and > yahoo > use DKIM and SPF, those emails would pass such DMARC, even thought they are > being sent through 3rd party services. and if DKIM and SPF get supported by > other services, it would cover them too. > What would that look like, exactly? From: your domain, a passing DKIM signature for a domain other than yours, a passing SPF test for a domain other than yours? If that's what you mean, then I can make any message I want that passes DMARC for your domain by sending it from my own box and signing it. Are you sure you want that? If that's not what you mean, then you'll have to build an example, because I don't get it. > also, making alignment and logic selectable, would not make additional > pressure on big ESPs infrastructure, but it would cover much of failure > cases current version has. > Actually I think if you advertise something that is substantially weaker than what DMARC has now, I suspect ESPs will be less likely to trust your stream because it's basically unprotected. none rly taking the discussion to next lvl, but merely acknowledging i > mentioned SRS, and dismissing it without much ado. > That probably means the benefit of adding SRS support wasn't obvious to the people responding. This may be obvious to you, but it's apparently not obvious to others. also, i have another suggestion: > include sender-id as another DMARC supported check algorithm. > > sender-id is different enough from SPF to cover many usage scenarios, > and would just add to dmarc strengths. i don't rly understand why ppl take > sender-id for 2nd generation SPF, since it isn't. > > yeah, i better not start this topic... we don't want another MARID. > I totally agree there, especially since Sender-ID got almost no adoption (see RFC 6686), and that seems unlikely to change now. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
