> This is the only one your having issues with? My queues are filled with
> dmarc@ and abuse@ report messages that finally timeout or get denied
> because the users don't exist, the mailbox is full, on and on and on. At
> first I would reach out to postmaster@ and other management addresses,
> but in a lot of cases those don't exist either, or the mailbox is full,
> or something else, on and on and on. So now I have a generic zone file
> that is _dmarc for the domain without an rua, and I point _dmarc.<domain
> name> to this file as authoritative so I don't send them anything since
> they don't want it.
I remember when rfc-ignorant.org solved some of these problems.
It's a shame that non-existent postmaster@ and abuse@ addresses are
non-existent on many systems nowadays, or generate an auto-response
explaining the user's eMail was filed into /dev/nul (and especially
those that also don't offer any alternative methods of contact).
We occasionally see "mailbox full" responses when sending out DMARC
reports too, and with some systems it seems to be sporadic or never
gets resolved (but we remain optimistic that someone will eventually
resolve the problem at some point).
> David
>
> --
> https://dprall.net
>
> On 5/17/2026 1:16 PM, Dan Mahoney via mailop wrote:
> > Hey folks,
> >
> > I'm doing a lot of work on cleaning up openDMARC's reporting (we've been
> > behind, I know, but with a DMARCbis RFC close to drop, the code needs some
> > love)
> >
> > Anyway I've seen some interesting misconfigurations -- to the point that
> > I'm both considering adding a backoff delay to the DMARC reporting scripts
> > (which would be triggered via a VERP-like tool), and also...surveying the
> > top 1M domains for obvious misconfigures (which wouldn't necessarily spot
> > this).
> >
> > With Big Mailbox now requiring DMARC, lots of people are going to various
> > dmarc record generators, pasting stuff in their DNS, and not following
> > through on the rest of the requirements.
> >
> > Here's one:
> >
> > * Wayfair (a big etailer who ostensibly sends lots of mail) has an rua
> > address. It's [email protected] <mailto:[email protected]>
> >
> > _dmarc.wayfair.com. 1800 IN TXT "v=DMARC1; p=quarantine;
> > rua=mailto:[email protected]; fo=1; pct=100; adkim=r; aspf=r"
> >
> > * They have proofpoint in front of their mailer:
> >
> > wayfair.com. 1800 IN MX 10
> > mxa-00180701.gslb.pphosted.com.
> > wayfair.com. 1800 IN MX 10
> > mxb-00180701.gslb.pphosted.com.
> >
> > * When I send reports to them, proofpoint accepts all the messages, and
> > internally routes it to...a gmail box. Not sure what you're doing with
> > those [wait for it], but there are LOTS of services you can put in your
> > RUA/RUF fields that can handle this for you and put it in a nice dashboard
> > and help you act on it. (Dmarcian, valimail, etc).
> >
> > But also:
> >
> > A) proofpoint is blasting the gmail box so hard that the backoff delay is
> > sending errors to me
> >
> > And B) proofpoint ignores google's 45x series error and continues trying to
> > send in the same SMTP connection so they also get 500-series errors.
> >
> > And C) Somewhere in this lunatic chain reports:
> >
> > 550 5.1.1 <[email protected]>... User unknown. So not only are wayfair
> > routing their reports to a gmail box, they're routing it to one they never
> > set up.
> >
> > (slow clap)
> >
> > Gmail (masters of "do weird black-boxy stuff") could totally detect DMARC
> > messages and exempt them from the filter, or perhaps query the _dmarc
> > records from their hosted zones and learn from this. Or maybe they could
> > have their FIRST MTA report user-unknown before it does all the
> > rate-limiting?
> >
> > And, bonus, I get longer reports because proofpoint tries all six of the
> > internal gmail mxes, with mixed 45X and 50X responses.
> >
> > ... while talking to alt1.aspmx.l.google.com.:
> >>>> DATA
> > <<< 450-4.2.1 The user you are trying to contact is receiving mail at a
> > rate that
> > <<< 450-4.2.1 prevents additional messages from being delivered. Please
> > resend your
> > <<< 450-4.2.1 message at a later time. If the user is able to receive mail
> > at that
> > <<< 450-4.2.1 time, your message will be delivered. For more information,
> > go to
> > <<< 450 4.2.1 https://support.google.com/mail/?p=ReceivingRate
> > 46e09a7af769-7e55b801ff8si5191570a34.44 - gsmtp
> > <[email protected]>... Deferred: 450-4.2.1 The user you are trying to
> > contact is receiving mail at a rate that
> > <<< 503-5.5.1 RCPT first. A mail transaction protocol command was issued
> > out of
> > <<< 503-5.5.1 sequence. For more information, go to
> > <<< 503-5.5.1 https://support.google.com/a/answer/3221692 and review RFC
> > 5321
> > <<< 503 5.5.1 specifications. 46e09a7af769-7e55b801ff8si5191570a34.44 -
> > gsmtp
> > ... while talking to alt2.aspmx.l.google.com.:
> >>>> DATA
> > <<< 450-4.2.1 The user you are trying to contact is receiving mail at a
> > rate that
> > <<< 450-4.2.1 prevents additional messages from being delivered. Please
> > resend your
> > <<< 450-4.2.1 message at a later time. If the user is able to receive mail
> > at that
> > <<< 450-4.2.1 time, your message will be delivered. For more information,
> > go to
> > <<< 450 4.2.1 https://support.google.com/mail/?p=ReceivingRate
> > 46e09a7af769-7e55bbdbd9csi5088545a34.77 - gsmtp
> > <[email protected]>... Deferred: 450-4.2.1 The user you are trying to
> > contact is receiving mail at a rate that
> > <<< 503-5.5.1 RCPT first. A mail transaction protocol command was issued
> > out of
> > <<< 503-5.5.1 sequence. For more information, go to
> > <<< 503-5.5.1 https://support.google.com/a/answer/3221692 and review RFC
> > 5321
> > <<< 503 5.5.1 specifications. 46e09a7af769-7e55bbdbd9csi5088545a34.77 -
> > gsmtp
> > ... while talking to alt3.aspmx.l.google.com.:
> >
> > Full email at https://www.gushi.org/ppemail.txt (will not persist forever).
> > Reach out to me if you need more debugging info.
> >
> >
> >
> >
> > _______________________________________________
> > mailop mailing list
> > [email protected]
> > https://list.mailop.org/listinfo/mailop
>
> _______________________________________________
> mailop mailing list
> [email protected]
> https://list.mailop.org/listinfo/mailop
--
Postmaster - [email protected]
Randolf Richardson, CNA - [email protected]
Inter-Corporate Computer & Network Services, Inc.
Vancouver, Beautiful British Columbia, Canada
https://www.inter-corporate.com/
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
