Postscreen und Antispam-Service: Abgelehnte Verbindungen

[greystone]

Eine kleine Information:

Ich habe seit längerem bei unserem Postfix-Firmenmailserver postscreen konfiguriert. Das Problem, dass sich da nach und nach gezeigt bzw. verstärkt hat, ist, dass immer wieder Verbindungen abgelehnt werden. Die Folge davon ist, dass manche Mails erst mit mehreren / vielen Stunden Verzögerung ausgeliefert wurden, da der Spamdienstleister Mailserver, die nicht erreichbar sind, erst einmal pausiert, was soweit gängige Vorgehensweise ist.

Ich habe auch Auszüge des Exim-Logs unseres Antispamdienstleisters (Spamexperts) bekommen, die klar ein "Connection refused" gezeigt haben. Das kann ich so bei den Postfix-Logs und auch im Monitoring nicht nachvollziehen. Im Postfix-Log ist das ja ohnehin nicht, da ein Connection refused ja ein Verbindungsabbruch vor der Kommunikation mit postfix/postscreen stattfindet.

Ich habe den Verdacht, dass es am postscreen liegen könnte, da dieser ja als Einzelplrozess ausgelegt ist. Die notwendige Einstellung der Anzahl von Daemons in master.cf für postscreen ist 1. D. h. trotz der Tatsache, dass Postscreen sehr effizient und schnell ist, dass es dadurch trotzdem zu kurzen Unerreichbarkeitszeiten kommt.

Die IPs, die Postscreen laut Log abgelehnt hat, kamen allesamt nicht vom Antispamdienstleister.

Jetzt habe ich den Postscreen mal rausgenommen und es schien, dass das direkt Besserung gebracht hat. Postscreen mit mehr als einem Prozess zu betreiben funktioniert nicht.

Hier sind ja bestimmt einige, die auch postscreen nutzen. Sind solche Probleme nachvollziehbar?

 

[nexus]

Jetzt habe ich den Postscreen mal rausgenommen und es schien, dass das direkt Besserung gebracht hat.

Dann zeig doch mal deine Postscreen Konfiguration, damit man Anhaltspunkte finden kann...Kann ja im Prinzip nur eine nicht optimale Konfiguration sein, wenn es ansich funktioniert.

 

[greystone]

# dpkg -l postfix
ii  postfix        3.7.11-0+deb12u1 amd64        High-performance mail transport agent

/etc/postfix/main.cf

...
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites =
  list.dnswl.org=127.0.[0..255].0*-2
  list.dnswl.org=127.0.[0..255].1*-4
  list.dnswl.org=127.0.[0..255].2*-6
  list.dnswl.org=127.0.[0..255].3*-8
  bl.mailspike.net=127.0.0.2*10
  bl.mailspike.net=127.0.0.10*5
  bl.mailspike.net=127.0.0.11*4
  bl.mailspike.net=127.0.0.12*3
  bl.mailspike.net=127.0.0.13*2
  bl.mailspike.net=127.0.0.14*1
  wl.mailspike.net=127.0.0.16*-2
  wl.mailspike.net=127.0.0.17*-4
  wl.mailspike.net=127.0.0.18*-6
  wl.mailspike.net=127.0.0.19*-8
  wl.mailspike.net=127.0.0.20*-10
  bl.ipv6.spameatingmonkey.net*2
  bl.spameatingmonkey.net*2
  ix.dnsbl.manitu.net*2
  bl.spamcop.net*2
  db.wpbl.info*2
  psbl.surriel.com*2
  torexit.dan.me.uk*2
  tor.dan.me.uk*1
  safe.dnsbl.sorbs.net*1
postscreen_dnsbl_threshold = 5
postscreen_dnsbl_whitelist_threshold = 0
postscreen_greet_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes

...

# postconf -x | grep postscreen

postscreen_access_list = permit_mynetworks
postscreen_allowlist_interfaces = static:all
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_bare_newline_ttl = 30d
postscreen_cache_cleanup_interval = 12h
postscreen_cache_map = btree:/var/lib/postfix/postscreen_cache
postscreen_cache_retention_time = 7d
postscreen_client_connection_count_limit = 50
postscreen_command_count_limit = 20
postscreen_command_filter =
postscreen_command_time_limit = 300s
postscreen_denylist_action = ignore
postscreen_disable_vrfy_command = no
postscreen_discard_ehlo_keyword_address_maps =
postscreen_discard_ehlo_keywords =
postscreen_dnsbl_action = enforce
postscreen_dnsbl_allowlist_threshold = 0
postscreen_dnsbl_max_ttl = 1h
postscreen_dnsbl_min_ttl = 60s
postscreen_dnsbl_reply_map =
postscreen_dnsbl_threshold = 5
postscreen_dnsbl_timeout = 10s
postscreen_dnsbl_whitelist_threshold = 0
postscreen_enforce_tls = no
postscreen_expansion_filter = $smtpd_expansion_filter
postscreen_forbidden_commands = CONNECT GET POST regexp:{{/^[^A-Z]/ Bogus}}
postscreen_greet_action = enforce
postscreen_greet_banner = mailserver.domain.de ESMTP Postfix
postscreen_greet_ttl = 1d
postscreen_greet_wait = 6s
postscreen_helo_required = yes
postscreen_non_smtp_command_action = drop
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes
postscreen_pipelining_ttl = 30d
postscreen_post_queue_limit = 100
postscreen_pre_queue_limit = 100
postscreen_reject_footer = $smtpd_reject_footer
postscreen_reject_footer_maps =
postscreen_tls_security_level =
postscreen_upstream_proxy_protocol =
postscreen_upstream_proxy_timeout = 5s
postscreen_use_tls = yes
postscreen_watchdog_timeout = 10s
proxy_write_maps = btree:/var/lib/postfix/verify_cache btree:/var/lib/postfix/postscreen_cache

 

[greystone]

Ich habe jetzt mal dass da ...

postscreen_client_connection_count_limit = 50

auf 2000 gesetzt. Ich habe zwar keine Metriken für die Anzahl der SMTP-Verbindungen, aber ich habe welche für die Anzahl der TCP-Verbindungen und da gibt es einzelne Spitzen von ca. 500 WAIT-Verbindungen.

 

[Joe User]

safe.dnsbl.sorbs.net*1

Sorbs ist tot, bitte dringend entfernen.

 

[porthos]

Ich habe jetzt mal dass da ...

postscreen_client_connection_count_limit = 50

auf 2000 gesetzt. Ich habe zwar keine Metriken für die Anzahl der SMTP-Verbindungen, aber ich habe welche für die Anzahl der TCP-Verbindungen und da gibt es einzelne Spitzen von ca. 500 WAIT-Verbindungen.

Dies könnte evtl. helfen (defaultmässig hat es einen Wert von 32768):
echo 256 >/proc/sys/net/ipv4/tcp_max_tw_buckets

 

[greystone]

Ich habe postscreen abgeschaltet. Seit dem ist das Problem wieder weg.

Ansonsten steht der Wert tcp_max_tw_buckets bei dem System auf 8192. Wenn ich die Dokumentation zu dem Wert richtig verstehe, dann würde sich das Problem verschärfen, wenn ich den Wert so deutlich auf 256 reduziere.

 

[porthos]

Ich habe postscreen abgeschaltet. Seit dem ist das Problem wieder weg.

Ansonsten steht der Wert tcp_max_tw_buckets bei dem System auf 8192. Wenn ich die Dokumentation zu dem Wert richtig verstehe, dann würde sich das Problem verschärfen, wenn ich den Wert so deutlich auf 256 reduziere.

Also ich hatte ein ähnliches Problem mit vielen WAIT-Einträgen. Das o.g. hat das Problem gelöst. Jetzt kaum WAIT-Einträge; wenn, dann nur noch einige wenige WAITs, und das nur für kurze Zeit.
Dokumentation, Realität und Interpretation scheinen nicht übereinzustimmen, oder kurz gesagt: Logic-Error irgendwo