At one time I suggested adding a feature to list domains that could be considered "in alignment" with yours. So if a domain owner wanted to authorize an email service provider, they could just add something to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or DKIM signing. I am still curious what's wrong with this proposal. It seems to me to cover Vlatko Salaj's use case, and would certainly be easier to implement than arranging to share a DKIM key.
Regards, Joe Humphreys On Thu, Apr 17, 2014 at 7:42 AM, Popowycz, Alex <[email protected]>wrote: > 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]] > *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 > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
