Perhaps I'm missing something, but eliminating alignment essentially nullifies the authentication value for a given domain. If, for example, I disable alignment then I'm essentially saying that anyone can hijack/spoof/misappropriate my domain as long as they have a validspf record for the sending mta or DKIM sign their message.
Example. My domain is legitimatemail.com. I have a DMARC record that has set alignment to OFF. Someone, either known to me out not, now sends using the FROM address of legitimatemail.com but signs with d=badmail.com. It seems with the proposal below that would "pass" DMARC processing and be delivered (or at least not get rejected due to DMARC). I guess I fail to see how this works towards reducing/eliminating fraudulent email. -----Original Message----- From: Vlatko Salaj [[email protected]<mailto:[email protected]>] Sent: Thursday, April 17, 2014 01:50 AM Eastern Standard Time To: [email protected] Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals On Wednesday, April 16, 2014 11:39 PM, Murray S. Kucherawy wrote: > I wouldn't take the lack of answers terribly personally. i rly don't. i just found it rly lolable how everybody is whining about ietf's purpose here, while list's main aim is about technical contributions to the dmarc standard, which of, i saw none. >> include an option in dmarc dns policy, so that domain owners could turn >> dmarc alignment check on/off. > 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. and it's a common practice, absolutely. whether it's formal or informal. >> 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. 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. 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. > How would it help your use case, for example? it would do wonders for me. my personal email stream would pass DMARC. 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. 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. it may even be worthwhile for big ESPs to use this type of DMARC policy: "reject", alignment OFF, logic AND, reporting ON. it would surely make reports they receive much more informative too, helping with data mining on other domain practices, which could be used in anti-spam etc. and any potential abuse would simply be dealt with by switching to alignment ON policy, when it's required for a particular domain. >> i already mentioned including SRS in check logic. unfortunately, no dmarc >> author rly added much to the topic > I seem to remember there was in fact discussion of your SRS advocacy. none rly taking the discussion to next lvl, but merely acknowledging i mentioned SRS, and dismissing it without much ado. 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. -- Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
