1

We are sending a newsletter every day, where most of the recipients have their email address registered at one mail service specific for Czech Republic. There are more than 10 000 mails sent every day which results in the remote mail server thinking of us as spammers and temporarily bans our IP on which our postfix server resides for about 10 minutes. That leads to thousands of mails in mail queue.

Here is a snippet from the syslog:

.
.
.
Jan  9 18:02:22 mta-01 postfix/smtp[9919]: 020966007F: to=<xxxxxxx@seznam.cz>, relay=mx1.seznam.cz[77.75.76.42]:25, delay=1.1, delays=0.06/0/1/0.03, dsn=2.0.0, status=sent (250 2.0.0 Mail 844435625 queued for delivery in session 3ae60000018a.)
Jan  9 18:02:22 mta-01 postfix/smtp[9930]: D62D36008A: to=<xxxxxxx@email.cz>, relay=mx1.seznam.cz[77.75.76.42]:25, delay=1.3, delays=0.07/0/1.2/0.03, dsn=2.0.0, status=sent (250 2.0.0 Mail 837963363 queued for delivery in session 85260000002a.)
Jan  9 18:02:22 mta-01 postfix/smtp[9925]: 4745060085: to=<yyyyyyy@seznam.cz>, relay=mx1.seznam.cz[77.75.76.42]:25, delay=1.1, delays=0.07/0/1/0.02, dsn=2.0.0, status=sent (250 2.0.0 Mail 844631208 queued for delivery in session 79e2000001e5.)
Jan  9 18:02:22 mta-01 postfix/smtp[9935]: 663016001F: to=<zzzzzzz@seznam.cz>, relay=mx1.seznam.cz[77.75.76.42]:25, delay=1.1, delays=0.07/0/1/0.02, dsn=2.0.0, status=sent (250 2.0.0 Mail 844631209 queued for delivery in session e8b10000026d.)
Jan  9 18:02:23 mta-01 postfix/smtp[9932]: 1E73460071: to=<fffffff@seznam.cz>, relay=mx1.seznam.cz[77.75.76.42]:25, delay=1.1, delays=0.09/0/1/0.02, dsn=2.0.0, status=sent (250 2.0.0 Mail 845409306 queued for delivery in session 85260000002b.)

Jan  9 19:59:51 mta-01 postfix/smtp[16337]: DE5C560B42: to=<xxxxxx@seznam.cz>, relay=mx2.seznam.cz[77.75.78.32]:25, delay=5863, delays=5857/6.1/0.03/0, dsn=4.7.1, status=deferred (host mx2.seznam.cz[77.75.78.32] refused to talk to me: 421 4.7.1 You have been temporarily banned. Try again later or report to .)
.
.
.

The mails are eventually sent after few hours, but it would be nice to shorten this period so the recipients get the newsletter in a smaller time window.

As we were advised by the provider of the mail service, we should set our postfix server to send maximum amount of mails in one SMTP connection and do not open more than 150 connections in 5 minute intervals.

I tried to set some of the suggested directives in the main.cf postfix config file as advised in http://www.postfix.org/TUNING_README.html but with no luck. Here are some of them that I tried:

initial_destination_concurrency=100
default_destination_concurrency_limit=100
default_destination_recipient_limit=100
default_destination_rate_delay=1s
default_process_limit=200
smtp_mx_session_limit=100
smtpd_client_connection_count_limit=100
smtp_destination_concurrency_limit=100
maximal_backoff_time = 1000s
minimal_backoff_time = 300s
maximal_queue_lifetime = 6h
bounce_queue_lifetime = 6h
smtp_connection_cache_destinations = seznam.cz, vlp.cz, denik.cz, vlmedia.cz
smtp_connection_cache_on_demand = yes
smtp_connection_cache_time_limit = 10s
smtp_connection_reuse_count_limit = 100

Any advise would be helpful, thanks.

0

The Postfix shared connection cache cannot be used with TLS. To verify, that TLS is used, you can enable additional Postfix SMTP client logging of TLS activity:

smtp_tls_loglevel = 1

Then you should see log messages similar to this one:

postfix/smtp: Untrusted TLS connection established to mx1.seznam.cz

To reuse the connections, you need to enable SMTP connection cache (as you did) and disable TLS connections to seznam.cz:

smtp_connection_cache_destinations = seznam.cz
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

tls_policy:

seznam.cz   none

Then the connection to seznam.cz should be reused. To verify, you should see a message with conn_use in the log similar to this one:

postfix/smtp: 1B2B3B4B: to=<example@seznam.cz>, relay=mx1.seznam.cz[77.75.78.42]:25,
**conn_use=2**, delay=0.03, delays=0.01/0/0/0.02, dsn=2.0.0, status=sent
(250 2.0.0 Mail 123456 queued for delivery in session 2345678.)

Be aware that all outgoing emails to seznam.cz will then be unencrypted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.