On Wed, Jan 5, 2022 at 10:49 AM Alessandro Vesely <ves...@tana.it> wrote:
> On Wed 05/Jan/2022 00:32:57 +0100 Brandon Long wrote: > > > I didn't see anyone address the original problem here much, so here > > are some details about this. > > > Thanks! > > > > There is the dmarc address that Google itself uses, > > dmarc-nore...@google.com <mailto:dmarc-nore...@google.com>, it > > sometimes has the same rejections. I haven't checked recently, but > > wouldn't surprise me. Indeed, the problem occurs at midnight in the > > most popular time zones, more in the various US ones than in Europe. > > Jittering your sends to not be on the hour is a good idea for everyone > > sending dmarc reports. > > > Actually there is a random sleep at the beginning. The short time it > delays should be enough to avoid hardware problems, especially at > major computer centers. > I don't know the state now, but 2.5x the average load of the Gmail receive pipeline on the hour, and 1.5x on the half hour was not uncommon, and was over 5-10 minutes. Peaks for individual accounts for individual things are much higher, and backoffs take their time to go through as well. > For non-Google dmarc report addresses hosted at Gmail/Workspace, it > > would be wise for the owners of those accounts to see the limits: > > https://support.google.com/a/answer/1366776?hl=en&ref_topic=28609 > > > > the main one being that Gmail accounts only accept about 1 > > message/second because they are not designed to be dumping grounds for > > automated mail. An internal FAQ stated that email is not a logging > > service, and it's a very poor alerting destination as well. > > Hmm... automated mail exists, and SMTP transport for logging and > alerting is widely used. That internal FAQ must obviously be talking > about Gmail accounts, not email services in general. I'm not clear > what is the market strategy that led to those limitations, but my > feeling is that Google should explain it more loudly, because people > seem to choose Gmail as a robust general-purpose email hub. > widely used doesn't mean good practice or fit for purpose. The point of the internal FAQ was so that internal users choose tools that were more fit for purpose. https://sre.google/sre-book/monitoring-distributed-systems/#id-LvQuvtYS7UvI8h4 Supporting higher volumes is certainly just a matter of engineering and cost, but engineering is a matter of trade offs. Most logging systems don't expend relatively large amounts of non-useful analysis on logging (spam/virus/phishing/smarts/updating search indexes on a per-entry basis). They also wouldn't likely wouldn't provide only unstructured text search over the corpus or lack of input to purpose built analysis pipelines. > The limits are implemented with allowances for bursts, and the > > distributed nature of the system means the limits are not perfectly > > enforced. It also has the classic problems of trying to impose a > > limit on a multi-hop system, so the name of the game is flow > > control... but that does lead to blocking messages that we could > > queue internally and deliver later. > > Not perfectly indeed. Mailinblue seems to work as one of those third > party services for analyzing dmarc reports. On that December day I > had just two domains to report at their address; if they have hundreds > of domains receiving a dozen reports each, that would still be below > 3600 messages in an hour. And, in addition to the random sleep, I > delay reporting by an hour (to account for DST). The log quoted below > shows attempts at 0142, 0147, 0152, 0222, 0227 and 0232 (UCT) for a > final 550. > I'm unclear how you expect your volume to them to be representative of the volume they are receiving. Those times do indicate that they are overloaded for a long time. I don't know what they are doing, why they are doing it, or whether they are aware of having mail blocked. Certainly the data is available in the Workspace mail logs. > It also pushes back on the servers sending to the accounts... which > > sometimes is problematic (some servers will delay the entire queue > > to the domain or domains at the IP) but has other benefits as > > well... not to mention, less chances of bouncing, since I'm sure > > anyone sending us 20qps of mail wouldn't really want us to send > > them 20qps of bounces delayed by 3 days. > > That sounds like some kind of greylisting... If delaying the entire > queue is a problem, the purpose must be to delay must be aimed at > specific mailboxes. By the time they've been selected, their > deliverability should have been sorted out as well, no? > You misunderstand, we treat the mailboxes individually, some mail servers treat 4xx results as a reason to delay their entire queue for our server, or they are too insistent on FIFO for their queue and it results in head of line blocking. Also, do you know if you'll accept a message at RCPT TO? Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
