On Thu 06/Jan/2022 20:02:48 +0100 Brandon Long wrote:
On Thu, Jan 6, 2022 at 5:55 AM Alessandro Vesely <ves...@tana.it> wrote:
On Wed 05/Jan/2022 21:25:35 +0100 Brandon Long wrote:
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:
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.
That's one point I'd be curious to understand. If a server is on the
ropes, not accepting connections or replying 421 to EHLO would be
fair. Delaying the whole incoming queue from that server would be an
advantage, in that situation. Checking the rate of a given recipient
before delaying or rejecting must have a different reason; it's not
because the hardware doesn't support higher volumes...
There's a reverse proxy in front of our smtp servers which does
load balancing, and the connection itself can be retried on other
servers... but yes, sometimes the individual server rejects a
connection early for capacity issues, or at data content if the
message is large enough to put the server at memory risk
(obviously we try to reject earlier if they send a SIZE= or use
BDAT). The smtp servers are also recipient agnostic and stateless,
so any server will do. >
This isn't about the individual smtp server, it's about the
individual backend account and the shared resources that serve that
particular account. Fair sharing is always complicated.
Thanks for sharing, although that info doesn't clarify on what
principle are based the tactics to delay messages so that they don't
accumulate in a short interval of time, even when there are no
capacity issues.
Best
Ale
--
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
