tech-volunteer-meeting
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Google needs slow delivery


From: Bob Proulx
Subject: Google needs slow delivery
Date: Sat, 29 Oct 2022 13:17:30 -0600

Hi Ian,

I use Postfix so not sure how much of this will translate to Exim but
if I do not slow down delivery to Google then I get rejections from
Google.  Because even though Google accounts are a huge source of spam
to me Google also is very parsnickety about accepting mail.

Google is the worst of them for me.  Probably because so many people
use Gmail that it is the one I run into delivery problems the most.
But certainly Yahoo and especially Microsoft cause me other specific
pain.  But this is what I need to do for Google.

In /etc/postfix/master.cf where services are defined configure an
addtional Gmail specific service.  I use a custom logging name and
therefore override the logging name for this service.

    # Google rate limits incoming mail to the point of failure.
    # Use a Gmail specific transport which is slow.
    gmail unix - - y - - smtp
        -o syslog_name=postfix/gmail

In the main.cf file configure custom rate limits for this service.  In
Postfix the first part of the variable name matches the service name
and the later part of the name matches the custom variable configured
for that service.  So in this case gmail_destination_concurrency_limit
configures "gmail" for "gmail_destination_concurrency_limit" of 2.
And so on for the rest.

    gmail_destination_concurrency_limit = 2
    gmail_destination_rate_delay = 1s
    gmail_destination_recipient_limit = 2

The defaults from postfix upstream are these.

    default_destination_concurrency_limit = 20
    default_destination_rate_delay = 0s
    default_destination_recipient_limit = 50

Normally one might *increase* those in order to speed delivery.  But
with Google I have had to decrease those in order to slow delivery.
Otherwise if I send to three people that are all at gmail.com then I
get a reject notice.  It's totally insane.

In the /etc/postfix/transport map file define a mapping from
@gmail.com to this transport.  Run "postmap transport" to rebuild the
transport.db database file.

    # Google rate limits incoming mail to the point of failure.
    # Use a Gmail specific policy which is slow.
    gmail.com gmail

In Postfix most of the time restarting is not necessary.  If changing
the master.cf file a "postfix reload" is needed to instruct the
supervisor process that options have changed.  The rest is automatic.
Which is to say that for the most part Postfix can be continuously
running with no perceptable downtime most of the time.

Google appears to group delivery by domain name even if they are
handling multiple domains.  So this only seems to affect @gmail.com
addresses.  I have a friend with a custom domain that is handled by
Gmail through the standard MX records to go there directly.  There is
only one address there.  I never have reject problems with that
person's one email address.  *Even though the content of the message
is identical*.  Google will reject the three to @gmail.com and accept
the message to the other domain which is going to the same server.

I did not think up the above configuration myself.  I read about the
technique here and then implemented it.  The example is why I call
this the turtle transport.  The main link is dead now.  Shout-Out to
the Internet Archive!

    
https://web.archive.org/web/20130628013524/http://steam.io/2013/04/01/postfix-rate-limiting/

Here is the main Postfix documentation page.

    https://www.postfix.org/documentation.html

Just by way of kickstarting the documentation the overview is here.

    http://www.postfix.org/OVERVIEW.html

But for this topic probably the specific documentation is here.

    http://www.postfix.org/TUNING_README.html#rope

That last is the specific documentation on this topic.  But I wanted
to sneak up on it with the more general overview stuff first.  Since
otherwise it's learning to swim by jumping into the deep end.

Hope this helps!
Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]