On Sun, 12 Feb 2017 21:26:55 +0000 Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> > host -t txt _dmarc.artifact-software.com > > "v=DMARC1; pct=100; p=quarantine; adkim=r; aspf=r" > > > > And as this mail is sent by cloud9, opendmarc does what it is > > supposed to do. > > Say no to DMARC. Don't make the mistake of outsourcing your inbound > email policy to random strangers who either don't understand all > the ways in which DMARC is flawed, or don't care about collateral > damage. Ok, but it is the inbound email policy of only /their/ domain. Like SPF, it's the responsability of the owner of the domain, not the responsability of the receiver. If someone fscks up the settings of his/her domain, it's not my responsibility. If someone doesn't publish glue records in DNS or uses a DNS servers that give different responses, it's not my problem. > There are good reasons why RFC7489 is an "informational" rather > than a "standards track" RFC. Well Viktor, I'm eager to know these reasons :) For the moment I do not see any harm in applying DMARC, but I'd like to hear your objections. > While DMARC may reduce Yahoo's abuse > desk costs, we don't have to play along. Though DMARC may reject > some forged Yahoo email, there's still plenty of 419 email from > the real Yahoo. DMARC is *not* the ultimate solution to spam. Spammers know how it works and they will do their utmost to bypass filtering when they deliver their bullshit. I just don't want other people to misuse the domains I own. > DO NOT publish DMARC policy. That's the choice of the owner of the domain. And his/her responsability. > DO NOT check DMARC policy, except > perhaps as a small bump in a composite spam score. That's the choice of the receiver. And his/her resposabilty. If I ask you to reject mail from my domain dos.nl which is not signed and coming from an ip that is not in my -all SPF record, who am I to tell you not to accept the mail anyway? If you want it, go ahead, you're welcome! :) R. -- richard lucassen http://contact.xaq.nl/
