On Fri 07/Jan/2022 19:56:33 +0100 Brandon Long wrote:
On Fri, Jan 7, 2022 at 1:40 AM Alessandro Vesely <ves...@tana.it> wrote:
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.
In a multi-hop system, you need flow control in order to push back on new
requests... but adding a queue means that pushback based flow control
would need to be based on the queue size, but having a world-wide
distributed queue makes keeping track of the queues for each individual
user very expensive... rate based flow control is an alternative, though it
also requires distributed global state... but that system is already needed
for a variety of other use cases.
The downstream shared resources are also complicated and may change
over time (consider primary/secondary fail-over or cell failures) or that a
user may be forwarding their mail to yet another account.
It's also much easier for customers to reason about an individual account limit
than shared limits... and also easier to know whether the system is failing
to handle the limits.
Having circuit breakers is also a good practice.
Fair enough. Thank you for a clear explanation.
Best
Ale
--
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
