From atann at alphasrv.net  Wed Sep  1 10:06:23 2021
From: atann at alphasrv.net (Andre Tann)
Date: Wed, 1 Sep 2021 10:06:23 +0200
Subject: Mail an GMX
Message-ID: <3e3a4e26-43b5-1c45-38b5-ca8952c599ad@alphasrv.net>

Servus zusammen,

seit einiger Zeit kommt es immer wieder zu Problemen bei der 
Auslieferung an GMX:

Sep  1 09:57:36 a10 postfix/smtp[3481]: 129923F12B: 
to=<recipient at gmx.net>, relay=mx01.emig.gmx.net[212.227.17.5]:25, 
delay=0.83, delays=0.16/0/0.39/0.28, dsn=5.0.0, status=bounced (host 
mx01.emig.gmx.net[212.227.17.5] said: 554-Transaction failed 554-Reject 
due to policy restrictions. 554 For explanation visit 
https://www.gmx.net/mail/senderguidelines?ip=95.217.28.6&c=hd (in reply 
to end of DATA command))

Es ist aber nicht so, daß das nie geht, sondern mal geht es, dann wieder 
nicht.

Ich finde die IP nicht auf eine Blacklist, mein HELO stimmt, das DNS 
stimmt, ich habe dkim und dmark und spf, und auch sonst finde ich 
nichts, woran es liegen könnte.

Wo könnte ich da noch ansetzen, hat jemand eine Idee?

-- 
Andre Tann

From florian at effenberger.org  Wed Sep  1 10:40:00 2021
From: florian at effenberger.org (Florian Effenberger)
Date: Wed, 1 Sep 2021 10:40:00 +0200
Subject: Mail an GMX
In-Reply-To: <3e3a4e26-43b5-1c45-38b5-ca8952c599ad@alphasrv.net>
References: <3e3a4e26-43b5-1c45-38b5-ca8952c599ad@alphasrv.net>
Message-ID: <91db723e-f8c0-cb7b-5aa0-71ce7a136006@effenberger.org>

Hallo,

Andre Tann wrote on 01.09.21 at 10:06:

> Sep  1 09:57:36 a10 postfix/smtp[3481]: 129923F12B: 
> to=<recipient at gmx.net>, relay=mx01.emig.gmx.net[212.227.17.5]:25, 
> delay=0.83, delays=0.16/0/0.39/0.28, dsn=5.0.0, status=bounced (host 
> mx01.emig.gmx.net[212.227.17.5] said: 554-Transaction failed 554-Reject 
> due to policy restrictions. 554 For explanation visit 
> https://www.gmx.net/mail/senderguidelines?ip=95.217.28.6&c=hd (in reply 
> to end of DATA command))
> 
> Es ist aber nicht so, daß das nie geht, sondern mal geht es, dann wieder 
> nicht.

kannst du die Mails nachvollziehen, sind die in Ordnung, oder evtl. mit 
falschen/kaputten Headern? (Siehe Punkt 2 und 3 der Liste)

> Wo könnte ich da noch ansetzen, hat jemand eine Idee?

Ich hatte beim ersten Auflösen des PTR eine ziemlich lange Wartezeit, 
das hat fast 10 Sekunden gedauert. Liegt es evtl. am DNS, dass es da 
einen Timeout gibt?

Ich kann aber nicht ausschließen, dass es an meinem lokalen Resolver 
liegt, von anderen Maschinen konnte ich das Problem nicht 
nachvollziehen, ist also vielleicht die falsche Fährte...

Viele Grüße
Flo

From atann at alphasrv.net  Wed Sep  1 11:12:15 2021
From: atann at alphasrv.net (Andre Tann)
Date: Wed, 1 Sep 2021 11:12:15 +0200
Subject: Mail an GMX
In-Reply-To: <91db723e-f8c0-cb7b-5aa0-71ce7a136006@effenberger.org>
References: <3e3a4e26-43b5-1c45-38b5-ca8952c599ad@alphasrv.net>
 <91db723e-f8c0-cb7b-5aa0-71ce7a136006@effenberger.org>
Message-ID: <c3c219e4-ea83-b935-2542-4cfc093a01f4@alphasrv.net>

Moin,

On 01.09.21 10:40, Florian Effenberger wrote:

> kannst du die Mails nachvollziehen, sind die in Ordnung, oder evtl. mit 
> falschen/kaputten Headern? (Siehe Punkt 2 und 3 der Liste)

Soweit ich sehen kann sind die Header in Ordnung, und tatsächlich war es 
so, daß meine eigene Mail betroffen war. Die kam aus dem Thunderbird, 
und da wärs auch eher unwahrscheinlich, daß die Header schräg sind.

Ich hatte sie aber nochmal geprüft, und mir ist nichts aufgefallen, was 
daran hätte falsch sein können.


> Ich hatte beim ersten Auflösen des PTR eine ziemlich lange Wartezeit, 
> das hat fast 10 Sekunden gedauert. Liegt es evtl. am DNS, dass es da 
> einen Timeout gibt?

$ dig -x 95.217.28.6 @8.8.8.8
[...]
;; ANSWER SECTION:
6.28.217.95.in-addr.arpa. 21600 IN      PTR     mailout.alphasrv.net.

;; Query time: 222 msec
[...]

Obwohl mir 200 ms auch etwas lange vorkommt. Sollte das nicht eher < 10 
ms sein?

-- 
Andre Tann

From driessen at fblan.de  Wed Sep  1 11:26:27 2021
From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Wed, 1 Sep 2021 11:26:27 +0200
Subject: AW: Mail an GMX
In-Reply-To: <c3c219e4-ea83-b935-2542-4cfc093a01f4@alphasrv.net>
References: <3e3a4e26-43b5-1c45-38b5-ca8952c599ad@alphasrv.net>
 <91db723e-f8c0-cb7b-5aa0-71ce7a136006@effenberger.org>
 <c3c219e4-ea83-b935-2542-4cfc093a01f4@alphasrv.net>
Message-ID: <032501d79f13$721c20c0$56546240$@fblan.de>

Im Auftrag von Andre Tann
> 
> > Ich hatte beim ersten Auflösen des PTR eine ziemlich lange Wartezeit,
> > das hat fast 10 Sekunden gedauert. Liegt es evtl. am DNS, dass es da
> > einen Timeout gibt?
> 
> $ dig -x 95.217.28.6 @8.8.8.8
> [...]
> ;; ANSWER SECTION:
> 6.28.217.95.in-addr.arpa. 21600 IN      PTR     mailout.alphasrv.net.
> 
> ;; Query time: 222 msec
> [...]

Wo wird die Domain DNS mäßig gehostet ? 
Und warum fragst Amerika nach ner deutschen IP 
Deutschland - Amerika- deutschland- amerika - zu dir wieder nach Deutschland 
Für 5 mal um die Welt sind 200 ms nicht schlecht :-)

Ich bekomme trotz zur Zeit 

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 01 11:24:57 CEST 2021
;; MSG SIZE  rcvd: 177

dig -x 95.217.28.6

; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> -x 95.217.28.6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30920
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;6.28.217.95.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
6.28.217.95.in-addr.arpa. 86400 IN      PTR     mailout.alphasrv.net.

;; AUTHORITY SECTION:
28.217.95.in-addr.arpa. 86400   IN      NS      ns.second-ns.com.
28.217.95.in-addr.arpa. 86400   IN      NS      ns1.your-server.de.
28.217.95.in-addr.arpa. 86400   IN      NS      ns3.second-ns.de.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 01 11:24:57 CEST 2021
;; MSG SIZE  rcvd: 177




> 
> Obwohl mir 200 ms auch etwas lange vorkommt. Sollte das nicht eher < 10
> ms sein?
> 
> --
> Andre Tann




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. "
"Digitalisierung heißt nicht das es WENIGER Arbeit wird. Es ist die Intelligente Art die erforderliche Arbeit auf den Kunden zu übertragen." 
Digitalisierung darf nicht zur Entmündigung und Benachteiligung der älteren brillentragenden Mitbürger führen."
" Es gibt über 2000 Jahre alte Papierdokumente, 10000 Jahre alte Steindokumente, ich wette das älteste elektronische Dokument ist noch keine 100 Jahre."



From wn at neessen.net  Wed Sep  1 11:46:35 2021
From: wn at neessen.net (Winfried Neessen)
Date: Wed, 01 Sep 2021 11:46:35 +0200
Subject: AW: Mail an GMX
In-Reply-To: <032501d79f13$721c20c0$56546240$@fblan.de>
References: <3e3a4e26-43b5-1c45-38b5-ca8952c599ad@alphasrv.net>
 <91db723e-f8c0-cb7b-5aa0-71ce7a136006@effenberger.org>
 <c3c219e4-ea83-b935-2542-4cfc093a01f4@alphasrv.net>
 <032501d79f13$721c20c0$56546240$@fblan.de>
Message-ID: <a40732a5c8ead400cec359cd42f9caef@neessen.net>

Hi,

Am 2021-09-01 11:26, schrieb Uwe Drießen:

> Und warum fragst Amerika nach ner deutschen IP
> Deutschland - Amerika- deutschland- amerika - zu dir wieder nach 
> Deutschland
> Für 5 mal um die Welt sind 200 ms nicht schlecht :-)
> 
Das ist natuerlich Quatsch. Google hat auch Server in Europa und in DE 
stehen.
D. h. die Anfragen gehen nicht ueber den Ozean und zurueck. Mein 
naechste Google
DNS Resolver steht z. B. im RZ meines ISP.

Und 'nen externen oeffentlichen DNS Resolver mit 'nem lokalen 
Caching-Resolver zu
vergleichen ist halt auch Apfel vs. Birne. Natuerlich ist der lokale 
Resolver
immer schneller.

Winni

From mailinglisten at pothe.de  Wed Sep  1 11:46:41 2021
From: mailinglisten at pothe.de (Andreas Pothe)
Date: Wed, 1 Sep 2021 11:46:41 +0200
Subject: Mail an GMX
In-Reply-To: <032501d79f13$721c20c0$56546240$@fblan.de>
References: <3e3a4e26-43b5-1c45-38b5-ca8952c599ad@alphasrv.net>
 <91db723e-f8c0-cb7b-5aa0-71ce7a136006@effenberger.org>
 <c3c219e4-ea83-b935-2542-4cfc093a01f4@alphasrv.net>
 <032501d79f13$721c20c0$56546240$@fblan.de>
Message-ID: <257d3132-0b8b-0af2-2bd4-2deb0fbb4902@pothe.de>

Moin,

Am 01.09.2021 um 11:26 schrieb Uwe Drießen:
> Wo wird die Domain DNS mäßig gehostet ?
Sieht nach Hetzner aus.
> Und warum fragst Amerika nach ner deutschen IP 
> Deutschland - Amerika- deutschland- amerika - zu dir wieder nach Deutschland 
> Für 5 mal um die Welt sind 200 ms nicht schlecht :-)

Google hat Server nicht nur in den USA stehen. dns.google.com gibt es
weltweit, auch in DE. Von meinem Heimanschluss (FTTH) in 8ms erreichbar,
was ziemlich sicher nicht bei transatlantischer Übertragung möglich wäre.

VG
Andreas

From atann at alphasrv.net  Wed Sep  1 12:02:55 2021
From: atann at alphasrv.net (Andre Tann)
Date: Wed, 01 Sep 2021 10:02:55 -0000
Subject: AW: Mail an GMX
In-Reply-To: <032501d79f13$721c20c0$56546240$@fblan.de>
References: <3e3a4e26-43b5-1c45-38b5-ca8952c599ad@alphasrv.net>
 <91db723e-f8c0-cb7b-5aa0-71ce7a136006@effenberger.org>
 <c3c219e4-ea83-b935-2542-4cfc093a01f4@alphasrv.net>
 <032501d79f13$721c20c0$56546240$@fblan.de>
Message-ID: <be5b1ced-01b7-67f7-86fb-95c7ddce223f@alphasrv.net>

Moin,

On 01.09.21 11:26, Uwe Drießen wrote:

> Wo wird die Domain DNS mäßig gehostet ?

Hetzner. Ja hast recht, für zweimal über den Teich gehts...


> Ich bekomme trotz zur Zeit
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Sep 01 11:24:57 CEST 2021
> ;; MSG SIZE  rcvd: 177

Weils im Cache liegt. 0 ms wären sonst etwas schnell.

Ich hab mal nach heise gefragt:

$ dig heise.de @8.8.8.8
[...]
;; Query time: 18 msec

$ dig -x 193.99.144.80 @8.8.8.8
[...]
;; Query time: 18 msec

Also gehts über den Teich auch schneller als meine 200 ms. Obwohl 
<kopfkratz> in 18 ms viermal über den Teich, das kann nicht sein, also 
rein physikalisch. Also steht die Maschine, die auf 8.8.8.8 hört, 
entweder doch nicht drüben, oder irgendwo ist noch ein Cache.

Wie auch immer, GMX wird ja nicht schon nach 200 ms aufgeben, und damit 
stellt sie die Frage immer noch für mich, wieso sie es manchmal annehmen 
und manchmal nicht.

-- 
Andre Tann

From r.sander at heinlein-support.de  Wed Sep  1 13:17:29 2021
From: r.sander at heinlein-support.de (Robert Sander)
Date: Wed, 1 Sep 2021 13:17:29 +0200
Subject: Mail an GMX
In-Reply-To: <be5b1ced-01b7-67f7-86fb-95c7ddce223f@alphasrv.net>
References: <3e3a4e26-43b5-1c45-38b5-ca8952c599ad@alphasrv.net>
 <91db723e-f8c0-cb7b-5aa0-71ce7a136006@effenberger.org>
 <c3c219e4-ea83-b935-2542-4cfc093a01f4@alphasrv.net>
 <032501d79f13$721c20c0$56546240$@fblan.de>
 <be5b1ced-01b7-67f7-86fb-95c7ddce223f@alphasrv.net>
Message-ID: <727ef1c1-5d26-ad89-6740-9573c0b7e01d@heinlein-support.de>

On 01.09.21 12:02, Andre Tann wrote:
> Also steht die Maschine, die auf 8.8.8.8 hört,
> entweder doch nicht drüben

8.8.8.8 ist eine Anycast-IP, die prinzipiell mehrfach auf der Welt 
terminiert. Mach einfach mal "mtr 8.8.8.8", dann siehst Du es (zumindest 
von Dir aus.

Viele Grüße
-- 
Robert Sander
Heinlein Consulting GmbH
Schwedter Str. 8/9b, 10119 Berlin

https://www.heinlein-support.de

Tel: 030 / 405051-43
Fax: 030 / 405051-19

Amtsgericht Berlin-Charlottenburg - HRB 220009 B
Geschäftsführer: Peer Heinlein - Sitz: Berlin

From lists at xunil.at  Thu Sep 16 10:29:26 2021
From: lists at xunil.at (Stefan G. Weichinger)
Date: Thu, 16 Sep 2021 10:29:26 +0200
Subject: postfix Auswertungen in Graylog
Message-ID: <ae2f0442-ce16-74c8-cf16-c96c22cb4115@xunil.at>



Hallo, Kollegen,

setz jemand von Euch Graylog ( 
https://www.graylog.org/products/open-source ) fürs Sammeln und 
Auswerten von Logs ein?

Ich sehe mich grade um nach Extraktoren etc. für Postfix, im Graylog 
Marketplace habe ich 2-3 Regelsätze gefunden ... vielleicht gibt es aber 
noch was Aktuelleres oder Besseres?

Für Feedback dazu bin ich dankbar!

Grüße, Stefan

From florian at bodici.de  Thu Sep 16 11:01:31 2021
From: florian at bodici.de (Florian)
Date: Thu, 16 Sep 2021 11:01:31 +0200
Subject: postfix Auswertungen in Graylog
In-Reply-To: <ae2f0442-ce16-74c8-cf16-c96c22cb4115@xunil.at>
References: <ae2f0442-ce16-74c8-cf16-c96c22cb4115@xunil.at>
Message-ID: <538b1616-ec94-06f2-82b0-1b90e11cbef0@bodici.de>

Hallo Stefan,

was genau willst du denn tun? Für eine tägliche Übersicht über meine 
Logs bin ich mit pflogsumm ganz zufrieden. Wenn es in Richtung 
Spamfilter (trainieren) geht, setze ich auf rspamd. Für umfangreichere 
statistische Auswertungen kann man elasticsearch/Kibana verwenden. 
Vielleicht sitzt Graylog irgendwo dazwischen?


Viele Grüße

Florian Vierke

Am 16.09.2021 um 10:29 schrieb Stefan G. Weichinger:
>
>
> Hallo, Kollegen,
>
> setz jemand von Euch Graylog ( 
> https://www.graylog.org/products/open-source ) fürs Sammeln und 
> Auswerten von Logs ein?
>
> Ich sehe mich grade um nach Extraktoren etc. für Postfix, im Graylog 
> Marketplace habe ich 2-3 Regelsätze gefunden ... vielleicht gibt es 
> aber noch was Aktuelleres oder Besseres?
>
> Für Feedback dazu bin ich dankbar!
>
> Grüße, Stefan

From lists at xunil.at  Thu Sep 16 12:49:11 2021
From: lists at xunil.at (Stefan G. Weichinger)
Date: Thu, 16 Sep 2021 12:49:11 +0200
Subject: postfix Auswertungen in Graylog
In-Reply-To: <538b1616-ec94-06f2-82b0-1b90e11cbef0@bodici.de>
References: <ae2f0442-ce16-74c8-cf16-c96c22cb4115@xunil.at>
 <538b1616-ec94-06f2-82b0-1b90e11cbef0@bodici.de>
Message-ID: <52b8d368-bc64-ec8b-f301-846f6a905436@xunil.at>

Am 16.09.21 um 11:01 schrieb Florian:
> Hallo Stefan,
> 
> was genau willst du denn tun? Für eine tägliche Übersicht über meine 
> Logs bin ich mit pflogsumm ganz zufrieden. Wenn es in Richtung 
> Spamfilter (trainieren) geht, setze ich auf rspamd. Für umfangreichere 
> statistische Auswertungen kann man elasticsearch/Kibana verwenden. 
> Vielleicht sitzt Graylog irgendwo dazwischen?

Graylog verwendet ElasticSearch als "Backend", also käme das sowieso mit.

Ich soll für einen Kunden eine Abfrage-Anwendung bauen, die einerseits 
ein paar Standard-Statistiken bereit stellt, und weiters zB 
Export-Möglichkeiten bieten soll.

Da geht es um Compliance-Themen, und es braucht eine mächtigere GUI für 
Abfragen und Suchen, etc

Und auch um 1 Jahr Aufbewahrungsfrist ... da macht es Sinn, ein 
sinnvolles Backend für die Logs zu haben.

Daher kamen wir auf Graylog, weil wir das an anderer Stelle gerade 
einbauen, für Debian-Syslogs usw.


From postfix at linuxmaker.de  Thu Sep 16 15:41:30 2021
From: postfix at linuxmaker.de (Andreas)
Date: Thu, 16 Sep 2021 15:41:30 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
Message-ID: <12180815.CXVp6WEDlD@stuttgart>

Hallo zusammen,

 

ich habe ein Dist-Upgrade von Debian-Buster auf Bullseyes gemacht und nach 
einem Reboot melden die Mail-Benutzer, dass an ihren Clients ein Timeout 
stattfindet und kein Mailabgleich mehr möglich ist.

 

Ich konnte soweit eingrenzen, dass nach einem Telnet auf port 587 bei 
Authentifizierungsversuch die Verbindung abreißt und im Logfile diese Meldung 
auftaucht:

 

Sep 16 15:13:20 mx postfix/submission/smtpd[11588]: warning: TLS library 
problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../
ssl/record/ssl3_record.c:331

Main.cf:

append_dot_mydomain = no

biff = no

bounce_queue_lifetime = 1h

compatibility_level = 2

confirm_delay_cleared = yes

delay_warning_time = 60

disable_vrfy_command = yes

html_directory = /usr/share/doc/postfix/html

inet_interfaces = all

local_recipient_maps = $virtual_mailbox_maps

mailbox_size_limit = 0

maximal_backoff_time = 15m

maximal_queue_lifetime = 1h

message_size_limit = 52428800

milter_default_action = tempfail

milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}

milter_protocol = 6

minimal_backoff_time = 5m

mua_client_restrictions = permit_mynetworks permit_sasl_authenticated reject

mua_relay_restrictions = reject_non_fqdn_recipient 
reject_unknown_recipient_domain permit_mynetworks permit_sasl_authenticated 
reject

mua_sender_restrictions = permit_mynetworks reject_non_fqdn_sender 
reject_sender_login_mismatch permit_sasl_authenticated reject

mydestination = mx.example.tld, localhost.example.tld, localhost

myhostname = mx.example.tld

mynetworks = 127.0.0.0/8 192.168.1.0/24 192.109.24.0/24 [::ffff:127.0.0.0]/104 
[::1]/128

myorigin = /etc/mailname

non_smtpd_milters = inet:localhost:11332

plaintext_reject_code = 550

postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_access

postscreen_bare_newline_enable = no

postscreen_blacklist_action = drop

postscreen_cache_cleanup_interval = 24h

postscreen_cache_map = proxy:btree:$data_directory/postscreen_cache

postscreen_dnsbl_action = enforce

postscreen_dnsbl_sites = b.barracudacentral.org=127.0.0.2*7 
dnsbl.inps.de=127.0.0.2*7 bl.mailspike.net=127.0.0.2*5 
bl.mailspike.net=127.0.0.[10;11;12]*4 dnsbl.sorbs.net=127.0.0.10*8 
dnsbl.sorbs.net=127.0.0.5*6 dnsbl.sorbs.net=127.0.0.7*3 
dnsbl.sorbs.net=127.0.0.8*2 dnsbl.sorbs.net=127.0.0.6*2 
dnsbl.sorbs.net=127.0.0.9*2 zen.spamhaus.org=127.0.0.[4..7]*6 
zen.spamhaus.org=127.0.0.3*4 zen.spamhaus.org=127.0.0.2*3 
hostkarma.junkemailfilter.com=127.0.0.2*3 
hostkarma.junkemailfilter.com=127.0.0.4*1 
hostkarma.junkemailfilter.com=127.0.1.2*1 wl.mailspike.net=127.0.0.
[18;19;20]*-2 hostkarma.junkemailfilter.com=127.0.0.1*-2

postscreen_dnsbl_threshold = 8

postscreen_dnsbl_ttl = 5m

postscreen_greet_action = enforce

postscreen_greet_banner = $smtpd_banner

postscreen_greet_ttl = 2d

postscreen_greet_wait = 3s

postscreen_non_smtp_command_enable = no

postscreen_pipelining_enable = no

proxy_read_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_sender_acl.cf, 
proxy:mysql:/etc/postfix/sql/mysql_tls_enforce_out_policy.cf, proxy:mysql:/
etc/postfix/sql/mysql_tls_enforce_in_policy.cf, proxy:mysql:/etc/postfix/sql/
sender-login-maps.cf, $local_recipient_maps $mydestination $virtual_alias_maps 
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains 
$relay_recipient_maps $relay_domains $mynetworks $smtpd_sender_login_maps

queue_run_delay = 5m

readme_directory = /usr/share/doc/postfix

recipient_delimiter = +

relay_domains = proxy:mysql:/etc/postfix/sql/mysql_virtual_mxdomain_maps.cf

relay_recipient_maps = proxy:mysql:/etc/postfix/sql/
mysql_relay_recipient_maps.cf

smtp_dns_support_level = dnssec

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

smtp_tls_ciphers = medium

smtp_tls_loglevel = 1

smtp_tls_policy_maps = mysql:/etc/postfix/sql/tls-policy.cf

smtp_tls_protocols = !SSLv2, !SSLv3

smtp_tls_security_level = dane

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_banner = $myhostname

smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/
postfix/without_ptr reject_unknown_client_hostname

smtpd_data_restrictions = reject_unauth_pipelining

smtpd_error_sleep_time = 10s

smtpd_hard_error_limit = ${stress?1}${stress:5}

smtpd_helo_required = yes

smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname 
reject_non_fqdn_helo_hostname reject_unknown_helo_hostname

smtpd_milters = inet:localhost:11332

smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, 
reject_invalid_helo_hostname, reject_unknown_reverse_client_hostname, 
reject_unauth_destination

smtpd_relay_restrictions = reject_non_fqdn_recipient 
reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination

smtpd_sender_login_maps = proxy:mysql:/etc/postfix/sql/
mysql_virtual_sender_acl.cf

smtpd_soft_error_limit = 3

smtpd_tls_auth_only = yes

smtpd_tls_cert_file = /etc/letsencrypt/live/mx.example.tld/fullchain.pem

smtpd_tls_ciphers = medium

smtpd_tls_dh1024_param_file = /etc/ssl/mail/dhparams_2048.pem

smtpd_tls_dh512_param_file = /etc/ssl/mail/dhparams_512.pem

smtpd_tls_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL

smtpd_tls_key_file = /etc/letsencrypt/live/mx.example.tld/privkey.pem

smtpd_tls_loglevel = 1

smtpd_tls_mandatory_ciphers = high

smtpd_tls_mandatory_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL

smtpd_tls_mandatory_protocols = !SSLv3

smtpd_tls_protocols = !SSLv3

smtpd_tls_security_level = may

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-
SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-
CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-
RSA-AES256-GCM-SHA384

tls_preempt_cipherlist = no

tls_ssl_options = NO_COMPRESSION

virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, 
proxy:mysql:/etc/postfix/sql/mysql_virtual_spamalias_maps.cf

virtual_gid_maps = static:5000

virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/
mysql_virtual_domains_maps.cf

virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/
mysql_virtual_mailbox_maps.cf

virtual_minimum_uid = 104

virtual_transport = lmtp:unix:private/dovecot-lmtp

virtual_uid_maps = static:5000

 

Ich finde gerade nicht die Parameter, die zu ändern sind bzw. welches Paket 
eventuell fehlerhaft sein könnte.

Viele Grüße und vielen Dank im Voraus

 

Andreas
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/c7deaa8c/attachment-0001.htm>

From postfix at linuxmaker.de  Thu Sep 16 15:33:35 2021
From: postfix at linuxmaker.de (Andreas)
Date: Thu, 16 Sep 2021 15:33:35 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
Message-ID: <22371949.eJIMzgIU6a@stuttgart>

Hallo zusammen,

ich habe ein Dist-Upgrade von Debian-Buster auf Bullseyes gemacht und nach 
einem Reboot melden die Mail-Benutzer, dass an ihren Clients ein Timeout 
stattfindet und kein Mailabgleich mehr möglich ist.

Ich konnte soweit eingrenzen, dass nach einem Telnet auf port 587 bei 
Authentifizierungsversuch die Verbindung abreißt und im Logfile diese Meldung 
auftaucht:

Sep 16 15:13:20 mx postfix/submission/smtpd[11588]: warning: TLS library 
problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../
ssl/record/ssl3_record.c:331

Main.cf:
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1h
compatibility_level = 2
confirm_delay_cleared = yes
delay_warning_time = 60
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
local_recipient_maps = $virtual_mailbox_maps
mailbox_size_limit = 0
maximal_backoff_time = 15m
maximal_queue_lifetime = 1h
message_size_limit = 52428800
milter_default_action = tempfail
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_protocol = 6
minimal_backoff_time = 5m
mua_client_restrictions = permit_mynetworks permit_sasl_authenticated reject
mua_relay_restrictions = reject_non_fqdn_recipient 
reject_unknown_recipient_domain permit_mynetworks permit_sasl_authenticated 
reject
mua_sender_restrictions = permit_mynetworks reject_non_fqdn_sender 
reject_sender_login_mismatch permit_sasl_authenticated reject
mydestination = mx.example.tld, localhost.example.tld, localhost
myhostname = mx.example.tld
mynetworks = 127.0.0.0/8 192.168.1.0/24 192.109.24.0/24 [::ffff:127.0.0.0]/104 
[::1]/128
myorigin = /etc/mailname
non_smtpd_milters = inet:localhost:11332
plaintext_reject_code = 550
postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_access
postscreen_bare_newline_enable = no
postscreen_blacklist_action = drop
postscreen_cache_cleanup_interval = 24h
postscreen_cache_map = proxy:btree:$data_directory/postscreen_cache
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = b.barracudacentral.org=127.0.0.2*7 
dnsbl.inps.de=127.0.0.2*7 bl.mailspike.net=127.0.0.2*5 
bl.mailspike.net=127.0.0.[10;11;12]*4 dnsbl.sorbs.net=127.0.0.10*8 
dnsbl.sorbs.net=127.0.0.5*6 dnsbl.sorbs.net=127.0.0.7*3 
dnsbl.sorbs.net=127.0.0.8*2 dnsbl.sorbs.net=127.0.0.6*2 
dnsbl.sorbs.net=127.0.0.9*2 zen.spamhaus.org=127.0.0.[4..7]*6 
zen.spamhaus.org=127.0.0.3*4 zen.spamhaus.org=127.0.0.2*3 
hostkarma.junkemailfilter.com=127.0.0.2*3 
hostkarma.junkemailfilter.com=127.0.0.4*1 
hostkarma.junkemailfilter.com=127.0.1.2*1 wl.mailspike.net=127.0.0.
[18;19;20]*-2 hostkarma.junkemailfilter.com=127.0.0.1*-2
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_ttl = 5m
postscreen_greet_action = enforce
postscreen_greet_banner = $smtpd_banner
postscreen_greet_ttl = 2d
postscreen_greet_wait = 3s
postscreen_non_smtp_command_enable = no
postscreen_pipelining_enable = no
proxy_read_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_sender_acl.cf, 
proxy:mysql:/etc/postfix/sql/mysql_tls_enforce_out_policy.cf, proxy:mysql:/
etc/postfix/sql/mysql_tls_enforce_in_policy.cf, proxy:mysql:/etc/postfix/sql/
sender-login-maps.cf, $local_recipient_maps $mydestination $virtual_alias_maps 
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains 
$relay_recipient_maps $relay_domains $mynetworks $smtpd_sender_login_maps
queue_run_delay = 5m
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = proxy:mysql:/etc/postfix/sql/mysql_virtual_mxdomain_maps.cf
relay_recipient_maps = proxy:mysql:/etc/postfix/sql/
mysql_relay_recipient_maps.cf
smtp_dns_support_level = dnssec
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_ciphers = medium
smtp_tls_loglevel = 1
smtp_tls_policy_maps = mysql:/etc/postfix/sql/tls-policy.cf
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname
smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/
postfix/without_ptr reject_unknown_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_error_sleep_time = 10s
smtpd_hard_error_limit = ${stress?1}${stress:5}
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname 
reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
smtpd_milters = inet:localhost:11332
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, 
reject_invalid_helo_hostname, reject_unknown_reverse_client_hostname, 
reject_unauth_destination
smtpd_relay_restrictions = reject_non_fqdn_recipient 
reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination
smtpd_sender_login_maps = proxy:mysql:/etc/postfix/sql/
mysql_virtual_sender_acl.cf
smtpd_soft_error_limit = 3
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/mx.example.tld/fullchain.pem
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/ssl/mail/dhparams_2048.pem
smtpd_tls_dh512_param_file = /etc/ssl/mail/dhparams_512.pem
smtpd_tls_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL
smtpd_tls_key_file = /etc/letsencrypt/live/mx.example.tld/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL
smtpd_tls_mandatory_protocols = !SSLv3
smtpd_tls_protocols = !SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-
SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-
CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-
RSA-AES256-GCM-SHA384
tls_preempt_cipherlist = no
tls_ssl_options = NO_COMPRESSION
virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, 
proxy:mysql:/etc/postfix/sql/mysql_virtual_spamalias_maps.cf
virtual_gid_maps = static:5000
virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/
mysql_virtual_domains_maps.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/
mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 104
virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_uid_maps = static:5000

Ich finde gerade nicht die Parameter, die zu ändern sind bzw. welches Paket 
eventuell fehlerhaft sein könnte.

Viele Grüße und vielen Dank im Voraus

Andreas
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/02f7ba74/attachment-0001.htm>

From bjo at schafweide.org  Thu Sep 16 15:52:24 2021
From: bjo at schafweide.org (Bjoern Franke)
Date: Thu, 16 Sep 2021 15:52:24 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
In-Reply-To: <12180815.CXVp6WEDlD@stuttgart>
References: <12180815.CXVp6WEDlD@stuttgart>
Message-ID: <78aff35f-6aa1-c1f9-34da-1194333a11b0@schafweide.org>

Moin,

> 
> tls_medium_cipherlist = 
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

was passiert, wenn du die mal weglässt?

Grüße
bjo

From ralph at schosemail.de  Thu Sep 16 16:07:31 2021
From: ralph at schosemail.de (Ralph Meyer)
Date: Thu, 16 Sep 2021 16:07:31 +0200 (CEST)
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <22371949.eJIMzgIU6a@stuttgart>
References: <22371949.eJIMzgIU6a@stuttgart>
Message-ID: <671109014.5168.1631801251768.JavaMail.zimbra@schosemail.de>


> Hallo zusammen,

Hi,

> Sep 16 15:13:20 mx postfix/submission/smtpd[11588]: warning: TLS library
> problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../
> ssl/record/ssl3_record.c:331

die Clients versuchen SSLv3, was du verbietest ?

> smtp_tls_protocols = !SSLv2, !SSLv3


Ralph

From postfix at linuxmaker.de  Thu Sep 16 16:28:45 2021
From: postfix at linuxmaker.de (Andreas)
Date: Thu, 16 Sep 2021 16:28:45 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
In-Reply-To: <78aff35f-6aa1-c1f9-34da-1194333a11b0@schafweide.org>
References: <12180815.CXVp6WEDlD@stuttgart>
 <78aff35f-6aa1-c1f9-34da-1194333a11b0@schafweide.org>
Message-ID: <2409994.s2tSJFeG0A@stuttgart>

Am Donnerstag, 16. September 2021, 15:52:24 CEST schrieb Bjoern Franke:
> Moin,
> 
> > tls_medium_cipherlist =
> > ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES2
> > 56-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:EC
> > DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA
> > 384
> was passiert, wenn du die mal weglässt?
> 
> Grüße
> bjo
Danke

für das Feedback. In diesem Fall bekomme ich auf Clientseite die Meldung
"Fehler beim Übertragen der Nachricht. Connection to server lost."

Und auf dem Server
Sep 16 16:22:29 mx postfix/postscreen[16889]: CONNECT from [93.195.83.17]:
44312 to [192.168.1.71]:25 
Sep 16 16:22:29 mx postfix/postscreen[16889]: PREGREET 25 after 0.01 from 
[93.195.83.17]:44312: EHLO stuttgart.localnet\r\n 
Sep 16 16:22:29 mx postfix/dnsblog[16949]: addr 93.195.83.17 listed by domain 
zen.spamhaus.org as 127.0.0.10 
Sep 16 16:22:29 mx postfix/tlsproxy[17979]: CONNECT from [93.195.83.17]:44312 
Sep 16 16:22:29 mx postfix/tlsproxy[17979]: Anonymous TLS connection 
established from [93.195.83.17]:44312: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X2551
9 server-signature RSA-PSS (2048 bits) server-digest SHA256

Auf meinem anderen Postfix-Server, exakt gleiche Konfiguration (abgesehen von 
IP, Domains, Accounts) ist der Fehler nicht aufgetreten.

Grüße
Andreas
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/a3df0fbc/attachment.htm>

From postfix at linuxmaker.de  Thu Sep 16 16:38:00 2021
From: postfix at linuxmaker.de (Andreas)
Date: Thu, 16 Sep 2021 16:38:00 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <671109014.5168.1631801251768.JavaMail.zimbra@schosemail.de>
References: <22371949.eJIMzgIU6a@stuttgart>
 <671109014.5168.1631801251768.JavaMail.zimbra@schosemail.de>
Message-ID: <6427627.eHJx5CItir@stuttgart>

Am Donnerstag, 16. September 2021, 16:07:31 CEST schrieb Ralph Meyer:
> > Hallo zusammen,
> 
> Hi,
> 
> > Sep 16 15:13:20 mx postfix/submission/smtpd[11588]: warning: TLS library
> > problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version
> > number:../ ssl/record/ssl3_record.c:331
> 
> die Clients versuchen SSLv3, was du verbietest ?
> 
> > smtp_tls_protocols = !SSLv2, !SSLv3
> 
> Ralph

Habe ich korrigiert in
smtp_tls_protocols = SSLv2, SSLv3

Der Versand geht immer noch nicht:
Sep 16 16:22:29 mx postfix/tlsproxy[17979]: CONNECT from [93.195.83.17]:44312 
Sep 16 16:22:29 mx postfix/tlsproxy[17979]: Anonymous TLS connection 
established from [93.195.83.17]:44312: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X2551
9 server-signature RSA-PSS (2048 bits) server-digest SHA256

Das trat jetzt erst nach dem Systemupgrade auf.

Grüße

Andreas
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/f94e88b2/attachment.htm>

From ralph at schosemail.de  Thu Sep 16 16:59:07 2021
From: ralph at schosemail.de (Ralph Meyer)
Date: Thu, 16 Sep 2021 16:59:07 +0200 (CEST)
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <6427627.eHJx5CItir@stuttgart>
References: <22371949.eJIMzgIU6a@stuttgart>
 <671109014.5168.1631801251768.JavaMail.zimbra@schosemail.de>
 <6427627.eHJx5CItir@stuttgart>
Message-ID: <1950255640.5489.1631804347831.JavaMail.zimbra@schosemail.de>

>> > Sep 16 15:13:20 mx postfix/submission/smtpd[11588]: warning: TLS library
>> > problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version
>> > number:../ ssl/record/ssl3_record.c:331
>> 
>> die Clients versuchen SSLv3, was du verbietest ?
>> 
>> > smtp_tls_protocols = !SSLv2, !SSLv3

> Habe ich korrigiert in
> smtp_tls_protocols = SSLv2, SSLv3

Glaub ich hab mich verkuckt. smtp_tls_protocols ist glaube für das Senden.
Jetzt sprichst du anscheinend nur noch SSLv2 und 3, was so ziemlich alle
deaktiviert haben dürften. Also dort wieder !SSLv2, !SSLv3.

Schau mal bei smtpd_tls......

Ich hab leider keine Doku zur Hand. Wer weiß es ohne nachlesen zu müssen ?

Ralph


From postfix at linuxmaker.de  Thu Sep 16 17:12:34 2021
From: postfix at linuxmaker.de (Andreas)
Date: Thu, 16 Sep 2021 17:12:34 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <1950255640.5489.1631804347831.JavaMail.zimbra@schosemail.de>
References: <22371949.eJIMzgIU6a@stuttgart> <6427627.eHJx5CItir@stuttgart>
 <1950255640.5489.1631804347831.JavaMail.zimbra@schosemail.de>
Message-ID: <3589590.xVT2Nf6vWY@stuttgart>

Am Donnerstag, 16. September 2021, 16:59:07 CEST schrieb Ralph Meyer:
> >> > Sep 16 15:13:20 mx postfix/submission/smtpd[11588]: warning: TLS
> >> > library
> >> > problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version
> >> > number:../ ssl/record/ssl3_record.c:331
> >> 
> >> die Clients versuchen SSLv3, was du verbietest ?
> >> 
> >> > smtp_tls_protocols = !SSLv2, !SSLv3
> > 
> > Habe ich korrigiert in
> > smtp_tls_protocols = SSLv2, SSLv3
> 
> Glaub ich hab mich verkuckt. smtp_tls_protocols ist glaube für das Senden.
> Jetzt sprichst du anscheinend nur noch SSLv2 und 3, was so ziemlich alle
> deaktiviert haben dürften. Also dort wieder !SSLv2, !SSLv3.
> 
> Schau mal bei smtpd_tls......
> 
> Ich hab leider keine Doku zur Hand. Wer weiß es ohne nachlesen zu müssen ?
 
Geht mir genauso. Da habe ich 

smtpd_tls_security_level = may  
smtpd_tls_auth_only = yes 
smtpd_tls_ciphers = medium 
smtpd_tls_mandatory_protocols = !SSLv3 
smtpd_tls_protocols = SSLv3 
smtpd_tls_mandatory_ciphers = high 
smtpd_tls_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL 
smtpd_tls_mandatory_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL

Aber wie gesagt, das hatte bisher prima funktioniert.

Andreas
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/f1073775/attachment.htm>

From postfix at linuxmaker.de  Thu Sep 16 17:17:49 2021
From: postfix at linuxmaker.de (Andreas)
Date: Thu, 16 Sep 2021 17:17:49 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <3589590.xVT2Nf6vWY@stuttgart>
References: <22371949.eJIMzgIU6a@stuttgart>
 <1950255640.5489.1631804347831.JavaMail.zimbra@schosemail.de>
 <3589590.xVT2Nf6vWY@stuttgart>
Message-ID: <2095264.eH9LDqEdVt@stuttgart>

Am Donnerstag, 16. September 2021, 17:12:34 CEST schrieb Andreas:
> 
> Geht mir genauso. Da habe ich
> 
> smtpd_tls_security_level = may
> smtpd_tls_auth_only = yes
> smtpd_tls_ciphers = medium
> smtpd_tls_mandatory_protocols = !SSLv3
> smtpd_tls_protocols = SSLv3
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL
> smtpd_tls_mandatory_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL
> 
> Aber wie gesagt, das hatte bisher prima funktioniert.
> 
> Andreas

Am Client sehe ich wieder:
"Fehler beim Übertragen der Nachricht. Im Ablauf des SSL-Protokolls ist ein 
Fehler aufgetreten: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert 
internal error "

Und am Server:

Sep 16 17:14:42 mx postfix/postscreen[23088]: CONNECT from [93.195.83.17]:
44470 to [192.168.1.71]:25 
Sep 16 17:14:42 mx postfix/postscreen[23088]: PREGREET 25 after 0.01 from 
[93.195.83.17]:44470: EHLO stuttgart.localnet\r\n 
Sep 16 17:14:42 mx postfix/dnsblog[23091]: addr 93.195.83.17 listed by domain 
zen.spamhaus.org as 127.0.0.10 
Sep 16 17:14:42 mx postfix/tlsproxy[23101]: CONNECT from [93.195.83.17]:44470 
Sep 16 17:14:42 mx postfix/tlsproxy[23101]: TLS handshake failed for 
service=smtpd peer=[93.195.83.17]:44470 
Sep 16 17:14:42 mx postfix/tlsproxy[23101]: DISCONNECT [93.195.83.17]:44470 
Sep 16 17:14:42 mx postfix/postscreen[23088]: HANGUP after 0.01 from 
[93.195.83.17]:44470 in tests after SMTP handshake 
Sep 16 17:14:42 mx postfix/postscreen[23088]: DISCONNECT [93.195.83.17]:44470

Andreas
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/8f708d5d/attachment.htm>

From ralph at schosemail.de  Thu Sep 16 17:27:30 2021
From: ralph at schosemail.de (Ralph Meyer)
Date: Thu, 16 Sep 2021 17:27:30 +0200 (CEST)
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <2095264.eH9LDqEdVt@stuttgart>
References: <22371949.eJIMzgIU6a@stuttgart>
 <1950255640.5489.1631804347831.JavaMail.zimbra@schosemail.de>
 <3589590.xVT2Nf6vWY@stuttgart> <2095264.eH9LDqEdVt@stuttgart>
Message-ID: <441819868.5666.1631806050175.JavaMail.zimbra@schosemail.de>


Ein Versuch noch.

>> smtpd_tls_protocols = SSLv3

smtpd_tls_protocols = !SSLv3

> Sep 16 17:14:42 mx postfix/tlsproxy[23101]: TLS handshake failed for
> service=smtpd peer=[93.195.83.17]:44470

Du machst nur SSLv3.

Ralph

From bjo at schafweide.org  Thu Sep 16 17:28:17 2021
From: bjo at schafweide.org (Bjoern Franke)
Date: Thu, 16 Sep 2021 17:28:17 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
In-Reply-To: <2409994.s2tSJFeG0A@stuttgart>
References: <12180815.CXVp6WEDlD@stuttgart>
 <78aff35f-6aa1-c1f9-34da-1194333a11b0@schafweide.org>
 <2409994.s2tSJFeG0A@stuttgart>
Message-ID: <e00637a8-e522-73f2-03c0-bb513c738ac3@schafweide.org>

Moin,
> 
> Sep 16 16:22:29 mx postfix/postscreen[16889]: CONNECT from 
> [93.195.83.17]:44312 to [192.168.1.71]:25
> Sep 16 16:22:29 mx postfix/postscreen[16889]: PREGREET 25 after 0.01 
> from [93.195.83.17]:44312: EHLO stuttgart.localnet\r\n
> Sep 16 16:22:29 mx postfix/dnsblog[16949]: addr 93.195.83.17 listed by 
> domain zen.spamhaus.org as 127.0.0.10
> Sep 16 16:22:29 mx postfix/tlsproxy[17979]: CONNECT from 
> [93.195.83.17]:44312
> Sep 16 16:22:29 mx postfix/tlsproxy[17979]: Anonymous TLS connection 
> established from [93.195.83.17]:44312: TLSv1.3 with cipher 
> TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X2551
> 9 server-signature RSA-PSS (2048 bits) server-digest SHA256
> 
> Auf meinem anderen Postfix-Server, exakt gleiche Konfiguration 
> (abgesehen von IP, Domains, Accounts) ist der Fehler nicht aufgetreten.

meint Client bei dir einen anderen Server, der Mails einliefert, oder 
ein MUA? Der sollte nicht auf Port 25 verbinden, wenn dort Postscreen rennt.

VG


From postfix at linuxmaker.de  Thu Sep 16 17:38:36 2021
From: postfix at linuxmaker.de (Andreas)
Date: Thu, 16 Sep 2021 17:38:36 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
In-Reply-To: <e00637a8-e522-73f2-03c0-bb513c738ac3@schafweide.org>
References: <12180815.CXVp6WEDlD@stuttgart> <2409994.s2tSJFeG0A@stuttgart>
 <e00637a8-e522-73f2-03c0-bb513c738ac3@schafweide.org>
Message-ID: <4434576.1ZGV1M3uWY@stuttgart>

Am Donnerstag, 16. September 2021, 17:28:17 CEST schrieb Bjoern Franke:
> meint Client bei dir einen anderen Server, der Mails einliefert, oder
> ein MUA? Der sollte nicht auf Port 25 verbinden, wenn dort Postscreen rennt.

Mit Client meine ich einen ganz normalen email-Client für Endbenutzer.

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/d07d3acd/attachment.htm>

From postfix at linuxmaker.de  Thu Sep 16 17:39:39 2021
From: postfix at linuxmaker.de (Andreas)
Date: Thu, 16 Sep 2021 17:39:39 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <441819868.5666.1631806050175.JavaMail.zimbra@schosemail.de>
References: <22371949.eJIMzgIU6a@stuttgart> <2095264.eH9LDqEdVt@stuttgart>
 <441819868.5666.1631806050175.JavaMail.zimbra@schosemail.de>
Message-ID: <8880851.WmlsqK6tX6@stuttgart>

Am Donnerstag, 16. September 2021, 17:27:30 CEST schrieb Ralph Meyer:
> Ein Versuch noch.
> 
> >> smtpd_tls_protocols = SSLv3
> 
> smtpd_tls_protocols = !SSLv3
> 
> > Sep 16 17:14:42 mx postfix/tlsproxy[23101]: TLS handshake failed for
> > service=smtpd peer=[93.195.83.17]:44470
> 
> Du machst nur SSLv3.
> 
> Ralph

Das ändert nur die Meldung am Mailclient:

"Fehler beim Übertragen der Nachricht. Connection to server lost. "

Andreas
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/a52b9812/attachment.htm>

From postfix at linuxmaker.de  Thu Sep 16 17:47:36 2021
From: postfix at linuxmaker.de (Andreas)
Date: Thu, 16 Sep 2021 17:47:36 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
In-Reply-To: <4434576.1ZGV1M3uWY@stuttgart>
References: <12180815.CXVp6WEDlD@stuttgart>
 <e00637a8-e522-73f2-03c0-bb513c738ac3@schafweide.org>
 <4434576.1ZGV1M3uWY@stuttgart>
Message-ID: <1735956.5htD2E6Uvd@stuttgart>

Am Donnerstag, 16. September 2021, 17:38:36 CEST schrieb Andreas:
> Am Donnerstag, 16. September 2021, 17:28:17 CEST schrieb Bjoern Franke:
> > meint Client bei dir einen anderen Server, der Mails einliefert, oder
> > ein MUA? Der sollte nicht auf Port 25 verbinden, wenn dort Postscreen
> > rennt.
> Mit Client meine ich einen ganz normalen email-Client für Endbenutzer.

Ach ja, die verbinden sich an Port 587 Submission.

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/da3172c9/attachment.htm>

From list+postfixbuch at gcore.biz  Thu Sep 16 17:59:36 2021
From: list+postfixbuch at gcore.biz (Gerald Galster)
Date: Thu, 16 Sep 2021 17:59:36 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <671109014.5168.1631801251768.JavaMail.zimbra@schosemail.de>
References: <22371949.eJIMzgIU6a@stuttgart>
 <671109014.5168.1631801251768.JavaMail.zimbra@schosemail.de>
Message-ID: <8C7C03B1-F961-4B07-A478-8679802B1C78@gcore.biz>

>> Sep 16 15:13:20 mx postfix/submission/smtpd[11588]: warning: TLS library
>> problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../
>> ssl/record/ssl3_record.c:331
> 
> die Clients versuchen SSLv3, was du verbietest ?

ssl3_* sind interne Funktionsnamen von openssl, die auch bei TLS verwendet werden.
Das hat nicht unbedingt etwas mit der verwendeten TLS/SSL Version zu tun.

>> smtp_tls_protocols = !SSLv2, !SSLv3

smtp_* ist für postfix als client, d.h. wenn postfix E-Mails an einen anderen
Mailserver schickt. smtpd_* ist für postfix als Server, d.h. wenn Mails
angenommen werden.

Viele Grüße
Gerald

From list+postfixbuch at gcore.biz  Thu Sep 16 17:57:21 2021
From: list+postfixbuch at gcore.biz (Gerald Galster)
Date: Thu, 16 Sep 2021 17:57:21 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <8880851.WmlsqK6tX6@stuttgart>
References: <22371949.eJIMzgIU6a@stuttgart> <2095264.eH9LDqEdVt@stuttgart>
 <441819868.5666.1631806050175.JavaMail.zimbra@schosemail.de>
 <8880851.WmlsqK6tX6@stuttgart>
Message-ID: <3197BA42-78CB-4EB4-8546-D6360274417C@gcore.biz>

> "Fehler beim Übertragen der Nachricht. Connection to server lost. "

Wie heißt der Server denn, damit man von extern das Zertifikat überprüfen kann?

Viele Grüße
Gerald
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/ec907b9e/attachment-0001.htm>

From list+postfixbuch at gcore.biz  Thu Sep 16 18:37:07 2021
From: list+postfixbuch at gcore.biz (Gerald Galster)
Date: Thu, 16 Sep 2021 18:37:07 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <3589590.xVT2Nf6vWY@stuttgart>
References: <22371949.eJIMzgIU6a@stuttgart> <6427627.eHJx5CItir@stuttgart>
 <1950255640.5489.1631804347831.JavaMail.zimbra@schosemail.de>
 <3589590.xVT2Nf6vWY@stuttgart>
Message-ID: <592476B5-6103-4AB1-92F0-6088EB016046@gcore.biz>

> smtpd_tls_ciphers = medium 
> smtpd_tls_mandatory_ciphers = high 

Ist der Unterschied zwischen den beiden gewollt?


https://syslink.pl/cipherlist/ empfiehlt:

smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/postfix.cert
smtpd_tls_key_file = /etc/ssl/postfix.key
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_mandatory_ciphers = medium
tls_medium_cipherlist = EECDH+AESGCM:EDH+AESGCM
tls_preempt_cipherlist = yes


Das Zertifikat von extern kannst Du z.B. so überprüfen:

openssl s_client -connect mailserver.de:25 -servername mailserver.de -starttls smtp -showcerts -debug -verify 5

Viele Grüße
Gerald
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210916/ec10126d/attachment.htm>

From postfix at linuxmaker.de  Fri Sep 17 09:41:17 2021
From: postfix at linuxmaker.de (Andreas)
Date: Fri, 17 Sep 2021 09:41:17 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <592476B5-6103-4AB1-92F0-6088EB016046@gcore.biz>
References: <22371949.eJIMzgIU6a@stuttgart> <3589590.xVT2Nf6vWY@stuttgart>
 <592476B5-6103-4AB1-92F0-6088EB016046@gcore.biz>
Message-ID: <1692353.O1egxhRhFb@stuttgart>

Guten Morgen Gerald,

Am Donnerstag, 16. September 2021, 18:37:07 CEST schrieb Gerald Galster:
> > smtpd_tls_ciphers = medium
> > smtpd_tls_mandatory_ciphers = high
> 
> Ist der Unterschied zwischen den beiden gewollt?
> 
Offen gesagt nein, das hatte ich aus einer Anleitung damals übernommen, die 
das so empfahl.

> 
> https://syslink.pl/cipherlist/ empfiehlt:
> 
> smtpd_use_tls = yes
> smtpd_tls_security_level = may
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/ssl/postfix.cert
> smtpd_tls_key_file = /etc/ssl/postfix.key
> smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
> smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
> smtpd_tls_mandatory_ciphers = medium
> tls_medium_cipherlist = EECDH+AESGCM:EDH+AESGCM
> tls_preempt_cipherlist = yes
> 
Vielen Dank für den Hinweis :-)

> 
> Das Zertifikat von extern kannst Du z.B. so überprüfen:
> 
> openssl s_client -connect mailserver.de:25 -servername mailserver.de
> -starttls smtp -showcerts -debug -verify 5

Ja, Du hast Recht, der Server lautet mx.germany.com. Ich hatte bereits gestern 

openssl s_client -connect mx.germany.com:587 -starttls smtp
openssl s_client -connect mx.germany.com:25 -starttls smtp

getestet, sah aber nichts was unstimmig wäre.

Inzwischen habe ich das Feedback erhalten, dass die Authenfizierung wieder 
klappt. Trotzdem wäre es mir lieb, zu verstehen, was da schiefgelaufen war 
nach dem Dist-Upgrade. Vor allem wenn diese Config vorher monatelang ohne 
Probleme gelaufen ist.

Grüße

Andreas


-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210917/55e81329/attachment.htm>

From list+postfixbuch at gcore.biz  Fri Sep 17 13:40:50 2021
From: list+postfixbuch at gcore.biz (Gerald Galster)
Date: Fri, 17 Sep 2021 13:40:50 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <1692353.O1egxhRhFb@stuttgart>
References: <22371949.eJIMzgIU6a@stuttgart> <3589590.xVT2Nf6vWY@stuttgart>
 <592476B5-6103-4AB1-92F0-6088EB016046@gcore.biz>
 <1692353.O1egxhRhFb@stuttgart>
Message-ID: <D7178D4C-4974-4D2C-A17C-68F0A25F67F5@gcore.biz>

Hallo Andreas,

> Inzwischen habe ich das Feedback erhalten, dass die Authenfizierung wieder klappt. Trotzdem wäre es mir lieb, zu verstehen, was da schiefgelaufen war nach dem Dist-Upgrade. Vor allem wenn diese Config vorher monatelang ohne Probleme gelaufen ist.


mein Mailserver läuft leider mit CentOS aber vielleicht tritt das Problem im Laufe der Zeit auch bei anderen auf.

Falls Du ein Backup des alten Systems hast könntest Du dort postconf ausführen und mit der Ausgabe vom aktuellen postconf vergleichen (diff).
Vielleicht haben sich Standardwerte geändert (seitens postfix oder Debian).

http://www.postfix.org/postconf.5.html#compatibility_level
http://www.postfix.org/COMPATIBILITY_README.html

Viele Grüße
Gerald
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210917/71f17e04/attachment.htm>

From andreas.schulze at datev.de  Fri Sep 17 17:17:46 2021
From: andreas.schulze at datev.de (A. Schulze)
Date: Fri, 17 Sep 2021 17:17:46 +0200
Subject: SSL routines:ssl3_get_record:wrong version number
In-Reply-To: <22371949.eJIMzgIU6a@stuttgart>
References: <22371949.eJIMzgIU6a@stuttgart>
Message-ID: <e7771321-2b5a-b5b5-d9ee-dd61769d9a36@datev.de>

Am 16.09.2021 um 15:33 schrieb Andreas:

> ich habe ein Dist-Upgrade von Debian-Buster auf Bullseyes gemacht und nach einem Reboot melden die Mail-Benutzer, dass an ihren Clients ein Timeout stattfindet und kein Mailabgleich mehr möglich ist.


> smtpd_tls_mandatory_protocols = !SSLv3
> smtpd_tls_protocols = !SSLv3

mit der Einstellung ist postfix-Seitig TLS1.0 oder höher aktiv. Vermutlich hast Du Clients,
die nun nicht mehr funktionieren und welche, die kein Problem haben.
Die, mit Problem, siehst Du im Log. Die verwenden vermutlich noch TLS1.0

Schau mal in Deine /etc/ssl/openssl.cnf. Dort wird **systemweit** eine minimale TLS-Version festgelegt.
Daran kommt auch Postfix nicht vorbei, selbst wenn man smtpd_tls_mandatory_protocols explizit auf TLSv1 stellt.
Dann ist die Schnittmenge 0 und TLS geht gar nicht mehr.

Stretch: https://sources.debian.org/src/openssl/1.1.0l-1%7Edeb9u1/apps/openssl.cnf/ (da fehlt die Einstellung noch)
und hier ist der Schalter, den ich meine
Buster: https://sources.debian.org/src/openssl/1.1.1d-0+deb10u6/apps/openssl.cnf/#L361
Bullseye: https://sources.debian.org/src/openssl/1.1.1k-1/apps/openssl.cnf/#L361

-> https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html
-> https://tk-sls.de/wp/5200


Andreas


From joerg at backschues.de  Sat Sep 18 14:10:52 2021
From: joerg at backschues.de (=?UTF-8?Q?J=c3=b6rg_Backschues?=)
Date: Sat, 18 Sep 2021 14:10:52 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
In-Reply-To: <1735956.5htD2E6Uvd@stuttgart>
References: <12180815.CXVp6WEDlD@stuttgart>
 <e00637a8-e522-73f2-03c0-bb513c738ac3@schafweide.org>
 <4434576.1ZGV1M3uWY@stuttgart> <1735956.5htD2E6Uvd@stuttgart>
Message-ID: <09c5519f-4741-6989-6c88-930279fac0ce@backschues.de>

Am 16.09.21 um 17:47 schrieb Andreas:

> Ach ja, die verbinden sich an Port 587 Submission.

Ein kleiner Tipp:

Grundsätzlich würde ich für das Versenden von E-Mails durch Endbenutzer 
keine opportunistische Verschlüsselung mehr über den Port 587 benutzen 
sondern auf Port 465 zurückgreifen. Da ist die Verschlüsselung nämlich 
verpflichtend.

Technisch wird das Thema recht gut im Privacy-Handbuch 
(<https://www.privacy-handbuch.de/handbuch_31c.htm>) beschrieben.

-- 
Gruß Jörg



From juri at koschikode.com  Sat Sep 18 15:39:26 2021
From: juri at koschikode.com (Juri Haberland)
Date: Sat, 18 Sep 2021 15:39:26 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
In-Reply-To: <09c5519f-4741-6989-6c88-930279fac0ce@backschues.de>
References: <12180815.CXVp6WEDlD@stuttgart>
 <e00637a8-e522-73f2-03c0-bb513c738ac3@schafweide.org>
 <4434576.1ZGV1M3uWY@stuttgart> <1735956.5htD2E6Uvd@stuttgart>
 <09c5519f-4741-6989-6c88-930279fac0ce@backschues.de>
Message-ID: <1c9916bf-4f75-5505-3fae-e9b7519f04e7@koschikode.com>

On 18.09.21 14:10, Jörg Backschues wrote:
> Am 16.09.21 um 17:47 schrieb Andreas:
> 
>> Ach ja, die verbinden sich an Port 587 Submission.

> Grundsätzlich würde ich für das Versenden von E-Mails durch Endbenutzer 
> keine opportunistische Verschlüsselung mehr über den Port 587 benutzen 
> sondern auf Port 465 zurückgreifen. Da ist die Verschlüsselung nämlich 
> verpflichtend.

Die Verschlüsselung auf Port 587 ist nicht opportunistisch, sondern
verpflichtend. Alles andere ist fehlkonfiguriert/-informiert.

Grüße,
  Juri

From juri at koschikode.com  Sat Sep 18 16:17:41 2021
From: juri at koschikode.com (Juri Haberland)
Date: Sat, 18 Sep 2021 16:17:41 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
In-Reply-To: <1c9916bf-4f75-5505-3fae-e9b7519f04e7@koschikode.com>
References: <12180815.CXVp6WEDlD@stuttgart>
 <e00637a8-e522-73f2-03c0-bb513c738ac3@schafweide.org>
 <4434576.1ZGV1M3uWY@stuttgart> <1735956.5htD2E6Uvd@stuttgart>
 <09c5519f-4741-6989-6c88-930279fac0ce@backschues.de>
 <1c9916bf-4f75-5505-3fae-e9b7519f04e7@koschikode.com>
Message-ID: <e4ed2825-b5e6-0a7b-ffa3-8ee121f1c575@koschikode.com>

On 18.09.21 15:39, Juri Haberland wrote:
> On 18.09.21 14:10, Jörg Backschues wrote:
>> Am 16.09.21 um 17:47 schrieb Andreas:
>> 
>>> Ach ja, die verbinden sich an Port 587 Submission.
> 
>> Grundsätzlich würde ich für das Versenden von E-Mails durch Endbenutzer 
>> keine opportunistische Verschlüsselung mehr über den Port 587 benutzen 
>> sondern auf Port 465 zurückgreifen. Da ist die Verschlüsselung nämlich 
>> verpflichtend.
> 
> Die Verschlüsselung auf Port 587 ist nicht opportunistisch, sondern
> verpflichtend. Alles andere ist fehlkonfiguriert/-informiert.

Hmm, manchmal sollte man erst nachlesen und dann posten:
STARTTLS auf Port 587 scheint tatsächlich nur den Status "may" zu haben :-/
Allerdings bringt Postfix in seiner default-Konfiguration das
verpflichtende STARTTLS mit.

Wie dem auch sei:
Beide Ports sind ok - sofern korrekt konfiguriert, aber der Einheitlichkeit
wegen wird mittlerweile tatsächlich 465 empfohlen - und weil einige
Implementationen von STARTTLS (aber wohl nicht bei Postfix) fehlerhaft sind.

Also entschuldigt die Störung :-)

Grüße,
  Juri

From list+postfixbuch at gcore.biz  Sat Sep 18 17:40:17 2021
From: list+postfixbuch at gcore.biz (Gerald Galster)
Date: Sat, 18 Sep 2021 17:40:17 +0200
Subject: TLS library problem: error:1408F10B:SSL
 routines:ssl3_get_record:wrong version number
In-Reply-To: <e4ed2825-b5e6-0a7b-ffa3-8ee121f1c575@koschikode.com>
References: <12180815.CXVp6WEDlD@stuttgart>
 <e00637a8-e522-73f2-03c0-bb513c738ac3@schafweide.org>
 <4434576.1ZGV1M3uWY@stuttgart> <1735956.5htD2E6Uvd@stuttgart>
 <09c5519f-4741-6989-6c88-930279fac0ce@backschues.de>
 <1c9916bf-4f75-5505-3fae-e9b7519f04e7@koschikode.com>
 <e4ed2825-b5e6-0a7b-ffa3-8ee121f1c575@koschikode.com>
Message-ID: <24584CAA-EADD-4545-8C04-E7D8D5BA80F2@gcore.biz>

>>>> Ach ja, die verbinden sich an Port 587 Submission.
>> 
>>> Grundsätzlich würde ich für das Versenden von E-Mails durch Endbenutzer 
>>> keine opportunistische Verschlüsselung mehr über den Port 587 benutzen 
>>> sondern auf Port 465 zurückgreifen. Da ist die Verschlüsselung nämlich 
>>> verpflichtend.
>> 
>> Die Verschlüsselung auf Port 587 ist nicht opportunistisch, sondern
>> verpflichtend. Alles andere ist fehlkonfiguriert/-informiert.
> 
> Hmm, manchmal sollte man erst nachlesen und dann posten:
> STARTTLS auf Port 587 scheint tatsächlich nur den Status "may" zu haben :-/
> Allerdings bringt Postfix in seiner default-Konfiguration das
> verpflichtende STARTTLS mit.

Falls Du smtpd_tls_auth_only meinst, das sollte man für submission zwar
aktivieren, ist aber keine Standardeinstellung:

http://www.postfix.org/postconf.5.html#smtpd_tls_auth_only

So wie ich es verstanden hab bedeutet opportunistisch in dem Zusammenhang,
dass STARTTLS verwendet wird wenn es angeboten wird. Das wäre ähnlich dem
tls security level "may" bei ausgehenden Verbindungen (postfix als Client),
der aber nur schaut ob es ein Zertifikat gibt und weder CA noch Common Name
verifiziert.

Als Server spielt der security level meist keine Rolle da der E-Mail Client
das Zertifikat überprüft (CA + Common-/Subject alternative name). Seitens
postfix hätte das nur Bedeutung wenn sich der E-Mail Client über ein
TLS-Zertifikat identifiziert (TLS client auth), quasi als Ersatz für
Username/Password.

> Wie dem auch sei:
> Beide Ports sind ok - sofern korrekt konfiguriert, aber der Einheitlichkeit
> wegen wird mittlerweile tatsächlich 465 empfohlen - und weil einige
> Implementationen von STARTTLS (aber wohl nicht bei Postfix) fehlerhaft sind.


Es war wohl möglich weitere Befehle in das STARTTLS Paket zu schmuggeln,
die danach im TLS-Context ausgeführt wurden.

https://lwn.net/Articles/866481/

Viele Grüße
Gerald

From ffiene at veka.com  Sat Sep 18 18:39:37 2021
From: ffiene at veka.com (Frank Fiene)
Date: Sat, 18 Sep 2021 18:39:37 +0200
Subject: Eigene Relay vor MS365
Message-ID: <7369EC54-3B25-4191-AE90-41C8EFFBD881@veka.com>

Moin!

Ich wollte mal eure Meinung einholen:


Wir wechseln gerade zu Exchange in der Cloud (Umstellung auf MS365).
Aus Sicherheitsaspekten ist das eh schon nicht optimal.

Wir haben ja unsere eigenen Mailrelay mit Postfix und rspamd.

Macht es Sinn, die weiterhin vor den Cloud-Exchange-Servern als Relays zu benutzen?

Im MS365 kann man ja z.B. keine Spam-Mails abweisen anstatt sie zu markieren und in eine Quarantäne zu schieben.

Wie gut sind die Filter im Cloud-Exchange von MS365?



Viele Grüße!
Frank
--
Frank Fiene
IT-Security Manager VEKA Group

Fon: +49 2526 29-6200
Fax: +49 2526 29-16-6200
mailto: ffiene at veka.com
http://www.veka.com

PGP-ID: 62112A51
PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51
Threema: VZK5NDWW

VEKA AKTIENGESELLSCHAFT
Dieselstr. 8
48324 Sendenhorst
Deutschland/Germany
http://www.veka.com

Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
Pascal Heitmar, Josef L. Beckhoff, Elke Hartleif, Dr. Werner Schuler,
Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Dr. Andreas W. Hillebrand

HRB 8282 AG Münster/District Court of Münster

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210918/a6dc0b2f/attachment.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: Message signed with OpenPGP
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210918/a6dc0b2f/attachment.asc>

From ffiene at veka.com  Sat Sep 18 18:43:35 2021
From: ffiene at veka.com (Frank Fiene)
Date: Sat, 18 Sep 2021 18:43:35 +0200
Subject: postfix Auswertungen in Graylog
In-Reply-To: <52b8d368-bc64-ec8b-f301-846f6a905436@xunil.at>
References: <ae2f0442-ce16-74c8-cf16-c96c22cb4115@xunil.at>
 <538b1616-ec94-06f2-82b0-1b90e11cbef0@bodici.de>
 <52b8d368-bc64-ec8b-f301-846f6a905436@xunil.at>
Message-ID: <EEF9CEE5-6956-4FD3-8EC7-95C6544DEE5F@veka.com>

Ja, wir machen sowas.

Ich habe schon alle Sachen ausprobiert, die man finden konnte, Grok-Filter, Graylog-Plugin.

Funktioniert irgendwie alles nicht.

In Graylog muss man anscheinend vieles selber machen, das ist nicht optimal.
Ich hätte erwartet, dass wenigsten so weit verbreitete Logs wie das von Postfix im Standard vernünftig verstanden werden.

Zum Lesen der Log-Einträge reicht es, aber die Felder werden nicht so richtig in Variablen aufgeteilt.


> Am 16.09.2021 um 12:49 schrieb Stefan G. Weichinger <lists at xunil.at>:
> 
> Am 16.09.21 um 11:01 schrieb Florian:
>> Hallo Stefan,
>> was genau willst du denn tun? Für eine tägliche Übersicht über meine Logs bin ich mit pflogsumm ganz zufrieden. Wenn es in Richtung Spamfilter (trainieren) geht, setze ich auf rspamd. Für umfangreichere statistische Auswertungen kann man elasticsearch/Kibana verwenden. Vielleicht sitzt Graylog irgendwo dazwischen?
> 
> Graylog verwendet ElasticSearch als "Backend", also käme das sowieso mit.
> 
> Ich soll für einen Kunden eine Abfrage-Anwendung bauen, die einerseits ein paar Standard-Statistiken bereit stellt, und weiters zB Export-Möglichkeiten bieten soll.
> 
> Da geht es um Compliance-Themen, und es braucht eine mächtigere GUI für Abfragen und Suchen, etc
> 
> Und auch um 1 Jahr Aufbewahrungsfrist ... da macht es Sinn, ein sinnvolles Backend für die Logs zu haben.
> 
> Daher kamen wir auf Graylog, weil wir das an anderer Stelle gerade einbauen, für Debian-Syslogs usw.
> 

Viele Grüße!
Frank
--
Frank Fiene
IT-Security Manager VEKA Group

Fon: +49 2526 29-6200
Fax: +49 2526 29-16-6200
mailto: ffiene at veka.com
http://www.veka.com

PGP-ID: 62112A51
PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51
Threema: VZK5NDWW

VEKA AKTIENGESELLSCHAFT
Dieselstr. 8
48324 Sendenhorst
Deutschland/Germany
http://www.veka.com

Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
Pascal Heitmar, Josef L. Beckhoff, Elke Hartleif, Dr. Werner Schuler,
Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Dr. Andreas W. Hillebrand

HRB 8282 AG Münster/District Court of Münster

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210918/217b7e78/attachment-0001.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: Message signed with OpenPGP
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210918/217b7e78/attachment-0001.asc>

From wn at neessen.net  Sat Sep 18 19:09:02 2021
From: wn at neessen.net (Winfried Neessen)
Date: Sat, 18 Sep 2021 19:09:02 +0200
Subject: Eigene Relay vor MS365
In-Reply-To: <7369EC54-3B25-4191-AE90-41C8EFFBD881@veka.com>
References: <7369EC54-3B25-4191-AE90-41C8EFFBD881@veka.com>
Message-ID: <43BC96D5-393F-48EB-9F36-D7C786574B41@neessen.net>

Hi Frank,

ich würde nicht empfehlen das zu tun. Wir hatten das 'ne Zeit lang in der Übergangsphase. Hat das Troubleshooting sehr erschwert und die Junk-Filter von O365 funktionieren und lernen m. E. ziemlich gut. In meinem Junk-Order landen pro Woche ca. 300-400 SPAM Mails und die Zahl der false-postives sind nach etwas "Einlernzeit" in den ersten Wochen bei 1-2 pro Monat. 

Winni

-- 


> Am 18.09.2021 um 18:49 schrieb Frank Fiene <ffiene at veka.com>:
> 
> ?Moin!
> 
> Ich wollte mal eure Meinung einholen:
> 
> 
> Wir wechseln gerade zu Exchange in der Cloud (Umstellung auf MS365).
> Aus Sicherheitsaspekten ist das eh schon nicht optimal.
> 
> Wir haben ja unsere eigenen Mailrelay mit Postfix und rspamd.
> 
> Macht es Sinn, die weiterhin vor den Cloud-Exchange-Servern als Relays zu benutzen?
> 
> Im MS365 kann man ja z.B. keine Spam-Mails abweisen anstatt sie zu markieren und in eine Quarantäne zu schieben.
> 
> Wie gut sind die Filter im Cloud-Exchange von MS365?
> 
> 
> 
> Viele Grüße!
> Frank
> -- 
> Frank Fiene
> IT-Security Manager VEKA Group
> 
> Fon: +49 2526 29-6200
> Fax: +49 2526 29-16-6200
> mailto: ffiene at veka.com
> http://www.veka.com
> 
> PGP-ID: 62112A51
> PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51
> Threema: VZK5NDWW
> 
> VEKA AKTIENGESELLSCHAFT 
> Dieselstr. 8 
> 48324 Sendenhorst 
> Deutschland/Germany 
> http://www.veka.com 
> 
> Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), 
> Pascal Heitmar, Josef L. Beckhoff, Elke Hartleif, Dr. Werner Schuler, 
> Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Dr. Andreas W. Hillebrand 
> 
> HRB 8282 AG Münster/District Court of Münster
> 
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210918/bfafe623/attachment.htm>

From lists at xunil.at  Sun Sep 19 10:59:54 2021
From: lists at xunil.at (Stefan G. Weichinger)
Date: Sun, 19 Sep 2021 10:59:54 +0200
Subject: postfix Auswertungen in Graylog
In-Reply-To: <EEF9CEE5-6956-4FD3-8EC7-95C6544DEE5F@veka.com>
References: <ae2f0442-ce16-74c8-cf16-c96c22cb4115@xunil.at>
 <538b1616-ec94-06f2-82b0-1b90e11cbef0@bodici.de>
 <52b8d368-bc64-ec8b-f301-846f6a905436@xunil.at>
 <EEF9CEE5-6956-4FD3-8EC7-95C6544DEE5F@veka.com>
Message-ID: <455bbc82-112d-22f1-7212-3110ee259cb5@xunil.at>

Am 18.09.21 um 18:43 schrieb Frank Fiene:
> Ja, wir machen sowas.
> 
> Ich habe schon alle Sachen ausprobiert, die man finden konnte, 
> Grok-Filter, Graylog-Plugin.
> 
> Funktioniert irgendwie alles nicht.
> 
> In Graylog muss man anscheinend vieles selber machen, das ist nicht optimal.
> Ich hätte erwartet, dass wenigsten so weit verbreitete Logs wie das von 
> Postfix im Standard vernünftig verstanden werden.
> 
> Zum Lesen der Log-Einträge reicht es, aber die Felder werden nicht so 
> richtig in Variablen aufgeteilt.

Oh, verstehe.

Ich habe erste Tests mit Logs und einen gl-Container angestellt, die 
Pipelines aus diesem github-Repo

https://github.com/ntimo/graylog-mailcow-content-pack

scheinen mir sehr mächtig zu sein, und klappen bereits teilweise für mich.

Mir fehlt noch das vollständige Verständnis, wie ich die Pipelines an 
meinen Input klemme, ich hab im Unterschied zu dem obigen Projekt keine 
einzelnen Container als Lieferanten.

Vielleicht finden wir gemeinsam mehr raus.

Den Autor hab ich auch schon angeschrieben, per gh-Issue.

From harald.witt at dpfa.de  Mon Sep 27 18:28:00 2021
From: harald.witt at dpfa.de (harald.witt at dpfa.de)
Date: Mon, 27 Sep 2021 18:28:00 +0200
Subject: =?iso-8859-1?Q?Lange_Zustellverz=F6gerungen_durch_postgrey?=
Message-ID: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>

Hallo an alle.
Ich habe auf meinem uralten Debian 8 seit vielen Jahren postgrey 1.35
problemlos laufen.
Seit einigen Wochen kommt es allerdings zu enormen Verzögerungen bei der
Zustellung (mehr als 12 Stunden).
Konfiguration ist Standard, also nichts angegeben und folglich: --delay=300
Sekunden, --max-age=35 Tage.
Und so sieht das aus:

1. Versuch wird erwartungsgemäß abgelehnt:
Sep 20 07:51:43 amidala postfix/smtpd[8360]: NOQUEUE: reject: RCPT from
mail-oln040092073048.outbound.protection.outlook.com[40.92.73.48]: 450 4.2.0
… Recipient address rejected: Greylisted, …

2. Versuch von der gleichen IP-Adresse und dem gleichen Namen wird
allerdings nach 15 Minuten auch wieder abgelehnt:
Sep 20 08:06:59 amidala postfix/smtpd[9441]: NOQUEUE: reject: RCPT from
mail-oln040092075048.outbound.protection.outlook.com[40.92.75.48]: 450 4.2.0
… Recipient address rejected: Greylisted, …

Und das geht dann den ganzen Tag, z. T. mit wechselnden Adressen und Namen,
so weiter … gekürzt …
Sep 20 08:24:20 amidala postfix/smtpd[10370]: NOQUEUE: reject: RCPT from
mail-oln040092069063.outbound.protection.outlook.com[40.92.69.63]: 450 4.2.0
… Recipient address rejected: Greylisted, …
…
Sep 20 17:25:02 amidala postfix/smtpd[18003]: NOQUEUE: reject: RCPT from
mail-oln040092070029.outbound.protection.outlook.com[40.92.70.29]: 450 4.2.0
… Recipient address rejected: Greylisted, …

Bis es irgendwann mal klappt:
Sep 20 18:24:25 amidala postgrey[1254]: action=pass, reason=triplet found,
delay=7123,
client_name=mail-vi1eur05olkn2051.outbound.protection.outlook.com,
client_address=40.92.90.51, …

Hat jemand einen Tipp, woher dieses Verhalten so plötzlich kommen kann?
Habe jetzt erstmal postgrey deaktiviert. Ist ja aber nicht im Sinne des
Erfinders.

Viele Dank schon mal
Harald

 

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210927/c26beeef/attachment.htm>

From ml at irmawi.de  Mon Sep 27 21:06:16 2021
From: ml at irmawi.de (Markus Winkler)
Date: Mon, 27 Sep 2021 21:06:16 +0200
Subject: =?UTF-8?Q?Re=3a_Lange_Zustellverz=c3=b6gerungen_durch_postgrey?=
In-Reply-To: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>
References: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>
Message-ID: <88b47029-d4ab-1794-02ed-bb39ed5c1c59@irmawi.de>

Hallo Harald,

On 27.09.21 18:28, harald.witt at dpfa.de wrote:
> mail-oln040092073048.outbound.protection.outlook.com[40.92.73.48]:
> mail-oln040092075048.outbound.protection.outlook.com[40.92.75.48]:
> mail-oln040092069063.outbound.protection.outlook.com[40.92.69.63]:
> mail-oln040092070029.outbound.protection.outlook.com[40.92.70.29]:
> mail-vi1eur05olkn2051.outbound.protection.outlook.com, 
> client_address=40.92.90.51, ?

> Hat jemand einen Tipp, woher dieses Verhalten so plötzlich kommen kann?

vielleicht haben die jetzt einen Haufen mehr Ausgangsrelay als bisher?

> Habe jetzt erstmal postgrey deaktiviert. Ist ja aber nicht im Sinne des 
> Erfinders.

Was Du mal versuchen könntest (ich kann mich nicht mehr ganz genau 
erinnern, ist schon eine Weile her, dass ich postgrey benutzt hatte):

Wenn Du --lookup-by-subnet verwendest, kannst Du mittels --ipv4cidr=N bzw. 
--ipv6cidr=N angeben, mit welcher Netzmaske es arbeiten soll - bei IPv4 
statt dem Default 24 also z. B. 16. Dann würde es bei den oben gezeigten 
M365-Servern schon beim zweiten Versuch matchen und die Mail wäre da.

IIRC wurden diese Optionen früher durch den CIDR-Patch zur Verfügung 
gestellt, der aber später in die reguläre postgrey-Version übernommen wurde.

(Und vielleicht auch mal in Betracht ziehen, den Server auf den aktuellen 
Stand zu bringen. ;-))

HTH und viele Grüße
Markus

From ml at irmawi.de  Mon Sep 27 21:23:48 2021
From: ml at irmawi.de (Markus Winkler)
Date: Mon, 27 Sep 2021 21:23:48 +0200
Subject: =?UTF-8?Q?Re=3a_Lange_Zustellverz=c3=b6gerungen_durch_postgrey?=
In-Reply-To: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>
References: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>
Message-ID: <c7a88229-2111-4b53-ce9a-f77a77714353@irmawi.de>

Vergessen, noch ein Hinweis dazu:

On 27.09.21 18:28, harald.witt at dpfa.de wrote:
> 1. Versuch wird erwartungsgemäß abgelehnt:
> Sep 20 07:51:43 amidala postfix/smtpd[8360]: NOQUEUE: reject: RCPT from 
> mail-oln040092073048.outbound.protection.outlook.com[40.92.73.48]: 450 
> 4.2.0 ? Recipient address rejected: Greylisted, ?
> 
> 2. Versuch von der gleichen IP-Adresse und dem gleichen Namen wird 
> allerdings nach 15 Minuten auch wieder abgelehnt:
> Sep 20 08:06:59 amidala postfix/smtpd[9441]: NOQUEUE: reject: RCPT from 
> mail-oln040092075048.outbound.protection.outlook.com[40.92.75.48]: 450 
> 4.2.0 ? Recipient address rejected: Greylisted, ?

Der zweite Versuch kommt weder vom gleichen Servername noch von der 
gleichen IP-Adresse (73 <-> 75). ;-) Postgrey weist den also korrekt ab.

Gruß
Markus

From harald.witt at dpfa.de  Tue Sep 28 08:52:23 2021
From: harald.witt at dpfa.de (harald.witt at dpfa.de)
Date: Tue, 28 Sep 2021 08:52:23 +0200
Subject: =?iso-8859-1?Q?AW:_Lange_Zustellverz=F6gerungen_durch_postgrey?=
In-Reply-To: <c7a88229-2111-4b53-ce9a-f77a77714353@irmawi.de>
References: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>
 <c7a88229-2111-4b53-ce9a-f77a77714353@irmawi.de>
Message-ID: <000801d7b435$64463cb0$2cd2b610$@dpfa.de>

Vergessen, noch ein Hinweis dazu:

On 27.09.21 18:28, harald.witt at dpfa.de wrote:
> 1. Versuch wird erwartungsgemäß abgelehnt:
> Sep 20 07:51:43 amidala postfix/smtpd[8360]: NOQUEUE: reject: RCPT 
> from
> mail-oln040092073048.outbound.protection.outlook.com[40.92.73.48]: 450
> 4.2.0 … Recipient address rejected: Greylisted, …
> 
> 2. Versuch von der gleichen IP-Adresse und dem gleichen Namen wird 
> allerdings nach 15 Minuten auch wieder abgelehnt:
> Sep 20 08:06:59 amidala postfix/smtpd[9441]: NOQUEUE: reject: RCPT 
> from
> mail-oln040092075048.outbound.protection.outlook.com[40.92.75.48]: 450
> 4.2.0 … Recipient address rejected: Greylisted, …

Der zweite Versuch kommt weder vom gleichen Servername noch von der gleichen
IP-Adresse (73 <-> 75). ;-) Postgrey weist den also korrekt ab.

*** Oops, hatte ich doch glatt übersehen. Danke für deine Hinweise! ***

Gruß
Markus


From infoomatic at gmx.at  Tue Sep 28 11:47:16 2021
From: infoomatic at gmx.at (infoomatic)
Date: Tue, 28 Sep 2021 11:47:16 +0200
Subject: =?UTF-8?Q?Re=3a_Lange_Zustellverz=c3=b6gerungen_durch_postgrey?=
In-Reply-To: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>
References: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>
Message-ID: <8d996c65-6b5d-ce2a-4d0b-cab54ab6260d@gmx.at>

Zu deiner Frage hab ich keine Antwort, aber evtl. eine Lösung:

sieh dir mal postscreen an (das kommt mit postfix mit) - ist recht
schnell und einfach eingerichtet, und funktioniert zumindest bei mir
besser als postgrey. Dazu noch per cron job die liste von  postwhite
(https://github.com/stevejenkins/postwhite) laden und du solltest keine
Verzögerungen mehr haben.

LG,
Robert


On 27.09.21 18:28, harald.witt at dpfa.de wrote:
>
> Hallo an alle.
> Ich habe auf meinem uralten Debian 8 seit vielen Jahren postgrey 1.35
> problemlos laufen.
> ...
> Hat jemand einen Tipp, woher dieses Verhalten so plötzlich kommen kann?
> Habe jetzt erstmal postgrey deaktiviert. Ist ja aber nicht im Sinne
> des Erfinders.
>
> Viele Dank schon mal
> Harald
>
>  
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20210928/e3b170e4/attachment.htm>

From Ralf.Hildebrandt at charite.de  Tue Sep 28 11:56:40 2021
From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt)
Date: Tue, 28 Sep 2021 11:56:40 +0200
Subject: [ext] Re: Lange =?utf-8?Q?Zustellverz?=
 =?utf-8?Q?=C3=B6gerungen?= durch postgrey
In-Reply-To: <8d996c65-6b5d-ce2a-4d0b-cab54ab6260d@gmx.at>
References: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>
 <8d996c65-6b5d-ce2a-4d0b-cab54ab6260d@gmx.at>
Message-ID: <YVLm2IINbsEJNFl0@charite.de>

* infoomatic <infoomatic at gmx.at>:

> sieh dir mal postscreen an (das kommt mit postfix mit) - ist recht
> schnell und einfach eingerichtet, und funktioniert zumindest bei mir
> besser als postgrey. Dazu noch per cron job die liste von  postwhite
> (https://github.com/stevejenkins/postwhite) laden und du solltest keine
> Verzögerungen mehr haben.

Ja, der Tip mit https://github.com/stevejenkins/postwhite funktioniert
sehr gut.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebrandt at charite.de | https://www.charite.de
	    

From sd at schnied.net  Wed Sep 29 07:35:08 2021
From: sd at schnied.net (Stefan Dorn)
Date: Wed, 29 Sep 2021 07:35:08 +0200
Subject: =?UTF-8?Q?Re=3a_Lange_Zustellverz=c3=b6gerungen_durch_postgrey?=
In-Reply-To: <8d996c65-6b5d-ce2a-4d0b-cab54ab6260d@gmx.at>
References: <001301d7b3bc$a37d9960$ea78cc20$@dpfa.de>
 <8d996c65-6b5d-ce2a-4d0b-cab54ab6260d@gmx.at>
Message-ID: <5a213ee4-0703-7eed-020a-a89e1e79706d@schnied.net>

Am 28.09.2021 um 11:47 schrieb infoomatic:
> sieh dir mal postscreen an (das kommt mit postfix mit) - ist recht 
> schnell und einfach eingerichtet, und funktioniert zumindest bei mir 
> besser als postgrey. Dazu noch per cron job die liste von postwhite 
> (https://github.com/stevejenkins/postwhite) laden und du solltest 
> keine Verzögerungen mehr haben.

Hi,

dabei bitte beachten: https://github.com/stevejenkins/postwhite/issues/56

Generell werden von postwhite SPF Records abgefragt. Nur bei Yahoo 
nicht. Die haben ein "ultra-mega-superduper-security-feature", damit 
niemand ihre streng geheimen IP Adressen raus bekommt: "Yahoo!'s SPF 
record doesn't support queries to expose their netblocks"
Deswegen muss in diesem Falle eine Webseite geparsed werden. Und Yahoo 
hat aufgrund der zahlreichen Übernahmen die URL irgendwann geändert.

Der o.g. pull request für die Änderung ist seit Dezember letzten Jahres 
offen, weshalb postwhite bei einer normalen Installation für Yahoo 
nicht  tut.

Gruß

Stefan


From fk+postfix at celebrate.de  Thu Sep 30 06:38:41 2021
From: fk+postfix at celebrate.de (fk+postfix at celebrate.de)
Date: Thu, 30 Sep 2021 06:38:41 +0200
Subject: Postfix / Dovecot im Kritis Bereich
Message-ID: <a8910e52-1de6-68b5-e265-fe022d0308f7@schlema.dlrg.de>

Guten Morgen in die Runde,

betreibt hier Jemand Postix und Dovecot im Bereich eines Kritis 
Unternehmens (Energie)?
Die (BSI-Kritisverordnung - BSI-KritisV) kenne ich.
Falls ja, könnte Diese(r) bitte einen kurzen Abriss über die 
Realisierung geben? Welches OS wird eingesetzt, gibt es besondere 
Absicherungen außer den üblichen wie Portfilter, Fail2Ban, Virenscanner...

Vielen Dank, Frank


From driessen at fblan.de  Thu Sep 30 10:35:38 2021
From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Thu, 30 Sep 2021 10:35:38 +0200
Subject: AW: Postfix / Dovecot im Kritis Bereich
In-Reply-To: <a8910e52-1de6-68b5-e265-fe022d0308f7@schlema.dlrg.de>
References: <a8910e52-1de6-68b5-e265-fe022d0308f7@schlema.dlrg.de>
Message-ID: <005401d7b5d6$25abbdc0$71033940$@fblan.de>

Im Auftrag von fk+postfix at celebrate.de


> betreibt hier Jemand Postix und Dovecot im Bereich eines Kritis
> Unternehmens (Energie)?
> Die (BSI-Kritisverordnung - BSI-KritisV) kenne ich.
> Falls ja, könnte Diese(r) bitte einen kurzen Abriss über die
> Realisierung geben? Welches OS wird eingesetzt, gibt es besondere
> Absicherungen außer den üblichen wie Portfilter, Fail2Ban, Virenscanner...
> 
> Vielen Dank, Frank

1. was ist heute nicht mehr kritische Struktur 
2. warum sollte "private" Mail nicht genauso abgesichert werden 
3. was willst du denn noch mehr tun wie  das oben angegebene? 

Alles was digital ist wird gehackt werden / können , die Frage ist nicht ob sondern nur wann das passiert und welche weiteren Sicherheitsmaßnahmen dann greifen wenn es passiert ist 
Frag mal Christian der hat noch ein paar zusätzliche Überwachungen für Mailserver :-)  


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. "
"Digitalisierung heißt nicht das es WENIGER Arbeit wird. Es ist die Intelligente Art die erforderliche Arbeit auf den Kunden zu übertragen." 
Digitalisierung darf nicht zur Entmündigung und Benachteiligung der älteren brillentragenden Mitbürger führen."
" Es gibt über 2000 Jahre alte Papierdokumente, 10000 Jahre alte Steindokumente, ich wette das älteste elektronische Dokument ist noch keine 100 Jahre."