again allow to block domains, not only mail domains

[stoecker]

This change takes the noreports file into account, but makes it clearer what exactly it blocks. Mails, Mail domains or domains. See also comment at #394

Also always having a @ in mail domains makes it clearer what is actually meant.

This change doesn't add the blocking of domains (not mail domains) in opendmarc.c. Probably easy, but I didn't find that when searching.

[thegushi]

I'll have a look. I think your docs changes were pretty clear as well, and I think at some point in the readme, we need to put together a "rate limiting" section that handles how reporting works.

One of the other things I'd like to make happen is: there's an RBL for places known to reject DMARC reports. If you're using dmarc-reports.pl to send forensic reports, there's also a table in the database (versus this static text file) that can be consulted.

So, two code paths: You're doing it the old-school opendmarc opens a pipe to sendmail thing, and this option is your only way. That's there for backwards compatiblity.

Or: You set ReportingCommand to /usr/local/wherever/opendmarc-reports.pl, and you get all the cool stuff with your forensic reports: verp, database-based backoff, lookup in the RBL, and it reads suppression data from both the DB and the plain text file. (Text file is easier for people to manage with things like puppet/ansible/change management tools, versus a line in a DB which is opaque to such things, that's why I want to support both).

Our options are complimentary (and why I was confused). Yours blocks things making it into the history file at all (most useful for exempting your own org's mail). Mine just suppresses the email (useful for when some dummy says "oh, I need to set this value? I'll just make something up").

But I think @-sign in general is a good idea, it matches the idea of what you'd expect in, say, a sendmail access map.

Give me a couple days on this one. It's been a busy week playing with code.