We have considered running dmarc checks on outbound to know if a message will likely be rejected. We also considered it for the custom from setting for Gmail before we decided that dmarc settings could change after setup.
It would make sense for an esp to check the sending configs for a customer against dmarc and warn the customer about it. You can't catch forwards and such, but you can know when the domain requires certain steps. As to the other part of this thread, blocking dmarc at smtp time is of course what you should do, but it's not always feasible. And even if you do block at smtp time, in forwarding situations you're just making someone else generate the backscatter... and internal forwarding that might be you again. And of course, those bounces going to a mailing list just cause havoc for some list providers, either greatly increasing bounce processing or if they don't handle bounces right, unsubscribing a bunch of folks, which is maybe worse... Ie, of course we made Google groups handle that correctly and of course we have ample capacity for bounces, but manu of the rejects Gmail does aren't to groups especially given groups also munges the header from. Damned if you do, damned if you don't. Brandon On Thu, Nov 21, 2019, 9:30 AM Luke via mailop <mailop@mailop.org> wrote: > There was nothing particularly useful or novel contained in the responses. > But as an ESP, we had no way of monitoring or tracking our senders' DMARC > reports. Heck, we had quite a few senders who had quarantine or reject > policies with no RUA or RUF addresses specified which is clearly there > problem and not anyone else's but I thought I'd throw it out there. > > So with DMARC, there are a lot of ways you can shoot yourself in the foot. > Domain alignment is probably the most common. For people who spend their > days monitoring a mailing list devoted to operating mail systems, this > probably seems like a laughably trivial thing to navigate. Well, it isn't. > > There are a number of seemingly innocuous settings one can mess with in > their ESP that can cause issues with domain alignment or even cause > authentication failures. These settings generally have no safeguards. If > someone has a DMARC policy at reject, and they mess with these settings in > such a way that it causes failures, having the bounce indicate as much is > extremely helpful not just for the sender, but for the ESP who will > inevitably help troubleshoot the issue. Few senders are going to go right > to their DMARC data when their open rates start to decline. Few ESP > support/deliverability teams have access to their user's DMARC data. Fewer > still are going to ask for a screenshot from the client's DMARC analytics > tool to ensure non-compliant mail isn't increasing. > > The bounces help a great deal. In many cases, you can set alerts to tell > you if bounces increase. In most cases you can review bounce codes and > response strings. In most cases, you can easily check for trends and > anomalies in bounces. > > I'm really not trying to make some virtuous stand saying mailbox providers > *must > *send bounces for DMARC failures. The problem isn't that big and people > eventually figure it out. I'm just saying that the DMARC failure bounces > that come back from the few providers who send them are quite helpful. > > Luke > > On Thu, Nov 21, 2019 at 9:42 AM Andrew C Aitchison <and...@aitchison.me.uk> > wrote: > >> >> For an ESP, did the DMARC rejects contains information not available >> elsewhere, or "just" put several relevant pieces of information in one >> place ? >> >> On Thu, 21 Nov 2019, Luke via mailop wrote: >> >> > DMARC rejects had great utility in my time working at an ESP. They would >> > have little or no utility for forwarded messages. It would be >> interesting >> > to see the spread of DMARC rejects for forwarded versus non forwarded >> > messages. Although it wouldn't change the fact that the responses are >> > indeed useful to many significant parties. >> > >> > On Thu, Nov 21, 2019, 7:02 AM Steve Atkins via mailop < >> mailop@mailop.org> >> > wrote: >> > >> >> >> >> On 21/11/2019 13:10, Luke via mailop wrote: >> >> >> >> ???? >> >> >> >> One of the features of email is that it you can send responses back >> about >> >> the status or handling of a message. Here's one such response from a >> gmail >> >> server: >> >> >> >> *550 5.7.1 Unauthenticated email from domain.tld is not accepted due to >> >> domain's DMARC policy. Please contact administrator of domain.tld >> domain if >> >> this was a legitimate mail.* >> >> >> >> Matt is right. Bounces like this tend to get peoples' attention and it >> is >> >> worth doing. Curious to learn more about what Rathbun said about not >> being >> >> able to accomplish this at scale. The challenges involved in that are >> >> beyond me but it does seem like Google is doing it. >> >> >> >> The most common case for DMARC declining to accept legitimate messages >> are >> >> because they've been forwarded (e.g. the tampering with the From: >> header on >> >> this mailing list is an attempt at mitigation of one situation where >> that >> >> happens). >> >> >> >> Where do you think that 5xx message will be seen in the case of normal >> >> email forwarding? Do you expect it to be converted by them to an >> >> asynchronous bounce? Where do you expect that bounce to be delivered? >> Do >> >> you expect it to be seen by humans? By automation? >> >> >> >> Cheers, >> >> Steve >> >> >> >> >> >> >> >> Oh...And I'm certain Google also sent a DMARC report :P >> >> >> >> >> >> On Thu, Nov 21, 2019 at 4:34 AM Andrew C Aitchison via mailop < >> >> mailop@mailop.org> wrote: >> >> >> >>> On Wed, 20 Nov 2019, Matt Vernhout via mailop wrote: >> >>> >> >>>> If a sender asked you to reject that mail with their policy do them >> >>>> a favour and send a bounce that says something like ‘your DMARC >> said >> >>>> to bounce failed messages, if this is wrong fix your authentication >> >>>> and try again’ >> >>> >> >>> ???? >> >>> >> >>> One of the features of DMARC is that it provides URLs for >> >>> reporting failed messages. >> >>> >> >>>> Bounces like this tend to get people attention. >> >>> >> >>> -- >> >>> Andrew C. Aitchison Kendal, UK >> >>> and...@aitchison.me.uk >> >>> _______________________________________________ >> >>> mailop mailing list >> >>> mailop@mailop.org >> >>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >>> >> >> >> >> _______________________________________________ >> >> mailop mailing listmailop@mailop.orghttps:// >> chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> >> >> _______________________________________________ >> >> mailop mailing list >> >> mailop@mailop.org >> >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> >> > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
