On Thu, Jan 6, 2022 at 5:55 AM Alessandro Vesely <[email protected]> wrote:
> On Wed 05/Jan/2022 21:25:35 +0100 Brandon Long wrote: > > On Wed, Jan 5, 2022 at 10:49 AM Alessandro Vesely <[email protected]> > wrote: > >> On Wed 05/Jan/2022 00:32:57 +0100 Brandon Long wrote: > >> > >>> There is the dmarc address that Google itself uses, > >>> [email protected] <mailto:[email protected]>, 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. > For a different question, if google has proper methods and checks to > receive DMARC reports, why doesn't it deploy them for hosted domains > too? There could be a dmarc-rua check box, for example. > I don't think accepting reports is all that useful by itself, it's the UI for displaying them and the intelligence you can bring to bear about the particular rejects. I guess it could fit into the Workspace Security Center, but I have no idea if they've considered it... they probably have a long list of ideas. https://workspace.google.com/products/admin/security-center/ > >>> 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. > > > Logging to port 514 is faster than sending email. However, it doesn't > have a way to answer 550 to OT or badly formatted messages. > Not having a way to express failure is certainly a choice, though I guess those failures would have to be reported and collected anyways, so that just changes where the failure monitoring data is pulled from (client or server). > Supporting higher volumes is certainly just a matter of engineering > > and cost, but engineering is a matter of trade offs. > > ... that's the trade off I'd be curious to understand. > > > >> [...] 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. > > Either they're constantly overloaded for hours, which my volume to > them makes me consider unlikely, or there is a crack whereby a lone > message in the night is rejected. BTW, I get a handful or two of > 450-4.2.1 ReceivingRate's every day, but on the odd day not even one. > Yet I send about the same amount of reports every day (about just > one hundred). How come? > it may correlate with spam campaigns that try to impersonate their clients, or badly set up clients or particular email campaigns that they send out. The rate of dmarc reports for a domain depends on how many individual systems they send mail to, with a secondary potential correlation to the volume to that system if it's enough to cause the reports to split across messages. > Also, do you know if you'll accept a message at RCPT TO? > > Almost always, at mine. Messages that have to be bounced after SMTP > acceptance block the mailbox for a couple of hours, to avoid (more) > backscatter. Otherwise, between RCPT and the end of data there's only > DKIM/ DMARC authentication, which contributes only a minor part of the > overall accept/ reject decisions. We reject probably 50-90% of messages at smtp time, and the lower end of that is after message content, and that's just for spam. Workspace customers can also add their own content based rejections. AV/malware is only possible with content. Brandon
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
