On Friday, June 06, 2014 10:49 AM [GMT+1=CET], Vlatko Salaj wrote: > On Friday, June 6, 2014 3:55 AM, J. Gomez <[email protected]> wrote: > > > > When you said "i have trust in ymail to send email on behalf of my > > domain", were you meaning that you wanted ymail using your domain > > in the MAIL-FROM envelope (1), or in the Header-From field (2)? > > (1) no. > (2) yes. > > > > If (1), that would be something unreasonable to expect from ymail, > > and please explain why would you need it. > > yes, as i said, no one expects such a broken behavior, so i don't. > > > > If (2), please explain whether ymail allows it or not, > > it does. > > > > and if not please explain why would that be a DMARC limitation > > instead > > of a ymail limitation. > > well, since it does support it, i guess there's nothing to answer > here, but let me make as plain as possible example: > > === > FROM header: [email protected] > MAIL-FROM envelope: [email protected] > DKIM domain: yahoo.com > === > > results: > 1. mail legitimate; validated by sending ESP using: > 2. valid DKIM @yahoo.com, > 3. servers validated by SPF at yahoo.com, > 4. goodone.tk SPF records r of no importance here, > 5. DMARC is unable to authenticate this email: no 3rd party support.
I think DMARC would be able to authenticate that email as long as GOODONE.TK included in his SPF record the SPF record of YAHOO.COM. In that case, DMARC checking for DKIM would fail, but DMARC checking for SPF would find that the Header-From domain is aligned with SPF, therefore the net result would be a DMARC pass. If the particular SPF record of YAHOO.COM does not lend itself to be SPF-included with third parties (as it uses the "redirect" mechanism), that is not a SPF problem nor a DMARC problem, instead it is a YAHOO.COM problem and an implicit declaration from YAHOO.COM that your use case does not fit with them (but if you don't have your own MTA, then again your use case could indeed fit with YAHOO.COM). > > Please, explain with more detail how is your usage > > scenario excluded by DMARC. I fail to see how, as > > described by you up to now, is your usage sceneario > > impeded by DMARC instead of by ymail/whatever, given > > that DMARC leverages SPF and SPF has the concept > > of includes available to you. > > i hope u understand now. if not, i won't be able to > provide more str8-forward examples of this scenario, > cause i'm not able to specify it more clearly than this. I don't understand why you say DMARC impedes your described use case, as I keep seeing that a simple SPF-include in your own SPF record --which you control yourself-- would make your use case DMARC-compliant. > > i hope others understand my example. I hope so too, so that I can be enlightened about why am I wrong. Regards, J.Gomez _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
