----- Original Message ----- > From: "Murray S. Kucherawy" <superu...@gmail.com> > To: "Dave Crocker" <dcroc...@bbiw.net> > Cc: dmarc@ietf.org > Sent: Wednesday, December 24, 2014 7:50:16 AM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker < d...@dcrocker.net > wrote: > > > I disagree. DMARC operators all seem to apply this practice, so it's > > > > correct to say that if you play this game, you reject mail from > > > > non-existent domains. Essentially in this way DMARC is a profile of > > > > RFC5321/RFC5322, which is perfectly acceptable. We are not updating > > > > those standards here, merely profiling them. > > > The fact that its use happens to correlate with DMARC use is a > > > distraction. For example, there are plenty of operators who use apply > > > this check but do not use DMARC. If the test is documented in a > > > specification, it should be in /one/ specification. Putting it into the > > > DMARC spec means it has to be documented somewhere else, for the folk > > > who don't use DMARC. > > This paragraph appears in the DMARC spec because the operators participating > all agreed that it should be part-and-parcel of this operating profile of > email. It's not as happenstance as this sounds so far; the very thrust of > DMARC is to make the From: content believable, and permitting a nonexistent > domain name to make it to the inbox contradicts that goal. All of this I feel strongly is part of "security considerations", even if they may be not in that chapter. What is the use of doing DMARC, if you allow weak input and vulnerabilities?
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
