From meinpapierkorb123 at gmail.com  Thu Oct 15 19:33:44 2020
From: meinpapierkorb123 at gmail.com (Mein Papierkorb)
Date: Thu, 15 Oct 2020 19:33:44 +0200
Subject: =?UTF-8?Q?Mailtransport_verz=c3=b6gert=3a_status=3ddeferred=2c_Conn?=
 =?UTF-8?Q?ection_timed_out?=
Message-ID: <bd4bfb2d-da44-b925-a896-cf2816d0f4b9@gmail.com>

Servus zusammen,

ich hatte am 1.9. schonmal an diese Liste geschrieben, worauf ich auch 
einige Antworten erhielt. Es war aber noch nichts problemlösendes dabei.

Nochmal von vorne:
Ich habe ein Debian stable mit Postfix, Dovecot, Bind relativ frisch am 
Laufen.
Vorher lief dieses Mailsetup auf einem veralteten Debian 7 mehrere Jahre 
einwandfrei.
Die Konfig-Dateien habe ich so ziemlich 1:1 übernommen und prinzipiell 
funktioniert auch alles.
Der MTA ist zudem auch ein ein- und ausgehender Relay-Server für einen 
Exchange-Server.

Das Problem ist nun, dass der Mailversand des Postfix häufig nur 
zeitverzögert stattfindet.
Zuerst habe ich das nur festgestellt, wenn Mails in die Welt 
hinausgeschickt wurden:
***
Oct 15 18:47:41 mail postfix/smtp[28570]: connect to 
mx01.emig.gmx.net[212.227.17.5]:25: Connection timed out
Oct 15 18:47:41 mail postfix/smtp[28570]: 6854D5C47D73: 
to=<xxx at gmx.net>, relay=none, delay=13065, delays=13003/1.8/60/0, 
dsn=4.4.1, status=deferred (connect to 
mx01.emig.gmx.net[212.227.17.5]:25: Connection timed out)
***

oder auch:

***
Oct 15 18:47:41 mail postfix/error[28607]: 2974C5C47FE2: 
to=<katharina58 at gmx.net>, relay=none, delay=13016, delays=12954/62/0/0, 
dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 
mx01.emig.gmx.net[212.227.17.5]:25: Connection timed out)
***


Gleiches stelle ich nun aber auch fest, wenn Mails eingehen und per 
Relay an den Exchange weitergeleitet werden sollen:
***
Oct 15 18:47:10 mail postfix/error[28477]: 4584B5C457C3: 
to=<bounce at exchangedomain>, relay=none, delay=13493, 
delays=13462/31/0/0, dsn=4.4.1, status=deferred (delivery temporarily 
suspended: connect to exchangeserver[ipv4]:25: Connection timed out)
***

Über ein Postfach des angebundenen Exchange-Servers wird gelegentlich 
(alle paar Wochen) ein Newsletter an mehrere tausend Empfänger versendet.
Dann treten diese Probleme massiv auf. Betroffen sind alle möglichen 
Domains: gmx.de, web.de, unitybox, t-online usw.
Aktuell sind ca 10.000 Mails in der Warteschlange, welche sehr langsam 
abgearbeitet wird (ganz grob 20 Mails pro Minute).
Irgendwo scheint es also einen Flaschenhals zu geben.

Diese Probleme stelle ich erst fest, seitdem ich den Mailserver 
umgezogen habe.
Ich wüsste nicht, was ich an der konfig verändert hätte, was Probleme 
dieser Art verursachen könnte.
Würden die Mails komplett abgelehnt und gar nicht versendet, dann würde 
ich das ja verstehen und einen Konfigurationsfehler ermitteln.
Aber die Mails werden ja transportiert - nur eben mit starker Verzögerung.
Ausgelastet ist der Mailserver mal so gar nicht, Ressourcen sind in 
jeder Hinsicht mehr als genug vorhanden.

DNS-mässig ist alles im grünen Bereich, auch der PTR-Eintrag ist korrekt 
gesetzt.

Ich kann mich nicht mehr genau erinnern, aber nach dem Umzug des 
Mailservers kam im Log ne Meldung, dass Postfix im Kompatibilitätsmodus 
läuft (chroot ?).
Kann es damit was zu tun haben?  Anbei die aktuelle master.cf.

Weiß jemand Rat?
vielen Dank vorab!

Gruß,
Markus







-------------- nächster Teil --------------
#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       -       -       -       smtpd
#smtp      inet  n       -       -       -       1       postscreen
#smtpd     pass  -       -       -       -       -       smtpd
#dnsblog   unix  -       -       -       -       0       dnsblog
#tlsproxy  unix  -       -       -       -       0       tlsproxy
submission inet n       -       -       -       -       smtpd
   -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#smtps     inet  n       -       -       -       -       smtpd
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#628       inet  n       -       -       -       -       qmqpd
pickup    fifo  n       -       -       60      1       pickup
cleanup   unix  n       -       -       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
#qmgr     fifo  n       -       n       300     1       oqmgr
tlsmgr    unix  -       -       -       1000?   1       tlsmgr
rewrite   unix  -       -       -       -       -       trivial-rewrite
bounce    unix  -       -       -       -       0       bounce
defer     unix  -       -       -       -       0       bounce
trace     unix  -       -       -       -       0       bounce
verify    unix  -       -       -       -       1       verify
flush     unix  n       -       -       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
proxywrite unix -       -       n       -       1       proxymap
smtp      unix  -       -       -       -       -       smtp
relay     unix  -       -       -       -       -       smtp
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq     unix  n       -       -       -       -       showq
error     unix  -       -       -       -       -       error
retry     unix  -       -       -       -       -       error
discard   unix  -       -       -       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       -       -       -       lmtp
anvil     unix  -       -       -       -       1       anvil
scache    unix  -       -       -       -       1       scache
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
#
# ====================================================================
#
# Recent Cyrus versions can use the existing "lmtp" master.cf entry.
#
# Specify in cyrus.conf:
#   lmtp    cmd="lmtpd -a" listen="localhost:lmtp" proto=tcp4
#
# Specify in main.cf one or more of the following:
#  mailbox_transport = lmtp:inet:localhost
#  virtual_transport = lmtp:inet:localhost
#
# ====================================================================
#
# Cyrus 2.1.5 (Amos Gouaux)
# Also specify in main.cf: cyrus_destination_recipient_limit=1
#
#cyrus     unix  -       n       n       -       -       pipe
#  user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user}
#
# ====================================================================
# Old example of delivery via Cyrus.
#
#old-cyrus unix  -       n       n       -       -       pipe
#  flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
#
# ====================================================================
#
# See the Postfix UUCP_README file for configuration details.
#
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix	-	n	n	-	2	pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}


From list+postfixbuch at gcore.biz  Thu Oct 15 21:37:09 2020
From: list+postfixbuch at gcore.biz (Gerald Galster)
Date: Thu, 15 Oct 2020 21:37:09 +0200
Subject: =?utf-8?Q?Re=3A_Mailtransport_verz=C3=B6gert=3A_status=3Ddeferred?=
 =?utf-8?Q?=2C_Connection_timed_out?=
In-Reply-To: <bd4bfb2d-da44-b925-a896-cf2816d0f4b9@gmail.com>
References: <bd4bfb2d-da44-b925-a896-cf2816d0f4b9@gmail.com>
Message-ID: <1A843D96-07CF-41A2-A479-B914450CF6DA@gcore.biz>


> Oct 15 18:47:41 mail postfix/error[28607]: 2974C5C47FE2: to=<katharina58 at gmx.net>, relay=none, delay=13016, delays=12954/62/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mx01.emig.gmx.net[212.227.17.5]:25: Connection timed out)
> ***

"Connection timed out" deutet auf ein Netzwerkproblem hin.

Mögliche Ansatzpunkte wären:

- Verbindungen gehen aus (/proc/sys/net/nf_conntrack_max oder ähnliches)
- Verbindungen sind via iptables limitiert (SYN Pakete werden geblockt, ...)
- Firewall/Router zwischendrin verursacht das Problem
- IDS/Deep Inspection greift in SMTP ein
- Fehler auf der Netzwerkkarte (ifconfig / errors / duplex mismatch)

Versuche mit netcat manuell eine Verbindung herzustellen. Falls Port 25 nicht erreichbar ist probiere einen anderen Port, z.B. 80 / 443. Funktioniert letzteres greift irgendwas in SMTP ein.

Vielleicht hilft ein tcptraceroute um zu sehen wo die Pakete verloren gehen: traceroute -n -T -p 25 <server>


> Oct 15 18:47:10 mail postfix/error[28477]: 4584B5C457C3: to=<bounce at exchangedomain>, relay=none, delay=13493, delays=13462/31/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to exchangeserver[ipv4]:25: Connection timed out)

delays=13462/31/0/0

The format of the "delays=a/b/c/d" logging is as follows: 

a = time from message arrival to last active queue entry
b = time from last active queue entry to connection setup
c = time in connection setup, including DNS, EHLO and STARTTLS
d = time in message transmission

a dauert ziemlich lange, wie ist die Verteilung der Mails in den Queues?

Für einen kurzen Überblick:

[root at server ~]# cd /var/spool/postfix
[root at server ~]# for i in *; do echo $i && find $i | wc -l; done

Aktiv zugestellt werden Mails in der active Queue, diese ist limitiert:
qmgr_message_active_limit (default: 20000), ggf. erhöhen

Alles darüber hinaus liegt z.B. in incoming und wandert erst nach active wenn dort Platz frei wird.

Wie sich die Mails verteilen kann man auch mit qshape nachschauen:
http://www.postfix.org/QSHAPE_README.html

Viele Grüße
Gerald

From meinpapierkorb123 at gmail.com  Thu Oct 15 22:15:55 2020
From: meinpapierkorb123 at gmail.com (Mein Papierkorb)
Date: Thu, 15 Oct 2020 22:15:55 +0200
Subject: =?UTF-8?Q?Re=3a_Mailtransport_verz=c3=b6gert=3a_status=3ddeferred?=
 =?UTF-8?Q?=2c_Connection_timed_out?=
In-Reply-To: <1A843D96-07CF-41A2-A479-B914450CF6DA@gcore.biz>
References: <bd4bfb2d-da44-b925-a896-cf2816d0f4b9@gmail.com>
 <1A843D96-07CF-41A2-A479-B914450CF6DA@gcore.biz>
Message-ID: <e250d8a9-a56e-70b8-dc53-587e74cf9060@gmail.com>

Hallo,

1)
die Verteilung der Mails in den Queues sieht wie folgt aus:
incoming: 1
active: 825
defer: 11601
deferred: 11601
alle anderen Queues sind im 1-2 stelligen Bereich.

2)
Kann es was mit dem Versionswechsel von 2.x auf 3.x und dem 
compatibilty_level zu tun haben?
Wie gesagt, ich habe den compatibility_level noch nicht auf 2 gesetzt, 
weil ich dessen Auswirkungen nicht kenne und nicht weiss, ob und wie 
vorab die main.cd oder master.cf angepasst werden muss.

3)
Zu dem Netzwerkproblem:
würde ich generell auch mal als Möglichkeit in Betracht ziehen, da es 
sich um einen virtuellen Server handelt.
Durch die Serverumstellung habe ich auch den Serverhoster gewechselt. 
Ich bin mit dem neuen VPS - Server bei Contabo.
Mit Netzwerkeinstellungen a la "nf_conntrack_max" etc kenne ich mich 
leider so gar nicht aus - diesen Eintrag konnte ich auch nicht finden.
Habe selbst zumindest nichts an solchen Stellen gefrickelt, wenn dann 
muss dort ne Standard-Einstellung vom Provider ein Limit setzen.
Werde dort morgen mal anfragen, ob die irgendwas limitieren.

Viele Grüße,
Markus



Am 15.10.2020 um 21:37 schrieb Gerald Galster:
>> Oct 15 18:47:41 mail postfix/error[28607]: 2974C5C47FE2: to=<katharina58 at gmx.net>, relay=none, delay=13016, delays=12954/62/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mx01.emig.gmx.net[212.227.17.5]:25: Connection timed out)
>> ***
> "Connection timed out" deutet auf ein Netzwerkproblem hin.
>
> Mögliche Ansatzpunkte wären:
>
> - Verbindungen gehen aus (/proc/sys/net/nf_conntrack_max oder ähnliches)
> - Verbindungen sind via iptables limitiert (SYN Pakete werden geblockt, ...)
> - Firewall/Router zwischendrin verursacht das Problem
> - IDS/Deep Inspection greift in SMTP ein
> - Fehler auf der Netzwerkkarte (ifconfig / errors / duplex mismatch)
>
> Versuche mit netcat manuell eine Verbindung herzustellen. Falls Port 25 nicht erreichbar ist probiere einen anderen Port, z.B. 80 / 443. Funktioniert letzteres greift irgendwas in SMTP ein.
>
> Vielleicht hilft ein tcptraceroute um zu sehen wo die Pakete verloren gehen: traceroute -n -T -p 25 <server>
>
>
>> Oct 15 18:47:10 mail postfix/error[28477]: 4584B5C457C3: to=<bounce at exchangedomain>, relay=none, delay=13493, delays=13462/31/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to exchangeserver[ipv4]:25: Connection timed out)
> delays=13462/31/0/0
>
> The format of the "delays=a/b/c/d" logging is as follows:
>
> a = time from message arrival to last active queue entry
> b = time from last active queue entry to connection setup
> c = time in connection setup, including DNS, EHLO and STARTTLS
> d = time in message transmission
>
> a dauert ziemlich lange, wie ist die Verteilung der Mails in den Queues?
>
> Für einen kurzen Überblick:
>
> [root at server ~]# cd /var/spool/postfix
> [root at server ~]# for i in *; do echo $i && find $i | wc -l; done
>
> Aktiv zugestellt werden Mails in der active Queue, diese ist limitiert:
> qmgr_message_active_limit (default: 20000), ggf. erhöhen
>
> Alles darüber hinaus liegt z.B. in incoming und wandert erst nach active wenn dort Platz frei wird.
>
> Wie sich die Mails verteilen kann man auch mit qshape nachschauen:
> http://www.postfix.org/QSHAPE_README.html
>
> Viele Grüße
> Gerald



From meinpapierkorb123 at gmail.com  Thu Oct 15 23:15:21 2020
From: meinpapierkorb123 at gmail.com (Mein Papierkorb)
Date: Thu, 15 Oct 2020 23:15:21 +0200
Subject: =?UTF-8?Q?gel=c3=b6st=3a_Mailtransport_verz=c3=b6gert=3a_status=3dd?=
 =?UTF-8?Q?eferred=2c_Connection_timed_out?=
In-Reply-To: <e250d8a9-a56e-70b8-dc53-587e74cf9060@gmail.com>
References: <bd4bfb2d-da44-b925-a896-cf2816d0f4b9@gmail.com>
 <1A843D96-07CF-41A2-A479-B914450CF6DA@gcore.biz>
 <e250d8a9-a56e-70b8-dc53-587e74cf9060@gmail.com>
Message-ID: <d7acd39c-9650-4c70-f105-62f345e5009c@gmail.com>

Hallo nochmal,

habe soeben bei dem Hoster Contabo angerufen und die haben tatsächlich 
bestätigt, dass sie zwecks Spam-Schutz bei allen Serverprodukten (egal 
ob VPS oder root-Servern) eine Bremse eingebaut haben.
Also steht für mich mal wieder ein kleiner Providerwechsel an... :-/
Aber immerhin: Ursache gefunden!
Danke an Gerald, der mich mit dem Stichwort "Netzwerkproblem" auf die 
richtige Spur gebracht hat.

Viele Grüße,
Markus


Am 15.10.2020 um 22:15 schrieb Mein Papierkorb:
> Hallo,
>
> 1)
> die Verteilung der Mails in den Queues sieht wie folgt aus:
> incoming: 1
> active: 825
> defer: 11601
> deferred: 11601
> alle anderen Queues sind im 1-2 stelligen Bereich.
>
> 2)
> Kann es was mit dem Versionswechsel von 2.x auf 3.x und dem 
> compatibilty_level zu tun haben?
> Wie gesagt, ich habe den compatibility_level noch nicht auf 2 gesetzt, 
> weil ich dessen Auswirkungen nicht kenne und nicht weiss, ob und wie 
> vorab die main.cd oder master.cf angepasst werden muss.
>
> 3)
> Zu dem Netzwerkproblem:
> würde ich generell auch mal als Möglichkeit in Betracht ziehen, da es 
> sich um einen virtuellen Server handelt.
> Durch die Serverumstellung habe ich auch den Serverhoster gewechselt. 
> Ich bin mit dem neuen VPS - Server bei Contabo.
> Mit Netzwerkeinstellungen a la "nf_conntrack_max" etc kenne ich mich 
> leider so gar nicht aus - diesen Eintrag konnte ich auch nicht finden.
> Habe selbst zumindest nichts an solchen Stellen gefrickelt, wenn dann 
> muss dort ne Standard-Einstellung vom Provider ein Limit setzen.
> Werde dort morgen mal anfragen, ob die irgendwas limitieren.
>
> Viele Grüße,
> Markus
>
>
>
> Am 15.10.2020 um 21:37 schrieb Gerald Galster:
>>> Oct 15 18:47:41 mail postfix/error[28607]: 2974C5C47FE2: 
>>> to=<katharina58 at gmx.net>, relay=none, delay=13016, 
>>> delays=12954/62/0/0, dsn=4.4.1, status=deferred (delivery 
>>> temporarily suspended: connect to 
>>> mx01.emig.gmx.net[212.227.17.5]:25: Connection timed out)
>>> ***
>> "Connection timed out" deutet auf ein Netzwerkproblem hin.
>>
>> Mögliche Ansatzpunkte wären:
>>
>> - Verbindungen gehen aus (/proc/sys/net/nf_conntrack_max oder ähnliches)
>> - Verbindungen sind via iptables limitiert (SYN Pakete werden 
>> geblockt, ...)
>> - Firewall/Router zwischendrin verursacht das Problem
>> - IDS/Deep Inspection greift in SMTP ein
>> - Fehler auf der Netzwerkkarte (ifconfig / errors / duplex mismatch)
>>
>> Versuche mit netcat manuell eine Verbindung herzustellen. Falls Port 
>> 25 nicht erreichbar ist probiere einen anderen Port, z.B. 80 / 443. 
>> Funktioniert letzteres greift irgendwas in SMTP ein.
>>
>> Vielleicht hilft ein tcptraceroute um zu sehen wo die Pakete verloren 
>> gehen: traceroute -n -T -p 25 <server>
>>
>>
>>> Oct 15 18:47:10 mail postfix/error[28477]: 4584B5C457C3: 
>>> to=<bounce at exchangedomain>, relay=none, delay=13493, 
>>> delays=13462/31/0/0, dsn=4.4.1, status=deferred (delivery 
>>> temporarily suspended: connect to exchangeserver[ipv4]:25: 
>>> Connection timed out)
>> delays=13462/31/0/0
>>
>> The format of the "delays=a/b/c/d" logging is as follows:
>>
>> a = time from message arrival to last active queue entry
>> b = time from last active queue entry to connection setup
>> c = time in connection setup, including DNS, EHLO and STARTTLS
>> d = time in message transmission
>>
>> a dauert ziemlich lange, wie ist die Verteilung der Mails in den Queues?
>>
>> Für einen kurzen Überblick:
>>
>> [root at server ~]# cd /var/spool/postfix
>> [root at server ~]# for i in *; do echo $i && find $i | wc -l; done
>>
>> Aktiv zugestellt werden Mails in der active Queue, diese ist limitiert:
>> qmgr_message_active_limit (default: 20000), ggf. erhöhen
>>
>> Alles darüber hinaus liegt z.B. in incoming und wandert erst nach 
>> active wenn dort Platz frei wird.
>>
>> Wie sich die Mails verteilen kann man auch mit qshape nachschauen:
>> http://www.postfix.org/QSHAPE_README.html
>>
>> Viele Grüße
>> Gerald
>
>


From lists at localguru.de  Wed Oct 28 16:10:29 2020
From: lists at localguru.de (Marcus Schopen)
Date: Wed, 28 Oct 2020 16:10:29 +0100
Subject: Fehler header HS_HEADER_1442 in 70_HS_header.cf von
 spamassassin.heinlein-support.de channel
Message-ID: <bc7b5a7d9d3b31006a3b9b59babbb34b1025f22a.camel@localguru.de>

Hei,

ich bekomme bei einem SA Update des spamassassin.heinlein-support.de
channel folgenden Fehler:

------
Possible unintended interpolation of @infongwp in string at
/tmp/.spamassassin20167iHPXwbtmp/70_HS_header.cf, rule HS_HEADER_1442,
line 1.
rules: failed to compile
Mail::SpamAssassin::Plugin::Check::_head_tests_0_1, skipping:
	(Global symbol "@infongwp" requires explicit package name at
/tmp/.spamassassin20167iHPXwbtmp/70_HS_header.cf, rule HS_HEADER_1442,
line 1.)
channel: lint check of update failed, channel failed
sa-update failed for unknown reasons
------

70_HS_header.cf:
------
header HS_HEADER_1442           X-Sender-Info:
=~/683525868 at infongwp-eu10.kundenserver.de/
describe HS_HEADER_1442         Heinlein Support Spamschutz Header-1442 
Spam
score HS_HEADER_1442            10
------

@Peer: vielleicht das @ escape'n?

Cheers
M.




From fk+postfix at celebrate.de  Fri Oct 30 11:02:56 2020
From: fk+postfix at celebrate.de (Frank Kirschner)
Date: Fri, 30 Oct 2020 11:02:56 +0100
Subject: IP Adresse beim initialen Kontakt blocken
Message-ID: <d6b11975-b1d0-d9bd-2fbb-ed7aba0474d7@celebrate.de>

Hallo zusammen,

Ich haben mir eine eigene DNS RBL aufgebaut, welche ich derzeit unter

smtpd_recipient_restrictions = .... reject_rbl_client rbl.intern, ...

nutze. Nun möchte ich die RBL aber schon beim initialen Kontakt, egal ob 
über SMTP oder Submission abweisen.
Wäre da die Einbindung in smtpd_helo_restrictions der richtige Ort? Also:

smtpd_helo_restrictions = reject_rbl_client rbl.intern

Viele Grüße,
Frank



From gnitzsche at netcologne.de  Fri Oct 30 11:40:15 2020
From: gnitzsche at netcologne.de (Gunther Nitzsche)
Date: Fri, 30 Oct 2020 11:40:15 +0100
Subject: IP Adresse beim initialen Kontakt blocken
In-Reply-To: <d6b11975-b1d0-d9bd-2fbb-ed7aba0474d7@celebrate.de>
References: <d6b11975-b1d0-d9bd-2fbb-ed7aba0474d7@celebrate.de>
Message-ID: <82b5db78-9eed-8389-b8e3-c956c13e4fda@netcologne.de>

Hi,

Dafür wäre imho postscreen der richtige Ansatz. Der blockt schon vor
Aufbau der postfix-Verbindung.

Ansonsten würde ich das in
smtpd_client_restrictions setzen.

Gruß
Gunther

Am 30.10.2020 um 11:02 schrieb Frank Kirschner:
> Hallo zusammen,
> 
> Ich haben mir eine eigene DNS RBL aufgebaut, welche ich derzeit unter
> 
> smtpd_recipient_restrictions = .... reject_rbl_client rbl.intern, ...
> 
> nutze. Nun möchte ich die RBL aber schon beim initialen Kontakt, egal ob
> über SMTP oder Submission abweisen.
> Wäre da die Einbindung in smtpd_helo_restrictions der richtige Ort? Also:
> 
> smtpd_helo_restrictions = reject_rbl_client rbl.intern
> 
> Viele Grüße,
> Frank
> 
> 

-- 
NetCologne Systemadministration

NetCologne Gesellschaft für Telekommunikation mbH
Am Coloneum 9 ; 50829 Köln
Geschäftsführer:
 Timo von Lepel
Vorsitzender des Aufsichtsrats:
 Dr. Andreas Cerbe
HRB 25580, AG Köln

From driessen at fblan.de  Fri Oct 30 11:35:20 2020
From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Fri, 30 Oct 2020 11:35:20 +0100
Subject: AW: IP Adresse beim initialen Kontakt blocken
In-Reply-To: <d6b11975-b1d0-d9bd-2fbb-ed7aba0474d7@celebrate.de>
References: <d6b11975-b1d0-d9bd-2fbb-ed7aba0474d7@celebrate.de>
Message-ID: <000001d6aea8$5e0d0a60$1a271f20$@fblan.de>

Im Auftrag von Frank Kirschner
> Betreff: IP Adresse beim initialen Kontakt blocken
> 
> Hallo zusammen,
> 
> Ich haben mir eine eigene DNS RBL aufgebaut, welche ich derzeit unter
> 
> smtpd_recipient_restrictions = .... reject_rbl_client rbl.intern, ...
> 
> nutze. Nun möchte ich die RBL aber schon beim initialen Kontakt, egal ob
> über SMTP oder Submission abweisen.
> Wäre da die Einbindung in smtpd_helo_restrictions der richtige Ort? Also:
> 
> smtpd_helo_restrictions = reject_rbl_client rbl.intern
> 
> Viele Grüße,
> Frank

Öhm ja und warum willst du die IP bis Postfix lassen ?
Hat Postfix Langeweile ? :-) 
 
Iptables (bzw. den neueren Ersatz) , IPset  

Ist eine Zeile und tausende Adressen, IP-Netze ..... 


Mit freundlichen Grüßen

Uwe Drießen
--
Software & Computer

Netzwerke, Server. 
Wir vernetzen Sie und Ihre Rechner !

Uwe Drießen
Lembergstraße 33
67824 Feilbingert

Tel.: 06708660045 

"wenn Digitalisierung den Aufwand im Vergleich zur Analogen Arbeitsweise dermaßen erhöht, das wir nur noch am PC sitzen müssten,
 dann wird es Zeit sich zu überlegen zur Analogen Arbeitsweise zurückzukehren" 
"Programmierer müssen lernen wie Menschen denken. "




From fk+postfix at celebrate.de  Fri Oct 30 13:17:09 2020
From: fk+postfix at celebrate.de (Frank Kirschner)
Date: Fri, 30 Oct 2020 13:17:09 +0100
Subject: IP Adresse beim initialen Kontakt blocken
In-Reply-To: <2bebf85e-508d-50cb-eee1-67cd2e914bc8@celebrate.de>
References: <d6b11975-b1d0-d9bd-2fbb-ed7aba0474d7@celebrate.de>
 <6b5054d4-b0eb-aea0-d6ce-74041ac34bfe@deiszner.de>
 <2bebf85e-508d-50cb-eee1-67cd2e914bc8@celebrate.de>
Message-ID: <faac628c-80ae-e9fc-7419-0f01628248da@celebrate.de>

> Am 30.10.2020 um 12:45 schrieb sebastian at deiszner.de:
>
>> Moin,
>>
>> wie ermittelst Du denn diese Adressen?
>>
> Hallo Sebastian,
>
> wir haben hier mehrere öffentliche Dienst. (www, smtp, imap ..)
> Dort werden die Logfiles mit fail2ban analysiert, das Ergebnis melden 
> wir u.a. an abuseipdb
> und loggen das in eine interne Datenbank. Ein eigenes Programm sammelt 
> zyklisch Informationen
> zu den IP Adressen: daraus werden Vektoren erstellt:
> - welche IP wie oft welchen Dienst nicht konform nutzt
> - auf wem die IP registriert ist z.B. Shodan.io
> - in wie weit zusammenhängende Subnetze aus den einzelnen IP's 
> generiert werden
> - gibt es zu verschiedenen IP identische Anfragen, z.B. fragt eine IP 
> einen SMTP Server nach "GET HTTP1.0" was ja sinnfrei ist
> Parallel dazu werden aus öffentlich verfügbaren Datenbanken z.B. 
> abuseipdb Informationen abgefragt; aus dem allen errechnet
> sich ein Risiko Scoring. Dies wird immer zur IP gespeichert und die 
> zeitliche Entwicklung des Scorings protokolliert.
>
> Aktuell werden IP's ab einem bestimmten Level in die jeweilige 
> Firewall der Server hinterlegt, was asynchron erfolgt.
> Hier habe ich rbldnsd aufgesetzt, welches aktuell Postfix dann die 
> Info liefert und einen entsprechenden Link in die abgelehnte Email
> einbaut, wo man um Reputation bitten kann.
>
> Zukünftig soll erst einmal eine Info erfolgen, ab einem bestimmten 
> Level (DDOS) dann ein Firewall block.
>
> lg Frank
>