From postfixbuch-listen at jpberlin.de Mon Apr 4 09:47:20 2022 From: postfixbuch-listen at jpberlin.de (Peer Heinlein) Date: Mon, 4 Apr 2022 09:47:20 +0200 Subject: Frage zu Support In-Reply-To: <6225D241020000E90006F391@weida.hki-jena.de> References: <6225D241020000E90006F391@weida.hki-jena.de> Message-ID: <53f10b88-05af-2387-23aa-032c7edfa987@jpberlin.de> Am 07.03.22 um 10:37 schrieb Peer-Joachim Koch: Hallo, > Ursprünglich hatte ich an den Listenbetreiber gedacht, der scheint aber > kein Interesse > zu haben (seit 2 Monaten Funkstille)..... Naja, die Anfrage ist ja von Ende Februar. :-) Aber Du hast natürlich recht, ich habe eben im Ticket nachgesehen, da ist seit die Antwort im März überfällig. Auch unser Team ist im März durch Corona ordentlich durchgewirbelt worden mit bis zu 30% Krankenstand in einigen Teams (und dabei sind wir noch nicht mal im Büro) und zusammen mit laufenden Projekten oder fix angesetzten Schulungen, die dann vertreten werden mussten, sind wir hier die letzten Wochen auch in den Basics nicht mehr hinterhergekommen. Laufende Projekte müssen da Vorfahrt haben wenn der Tag zu kurz ist. Dein AP springt auch diese Woche kurzfristig als Postfix-Dozent in einemk Kurs ein, da unser anderer Kollege das kranke Kind betreuen muss. Ich gebe das aber gleich nochmal rüber, dass Du da heute Abend eine Antwort bekommst. Tut mir leid, wenn das die letzten Wochen auf der Strecke bleiben musste. Grundsätzlich sehen wir ab dieser Woche bzw. Anfang nächster Woche wieder Licht am Ende des Tunnels, dann sind alle langsam mal durch und die Kinder auch. Reicht uns dann auch, die letzten 6 Wochen waren nicht witzig. peer -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-42 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin From atann at alphasrv.net Mon Apr 4 16:02:21 2022 From: atann at alphasrv.net (Andre Tann) Date: Mon, 4 Apr 2022 16:02:21 +0200 Subject: Mails an Gmail kommen nicht an Message-ID: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> Hallo zusammen, ich habe mal wieder ein Problem bei der Mailzustellung, diesmal an Gmail. Der Effekt ist, daß die Mail überhaupt nicht zugestellt wird, weder landet sie beim Empfänger im Spam noch in irgend einem anderen Ordner des Empfängers. Auf meiner Seite sehe ich folgendes: Mar 20 23:05:13 a10 postfix/smtp[1701]: 346963EB6D: to=, relay=gmail-smtp-in.l.google.com[64.233.164.27]:25, delay=0.99, delays=0.3/0/0.26/0.43, dsn=2.0.0, status=sent (250 2.0.0 OK 1647813913 w20-20020a2e9bd4000000b0024952f7bacfsi7860917ljj.42 - gsmtp) status=sent => die Mail sollte bei Gmail wenigstens irgendwo auftauchen. Tut sie aber nicht. Wenn ich dann Testmail verschicke, um die Sache einzukreisen, dann kommen diese durchaus an. Es handelt sich also um ein sporadisches Problem. Bisher ist es mir nur bei Mails aufgefallen, die ich mit voller Signatur inkl. Logo usw. verschickt habe. Es handelt sich zwar nicht um Spam, aber vielleicht sieht Gmail das anders. Aber deswegen gleich die ganze Mail zu verwerfen? Meine Frage ist: Gibt es bei Gmail Einstellungen, die dazu führen, daß Mails gelöscht werden? Oder sowas wie "Spam-Score > 20 => löschen". Oder hat jemand noch Ideen? -- Andre Tann From harald.witt at dpfa.de Mon Apr 4 19:02:35 2022 From: harald.witt at dpfa.de (harald.witt at dpfa.de) Date: Mon, 4 Apr 2022 19:02:35 +0200 Subject: AW: Mails an Gmail kommen nicht an In-Reply-To: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> References: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> Message-ID: <000e01d84845$c88803d0$59980b70$@dpfa.de> Nur mal so zum Lachen oder Nachdenken oder eventuell auch als korrekte Antwort? In MS-Outlook gibt es die Möglichkeit, den Spamverdacht so einzustellen, dass die betroffene E-Mail ohne zu Fragen gelöscht wird. Ich hatte selbst schon ein solches Erlebnis der dritten MS-Art. Grüße Harald -----Ursprüngliche Nachricht----- Von: Postfixbuch-users Im Auftrag von Andre Tann via Postfixbuch-users Gesendet: Montag, 4. April 2022 16:02 An: postfixbuch-users at listen.jpberlin.de Cc: Andre Tann Betreff: Mails an Gmail kommen nicht an Hallo zusammen, ich habe mal wieder ein Problem bei der Mailzustellung, diesmal an Gmail. Der Effekt ist, daß die Mail überhaupt nicht zugestellt wird, weder landet sie beim Empfänger im Spam noch in irgend einem anderen Ordner des Empfängers. Auf meiner Seite sehe ich folgendes: Mar 20 23:05:13 a10 postfix/smtp[1701]: 346963EB6D: to=, relay=gmail-smtp-in.l.google.com[64.233.164.27]:25, delay=0.99, delays=0.3/0/0.26/0.43, dsn=2.0.0, status=sent (250 2.0.0 OK 1647813913 w20-20020a2e9bd4000000b0024952f7bacfsi7860917ljj.42 - gsmtp) status=sent => die Mail sollte bei Gmail wenigstens irgendwo auftauchen. Tut sie aber nicht. Wenn ich dann Testmail verschicke, um die Sache einzukreisen, dann kommen diese durchaus an. Es handelt sich also um ein sporadisches Problem. Bisher ist es mir nur bei Mails aufgefallen, die ich mit voller Signatur inkl. Logo usw. verschickt habe. Es handelt sich zwar nicht um Spam, aber vielleicht sieht Gmail das anders. Aber deswegen gleich die ganze Mail zu verwerfen? Meine Frage ist: Gibt es bei Gmail Einstellungen, die dazu führen, daß Mails gelöscht werden? Oder sowas wie "Spam-Score > 20 => löschen". Oder hat jemand noch Ideen? -- Andre Tann From fk+postfix at celebrate.de Tue Apr 5 09:50:45 2022 From: fk+postfix at celebrate.de (fk+postfix at celebrate.de) Date: Tue, 5 Apr 2022 09:50:45 +0200 Subject: Logeintrag erzeugen Message-ID: <0a603c89-0054-dc09-daed-60478baa78e6@celebrate.de> Hallo zusammen, ich nutze Postfix 2.10.1 Bei den *smtpd_recipient_restrictions***habe ich eine whitelist mit den Mailserver IPs unserer wichtigsten und zuverlässigsten Geschäftspartnern hinterlegt: *check_client_access cidr:/etc/postfix/whitelist/postfix-dnswl-permit* die Datei *postfix-dnswl-permit* sieht wie folgt aus: *94.199.93.163/32    permit_auth_destination* Der Whitelist Check wird vor den *reject_rbl_client* Abfragen durchgeführt, den letzten Überprüfungen in meiner Kette. Frage: gibt es die Möglichkeit, dass wenn ein Treffer in der white list erfolgte, darüber einen Eintrag ins Log zu bekommen? So in der Art:/94.199.93.163 found in white list/ Viele Grüße, Frank -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From lists at xunil.at Tue Apr 5 10:43:55 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Tue, 5 Apr 2022 10:43:55 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? Message-ID: Mein postfix/dovecot-Setup ist eigentlich seit Jahren recht robust am Laufen. Ich hab mich auch nicht mehr allzu aktiv damit befasst, weil es eben sehr ok zu funktionieren schien. Letztens beobachte ich Verzögerungen beim Versenden von Mails und muss mich nun wieder etwas näher einarbeiten. - Ich versende aus Thunderbird 91.7.0 unter Fedora 35, per STARTTLS, auf Port 587. Und in letzter Zeit braucht das immer einige Zeit, bis das Mail dann endlich raus geht. So ein Vorgang sieht in etwa so aus: journalctl --since 10:00 -u postfix | grep 38541 Apr 05 10:33:03 oc.oops.co.at postfix/submission/smtpd[38541]: initializing the server-side TLS engine Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: connect from localhost[127.0.0.1] Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: setting up TLS connection from localhost[127.0.0.1] Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: localhost[127.0.0.1]: TLS cipher list "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" Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:before SSL initialization Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:before SSL initialization Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL3 alert write:fatal:protocol version Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:error in error Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept error from localhost[127.0.0.1]: -1 Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:ssl/statem/statem_srvr.c:1685: Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: lost connection after STARTTLS from localhost[127.0.0.1] Apr 05 10:33:04 oc.oops.co.at postfix/submission/smtpd[38541]: disconnect from localhost[127.0.0.1] ehlo=1 starttls=0/1 commands=1/2 Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: connect from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: setting up TLS connection from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: TLS cipher list "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" Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:before SSL initialization Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:before SSL initialization Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: Decrypting session ticket, key expiration: 1649146784 Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:SSLv3/TLS read client hello Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:SSLv3/TLS write server hello Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:SSLv3/TLS write change cipher spec Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:TLSv1.3 write encrypted extensions Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:SSLv3/TLS write finished Apr 05 10:36:41 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:TLSv1.3 early data Apr 05 10:36:42 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:TLSv1.3 early data Apr 05 10:36:42 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:SSLv3/TLS read finished Apr 05 10:36:42 oc.oops.co.at postfix/submission/smtpd[38541]: unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: Reusing old session (RFC 5077 session ticket) Apr 05 10:36:42 oc.oops.co.at postfix/submission/smtpd[38541]: Anonymous TLS connection established from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) Apr 05 10:36:42 oc.oops.co.at postfix/submission/smtpd[38541]: 2F88988924: client=unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b], sasl_method=PLAIN, sasl_username=oc at oc.oops.co.at Apr 05 10:36:42 oc.oops.co.at postfix/submission/smtpd[38541]: disconnect from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8 Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: connect from localhost[127.0.0.1] Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: setting up TLS connection from localhost[127.0.0.1] Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: localhost[127.0.0.1]: TLS cipher list "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" Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:before SSL initialization Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:before SSL initialization Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL3 alert write:fatal:protocol version Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept:error in error Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: SSL_accept error from localhost[127.0.0.1]: -1 Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:ssl/statem/statem_srvr.c:1685: Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: lost connection after STARTTLS from localhost[127.0.0.1] Apr 05 10:37:04 oc.oops.co.at postfix/submission/smtpd[38541]: disconnect from localhost[127.0.0.1] ehlo=1 starttls=0/1 commands=1/2 - # postconf -n address_verify_map = btree:/var/lib/postfix/verify_cache broken_sasl_auth_clients = yes command_directory = /usr/sbin compatibility_level = 3.6 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 home_mailbox = .maildir/ html_directory = no inet_protocols = all local_recipient_maps = $virtual_mailbox_maps local_transport = virtual mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 20480000 meta_directory = /etc/postfix milter_default_action = accept milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen} milter_protocol = 6 mydestination = localhost.$mydomain, localhost myhostname = oc.oops.co.at newaliases_path = /usr/bin/newaliases non_smtpd_milters = inet:localhost:11332 postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_spf_whitelist.cidr, cidr:/etc/postfix/postscreen_access.cidr postscreen_bare_newline_enable = no postscreen_blacklist_action = drop postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = 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 bl.spameatingmonkey.net bl.spamcop.net spamtrap.trblspam.com 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*2 zen.spamhaus.org=127.0.0.[10;11]*8 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 ix.dnsbl.manitu.net mail.bl.blocklist.de iadb.isipp.com=127.0.[0..255].[0..255]*-2 iadb.isipp.com=127.3.100.[6..200]*-2 postscreen_dnsbl_threshold = 3 postscreen_enforce_tls = $smtpd_enforce_tls postscreen_greet_action = enforce postscreen_greet_banner = $smtpd_banner postscreen_greet_ttl = 30d postscreen_non_smtp_command_action = drop postscreen_non_smtp_command_enable = no postscreen_non_smtp_command_ttl = 30d postscreen_pipelining_enable = no postscreen_use_tls = $smtpd_use_tls queue_directory = /var/spool/postfix readme_directory = no relay_domains = hash:/etc/postfix/relay_domains relocated_maps = hash:/etc/postfix/relocated sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop shlib_directory = /usr/lib64/postfix/${mail_version} smtp_bind_address6 = 2a01:7e01:e001:29e::4711 smtp_tls_loglevel = 1 smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache smtpd_milters = inet:localhost:11332 smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unknown_recipient_domain, reject_unverified_recipient, check_recipient_access hash:/etc/postfix/verify_domains, check_recipient_access hash:/etc/postfix/roleaccount_exceptions, check_client_access cidr:/etc/postfix/client_checks, check_policy_service inet:127.0.0.1:12340, permit smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $mydomain smtpd_sasl_path = /var/run/dovecot/auth-client smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/live/oc.oops.co.at/fullchain.pem smtpd_tls_dh1024_param_file = /etc/ssl/dhparams.pem smtpd_tls_key_file = /etc/letsencrypt/live/oc.oops.co.at/privkey.pem smtpd_tls_loglevel = 2 smtpd_tls_mandatory_ciphers = medium smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_security_level = may 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 = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = proxy:mysql:/etc/postfix/virtual_alias_maps.cf, hash:/etc/postfix/virtual_alias_maps virtual_gid_maps = static:5000 virtual_mailbox_base = /home/vmail virtual_mailbox_domains = proxy:mysql:/etc/postfix/virtual_mailbox_domains.cf virtual_mailbox_limit = 512000000 virtual_mailbox_maps = proxy:mysql:/etc/postfix/virtual_mailbox_maps.cf virtual_minimum_uid = 5000 virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_uid_maps = static:5000 # master.cf submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_local_domain=$myhostname -o smtpd_client_restrictions=permit_sasl_authenticated,reject #-o smtpd_sender_login_maps=hash:/etc/postfix/virtual -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_tls_security_options=noanonymous #-o smtpd_sender_restrictions=reject_sender_login_mismatch -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject amavisfeed unix - - n - 2 lmtp -o lmtp_data_done_timeout=1200 -o lmtp_send_xforward_command=yes -o disable_dns_lookups=yes 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_tls_security_level=none -o smtpd_delay_reject=no -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters smtp-ipv4-only unix - - n - - smtp -o inet_protocols=ipv4 smtp-ipv6-only unix - - n - - smtp -o inet_protocols=ipv6 -o smtp_bind_address6=2a01:7e01:e001:29e::4711 #smtps inet n - n - - smtpd # -o syslog_name=postfix/smtps # -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_reject_unlisted_recipient=no # -o smtpd_client_restrictions=$mua_client_restrictions # -o smtpd_helo_restrictions=$mua_helo_restrictions # -o smtpd_sender_restrictions=$mua_sender_restrictions # -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING #628 inet n - n - - qmqpd pickup unix n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr unix n - n 300 1 qmgr #qmgr unix n - n 300 1 oqmgr tlsmgr unix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scache unix - - n - 1 scache --- Ich dachte, ich hätte SSLv3 längst deaktiviert, aber irgendwo scheint das noch verwendet zu werden, bzw. es wird versucht, es zu verwenden? Der Postfix ist Version 3.6.5-r2 unter Gentoo. Für sachdienliche Hinweise wäre ich sehr dankbar ;-) From atann at alphasrv.net Tue Apr 5 13:00:45 2022 From: atann at alphasrv.net (Andre Tann) Date: Tue, 5 Apr 2022 13:00:45 +0200 Subject: AW: Mails an Gmail kommen nicht an In-Reply-To: <000e01d84845$c88803d0$59980b70$@dpfa.de> References: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> <000e01d84845$c88803d0$59980b70$@dpfa.de> Message-ID: Moin, On 04.04.22 19:02, harald.witt at dpfa.de wrote: > In MS-Outlook gibt es die Möglichkeit, den Spamverdacht so einzustellen, dass die betroffene E-Mail ohne zu Fragen gelöscht wird. Ich hatte selbst schon ein solches Erlebnis der dritten MS-Art. Ich habe das überprüft - Outlook ist nicht im Spiel. Seit gestern weiß ich auch von einem weiteren Fall. Dieser User geht über die Gmail Weboberfläche. Es muß also bei Google liegen. -- Andre Tann From michael at linuxfox.de Tue Apr 5 13:11:30 2022 From: michael at linuxfox.de (Michael Grundmann) Date: Tue, 5 Apr 2022 13:11:30 +0200 Subject: Mails an Gmail kommen nicht an In-Reply-To: References: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> <000e01d84845$c88803d0$59980b70$@dpfa.de> Message-ID: <412f9cf8-5159-31e6-5eb7-49eebd182a4f@linuxfox.de> Am 05.04.22 um 13:00 schrieb Andre Tann via Postfixbuch-users: Hi, > Seit gestern weiß ich auch von einem weiteren Fall. Dieser User geht > über die Gmail Weboberfläche. Es muß also bei Google liegen. ja natürlich - deine Mail wurde mit status=sent 250 übergeben - damit hat dir Google quittiert, dass die Mail angenommen wurde. Was jetzt weiter passiert, kann dir nur Google sagen -- Gruß Michael Wenn du verstehst, was du tust, wirst du nichts lernen From atann at alphasrv.net Tue Apr 5 13:53:48 2022 From: atann at alphasrv.net (Andre Tann) Date: Tue, 5 Apr 2022 13:53:48 +0200 Subject: Mails an Gmail kommen nicht an In-Reply-To: <412f9cf8-5159-31e6-5eb7-49eebd182a4f@linuxfox.de> References: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> <000e01d84845$c88803d0$59980b70$@dpfa.de> <412f9cf8-5159-31e6-5eb7-49eebd182a4f@linuxfox.de> Message-ID: <0832e3c6-2c60-c021-bffd-c7773a862d6a@alphasrv.net> Hi Michael, On 05.04.22 13:11, Michael Grundmann via Postfixbuch-users wrote: > ja natürlich - deine Mail wurde mit status=sent 250 übergeben - damit > hat dir Google quittiert, dass die Mail angenommen wurde. Was jetzt > weiter passiert, kann dir nur Google sagen Da gibts ja immer noch zwei Aspekte: - ein dem User zugängliches Setting führt dazu, daß die Mail verworfen wird. Ein Filter im Client, eine Einstellung in den Google-Spam-Settings, sowas. Scheint hier nicht der Fall zu sein. - Google sortiert die Mail aus, ohne daß der User das sehen oder etwas dagegen tun könnte. So scheint es hier zu liegen, und das ist dann schon unangenehmer. -- Andre Tann From michael at linuxfox.de Tue Apr 5 20:04:33 2022 From: michael at linuxfox.de (Michael Grundmann) Date: Tue, 5 Apr 2022 20:04:33 +0200 Subject: Mails an Gmail kommen nicht an In-Reply-To: <0832e3c6-2c60-c021-bffd-c7773a862d6a@alphasrv.net> References: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> <000e01d84845$c88803d0$59980b70$@dpfa.de> <412f9cf8-5159-31e6-5eb7-49eebd182a4f@linuxfox.de> <0832e3c6-2c60-c021-bffd-c7773a862d6a@alphasrv.net> Message-ID: <57d051fa-bd84-eed3-f84f-828fbbce1a8b@linuxfox.de> Am 05.04.22 um 13:53 schrieb Andre Tann via Postfixbuch-users: Hi Andre, > > - Google sortiert die Mail aus, ohne daß der User das sehen oder etwas > dagegen tun könnte. So scheint es hier zu liegen, und das ist dann > schon unangenehmer. > 250 ist 250 - dein Mailserver hat übergeben und der andere hat angenommen - in allen Belangen bist du raus. Ganz ehrlich, was kümmert dich nach 250 noch der Rest. Das Problem übergibt man ... From atann at alphasrv.net Wed Apr 6 10:45:45 2022 From: atann at alphasrv.net (Andre Tann) Date: Wed, 6 Apr 2022 10:45:45 +0200 Subject: Mails an Gmail kommen nicht an In-Reply-To: <57d051fa-bd84-eed3-f84f-828fbbce1a8b@linuxfox.de> References: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> <000e01d84845$c88803d0$59980b70$@dpfa.de> <412f9cf8-5159-31e6-5eb7-49eebd182a4f@linuxfox.de> <0832e3c6-2c60-c021-bffd-c7773a862d6a@alphasrv.net> <57d051fa-bd84-eed3-f84f-828fbbce1a8b@linuxfox.de> Message-ID: <9a1fe1cd-0798-5681-7f87-b7ce21908eb2@alphasrv.net> Moin, On 05.04.22 20:04, Michael Grundmann via Postfixbuch-users wrote: > 250 ist 250 - dein Mailserver hat übergeben und der andere hat > angenommen - in allen Belangen bist du raus. Ganz ehrlich, was kümmert > dich nach 250 noch der Rest. Das Problem übergibt man ... Tja... die Frage ist nur: an wen. In dem Fall ist es tatsächlich meine eigene Mail, die nicht ankommt, und es stört mich erheblich, daß das so ist. Den Empfänger stört es weniger. Denn ich will in diesem Fall was von ihm, nicht er von mir. Wenn ich nun sage "Dann such Dir halt einen Provider, der Dir die Mails richtig zustellt, wenn es schon 250 heißt", dann krieg ich zur Antwort: "bin ja froh, wenn ich diese Mail nicht kriege, hab ich weniger zu tun". Die Dinge liegen nicht immer ganz so einfach, wie sie zu sein scheinen. -- Andre Tann From lists at xunil.at Wed Apr 6 10:44:52 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Wed, 6 Apr 2022 10:44:52 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: References: Message-ID: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> Am 05.04.22 um 10:43 schrieb Stefan G. Weichinger via Postfixbuch-users: > Ich dachte, ich hätte SSLv3 längst deaktiviert, aber irgendwo scheint > das noch verwendet zu werden, bzw. es wird versucht, es zu verwenden? Ich habe gestern noch das Setup in Richtung postfixadmin geprüft und aktualisiert (mysql-queries) und die TLS-Parameter mit einem funktionierenden Kundenserver verglichen, bzw. mit den Empfehlungen des Mozilla-Generators. Nach wie vor diese Verzögerung, ich komme nicht weiter. Hier ein aktueller Vorgang in den Logs: Apr 06 10:39:45 oc.oops.co.at postfix/submission/smtpd[483602]: initializing the server-side TLS engine Apr 06 10:39:45 oc.oops.co.at postfix/tlsmgr[483603]: open smtp TLS cache btree:/var/lib/postfix/smtp_scache Apr 06 10:39:45 oc.oops.co.at postfix/tlsmgr[483603]: tlsmgr_cache_run_event: start TLS smtp session cache cleanup Apr 06 10:41:45 oc.oops.co.at postfix/submission/smtpd[483602]: connect from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: setting up TLS connection from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: TLS cipher list "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" Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:before SSL initialization Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:before SSL initialization Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:SSLv3/TLS read client hello Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:SSLv3/TLS write server hello Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:SSLv3/TLS write change cipher spec Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:TLSv1.3 write encrypted extensions Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:SSLv3/TLS write certificate Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:TLSv1.3 write server certificate verify Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:SSLv3/TLS write finished Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:TLSv1.3 early data Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:TLSv1.3 early data Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:SSLv3/TLS read finished Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: Issuing session ticket, key expiration: 1649236305 Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: SSL_accept:SSLv3/TLS write session ticket Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: Anonymous TLS connection established from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: 7678889242: client=unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b], sasl_method=PLAIN, sasl_username=oc at oc.oops.co.at Apr 06 10:41:46 oc.oops.co.at postfix/cleanup[483697]: 7678889242: message-id= Apr 06 10:41:46 oc.oops.co.at postfix/qmgr[483576]: 7678889242: from=, size=688, nrcpt=1 (queue active) Apr 06 10:41:46 oc.oops.co.at postfix/lmtp[483698]: 7678889242: to=, relay=oc.oops.co.at[private/dovecot-lmtp], delay=0.19, delays=0.16/0.02/0.01/0.01, dsn=2.0.0, status=sent (250 2.0.0 tGAcJEpSTWJzYQcAzb/H+g Saved) Apr 06 10:41:46 oc.oops.co.at postfix/qmgr[483576]: 7678889242: removed Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: disconnect from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8 (mein TB liefert von der IP [2001:470:51e4:0:c577:c9ad:a9e5:216b] ein) - config aktuell: postconf -n address_verify_map = btree:/var/lib/postfix/verify_cache broken_sasl_auth_clients = yes command_directory = /usr/sbin compatibility_level = 3.6 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 home_mailbox = .maildir/ html_directory = no inet_protocols = all local_recipient_maps = $virtual_mailbox_maps local_transport = virtual mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 20480000 meta_directory = /etc/postfix milter_default_action = accept milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen} milter_protocol = 6 mydestination = localhost.$mydomain, localhost myhostname = oc.oops.co.at newaliases_path = /usr/bin/newaliases non_smtpd_milters = inet:localhost:11332 postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_spf_whitelist.cidr, cidr:/etc/postfix/postscreen_access.cidr postscreen_bare_newline_enable = no postscreen_blacklist_action = drop postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = 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 bl.spameatingmonkey.net bl.spamcop.net spamtrap.trblspam.com 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*2 zen.spamhaus.org=127.0.0.[10;11]*8 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 ix.dnsbl.manitu.net mail.bl.blocklist.de iadb.isipp.com=127.0.[0..255].[0..255]*-2 iadb.isipp.com=127.3.100.[6..200]*-2 postscreen_dnsbl_threshold = 3 postscreen_greet_action = enforce postscreen_greet_banner = $smtpd_banner postscreen_greet_ttl = 30d postscreen_non_smtp_command_action = drop postscreen_non_smtp_command_enable = no postscreen_non_smtp_command_ttl = 30d postscreen_pipelining_enable = no queue_directory = /var/spool/postfix readme_directory = no relay_domains = proxy:mysql:/etc/postfix/sql/mysql_relay_domains.cf relocated_maps = hash:/etc/postfix/relocated sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop shlib_directory = /usr/lib64/postfix/${mail_version} smtp_bind_address6 = 2a01:7e01:e001:29e::4711 smtp_tls_loglevel = 2 smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache smtpd_milters = inet:localhost:11332 smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unknown_recipient_domain, reject_unverified_recipient, check_recipient_access hash:/etc/postfix/verify_domains, check_recipient_access hash:/etc/postfix/roleaccount_exceptions, check_client_access cidr:/etc/postfix/client_checks, check_policy_service inet:127.0.0.1:12340, permit smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $mydomain smtpd_sasl_path = /var/run/dovecot/auth-client smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_sasl_type = dovecot smtpd_tls_auth_only = no smtpd_tls_cert_file = /etc/letsencrypt/live/oc.oops.co.at/fullchain.pem smtpd_tls_dh1024_param_file = /etc/ssl/dhparams.pem smtpd_tls_key_file = /etc/letsencrypt/live/oc.oops.co.at/privkey.pem smtpd_tls_loglevel = 2 smtpd_tls_mandatory_ciphers = medium smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_security_level = may smtpd_tls_session_cache_timeout = 3600s 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 = yes tls_random_source = dev:/dev/urandom tls_ssl_options = NO_RENEGOTIATION transport_maps = proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf, hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf virtual_gid_maps = static:5000 virtual_mailbox_base = /home/vmail virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/mysql_virtual_domains_maps.cf virtual_mailbox_limit = 512000000 virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf virtual_minimum_uid = 5000 virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_uid_maps = static:5000 # master.cf smtp inet n - n - 1 postscreen smtpd pass - - n - - smtpd dnsblog unix - - n - 0 dnsblog tlsproxy unix - - n - 0 tlsproxy # submission inet n - n - - smtpd -o syslog_name=postfix/submission #-o smtpd_tls_security_level=may -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_local_domain=$myhostname -o smtpd_client_restrictions=permit_sasl_authenticated,reject #-o smtpd_sender_login_maps=hash:/etc/postfix/virtual -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_tls_security_options=noanonymous #-o smtpd_sender_restrictions=reject_sender_login_mismatch -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject amavisfeed unix - - n - 2 lmtp -o lmtp_data_done_timeout=1200 -o lmtp_send_xforward_command=yes -o disable_dns_lookups=yes 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_tls_security_level=none -o smtpd_delay_reject=no -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters smtp-ipv4-only unix - - n - - smtp -o inet_protocols=ipv4 smtp-ipv6-only unix - - n - - smtp -o inet_protocols=ipv6 -o smtp_bind_address6=2a01:7e01:e001:29e::4711 #smtps inet n - n - - smtpd # -o syslog_name=postfix/smtps # -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_reject_unlisted_recipient=no # -o smtpd_client_restrictions=$mua_client_restrictions # -o smtpd_helo_restrictions=$mua_helo_restrictions # -o smtpd_sender_restrictions=$mua_sender_restrictions # -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING #628 inet n - n - - qmqpd pickup unix n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr unix n - n 300 1 qmgr #qmgr unix n - n 300 1 oqmgr tlsmgr unix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scache unix - - n - 1 scache From postfixbuch-users at drobic.de Wed Apr 6 16:29:15 2022 From: postfixbuch-users at drobic.de (Sandy Drobic) Date: Wed, 6 Apr 2022 16:29:15 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> Message-ID: <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> Lasse Dich nicht von dem SSLv3 irritieren im Log, es wird ganz korrekt eine TLS 1.3 Verbindung ausgehandelt. Das ist nur eine interne Bezeichnung von Postfix, die leider oft zu Irritationen führt. Der Vorgang scheint auch nur eine Sekunde zu dauern anfgefangen von "connect from" bis "status=sent" Wo ist die große Verzögerung, die Du beklagst? Gruß Sandy Am 06.04.2022 um 10:44 schrieb Stefan G. Weichinger via Postfixbuch-users: > Am 05.04.22 um 10:43 schrieb Stefan G. Weichinger via Postfixbuch-users: > >> Ich dachte, ich hätte SSLv3 längst deaktiviert, aber irgendwo scheint das >> noch verwendet zu werden, bzw. es wird versucht, es zu verwenden? > > Ich habe gestern noch das Setup in Richtung postfixadmin geprüft und > aktualisiert (mysql-queries) und die TLS-Parameter mit einem > funktionierenden Kundenserver verglichen, bzw. mit den Empfehlungen des > Mozilla-Generators. > > Nach wie vor diese Verzögerung, ich komme nicht weiter. > > Hier ein aktueller Vorgang in den Logs: > > Apr 06 10:39:45 oc.oops.co.at postfix/submission/smtpd[483602]: initializing > the server-side TLS engine > Apr 06 10:39:45 oc.oops.co.at postfix/tlsmgr[483603]: open smtp TLS cache > btree:/var/lib/postfix/smtp_scache > Apr 06 10:39:45 oc.oops.co.at postfix/tlsmgr[483603]: > tlsmgr_cache_run_event: start TLS smtp session cache cleanup > Apr 06 10:41:45 oc.oops.co.at postfix/submission/smtpd[483602]: connect from > unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: setting up > TLS connection from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: TLS cipher list > "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" > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:before SSL initialization > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:before SSL initialization > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:SSLv3/TLS read client hello > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:SSLv3/TLS write server hello > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:SSLv3/TLS write change cipher spec > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:TLSv1.3 write encrypted extensions > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:SSLv3/TLS write certificate > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:TLSv1.3 write server certificate verify > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:SSLv3/TLS write finished > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:TLSv1.3 early data > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:TLSv1.3 early data > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:SSLv3/TLS read finished > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: Issuing session ticket, key > expiration: 1649236305 > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: > SSL_accept:SSLv3/TLS write session ticket > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: Anonymous > TLS connection established from > unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: TLSv1.3 with cipher > TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature > RSA-PSS (2048 bits) server-digest SHA256 > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: 7678889242: > client=unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b], sasl_method=PLAIN, > sasl_username=oc at oc.oops.co.at > Apr 06 10:41:46 oc.oops.co.at postfix/cleanup[483697]: 7678889242: > message-id= > Apr 06 10:41:46 oc.oops.co.at postfix/qmgr[483576]: 7678889242: > from=, size=688, nrcpt=1 (queue active) > Apr 06 10:41:46 oc.oops.co.at postfix/lmtp[483698]: 7678889242: > to=, relay=oc.oops.co.at[private/dovecot-lmtp], > delay=0.19, delays=0.16/0.02/0.01/0.01, dsn=2.0.0, status=sent (250 2.0.0 > tGAcJEpSTWJzYQcAzb/H+g Saved) > Apr 06 10:41:46 oc.oops.co.at postfix/qmgr[483576]: 7678889242: removed > Apr 06 10:41:46 oc.oops.co.at postfix/submission/smtpd[483602]: disconnect > from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] ehlo=2 starttls=1 auth=1 > mail=1 rcpt=1 data=1 quit=1 commands=8 > > > (mein TB liefert von der IP [2001:470:51e4:0:c577:c9ad:a9e5:216b] ein) > > - > > config aktuell: > >  postconf -n > address_verify_map = btree:/var/lib/postfix/verify_cache > broken_sasl_auth_clients = yes > command_directory = /usr/sbin > compatibility_level = 3.6 > daemon_directory = /usr/libexec/postfix > data_directory = /var/lib/postfix > debug_peer_level = 2 > debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd > $daemon_directory/$process_name $process_id & sleep 5 > home_mailbox = .maildir/ > html_directory = no > inet_protocols = all > local_recipient_maps = $virtual_mailbox_maps > local_transport = virtual > mail_owner = postfix > mailq_path = /usr/bin/mailq > manpage_directory = /usr/share/man > message_size_limit = 20480000 > meta_directory = /etc/postfix > milter_default_action = accept > milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen} > milter_protocol = 6 > mydestination = localhost.$mydomain, localhost > myhostname = oc.oops.co.at > newaliases_path = /usr/bin/newaliases > non_smtpd_milters = inet:localhost:11332 > postscreen_access_list = permit_mynetworks, > cidr:/etc/postfix/postscreen_spf_whitelist.cidr, > cidr:/etc/postfix/postscreen_access.cidr > postscreen_bare_newline_enable = no > postscreen_blacklist_action = drop > postscreen_dnsbl_action = enforce > postscreen_dnsbl_sites = 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 > bl.spameatingmonkey.net bl.spamcop.net spamtrap.trblspam.com > 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*2 > zen.spamhaus.org=127.0.0.[10;11]*8 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 ix.dnsbl.manitu.net > mail.bl.blocklist.de iadb.isipp.com=127.0.[0..255].[0..255]*-2 > iadb.isipp.com=127.3.100.[6..200]*-2 > postscreen_dnsbl_threshold = 3 > postscreen_greet_action = enforce > postscreen_greet_banner = $smtpd_banner > postscreen_greet_ttl = 30d > postscreen_non_smtp_command_action = drop > postscreen_non_smtp_command_enable = no > postscreen_non_smtp_command_ttl = 30d > postscreen_pipelining_enable = no > queue_directory = /var/spool/postfix > readme_directory = no > relay_domains = proxy:mysql:/etc/postfix/sql/mysql_relay_domains.cf > relocated_maps = hash:/etc/postfix/relocated > sample_directory = /etc/postfix > sendmail_path = /usr/sbin/sendmail > setgid_group = postdrop > shlib_directory = /usr/lib64/postfix/${mail_version} > smtp_bind_address6 = 2a01:7e01:e001:29e::4711 > smtp_tls_loglevel = 2 > smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache > smtpd_milters = inet:localhost:11332 > smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, > reject_unauth_destination, reject_unknown_recipient_domain, > reject_unverified_recipient, check_recipient_access > hash:/etc/postfix/verify_domains, check_recipient_access > hash:/etc/postfix/roleaccount_exceptions, check_client_access > cidr:/etc/postfix/client_checks, check_policy_service inet:127.0.0.1:12340, > permit > smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, > reject_unauth_destination > smtpd_sasl_auth_enable = yes > smtpd_sasl_local_domain = $mydomain > smtpd_sasl_path = /var/run/dovecot/auth-client > smtpd_sasl_security_options = noanonymous > smtpd_sasl_tls_security_options = $smtpd_sasl_security_options > smtpd_sasl_type = dovecot > smtpd_tls_auth_only = no > smtpd_tls_cert_file = /etc/letsencrypt/live/oc.oops.co.at/fullchain.pem > smtpd_tls_dh1024_param_file = /etc/ssl/dhparams.pem > smtpd_tls_key_file = /etc/letsencrypt/live/oc.oops.co.at/privkey.pem > smtpd_tls_loglevel = 2 > smtpd_tls_mandatory_ciphers = medium > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > smtpd_tls_security_level = may > smtpd_tls_session_cache_timeout = 3600s > 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 = yes > tls_random_source = dev:/dev/urandom > tls_ssl_options = NO_RENEGOTIATION > transport_maps = proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf, > hash:/etc/postfix/transport > unknown_local_recipient_reject_code = 550 > virtual_alias_maps = > proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, > proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf, > proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf > virtual_gid_maps = static:5000 > virtual_mailbox_base = /home/vmail > virtual_mailbox_domains = > proxy:mysql:/etc/postfix/sql/mysql_virtual_domains_maps.cf > virtual_mailbox_limit = 512000000 > virtual_mailbox_maps = > proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf, > proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf > virtual_minimum_uid = 5000 > virtual_transport = lmtp:unix:private/dovecot-lmtp > virtual_uid_maps = static:5000 > > > # master.cf > > smtp      inet  n       -       n       -       1       postscreen > smtpd     pass  -       -       n       -       -       smtpd > dnsblog   unix  -       -       n       -       0       dnsblog > tlsproxy  unix  -       -       n       -       0       tlsproxy > # > > submission inet n       -       n       -       -       smtpd >         -o syslog_name=postfix/submission >         #-o smtpd_tls_security_level=may >         -o smtpd_sasl_auth_enable=yes >         -o smtpd_sasl_security_options=noanonymous >         -o smtpd_sasl_local_domain=$myhostname >         -o smtpd_client_restrictions=permit_sasl_authenticated,reject >         #-o smtpd_sender_login_maps=hash:/etc/postfix/virtual >         -o smtpd_sasl_security_options=noanonymous >         -o smtpd_sasl_tls_security_options=noanonymous >         #-o smtpd_sender_restrictions=reject_sender_login_mismatch >         -o > smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject > > > amavisfeed unix  -       -       n       -       2       lmtp >         -o lmtp_data_done_timeout=1200 >         -o lmtp_send_xforward_command=yes >         -o disable_dns_lookups=yes > > 127.0.0.1:10025 inet n  -       n       -       -       smtpd >         -o content_filter= >         -o local_recipient_maps= >         -o relay_recipient_maps= >         -o smtpd_tls_security_level=none >         -o smtpd_delay_reject=no >         -o smtpd_restriction_classes= >         -o smtpd_client_restrictions= >         -o smtpd_helo_restrictions= >         -o smtpd_sender_restrictions= >         -o smtpd_recipient_restrictions=permit_mynetworks,reject >         -o smtpd_data_restrictions=reject_unauth_pipelining >         -o smtpd_end_of_data_restrictions= >         -o mynetworks=127.0.0.0/8 >         -o smtpd_error_sleep_time=0 >         -o smtpd_soft_error_limit=1001 >         -o smtpd_hard_error_limit=1000 >         -o smtpd_client_connection_count_limit=0 >         -o smtpd_client_connection_rate_limit=0 >         -o > receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters > > smtp-ipv4-only unix  -       -       n        -       -       smtp >         -o inet_protocols=ipv4 > smtp-ipv6-only unix  -       -       n        -       -       smtp >         -o inet_protocols=ipv6 >     -o smtp_bind_address6=2a01:7e01:e001:29e::4711 > > #smtps     inet  n       -       n       -       -       smtpd > #  -o syslog_name=postfix/smtps > #  -o smtpd_tls_wrappermode=yes > #  -o smtpd_sasl_auth_enable=yes > #  -o smtpd_reject_unlisted_recipient=no > #  -o smtpd_client_restrictions=$mua_client_restrictions > #  -o smtpd_helo_restrictions=$mua_helo_restrictions > #  -o smtpd_sender_restrictions=$mua_sender_restrictions > #  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject > #  -o milter_macro_daemon_name=ORIGINATING > #628       inet  n       -       n       -       -       qmqpd > pickup    unix  n       -       n       60      1       pickup > cleanup   unix  n       -       n       -       0       cleanup > qmgr      unix  n       -       n       300     1       qmgr > #qmgr     unix  n       -       n       300     1       oqmgr > tlsmgr    unix  -       -       n       1000?   1       tlsmgr > rewrite   unix  -       -       n       -       - trivial-rewrite > bounce    unix  -       -       n       -       0       bounce > defer     unix  -       -       n       -       0       bounce > trace     unix  -       -       n       -       0       bounce > verify    unix  -       -       n       -       1       verify > flush     unix  n       -       n       1000?   0       flush > proxymap  unix  -       -       n       -       -       proxymap > proxywrite unix -       -       n       -       1       proxymap > smtp      unix  -       -       n       -       -       smtp > relay     unix  -       -       n       -       -       smtp > #       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 > showq     unix  n       -       n       -       -       showq > error     unix  -       -       n       -       -       error > retry     unix  -       -       n       -       -       error > discard   unix  -       -       n       -       -       discard > local     unix  -       n       n       -       -       local > virtual   unix  -       n       n       -       -       virtual > lmtp      unix  -       -       n       -       -       lmtp > anvil     unix  -       -       n       -       1       anvil > scache    unix  -       -       n       -       1       scache > From lists at xunil.at Wed Apr 6 20:39:21 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Wed, 6 Apr 2022 20:39:21 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> Message-ID: <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> Am 06.04.22 um 16:29 schrieb Sandy Drobic: > > > Lasse Dich nicht von dem SSLv3 irritieren im Log, es wird ganz korrekt > eine TLS 1.3 Verbindung ausgehandelt. > Das ist nur eine interne Bezeichnung von Postfix, die leider oft zu > Irritationen führt. OK, danke > Der Vorgang scheint auch nur eine Sekunde zu dauern anfgefangen von > "connect from" bis "status=sent" > Wo ist die große Verzögerung, die Du beklagst? Ich sehe die Verzögerung im Thunderbird. Ich hab jetzt mal "journalctl -f -u postfix" beobachtet und ein Mail versendet. Es dauert vielleicht 2 Minuten, bis der connect sichtbar wird im postfix. Dann geht es flott, korrekt. postscreen? iptables und fail2ban hab ich gecheckt (ja, das würde wohl keine Verzögerung geben, sondern eher ein dauerhaftes Blocken). Die Verzögerung ist auch bei einem anderen User an einem anderen Standort aufgetreten, daher eher keine Abhängigkeit von hier und zB irgendwelchen Rules an meinem Standort (firewall, router etc, mein OS usw.) From lists at xunil.at Fri Apr 8 08:58:44 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Fri, 8 Apr 2022 08:58:44 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> Message-ID: <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> Am 06.04.22 um 20:39 schrieb Stefan G. Weichinger via Postfixbuch-users: > Am 06.04.22 um 16:29 schrieb Sandy Drobic: >> >> >> Lasse Dich nicht von dem SSLv3 irritieren im Log, es wird ganz korrekt >> eine TLS 1.3 Verbindung ausgehandelt. >> Das ist nur eine interne Bezeichnung von Postfix, die leider oft zu >> Irritationen führt. > > OK, danke > >> Der Vorgang scheint auch nur eine Sekunde zu dauern anfgefangen von >> "connect from" bis "status=sent" >> Wo ist die große Verzögerung, die Du beklagst? > > Ich sehe die Verzögerung im Thunderbird. Ich hab jetzt mal "journalctl > -f -u postfix" beobachtet und ein Mail versendet. > > Es dauert vielleicht 2 Minuten, bis der connect sichtbar wird im > postfix. Dann geht es flott, korrekt. > > postscreen? iptables und fail2ban hab ich gecheckt (ja, das würde wohl > keine Verzögerung geben, sondern eher ein dauerhaftes Blocken). > > Die Verzögerung ist auch bei einem anderen User an einem anderen > Standort aufgetreten, daher eher keine Abhängigkeit von hier und zB > irgendwelchen Rules an meinem Standort (firewall, router etc, mein OS usw.) Wenn ich versende, wird geloggt: Apr 08 08:54:02 oc.oops.co.at postfix/submission/smtpd[6022]: initializing the server-side TLS engine dann etwa 2 Minuten bis es hier dann wirklich durch geht: Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: connect from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: setting up TLS connection from unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b] Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: TLS cipher list "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" Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:before SSL initialization Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:before SSL initialization Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: unknown[2001:470:51e4:0:c577:c9ad:a9e5:216b]: Decrypting session ticket, key expiration: 1649400877 Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:SSLv3/TLS read client hello Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:SSLv3/TLS write server hello Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:SSLv3/TLS write change cipher spec Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:TLSv1.3 write encrypted extensions Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:SSLv3/TLS write finished Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:TLSv1.3 early data Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:TLSv1.3 early data Apr 08 08:56:02 oc.oops.co.at postfix/submission/smtpd[6022]: SSL_accept:SSLv3/TLS read finished Kann das mit IPv4 vs. v6 zu tun haben? Bislang klappte es mit beiden Stacks sauber. From lists at xunil.at Fri Apr 8 11:30:15 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Fri, 8 Apr 2022 11:30:15 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> Message-ID: <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> ich hab jetzt auch mal noch smtps auf Port 465 dazu gebaut: smtps inet n - n - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_local_domain=$myhostname -o smtpd_client_restrictions=permit_sasl_authenticated,reject #-o smtpd_sender_login_maps=hash:/etc/postfix/virtual -o smtpd_sasl_tls_security_options=noanonymous (ob die Parameter schon 100% gut sind, weiß ich nicht) - Ein Test mit swaks vom selben PC hier läuft zackig durch: swaks --server oc.oops.co.at --from office at oops.co.at --to stefan at oops.co.at --auth --auth-user someuser at oc.oops.co.at --auth-password somepassssss --port 465 -tlsc === Trying oc.oops.co.at:465... === Connected to oc.oops.co.at. === TLS started with cipher TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 === TLS no local certificate set === TLS peer DN="/CN=www.oops.co.at" <~ 220 oc.oops.co.at ESMTP Postfix ~> EHLO 85f092d35c77 <~ 250-oc.oops.co.at <~ 250-PIPELINING <~ 250-SIZE 20480000 <~ 250-VRFY <~ 250-ETRN <~ 250-AUTH PLAIN <~ 250-AUTH=PLAIN <~ 250-ENHANCEDSTATUSCODES <~ 250-8BITMIME <~ 250-DSN <~ 250-SMTPUTF8 <~ 250 CHUNKING ~> AUTH PLAIN AG9jQG9jLm9vcHMuY28uYXQAMkRoRnhieTFONw== <~ 235 2.7.0 Authentication successful ~> MAIL FROM: <~ 250 2.1.0 Ok ~> RCPT TO: <~ 250 2.1.5 Ok ~> DATA <~ 354 End data with . ~> Date: Fri, 08 Apr 2022 11:27:23 +0200 ~> To: stefan at oops.co.at ~> From: office at oops.co.at ~> Subject: test Fri, 08 Apr 2022 11:27:23 +0200 ~> X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/ ~> ~> This is a test mailing ~> ~> . <~ 250 2.0.0 Ok: queued as 6D03F2D3277 ~> QUIT <~ 221 2.0.0 Bye === Connection closed with remote host. TB auf Port 465: selbe Verzögerung Vielleicht ein Bug in Thunderbird 91.7.0, bzw. dem Fedora-Paket? Wobei der andere User unter Windows 11 arbeitet. From postfixbuch-users at drobic.de Fri Apr 8 18:52:51 2022 From: postfixbuch-users at drobic.de (Sandy Drobic) Date: Fri, 8 Apr 2022 18:52:51 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> Message-ID: <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> Am 08.04.2022 um 11:30 schrieb Stefan G. Weichinger via Postfixbuch-users: > > TB auf Port 465: selbe Verzögerung > > Vielleicht ein Bug in Thunderbird 91.7.0, bzw. dem Fedora-Paket? > > Wobei der andere User unter Windows 11 arbeitet. Ich gehe eher von einem Problem mit Timeouts bei Postscreen aus. Nimm die Postscreen-Konfig mal raus und teste dann. From lists at xunil.at Mon Apr 11 09:52:25 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Mon, 11 Apr 2022 09:52:25 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> Message-ID: Am 08.04.22 um 18:52 schrieb Sandy Drobic: > > > Am 08.04.2022 um 11:30 schrieb Stefan G. Weichinger via Postfixbuch-users: >> >> TB auf Port 465: selbe Verzögerung >> >> Vielleicht ein Bug in Thunderbird 91.7.0, bzw. dem Fedora-Paket? >> >> Wobei der andere User unter Windows 11 arbeitet. > > Ich gehe eher von einem Problem mit Timeouts bei Postscreen aus. Nimm > die Postscreen-Konfig mal raus und teste dann. Interessanterweise wurde es nun auf einmal wieder flotter. Warum auch immer, ich kann keine konkrete Änderung an der Config zuordnen. Ich beobachte weiter. Danke vorerst. From lists at xunil.at Tue Apr 12 09:46:46 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Tue, 12 Apr 2022 09:46:46 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> Message-ID: <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> Am 11.04.22 um 09:52 schrieb Stefan G. Weichinger via Postfixbuch-users: >> Ich gehe eher von einem Problem mit Timeouts bei Postscreen aus. Nimm >> die Postscreen-Konfig mal raus und teste dann. > > Interessanterweise wurde es nun auf einmal wieder flotter. Warum auch > immer, ich kann keine konkrete Änderung an der Config zuordnen. > > Ich beobachte weiter. Danke vorerst. Nun wieder langsam. Ergänzend nun postscreen weg genommen. Nach wie vor langsam bzw. eben verzögert, wie beschrieben. From postfixbuch-users at drobic.de Tue Apr 12 11:31:17 2022 From: postfixbuch-users at drobic.de (Sandy Drobic) Date: Tue, 12 Apr 2022 11:31:17 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> Message-ID: Am 12.04.2022 um 09:46 schrieb Stefan G. Weichinger via Postfixbuch-users: > > Am 11.04.22 um 09:52 schrieb Stefan G. Weichinger via Postfixbuch-users: > >>> Ich gehe eher von einem Problem mit Timeouts bei Postscreen aus. Nimm die >>> Postscreen-Konfig mal raus und teste dann. >> >> Interessanterweise wurde es nun auf einmal wieder flotter. Warum auch >> immer, ich kann keine konkrete Änderung an der Config zuordnen. >> >> Ich beobachte weiter. Danke vorerst. > > Nun wieder langsam. Ergänzend nun postscreen weg genommen. Nach wie vor > langsam bzw. eben verzögert, wie beschrieben. Das klingt eher nach einem Netzwerkproblem als nach Postfix. Firewall oder Providereinstellung? Passiert das auch, wenn aus dem lokalen Netzwerk zugegriffen wird? From lists at xunil.at Tue Apr 12 12:13:42 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Tue, 12 Apr 2022 12:13:42 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> Message-ID: Am 12.04.22 um 11:31 schrieb Sandy Drobic: > > > Am 12.04.2022 um 09:46 schrieb Stefan G. Weichinger via Postfixbuch-users: >> >> Am 11.04.22 um 09:52 schrieb Stefan G. Weichinger via Postfixbuch-users: >> >>>> Ich gehe eher von einem Problem mit Timeouts bei Postscreen aus. >>>> Nimm die Postscreen-Konfig mal raus und teste dann. >>> >>> Interessanterweise wurde es nun auf einmal wieder flotter. Warum auch >>> immer, ich kann keine konkrete Änderung an der Config zuordnen. >>> >>> Ich beobachte weiter. Danke vorerst. >> >> Nun wieder langsam. Ergänzend nun postscreen weg genommen. Nach wie >> vor langsam bzw. eben verzögert, wie beschrieben. > > Das klingt eher nach einem Netzwerkproblem als nach Postfix. Firewall > oder Providereinstellung? > Passiert das auch, wenn aus dem lokalen Netzwerk zugegriffen wird? Lokales Netzwerk gibt es quasi nicht: der Postfix läuft in einer VM bei linode, ich komme also mit Thunderbird immer von außerhalb. In der VM sind die iptables per ferm konfiguriert, die statische IP meines Büros wird dort für alle Ports erlaubt. Andere IPs dürfen auf "http https sieve submission smtp imaps". fail2ban exkludiert auch meine IP. Ich dreh fail2ban testweise mal ab. smtps/port 465 hab ich wieder deaktiviert. swaks von hier läuft problemlos durch. Ich ändere noch mal das Passwort des Versand-Users, da war mit swaks grad temporär ein Thema (evtl. weil Sonderzeichen auf der Shell escaped werden müssen). From technoworx at gmx.de Tue Apr 12 12:27:55 2022 From: technoworx at gmx.de (Alexander Stoll) Date: Tue, 12 Apr 2022 12:27:55 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> Message-ID: <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> Am 12.04.2022 um 12:13 schrieb Stefan G. Weichinger via Postfixbuch-users: > Lokales Netzwerk gibt es quasi nicht: der Postfix läuft in einer VM bei > linode, ich komme also mit Thunderbird immer von außerhalb. > > In der VM sind die iptables per ferm konfiguriert, die statische IP > meines Büros wird dort für alle Ports erlaubt. Andere IPs dürfen auf > "http https sieve submission smtp imaps". > > fail2ban exkludiert auch meine IP. > > Ich dreh fail2ban testweise mal ab. > > smtps/port 465 hab ich wieder deaktiviert. > > swaks von hier läuft problemlos durch. > > Ich ändere noch mal das Passwort des Versand-Users, da war mit swaks > grad temporär ein Thema (evtl. weil Sonderzeichen auf der Shell escaped > werden müssen). Hmmm, bei solchen Verzögerungen überprüfe ich reflexartig immer die DNS Auflösung und habe eine Trefferquote von 90%... DNS Resolver ansprechbar und verzögerungsfrei? From lists at xunil.at Tue Apr 12 12:55:21 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Tue, 12 Apr 2022 12:55:21 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> Message-ID: <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> Am 12.04.22 um 12:27 schrieb Alexander Stoll via Postfixbuch-users: > Hmmm, bei solchen Verzögerungen überprüfe ich reflexartig immer die DNS > Auflösung und habe eine Trefferquote von 90%... > > DNS Resolver ansprechbar und verzögerungsfrei? Ja. Lokaler DNS per unbound auf pfsense. Hostname des SMTP-Servers sofort da. Sowohl aus dem Cache lokal unter Fedora 35, als eben auch vom Unbound am Router. - Wie erwähnt: ein 2. Mailuser sieht die selbe Verzögerung. Anderer Internet-Anschluss, anderes OS, selbe TB-Version. Ich denke, ich hatte das auch mit meinem Laptop von unterwegs (LTE ...), das checke ich abends noch mal durch. Danke Euch bislang From technoworx at gmx.de Tue Apr 12 13:05:06 2022 From: technoworx at gmx.de (Alexander Stoll) Date: Tue, 12 Apr 2022 13:05:06 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> Message-ID: <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> Am 12.04.2022 um 12:55 schrieb Stefan G. Weichinger via Postfixbuch-users: > > Am 12.04.22 um 12:27 schrieb Alexander Stoll via Postfixbuch-users: > >> Hmmm, bei solchen Verzögerungen überprüfe ich reflexartig immer die >> DNS Auflösung und habe eine Trefferquote von 90%... >> >> DNS Resolver ansprechbar und verzögerungsfrei? > > Ja. > > Lokaler DNS per unbound auf pfsense. Hostname des SMTP-Servers sofort da. > > Sowohl aus dem Cache lokal unter Fedora 35, als eben auch vom Unbound am > Router. Das ist die Sicht des Client, wenn ich den Thread noch richtig erinnere, war die Verzögerung im Log des Server sichtbar... Worauf ich raus will, ob der Server bei der Reverse Auflösung des SMTP-Clients !!! einen Timeout bekommt, weil er irgendwelche DNS basierten Access Listen prüfen muss... From lists at xunil.at Wed Apr 13 09:43:52 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Wed, 13 Apr 2022 09:43:52 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> Message-ID: <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> Am 12.04.22 um 13:05 schrieb Alexander Stoll via Postfixbuch-users: > Am 12.04.2022 um 12:55 schrieb Stefan G. Weichinger via Postfixbuch-users: >> >> Am 12.04.22 um 12:27 schrieb Alexander Stoll via Postfixbuch-users: >> >>> Hmmm, bei solchen Verzögerungen überprüfe ich reflexartig immer die >>> DNS Auflösung und habe eine Trefferquote von 90%... >>> >>> DNS Resolver ansprechbar und verzögerungsfrei? >> >> Ja. >> >> Lokaler DNS per unbound auf pfsense. Hostname des SMTP-Servers sofort da. >> >> Sowohl aus dem Cache lokal unter Fedora 35, als eben auch vom Unbound >> am Router. > > Das ist die Sicht des Client, wenn ich den Thread noch richtig erinnere, > war die Verzögerung im Log des Server sichtbar... > Worauf ich raus will, ob der Server bei der Reverse Auflösung des > SMTP-Clients !!! einen Timeout bekommt, weil er irgendwelche DNS > basierten Access Listen prüfen muss... Ja, verstehe. Ich hatte 3 DNS von Linode eingetragen, habe nun einen durch 8.8.8.8 (testweise) ersetzt und postfix neu gestartet. Verhalten bei Versand ist leider unverändert. Ein Test über LTE sieht aber flotter aus. Das würde darauf hindeuten, dass meine IP und die des User2 irgendwie anders behandelt werden, als die (dem Mailserver noch neue) LTE-IP, nicht? Bei mir hier hab ich auch noch IPv6 laufen, das käme auch noch auf die Liste der Variablen. postscreen mitsamt seinen DNSBLs (vermutlich sollte ich da mal ausmisten) ist aktuell ja AUS. rspamd würde doch erst nach der Authentifizierung eingreifen, oder? From list+postfixbuch at gcore.biz Wed Apr 13 11:27:10 2022 From: list+postfixbuch at gcore.biz (Gerald Galster) Date: Wed, 13 Apr 2022 11:27:10 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> Message-ID: >>>> Hmmm, bei solchen Verzögerungen überprüfe ich reflexartig immer die DNS Auflösung und habe eine Trefferquote von 90%... >>>> >>>> DNS Resolver ansprechbar und verzögerungsfrei? >>> >>> Ja. >>> >>> Lokaler DNS per unbound auf pfsense. Hostname des SMTP-Servers sofort da. >>> >>> Sowohl aus dem Cache lokal unter Fedora 35, als eben auch vom Unbound am Router. >> Das ist die Sicht des Client, wenn ich den Thread noch richtig erinnere, war die Verzögerung im Log des Server sichtbar... >> Worauf ich raus will, ob der Server bei der Reverse Auflösung des SMTP-Clients !!! einen Timeout bekommt, weil er irgendwelche DNS basierten Access Listen prüfen muss... > > Ja, verstehe. Ich hatte 3 DNS von Linode eingetragen, habe nun einen durch 8.8.8.8 (testweise) ersetzt und postfix neu gestartet. Verhalten bei Versand ist leider unverändert. Hast Du schon mal einen strace probiert? strace -f -s 4096 -p -tt > log.txt 2>&1 Anhand der Zeitstempel findet man vielleicht einen connect, der länger dauert oder fehlschlägt. (z.B. reconnect über IPv4 nach einem timeout weil IPv6 nicht geklappt hat) Viele Grüße Gerald From lists at xunil.at Wed Apr 13 12:45:05 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Wed, 13 Apr 2022 12:45:05 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> Message-ID: <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> Am 13.04.22 um 11:27 schrieb Gerald Galster: >>>>> Hmmm, bei solchen Verzögerungen überprüfe ich reflexartig immer die DNS Auflösung und habe eine Trefferquote von 90%... >>>>> >>>>> DNS Resolver ansprechbar und verzögerungsfrei? >>>> >>>> Ja. >>>> >>>> Lokaler DNS per unbound auf pfsense. Hostname des SMTP-Servers sofort da. >>>> >>>> Sowohl aus dem Cache lokal unter Fedora 35, als eben auch vom Unbound am Router. >>> Das ist die Sicht des Client, wenn ich den Thread noch richtig erinnere, war die Verzögerung im Log des Server sichtbar... >>> Worauf ich raus will, ob der Server bei der Reverse Auflösung des SMTP-Clients !!! einen Timeout bekommt, weil er irgendwelche DNS basierten Access Listen prüfen muss... >> >> Ja, verstehe. Ich hatte 3 DNS von Linode eingetragen, habe nun einen durch 8.8.8.8 (testweise) ersetzt und postfix neu gestartet. Verhalten bei Versand ist leider unverändert. > > Hast Du schon mal einen strace probiert? strace -f -s 4096 -p -tt > log.txt 2>&1 > Anhand der Zeitstempel findet man vielleicht einen connect, der länger dauert oder fehlschlägt. > (z.B. reconnect über IPv4 nach einem timeout weil IPv6 nicht geklappt hat) Danke für den Tip Ich hab das auf die main PID von Thunderbird angesetzt, korrekt? Die Interpretation ist für mich noch etwas schwierig. Jedenfalls viele Zeilen mit " <... recvmsg resumed>{msg_namelen=0}, 0) = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)" ich werde auch mal IPv6 ausknipsen From fk+postfix at celebrate.de Wed Apr 13 13:22:20 2022 From: fk+postfix at celebrate.de (fk+postfix at celebrate.de) Date: Wed, 13 Apr 2022 13:22:20 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> Message-ID: <3cbde0a5-cce3-4765-ef2d-63c5e7651f14@celebrate.de> Am 13.04.2022 um 12:45 schrieb Stefan G. Weichinger via Postfixbuch-users: > Am 13.04.22 um 11:27 schrieb Gerald Galster: >>>>>> Hmmm, bei solchen Verzögerungen überprüfe ich reflexartig immer >>>>>> die DNS Auflösung und habe eine Trefferquote von 90%... >>>>>> >>>>>> DNS Resolver ansprechbar und verzögerungsfrei? >>>>> >>>>> Ja. >>>>> >>>>> Lokaler DNS per unbound auf pfsense. Hostname des SMTP-Servers >>>>> sofort da. >>>>> >>>>> Sowohl aus dem Cache lokal unter Fedora 35, als eben auch vom >>>>> Unbound am Router. >>>> Das ist die Sicht des Client, wenn ich den Thread noch richtig >>>> erinnere, war die Verzögerung im Log des Server sichtbar... >>>> Worauf ich raus will, ob der Server bei der Reverse Auflösung des >>>> SMTP-Clients !!! einen Timeout bekommt, weil er irgendwelche DNS >>>> basierten Access Listen prüfen muss... >>> >>> Ja, verstehe. Ich hatte 3 DNS von Linode eingetragen, habe nun einen >>> durch 8.8.8.8 (testweise) ersetzt und postfix neu gestartet. >>> Verhalten bei Versand ist leider unverändert. >> >> Hast Du schon mal einen strace probiert? strace -f -s 4096 -p >> -tt > log.txt 2>&1 >> Anhand der Zeitstempel findet man vielleicht einen connect, der >> länger dauert oder fehlschlägt. >> (z.B. reconnect über IPv4 nach einem timeout weil IPv6 nicht geklappt >> hat) > > > ich werde auch mal IPv6 ausknipsen Das war mal bei mir ein Problem. Postfix läuft virtuell im LXC Container, im Kernel gab es ein Bug mit der Netzwerk Virtualisierung, wenn Postfix für IPv4 und v6 konfiguriert war (default), die Node aber IPv6 deaktiviert hatte. lg Frank From lists at xunil.at Wed Apr 13 14:01:21 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Wed, 13 Apr 2022 14:01:21 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <3cbde0a5-cce3-4765-ef2d-63c5e7651f14@celebrate.de> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> <3cbde0a5-cce3-4765-ef2d-63c5e7651f14@celebrate.de> Message-ID: <874f2ca3-5d70-d027-25d7-6276f729e461@xunil.at> Am 13.04.22 um 13:22 schrieb Frank Kirschner via Postfixbuch-users: > Am 13.04.2022 um 12:45 schrieb Stefan G. Weichinger via Postfixbuch-users: >> ich werde auch mal IPv6 ausknipsen > > Das war mal bei mir ein Problem. Postfix läuft virtuell im LXC > Container, im Kernel gab es ein Bug mit der Netzwerk Virtualisierung, > wenn Postfix für IPv4 und v6 konfiguriert war (default), die Node aber > IPv6 deaktiviert hatte. Soeben auf meinem PC IPv6 per NetworkManager ausgeschaltet. Versand aus TB zackig/problemlos. DNS-Record kontrolliert: AAAA-Record OK aus Sicht des PCs, ssh auf FQDN per IPv6 klappt tadellos, also sollte das Routing passen. Mein swaks-Docker-Image kann kein "-6", also lokal nachinstalliert. Und da haben wir den Timeout. swaks --server oc.oops.co.at --from office at oops.co.at --to stefan at oops.co.at --auth --auth-user oc at oc.oops.co.at --auth-password $somepass --port 587 -tls -6 --helo mypc.loc.oops.co.at === Trying oc.oops.co.at:587... === Connected to oc.oops.co.at. <** Timeout (30 secs) waiting for server response -> QUIT <** Timeout (30 secs) waiting for server response === Connection closed with remote host. Währenddessen sehe ich am Server nur: Apr 13 13:52:01 oc.oops.co.at postfix/submission/smtpd[1270232]: initializing the server-side TLS engine ohne Angabe einer IP, weder v4 noch v6. smtpd lauscht laut "ss -lnp" auf v4 und v6 Das heißt, es klappt nicht mit ipv6-only, und der Fallback auf v4 ist das, was ich als "Verzögerung" wahrnehme. Ich hab jetzt mal die v6-IP meines PCs als debug_peer eingetragen und generiere entsprechend detaillierte Logs ... From lists at xunil.at Wed Apr 13 15:31:51 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Wed, 13 Apr 2022 15:31:51 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <874f2ca3-5d70-d027-25d7-6276f729e461@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> <3cbde0a5-cce3-4765-ef2d-63c5e7651f14@celebrate.de> <874f2ca3-5d70-d027-25d7-6276f729e461@xunil.at> Message-ID: <95c83766-03b8-1786-d41a-40a627d0a35c@xunil.at> Am 13.04.22 um 14:01 schrieb Stefan G. Weichinger via Postfixbuch-users: > smtpd lauscht laut "ss -lnp" auf v4 und v6 > > Das heißt, es klappt nicht mit ipv6-only, und der Fallback auf v4 ist > das, was ich als "Verzögerung" wahrnehme. > > Ich hab jetzt mal die v6-IP meines PCs als debug_peer eingetragen und > generiere entsprechend detaillierte Logs ... Ich hab da noch einen Verdacht. Ich hab mir mal eine weitere "IPv6-Adresse" bei linode geben lassen, nachdem der ursprüngliche Range immer wieder auf irgendwelche Blacklists gerutscht war (das war nicht mein Server, sondern irgendwelche anderen Linode-Kunden oder so). Der Linode-Support meinte, sie können mir nur eine weiteren Range zuteilen, aber den originalen nicht weg nehmen. Damit postfix nicht aus dem alten Netz sendet, hab ich das hier gesetzt: smtp_bind_address6 = 2a01:7e01:e001:29e::4711 Das betrifft aber den Client, und nicht den Server-Part. Der Server-Part läuft auf allen Interfaces, vermutlich könnte/sollte ich "inet_interfaces" noch entsprechend setzen? Hier dann die Folgefrage nach der Formatierung: v6-IP in eckiger Klammer? Localhost mit rein? Der Server hat aktuell eben auch beide v6-IPs, sollte ja kein Problem sein. Aber evtl kommt das Problem irgendwo aus dieser Ecke ... Dies nur als Ergänzung. danke Euch, Grüße, Stefan From lists at xunil.at Fri Apr 15 09:30:36 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Fri, 15 Apr 2022 09:30:36 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <95c83766-03b8-1786-d41a-40a627d0a35c@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> <3cbde0a5-cce3-4765-ef2d-63c5e7651f14@celebrate.de> <874f2ca3-5d70-d027-25d7-6276f729e461@xunil.at> <95c83766-03b8-1786-d41a-40a627d0a35c@xunil.at> Message-ID: <1ea2f9f8-0cb7-d904-1afa-d582160ee5a6@xunil.at> Am 13.04.22 um 15:31 schrieb Stefan G. Weichinger via Postfixbuch-users: > Ich hab mir mal eine weitere "IPv6-Adresse" bei linode geben lassen, > nachdem der ursprüngliche Range immer wieder auf irgendwelche Blacklists > gerutscht war (das war nicht mein Server, sondern irgendwelche anderen > Linode-Kunden oder so). > > Der Linode-Support meinte, sie können mir nur eine weiteren Range > zuteilen, aber den originalen nicht weg nehmen. > > Damit postfix nicht aus dem alten Netz sendet, hab ich das hier gesetzt: > > smtp_bind_address6 = 2a01:7e01:e001:29e::4711 > > Das betrifft aber den Client, und nicht den Server-Part. > > Der Server-Part läuft auf allen Interfaces, vermutlich könnte/sollte ich > "inet_interfaces" noch entsprechend setzen? > > Hier dann die Folgefrage nach der Formatierung: v6-IP in eckiger > Klammer? Localhost mit rein? > > Der Server hat aktuell eben auch beide v6-IPs, sollte ja kein Problem sein. > > Aber evtl kommt das Problem irgendwo aus dieser Ecke ... Zähneknirschend IPv6 am postfix ausgeschaltet .. zwecks Eingrenzung. Nun klappt es ohne Verzögerung. Das kann ich so aber nicht lassen ;-) From ml at irmawi.de Fri Apr 15 11:28:14 2022 From: ml at irmawi.de (Markus Winkler) Date: Fri, 15 Apr 2022 11:28:14 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <95c83766-03b8-1786-d41a-40a627d0a35c@xunil.at> References: <424fbda8-f2a6-c1b2-330c-57961afa7842@xunil.at> <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> <3cbde0a5-cce3-4765-ef2d-63c5e7651f14@celebrate.de> <874f2ca3-5d70-d027-25d7-6276f729e461@xunil.at> <95c83766-03b8-1786-d41a-40a627d0a35c@xunil.at> Message-ID: <2cccfc78-5128-009c-7820-3f2427d6993c@irmawi.de> Hallo Stefan, On 13.04.22 15:31, Stefan G. Weichinger via Postfixbuch-users wrote: > Der Server-Part läuft auf allen Interfaces, vermutlich könnte/sollte ich > "inet_interfaces" noch entsprechend setzen? > > Hier dann die Folgefrage nach der Formatierung: v6-IP in eckiger Klammer? https://www.postfix.org/postconf.5.html#inet_interfaces Note 2: address information may be enclosed inside [], but this form is not required here. Viele Grüße Markus From lists at xunil.at Fri Apr 15 14:01:37 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Fri, 15 Apr 2022 14:01:37 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: <2cccfc78-5128-009c-7820-3f2427d6993c@irmawi.de> References: <8ecf916b-23ad-7d61-8912-ecaf91603d0a@drobic.de> <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> <3cbde0a5-cce3-4765-ef2d-63c5e7651f14@celebrate.de> <874f2ca3-5d70-d027-25d7-6276f729e461@xunil.at> <95c83766-03b8-1786-d41a-40a627d0a35c@xunil.at> <2cccfc78-5128-009c-7820-3f2427d6993c@irmawi.de> Message-ID: Am 15.04.22 um 11:28 schrieb Markus Winkler via Postfixbuch-users: > Hallo Stefan, > > On 13.04.22 15:31, Stefan G. Weichinger via Postfixbuch-users wrote: >> Der Server-Part läuft auf allen Interfaces, vermutlich könnte/sollte >> ich "inet_interfaces" noch entsprechend setzen? >> >> Hier dann die Folgefrage nach der Formatierung: v6-IP in eckiger Klammer? > > https://www.postfix.org/postconf.5.html#inet_interfaces > > Note 2: address information may be enclosed inside [], but this form is > not required here. Ja, danke. Entsprechend formuliert, aktiv. Bin dran, tcpdumps zu machen und den linode-Support zu befragen. From lists at xunil.at Fri Apr 15 14:10:07 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Fri, 15 Apr 2022 14:10:07 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: References: <9fa282e9-d43c-e9cf-992c-0802838f6d62@xunil.at> <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> <3cbde0a5-cce3-4765-ef2d-63c5e7651f14@celebrate.de> <874f2ca3-5d70-d027-25d7-6276f729e461@xunil.at> <95c83766-03b8-1786-d41a-40a627d0a35c@xunil.at> <2cccfc78-5128-009c-7820-3f2427d6993c@irmawi.de> Message-ID: Am 15.04.22 um 14:01 schrieb Stefan G. Weichinger via Postfixbuch-users: > > Am 15.04.22 um 11:28 schrieb Markus Winkler via Postfixbuch-users: >> Hallo Stefan, >> >> On 13.04.22 15:31, Stefan G. Weichinger via Postfixbuch-users wrote: >>> Der Server-Part läuft auf allen Interfaces, vermutlich könnte/sollte >>> ich "inet_interfaces" noch entsprechend setzen? >>> >>> Hier dann die Folgefrage nach der Formatierung: v6-IP in eckiger >>> Klammer? >> >> https://www.postfix.org/postconf.5.html#inet_interfaces >> >> Note 2: address information may be enclosed inside [], but this form >> is not required here. > > Ja, danke. Entsprechend formuliert, aktiv. > > Bin dran, tcpdumps zu machen und den linode-Support zu befragen. Wenn ich per "swaks -6" den Versand versuche und parallel "tcpdump port 587" mache, kommt kein einziges Paket dort vorbei. Das ist NICHT gut :-) Aber eine Spur. From lists at xunil.at Tue Apr 19 13:25:40 2022 From: lists at xunil.at (Stefan G. Weichinger) Date: Tue, 19 Apr 2022 13:25:40 +0200 Subject: Langsamer Versand, wo kommt SSL3 her? In-Reply-To: References: <6282cd69-9e7a-3dba-7152-a16483738391@xunil.at> <549a6e77-edc4-9e15-1073-133b11a33197@xunil.at> <4d185fc8-ac10-730f-e517-a1c34ea02a1b@drobic.de> <78dd3c26-46ab-d96b-315d-9dc3f7d5a56b@xunil.at> <95ea9acb-9c39-2e37-d3d8-40da6bf0aa44@gmx.de> <471c2be0-14b6-9b3d-0250-5866ea5185d6@xunil.at> <225c7f0c-e975-df03-770a-7d2f6d78d856@gmx.de> <294140ed-b332-6bae-e1ba-7c42315c132b@xunil.at> <199f8a4f-f541-eeae-7cc2-0375c19c4e46@xunil.at> <3cbde0a5-cce3-4765-ef2d-63c5e7651f14@celebrate.de> <874f2ca3-5d70-d027-25d7-6276f729e461@xunil.at> <95c83766-03b8-1786-d41a-40a627d0a35c@xunil.at> <2cccfc78-5128-009c-7820-3f2427d6993c@irmawi.de> Message-ID: <1a653d6c-3cf4-b1d5-ffa3-9e6426650ea9@xunil.at> Am 15.04.22 um 14:10 schrieb Stefan G. Weichinger via Postfixbuch-users: > > Am 15.04.22 um 14:01 schrieb Stefan G. Weichinger via Postfixbuch-users: >> >> Am 15.04.22 um 11:28 schrieb Markus Winkler via Postfixbuch-users: >>> Hallo Stefan, >>> >>> On 13.04.22 15:31, Stefan G. Weichinger via Postfixbuch-users wrote: >>>> Der Server-Part läuft auf allen Interfaces, vermutlich könnte/sollte >>>> ich "inet_interfaces" noch entsprechend setzen? >>>> >>>> Hier dann die Folgefrage nach der Formatierung: v6-IP in eckiger >>>> Klammer? >>> >>> https://www.postfix.org/postconf.5.html#inet_interfaces >>> >>> Note 2: address information may be enclosed inside [], but this form >>> is not required here. >> >> Ja, danke. Entsprechend formuliert, aktiv. >> >> Bin dran, tcpdumps zu machen und den linode-Support zu befragen. > > Wenn ich per "swaks -6" den Versand versuche und parallel "tcpdump port > 587" mache, kommt kein einziges Paket dort vorbei. > > Das ist NICHT gut :-) > > Aber eine Spur. wenn ich per Telnet zu Port 587 verbinde, erhalte ich mit IPv4 auf mein "EHLO mypc.fqdn.at" sofort Antwort, bei IPv6 erst mit Verzögerung. Die Antwort: telnet $v4_addr 587 Trying xxyy ... Connected to xxyy . Escape character is '^]'. 220 oc.oops.co.at ESMTP Postfix EHLO mypc.fqdn.at 250-my.server.at 250-PIPELINING 250-SIZE 20480000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING ferm ist AUS, Server rebootet, nix in den iptables ... From ml-pbu at syntaxys.de Wed Apr 27 10:20:27 2022 From: ml-pbu at syntaxys.de (Achim Lammerts) Date: Wed, 27 Apr 2022 10:20:27 +0200 Subject: HANGUPs beim postscreen Message-ID: <275ae8de-652c-069b-44f4-45e57efc045d@syntaxys.de> Guten Morgen Liste, im Log finde ich immer wieder Einträge von neuen Verbindungen, die es nicht am postscreen vorbei schaffen und ich versuche zu verstehen, woran das liegt. Nach 5-6 Sekunden geben die einliefernden MTAs auf, obwohl sie eine Freigabe zum smtpd erhalten. Oder interpretiere ich das falsch? Apr 27 09:14:16 host postfix/postscreen[73824]: connection established fd 128 Apr 27 09:14:16 host postfix/postscreen[73824]: master_notify: status 0 Apr 27 09:14:16 host postfix/postscreen[73824]: psc_endpt_lookup_done: sq=0 cq=0 connect from [41.139.0.81]:54218 Apr 27 09:14:16 host postfix/postscreen[73824]: CONNECT from [41.139.0.81]:54218 to [a.b.c.d]:25 Apr 27 09:14:16 host postfix/postscreen[73824]: source=postscreen_access_list address=41.139.0.81 acl=permit_mynetworks Apr 27 09:14:16 host postfix/postscreen[73824]: match_hostaddr: postscreen_access_list: 41.139.0.81 ~? 127.0.0.0/8 Apr 27 09:14:16 host postfix/postscreen[73824]: match_hostaddr: postscreen_access_list: 41.139.0.81 ~? 192.168.0.0/16 Apr 27 09:14:16 host postfix/postscreen[73824]: match_hostaddr: postscreen_access_list: 41.139.0.81 ~? a.b.c.d Apr 27 09:14:16 host postfix/postscreen[73824]: match_hostaddr: postscreen_access_list: 41.139.0.81 ~? [::ffff:127.0.0.0]/104 Apr 27 09:14:16 host postfix/postscreen[73824]: match_hostaddr: postscreen_access_list: 41.139.0.81 ~? [::1]/128 Apr 27 09:14:16 host postfix/postscreen[73824]: match_hostaddr: postscreen_access_list: 41.139.0.81 ~? [aa:bb:cc:dd::1] Apr 27 09:14:16 host postfix/postscreen[73824]: match_list_match: 41.139.0.81: no match Apr 27 09:14:16 host postfix/postscreen[73824]: source=postscreen_access_list address=41.139.0.81 - no match Apr 27 09:14:16 host postfix/postscreen[73824]: dict_cache_lookup: key=41.139.0.81 value=(not found) Apr 27 09:14:16 host postfix/postscreen[73824]: psc_endpt_lookup_done: new + recent flags: NEW|PREGR_TODO Apr 27 09:14:16 host postfix/postscreen[73824]: match_hostaddr: postscreen_whitelist_interfaces: a.b.c.d ~? static:all(0,lock|utf8_request) Apr 27 09:14:16 host postfix/postscreen[73824]: > [41.139.0.81]:54218: 220-host.domain.tld ESMTP Postfix Apr 27 09:14:16 host postfix/postscreen[73824]: psc_early_tests: read-request fd=128 Apr 27 09:14:16 host postfix/postscreen[73824]: master_notify: status 1 Apr 27 09:14:16 host postfix/postscreen[73824]: watchdog_start: 0x55fa03b257d0 Apr 27 09:14:19 host postfix/postscreen[73824]: watchdog_event: 0x55fa03b257d0 0 Apr 27 09:14:19 host postfix/postscreen[73824]: watchdog_start: 0x55fa03b257d0 Apr 27 09:14:19 host postfix/postscreen[73824]: watchdog_start: 0x55fa03b257d0 Apr 27 09:14:21 host postfix/postscreen[73824]: psc_early_event: sq=0 cq=1 event 1 on smtp socket 128 from [41.139.0.81]:54218 flags=NEW|PREGR_TODO Apr 27 09:14:21 host postfix/postscreen[73824]: psc_early_event: clear-request fd=128 Apr 27 09:14:21 host postfix/postscreen[73824]: HANGUP after 5.2 from [41.139.0.81]:54218 in tests before SMTP handshake Apr 27 09:14:21 host postfix/postscreen[73824]: flags for psc_conclude: NOFORWARD|NEW|HANGUP|PREGR_TODO Apr 27 09:14:21 host postfix/postscreen[73824]: DISCONNECT [41.139.0.81]:54218 Apr 27 09:14:21 host postfix/postscreen[73824]: connection closed fd 128 Scheinbar passiert das wohl nur bei Spamhosts, bei erwünschten Mails ist mir noch nichts aufgefallen. Ist hier eine generelle Einstellung in der Konfiguration erforderlich? Wo entsteht diese Verzögerung? Vielen Dank für Euer Feedback! Achim -- Wietse, I am so grateful. From Ralf.Hildebrandt at charite.de Wed Apr 27 10:54:03 2022 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Wed, 27 Apr 2022 10:54:03 +0200 Subject: [ext] HANGUPs beim postscreen In-Reply-To: <275ae8de-652c-069b-44f4-45e57efc045d@syntaxys.de> References: <275ae8de-652c-069b-44f4-45e57efc045d@syntaxys.de> Message-ID: * Achim Lammerts via Postfixbuch-users : > Guten Morgen Liste, > im Log finde ich immer wieder Einträge von neuen Verbindungen, die es nicht > am postscreen vorbei schaffen und ich versuche zu verstehen, woran das > liegt. Nach 5-6 Sekunden geben die einliefernden MTAs auf, obwohl sie eine > Freigabe zum smtpd erhalten. Oder interpretiere ich das falsch? Ist halt schlecht programmiert, der Bot. > Apr 27 09:14:21 host postfix/postscreen[73824]: HANGUP after 5.2 from [41.139.0.81]:54218 in tests before SMTP handshake -- 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 Ralf.Hildebrandt at charite.de Wed Apr 27 11:32:37 2022 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Wed, 27 Apr 2022 11:32:37 +0200 Subject: [ext] HANGUPs beim postscreen In-Reply-To: References: <275ae8de-652c-069b-44f4-45e57efc045d@syntaxys.de> Message-ID: * Ralf Hildebrandt via Postfixbuch-users : > * Achim Lammerts via Postfixbuch-users : > > Guten Morgen Liste, > > im Log finde ich immer wieder Einträge von neuen Verbindungen, die es nicht > > am postscreen vorbei schaffen und ich versuche zu verstehen, woran das > > liegt. Nach 5-6 Sekunden geben die einliefernden MTAs auf, obwohl sie eine > > Freigabe zum smtpd erhalten. Oder interpretiere ich das falsch? > > Ist halt schlecht programmiert, der Bot. > > > Apr 27 09:14:21 host postfix/postscreen[73824]: HANGUP after 5.2 from [41.139.0.81]:54218 in tests before SMTP handshake Habe mal bei mir gezählt: # xzegrep -c "HANGUP after.*in tests before SMTP handshake" /var/log/mail.log* /var/log/mail.log-20220420.xz:345 /var/log/mail.log-20220421.xz:271 /var/log/mail.log-20220422.xz:198 /var/log/mail.log-20220423.xz:283 /var/log/mail.log-20220424.xz:261 /var/log/mail.log-20220425.xz:493 /var/log/mail.log-20220426:248 /var/log/mail.log:216 # xzegrep -c "HANGUP after.*in tests after SMTP handshake" /var/log/mail.log* /var/log/mail.log-20220420.xz:44590 /var/log/mail.log-20220421.xz:7646 /var/log/mail.log-20220422.xz:15469 /var/log/mail.log-20220423.xz:9714 /var/log/mail.log-20220424.xz:22743 /var/log/mail.log-20220425.xz:13941 /var/log/mail.log-20220426:18100 /var/log/mail.log:21019 -- 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 ml-pbu at syntaxys.de Wed Apr 27 12:36:04 2022 From: ml-pbu at syntaxys.de (Achim Lammerts) Date: Wed, 27 Apr 2022 12:36:04 +0200 Subject: [ext] HANGUPs beim postscreen In-Reply-To: References: <275ae8de-652c-069b-44f4-45e57efc045d@syntaxys.de> Message-ID: <8b12396d-3ede-ef40-de43-3db5b9e7d2e0@syntaxys.de> Danke, da bin ich beruhigt. Ich war mir nicht sicher, ob da etwas in der Konfiguration nicht passt, da dies bei neuen Hosts (PASS NEW) fast immer passiert, bei jenen im Cache aber nicht mehr. Am 27.04.22 um 11:32 schrieb Ralf Hildebrandt via Postfixbuch-users: > * Ralf Hildebrandt via Postfixbuch-users : >> * Achim Lammerts via Postfixbuch-users : >>> Guten Morgen Liste, >>> im Log finde ich immer wieder Einträge von neuen Verbindungen, die es nicht >>> am postscreen vorbei schaffen und ich versuche zu verstehen, woran das >>> liegt. Nach 5-6 Sekunden geben die einliefernden MTAs auf, obwohl sie eine >>> Freigabe zum smtpd erhalten. Oder interpretiere ich das falsch? >> >> Ist halt schlecht programmiert, der Bot. >> >>> Apr 27 09:14:21 host postfix/postscreen[73824]: HANGUP after 5.2 from [41.139.0.81]:54218 in tests before SMTP handshake > > Habe mal bei mir gezählt: > > # xzegrep -c "HANGUP after.*in tests before SMTP handshake" /var/log/mail.log* > /var/log/mail.log-20220420.xz:345 > /var/log/mail.log-20220421.xz:271 > /var/log/mail.log-20220422.xz:198 > /var/log/mail.log-20220423.xz:283 > /var/log/mail.log-20220424.xz:261 > /var/log/mail.log-20220425.xz:493 > /var/log/mail.log-20220426:248 > /var/log/mail.log:216 > > # xzegrep -c "HANGUP after.*in tests after SMTP handshake" /var/log/mail.log* > /var/log/mail.log-20220420.xz:44590 > /var/log/mail.log-20220421.xz:7646 > /var/log/mail.log-20220422.xz:15469 > /var/log/mail.log-20220423.xz:9714 > /var/log/mail.log-20220424.xz:22743 > /var/log/mail.log-20220425.xz:13941 > /var/log/mail.log-20220426:18100 > /var/log/mail.log:21019 > -- Wietse, I am so grateful. From max.grobecker at ml.grobecker.info Fri Apr 29 00:09:03 2022 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Fri, 29 Apr 2022 00:09:03 +0200 Subject: "delay_warning_time" pro Transport oder Absender einstellbar? Message-ID: <89c64e0c-b85f-e2cf-4c7b-f9da71d5bb0e@grobecker.info> Moin-Moin, ich habe hier einen Postfix, welcher ein- und ausgehende E-Mails verarbeitet. E-Mails von uns an extern werden über den Submission-Port eingeliefert. Jetzt war mehrfach das Problem aufgetreten, dass E-Mails an falsch geschriebene Domains (z.B. gmail.de anstelle von gmail.com) schlicht in der Queue liegen bleiben, da der Host zwar auflösbar, aber eben nicht auf Port 25 erreichbar ist. Die Absender erhalten darüber standardmäßig keine Info, bis die Mail irgendwann "afgelopen" ist. Bis dahin vergeht aber viel Zeit und die Absender wissen derweil nicht, dass ihre Mail nicht angekommen ist. Nun habe ich "delay_warning_time" auf 4h konfiguriert. Das erzeugt erwartungsgemäß in solchen Fällen tatsächlich 4h später eine Nachricht von Postfix an den Absender. Alle happy. Dummerweise erzeugt es auch bei E-Mails, die von extern an unsere Domains eingeliefert werden, eine solche Nachricht, wenn die Mailzustellung intern bei uns verzögert wird (z.B. Wartungsarbeiten), an die externen Absender ebenfalls solche Meldungen, was ich eigentlich aus einer Vielzahl von Gründen vermeiden will. Jetzt kam mir der Gedanke, dass es möglicherweise reicht, die "delay_warning_time" als Option nur an dem Submission-Dienst zu konfigurieren und Postfix dies irgendwie intern an der Mail markiert, dass eine solche "Delay Warning" verschickt werden soll. Wenn ich das richtig sehe, werden die Warnungen zwar von qmgr verschickt, aber dem cleanup-Dienst gehört der "delay_warning_time"-Parameter. Da wir für Mails über Submission ohnehin einen eigenen "cleanup"-Prozess verwenden, habe ich also dort in der master.cf diese Option eingefügt. Allerdings will auch das nicht so richtig funktionieren - auch hier bekomme ich keine Warnungen nach den vier Stunden, wenn es nicht explizit in der main.cf global gesetzt ist. Gibt es abseits davon eine halbwegs seriöse Methode, wie Postfix nur an bestimmte Absender, entweder bestimmt durch die Art der Einlieferung oder durch die Absender-Domain eine solche Warnung erzeugt? Vielen Dank und Grüße! Max From max.grobecker at ml.grobecker.info Fri Apr 29 11:27:51 2022 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Fri, 29 Apr 2022 11:27:51 +0200 Subject: "delay_warning_time" pro Transport oder Absender einstellbar? In-Reply-To: <89c64e0c-b85f-e2cf-4c7b-f9da71d5bb0e@grobecker.info> References: <89c64e0c-b85f-e2cf-4c7b-f9da71d5bb0e@grobecker.info> Message-ID: <6c9662b4-b0ad-50c0-1861-9583bf5b55fd@grobecker.info> Moin, ein Update dazu: > Wenn ich das richtig sehe, werden die Warnungen zwar von qmgr verschickt, aber dem cleanup-Dienst gehört der "delay_warning_time"-Parameter. > Da wir für Mails über Submission ohnehin einen eigenen "cleanup"-Prozess verwenden, habe ich also dort in der master.cf diese Option eingefügt. Das funktioniert doch. Man muss es nur an den Submission-Dienst in der master.cf konfigurieren, der auch beim Testen genutzt wird... ? Viele Grüße Max From ffiene at veka.com Fri Apr 29 20:19:11 2022 From: ffiene at veka.com (Frank Fiene) Date: Fri, 29 Apr 2022 20:19:11 +0200 Subject: Viele STARTTLS Fehler nach Tausch des Zertifikates Message-ID: Moin! Ich weiß nicht mehr weiter. Wenn ich https://www.checktls.com/TestReceiver auf unserer Domain versuche, sieht alles gut aus. [000.000] Trying TLS on smtp1.veka.com[185.254.60.2:25] (10) [000.091] Server answered [001.038] EHLO www12-azure.checktls.com [001.134] STARTTLS [001.225] EHLO www12-azure.checktls.com [002.002] <~~ 250-smtp1.veka.com 250-PIPELINING 250-SIZE 65536000 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 SMTPUTF8 [002.003] TLS successfully started on this server [002.003] ~~> MAIL FROM: [002.093] <~~ 250 2.1.0 Ok [002.094] Sender is OK [002.094] ~~> QUIT [002.185] <~~ 221 2.0.0 Bye Es kommen aber diverse Mails nicht an, vor allem von Microsoft und web.de , gmx wahrscheinlich auch. Davon hab ich einiges im Log der MXe stehen: Apr 29 19:55:54 smtp1 postfix/smtpd[20048]: lost connection after STARTTLS from smtpout15.sweb.ru[2a02:408:7722:1:77:222:41:79] Apr 29 19:56:09 smtp1 postfix/smtpd[20045]: lost connection after STARTTLS from delivery.mailspamprotection.com[185.56.84.23] Apr 29 19:56:46 smtp1 postfix/smtpd[22521]: lost connection after STARTTLS from e2i45.smtp2go.com[103.2.140.45] Apr 29 19:58:50 smtp1 postfix/smtpd[23630]: lost connection after STARTTLS from server2.limesoft.com.br[67.23.255.130] Apr 29 20:00:16 smtp1 postfix/smtpd[27009]: lost connection after STARTTLS from mout.gmx.net[212.227.15.15] Apr 29 20:00:18 smtp1 postfix/smtpd[27006]: lost connection after STARTTLS from out3-76.antispamcloud.com[185.201.18.76] Apr 29 20:03:25 smtp1 postfix/smtpd[27420]: lost connection after STARTTLS from molamola.ripe.net[2001:67c:2e8:11::c100:1371] Apr 29 20:03:25 smtp1 postfix/smtpd[30976]: lost connection after STARTTLS from molamola.ripe.net[193.0.19.113] Apr 29 20:04:06 smtp1 postfix/smtpd[30976]: lost connection after STARTTLS from 153207.onlinenow.com.ar[205.251.153.207] Apr 29 20:04:40 smtp1 postfix/smtpd[32610]: lost connection after STARTTLS from smtpout13.sweb.ru[2a02:408:7722:1:77:222:41:57] Apr 29 20:04:52 smtp1 postfix/smtpd[32596]: lost connection after STARTTLS from mout.web.de[212.227.17.12] Apr 29 20:05:03 smtp1 postfix/smtpd[32595]: lost connection after STARTTLS from nx226.node02.secure-mailgate.com[192.162.87.226] Apr 29 20:05:39 smtp1 postfix/smtpd[32599]: lost connection after STARTTLS from mout.gmx.net[212.227.17.22] Apr 29 20:06:32 smtp1 postfix/smtpd[32598]: lost connection after STARTTLS from nx109.node02.secure-mailgate.com[192.162.87.109] Apr 29 20:07:25 smtp1 postfix/smtpd[32595]: lost connection after STARTTLS from mail.ozokgroup.com[185.111.235.60] Apr 29 20:09:14 smtp1 postfix/smtpd[32597]: lost connection after STARTTLS from resqmta-a1p-077438.sys.comcast.net[96.103.146.52] Apr 29 20:11:08 smtp1 postfix/smtpd[6695]: lost connection after STARTTLS from delivery.mailspamprotection.com[185.56.85.145] Apr 29 20:11:30 smtp1 postfix/smtpd[6695]: lost connection after STARTTLS from mout.web.de[212.227.17.11] Apr 29 20:12:09 smtp1 postfix/smtpd[6537]: lost connection after STARTTLS from cp-nbg1-bgho.nethinks.com[212.218.193.253] Komischerweise nichts von Microsoft. Bin mal gespannt, ob die Mail hier wieder von der Mailingliste zu mir kommt. 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: -------------- 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 : From ffiene at veka.com Fri Apr 29 20:38:23 2022 From: ffiene at veka.com (Frank Fiene) Date: Fri, 29 Apr 2022 20:38:23 +0200 Subject: Viele STARTTLS Fehler nach Tausch des Zertifikates In-Reply-To: References: Message-ID: Oh Mann, ich Vollidiot. Mein DANE ist natürlich jetzt broken und die besagten Anbieter testen wohl den TLSA. :-( Anfängerfehler. > Am 29.04.2022 um 20:19 schrieb Frank Fiene via Postfixbuch-users : > > Moin! > > Ich weiß nicht mehr weiter. > > Wenn ich https://www.checktls.com/TestReceiver auf unserer Domain versuche, sieht alles gut aus. > > [000.000] Trying TLS on smtp1.veka.com [185.254.60.2:25] (10) [000.091] Server answered [001.038] ESMTP Postfix (Ubuntu) [001.038] We are allowed to connect [001.038] ??> EHLO www12-azure.checktls.com [001.134] > 250-PIPELINING > 250-SIZE 65536000 > 250-ETRN > 250-STARTTLS > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250-DSN > 250 SMTPUTF8 [001.134] We can use this server [001.134] TLS is an option on this server [001.135] ??> STARTTLS [001.225] = veka.com | DNS:veka.com | DNS:*.veka.com | DNS:*.veka.de | DNS:veka.de | DNS:veka.nl | DNS:www.veka.nl | DNS:www.architecten.vekakozijn.nl | DNS:architecten.vekakozijn.nl | DNS:www.veka.ch | DNS:veka.ch | DNS:www.veka.it | DNS:veka.it | DNS:www.veka.be | DNS:veka.be | DNS:www.veka.cz | DNS:veka.cz | DNS:www.veka-ut.de | DNS:veka-ut.de | DNS:www.veka.com.tr | DNS:veka.com.tr | DNS:www.extranet.veka.fr | DNS:extranet.veka.fr | DNS:www.extranet.veka.es | DNS:extranet.veka.es | DNS:www.veka.pt | DNS:veka.pt | DNS:www.extranet.veka.pt | DNS:extranet.veka.pt | DNS:www.vekats.com | DNS:vekats.com | DNS:www.veka.sk | DNS:veka.sk | DNS:astaro.de01.veka.com ) Not Valid Before: Apr 28 00:00:00 2022 GMT Not Valid After: May 20 23:59:59 2023 GMT subject= /C=DE/ST=Nordrhein-Westfalen/L=Sendenhorst/O=Veka AG/CN=veka.com issuer= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=GeoTrust TLS RSA CA G1 Certificate #2 of 3 (sent by MX): Cert VALIDATED: ok Not Valid Before: Nov 2 12:23:37 2017 GMT Not Valid After: Nov 2 12:23:37 2027 GMT subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=GeoTrust TLS RSA CA G1 issuer= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 Certificate #3 of 3 (added from CA Root Store): Cert VALIDATED: ok Not Valid Before: Aug 1 12:00:00 2013 GMT Not Valid After: Jan 15 12:00:00 2038 GMT subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 issuer= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 [001.911] ~~> EHLO www12-azure.checktls.com [002.002] <~~ 250-smtp1.veka.com > 250-PIPELINING > 250-SIZE 65536000 > 250-ETRN > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250-DSN > 250 SMTPUTF8 [002.003] TLS successfully started on this server [002.003] ~~> MAIL FROM:> [002.093] <~~ 250 2.1.0 Ok [002.094] Sender is OK [002.094] ~~> QUIT [002.185] <~~ 221 2.0.0 Bye > > Es kommen aber diverse Mails nicht an, vor allem von Microsoft und web.de , gmx wahrscheinlich auch. > > Davon hab ich einiges im Log der MXe stehen: > > Apr 29 19:55:54 smtp1 postfix/smtpd[20048]: lost connection after STARTTLS from smtpout15.sweb.ru [2a02:408:7722:1:77:222:41:79] > Apr 29 19:56:09 smtp1 postfix/smtpd[20045]: lost connection after STARTTLS from delivery.mailspamprotection.com [185.56.84.23] > Apr 29 19:56:46 smtp1 postfix/smtpd[22521]: lost connection after STARTTLS from e2i45.smtp2go.com [103.2.140.45] > Apr 29 19:58:50 smtp1 postfix/smtpd[23630]: lost connection after STARTTLS from server2.limesoft.com.br [67.23.255.130] > Apr 29 20:00:16 smtp1 postfix/smtpd[27009]: lost connection after STARTTLS from mout.gmx.net [212.227.15.15] > Apr 29 20:00:18 smtp1 postfix/smtpd[27006]: lost connection after STARTTLS from out3-76.antispamcloud.com [185.201.18.76] > Apr 29 20:03:25 smtp1 postfix/smtpd[27420]: lost connection after STARTTLS from molamola.ripe.net [2001:67c:2e8:11::c100:1371] > Apr 29 20:03:25 smtp1 postfix/smtpd[30976]: lost connection after STARTTLS from molamola.ripe.net [193.0.19.113] > Apr 29 20:04:06 smtp1 postfix/smtpd[30976]: lost connection after STARTTLS from 153207.onlinenow.com.ar [205.251.153.207] > Apr 29 20:04:40 smtp1 postfix/smtpd[32610]: lost connection after STARTTLS from smtpout13.sweb.ru [2a02:408:7722:1:77:222:41:57] > Apr 29 20:04:52 smtp1 postfix/smtpd[32596]: lost connection after STARTTLS from mout.web.de [212.227.17.12] > Apr 29 20:05:03 smtp1 postfix/smtpd[32595]: lost connection after STARTTLS from nx226.node02.secure-mailgate.com [192.162.87.226] > Apr 29 20:05:39 smtp1 postfix/smtpd[32599]: lost connection after STARTTLS from mout.gmx.net [212.227.17.22] > Apr 29 20:06:32 smtp1 postfix/smtpd[32598]: lost connection after STARTTLS from nx109.node02.secure-mailgate.com [192.162.87.109] > Apr 29 20:07:25 smtp1 postfix/smtpd[32595]: lost connection after STARTTLS from mail.ozokgroup.com [185.111.235.60] > Apr 29 20:09:14 smtp1 postfix/smtpd[32597]: lost connection after STARTTLS from resqmta-a1p-077438.sys.comcast.net [96.103.146.52] > Apr 29 20:11:08 smtp1 postfix/smtpd[6695]: lost connection after STARTTLS from delivery.mailspamprotection.com [185.56.85.145] > Apr 29 20:11:30 smtp1 postfix/smtpd[6695]: lost connection after STARTTLS from mout.web.de [212.227.17.11] > Apr 29 20:12:09 smtp1 postfix/smtpd[6537]: lost connection after STARTTLS from cp-nbg1-bgho.nethinks.com [212.218.193.253] > > Komischerweise nichts von Microsoft. > > Bin mal gespannt, ob die Mail hier wieder von der Mailingliste zu mir kommt. > > > 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 > Viele Grüße! i.A. Frank Fiene -- 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: -------------- 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 : From max.grobecker at ml.grobecker.info Fri Apr 29 23:02:59 2022 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Fri, 29 Apr 2022 23:02:59 +0200 Subject: Mails an Gmail kommen nicht an In-Reply-To: <9a1fe1cd-0798-5681-7f87-b7ce21908eb2@alphasrv.net> References: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> <000e01d84845$c88803d0$59980b70$@dpfa.de> <412f9cf8-5159-31e6-5eb7-49eebd182a4f@linuxfox.de> <0832e3c6-2c60-c021-bffd-c7773a862d6a@alphasrv.net> <57d051fa-bd84-eed3-f84f-828fbbce1a8b@linuxfox.de> <9a1fe1cd-0798-5681-7f87-b7ce21908eb2@alphasrv.net> Message-ID: <124db294-650f-fc28-075d-16e526b16f8f@grobecker.info> Moin, wenn wir davon ausgehen, dass es an der Signatur liegt: Enthält diese Signatur Links, möglicherweise auch noch welche über Short-URL-Anbieter (wie bit[.]ly)? Oder bindest du Grafiken über irgendwelche externen Dienste ein? Diese Anbieter werden bei mir mittlerweile vom Spamfilter ziemlich abgestraft. Dafür, dass sie sich nicht für fünf Pfennig für Abuse-Reports interessieren. Ich müsste mich doch sehr wundern, wenn ich da der Einzige bin... Viele Grüße Max From sebastian at debianfan.de Fri Apr 29 23:23:00 2022 From: sebastian at debianfan.de (sebastian at debianfan.de) Date: Fri, 29 Apr 2022 23:23:00 +0200 Subject: Problem mit smtp & master.cf Message-ID: <5f8afd66-c91b-3f74-995a-d6e921ac6770@debianfan.de> Moin zusammen, die master.cf sieht so aus: smtp inet n - y - 1 postscreen -o smtpd_sasl_auth_enable=no Jetzt soll noch spamassassin als content-Filter hinzukommen. Ich hätte das jetzt so gemacht: smtp inet n - y - 1 postscreen -o smtpd_sasl_auth_enable=no -o content_filter=spamassassin und dann unten jeweils: spamassassin unix - n n - - pipe user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient} Mails kommen in den Postfächern an - aber Spamassassin bekommt diese nicht zu sehen - die GTUBE-Nachricht sollte ja doch schon irgendwie gekennzeichnet werden... Wo liegt der Fehler? gruß Sebastian From atann at alphasrv.net Sat Apr 30 19:30:09 2022 From: atann at alphasrv.net (Andre Tann) Date: Sat, 30 Apr 2022 19:30:09 +0200 Subject: Mails an Gmail kommen nicht an In-Reply-To: <124db294-650f-fc28-075d-16e526b16f8f@grobecker.info> References: <4218a665-a4fe-39f6-db7c-fa1177f543ef@alphasrv.net> <000e01d84845$c88803d0$59980b70$@dpfa.de> <412f9cf8-5159-31e6-5eb7-49eebd182a4f@linuxfox.de> <0832e3c6-2c60-c021-bffd-c7773a862d6a@alphasrv.net> <57d051fa-bd84-eed3-f84f-828fbbce1a8b@linuxfox.de> <9a1fe1cd-0798-5681-7f87-b7ce21908eb2@alphasrv.net> <124db294-650f-fc28-075d-16e526b16f8f@grobecker.info> Message-ID: Moin, On 29.04.22 23:02, Max Grobecker via Postfixbuch-users wrote: > wenn wir davon ausgehen, dass es an der Signatur liegt: > Enthält diese Signatur Links, möglicherweise auch noch welche über > Short-URL-Anbieter (wie bit[.]ly)? > Oder bindest du Grafiken über irgendwelche externen Dienste ein? Links ja, zur eigenen Webseite. Aber kein bitly natürlich. Grafiken sind auch drin, aber die kommen direkt mit der Mail, und werden nicht nachgeladen. Das kanns also nicht sein. -- Andre Tann