Re: [dmarc-discuss] Get failure reports without actually rejecting messages?
Hi Jonathan, > After further research, I think this is because failure reports aren't > actually generated for p=none, i.e., they're only generated for p=reject. There is no such linkage. I see failure reports for domains that publish "p=none" all the time. However (unfortunately) I don't get them from from all DMARC-enabled receivers. Just as DMARC senders choose whether to deploy SPF, DKIM, or both, receivers decide individually whether or not to send failure reports. When you find somebody at a large mailbox provider who doesn't send them, who's willing and/or able to talk about it, the driver is usually liability concerns around whether or not you can send failure reports without running afoul of data/personal privacy laws in some or many jurisdictions where they operate. Speaking only for the small domains I operate, Hotmail appears to be the larges US-based mailbox provider sending failure reports - I received one from them just last week. Internationally, I'd say it's NetEase of China (notably 126.com and 163.com). However many small domain operators using the OpenDMARC milter seem to enable failure reports. > Unfortunately, the information we're getting from the aggregate > reports that various domains are sending us is not always sufficient > for us to figure out DMARC failures. Are you seeing failures for messages sent by servers you operate or authorize? Or is it more a question of identifying the various sources you don't already know about and figuring out why messages using your domain(s) are coming from them? I'm sure you can deal with the aggregate reports from a parsing perspective, but perhaps you could use some assistance with the interpretation of the data? There are a number of services listed on the resources pages at DMARC.org (link below). Most often I hear about folks starting with the free tier that dmarcian.com offers, but anybody on that list could provide assistance. >From comments in the reports, and from databases the report processors maintain, you can often get a clearer picture of traffic that's going through known forwarders or mailing list operators. (Such traffic might be expected to have authentication failures for assorted reasons you're probably already aware of.) --Steve. Products and Services: https://dmarc.org/resources/products-and-services/ ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Get failure reports without actually rejecting messages?
Hi Jonathan, Your thesis is incorrect: there is no connection between your specified policy and whether you'll receive failure reports. Very few receivers are willing to send failure reports so, in general, you won't receive them. There are some situations in which they are made available under NDA, but I'd suggest that that's generally only relevant for the largest senders in the world. This does mean that you have imperfect information available on the basis of which to decide whether to switch to p=(quarantine|reject). I would point out one useful detail which is relevant if your concern is corporate email (rather than bulk): because of the traditional handling of discussion lists (mailing lists in which subscribers may also post, like this one), some list providers will alter the From: header for messages from p=(quarantine|reject) domains, which means that p=none results will be slightly worse than they should be. To explore this, set "p=quarantine; pct=0". This is the same policy as p=none (because the 100% that fall back will fall back to none), but is enough to trigger the From: change in some cases, particularly Google Groups. - Roland On 12/07/17 10:45, Jonathan Kamens via dmarc-discuss wrote: We've recently started using DMARC for our domain, and we're doing our best to get everything passing before we switch from p=none to p=reject. Unfortunately, the information we're getting from the aggregate reports that various domains are sending us is not always sufficient for us to figure out DMARC failures. We thought we could address this by putting an "ruf" field into our DMARC record, but after doing that, we're still not getting any failure reports. After further research, I think this is because failure reports aren't actually generated for p=none, i.e., they're only generated for p=reject. Is that correct? If so, that seems like a real problem that I don't know how to get past. Here's the thing... I'm pretty sure most of the DMARC failures we're seeing are actually legitimate email messages, but like I said, we don't have enough information from the aggregate reports to be able to figure out why they're failing DMARC. There's a chicken-and-egg problem here: I can't get enough information to figure out what's going wrong with these emails until I enable p=reject, and because I don't want to bounce legitimate emails, I can't enable p=reject until I've figured out what's going wrong with these emails. So, what am I supposed to do? Also, another thing I'm confused about from reading the available information about DMARC is whether, once we enable p=reject, we'll get copies of /all/ messages that are rejected due to DMARC failures, or whether instead it's up to the discretion of each receiving MTA to decide whether to generate a failure report. If the former, then at least theoretically, we could enable p=reject briefly, collect some sample DMARC failure reports to troubleshoot, then disable p=reject, troubleshoot the failures, and forward them on to their intended recipients, so no email ends up getting lost. But if it's up to the discretion of the MTA whether to generate a bounce report, then even if we only enable p=reject for a short period of time, we could end up causing legitimate emails to be lost, and we'd really rather not have that happen. Thanks, Jonathan Kamens ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html) ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
[dmarc-discuss] Get failure reports without actually rejecting messages?
We've recently started using DMARC for our domain, and we're doing our best to get everything passing before we switch from p=none to p=reject. Unfortunately, the information we're getting from the aggregate reports that various domains are sending us is not always sufficient for us to figure out DMARC failures. We thought we could address this by putting an "ruf" field into our DMARC record, but after doing that, we're still not getting any failure reports. After further research, I think this is because failure reports aren't actually generated for p=none, i.e., they're only generated for p=reject. Is that correct? If so, that seems like a real problem that I don't know how to get past. Here's the thing... I'm pretty sure most of the DMARC failures we're seeing are actually legitimate email messages, but like I said, we don't have enough information from the aggregate reports to be able to figure out why they're failing DMARC. There's a chicken-and-egg problem here: I can't get enough information to figure out what's going wrong with these emails until I enable p=reject, and because I don't want to bounce legitimate emails, I can't enable p=reject until I've figured out what's going wrong with these emails. So, what am I supposed to do? Also, another thing I'm confused about from reading the available information about DMARC is whether, once we enable p=reject, we'll get copies of /all/ messages that are rejected due to DMARC failures, or whether instead it's up to the discretion of each receiving MTA to decide whether to generate a failure report. If the former, then at least theoretically, we could enable p=reject briefly, collect some sample DMARC failure reports to troubleshoot, then disable p=reject, troubleshoot the failures, and forward them on to their intended recipients, so no email ends up getting lost. But if it's up to the discretion of the MTA whether to generate a bounce report, then even if we only enable p=reject for a short period of time, we could end up causing legitimate emails to be lost, and we'd really rather not have that happen. Thanks, Jonathan Kamens ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
