From meinpapierkorb123 at gmail.com  Sat Jun 13 14:10:01 2020
From: meinpapierkorb123 at gmail.com (Mein Papierkorb)
Date: Sat, 13 Jun 2020 14:10:01 +0200
Subject: postgrey sofort-shutdown auf debian 10
Message-ID: <8320de64-f676-539a-ea2b-04363c2fe81c@gmail.com>

Hallo zusammen,

es wurde höchste Zeit meinen Mailserver auf einen aktuellen Stand zu 
bringen.
Generell kommt zum Einsatz: Postfix, Dovecot und Postgrey.

Alter Debian-Server: Postfix 2.9.6, Dovecot 2.1.7, Postgrey 1.3.4
Neuer Debian-Server: Postfix 3.4.10, Dovecot 2.3.4.1, Postgrey 1.3.6

Die config-Files habe ich 1:1 übernommen.

Bis auf Postgrey läuft auch alles. Postfix meldet zwar "Using 
backwards-compatible default setting chroot=y", aber soweit ich das 
verstanden habe, soll das nicht weiter schlimm sein. Da ich nicht weiss, 
ob ich chroot einfach mal auf no setzen kann, würde ich es auch erstmal 
so lassen wollen. Oder besteht handlungsbedarf?

Wichtiger wäre mir, dass Postgrey wieder läuft, damit der Spam wieder 
reduziert wird.
Offenbar bin ich nicht der erste mit dem Problem:
https://serverfault.com/questions/471581/postfix-warning-connect-to-127-0-0-110023-connection-refused-not-receiving

Serverfault-Forum
Im Logfile taucht dann sowas auf:
****************
Jan 23 01:34:44 myservername postfix/smtpd[1055]: connect from 
db3ehsobe006.messaging.microsoft.com[213.199.154.144]
Jan 23 01:34:45 myservername postfix/smtpd[1055]: warning: connect to 
127.0.0.1:10023: Connection refused
Jan 23 01:34:45 myservername postfix/smtpd[1055]: warning: problem 
talking to server 127.0.0.1:10023: Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: warning: connect to 
127.0.0.1:10023: Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: warning: problem 
talking to server 127.0.0.1:10023: Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: NOQUEUE: reject: RCPT 
from db3ehsobe006.messaging.microsoft.com[213.199.154.144]: 451 4.3.5 
Server configuration problem; from=<MyKnownWorking at EmailAccountOutside> 
to=<MyAccount at MyDomain.com> proto=ESMTP 
helo=<db3outboundpool.messaging.microsoft.com>
***************


Postgrey lässt sich zwar ohne Fehlermeldung starten, beendet sich 
offenbar aber sofort wieder, ohne eine Fehlermeldung in Logfiles zu 
hinterlassen. In der Prozessliste ist postgrey nicht zu finden, was die 
Fehlermeldungen im Log erklärt.

Auf dem alten Server hatte ich in der main.cf vom Postfix
check_policy_service inet:127.0.0.1:10023,
und unter /etc/default/postgrey stand
POSTGREY_OPTS="--inet=10023"
Diese Einstellungen hatte ich 1:1 übernommen.
In dem o.g. Artikel wird dann zur Fehlerbehebung empfohlen an beiden 
Stellen entweder die 127.0.0.1 oder die externe IPv4-Adresse vor den 
Port zu setzen. Habe beides probiert, aber Postgrey beendet sich danach 
auch weiterhin sofort wieder.

Weiß jemand Rat?

Danke vorab & Gruß,
Markus


From ronny at seffner.de  Mon Jun 15 12:13:45 2020
From: ronny at seffner.de (Ronny Seffner)
Date: Mon, 15 Jun 2020 12:13:45 +0200
Subject: AW: postgrey sofort-shutdown auf debian 10
In-Reply-To: <8320de64-f676-539a-ea2b-04363c2fe81c@gmail.com>
References: <8320de64-f676-539a-ea2b-04363c2fe81c@gmail.com>
Message-ID: <018501d642fd$a8fed380$fafc7a80$@seffner.de>

Hallo Markus,

a) möchte ich Dir empfehlen, Dich mal mit rspamd zu beschäftigen, vielleicht magst Du dann postgrey ablösen
b) kannst Du doch postgrey (mit -v) mal als binary direkt an der Konsole starten (statt mit init/systemd) - dann sagt er Dir bestimmt, warum er gedenkt gleich wieder aus zu gehen

Mit freundlichen Grüßen / Kind regards
     Ronny Seffner



From infoomatic at gmx.at  Mon Jun 15 12:18:56 2020
From: infoomatic at gmx.at (infoomatic)
Date: Mon, 15 Jun 2020 12:18:56 +0200
Subject: AW: postgrey sofort-shutdown auf debian 10
In-Reply-To: <018501d642fd$a8fed380$fafc7a80$@seffner.de>
References: <8320de64-f676-539a-ea2b-04363c2fe81c@gmail.com>
 <018501d642fd$a8fed380$fafc7a80$@seffner.de>
Message-ID: <ef60c58d-0418-dd43-e850-9efee07c6603@gmx.at>

Dann werf ich auch noch was in den Pot: rspamd ist auch von mir eine
klare Empfehlung, aber wenn du postgrey mal eben schnell ablösen willst
dann würd ich einfach postscreen verwenden - wird von postfix
mitgeliefert und ist in ein paar Zeilen konfiguriert (ohne eben ein
zusätzliches mächtiges tool wie rspamd verwenden zu müssen)

LG,

infoomatic


On 15.06.20 12:13, Ronny Seffner wrote:
> Hallo Markus,
>
> a) möchte ich Dir empfehlen, Dich mal mit rspamd zu beschäftigen, vielleicht magst Du dann postgrey ablösen
> b) kannst Du doch postgrey (mit -v) mal als binary direkt an der Konsole starten (statt mit init/systemd) - dann sagt er Dir bestimmt, warum er gedenkt gleich wieder aus zu gehen
>
> Mit freundlichen Grüßen / Kind regards
>      Ronny Seffner
>


From stefan1 at hofmeir.de  Tue Jun 16 15:04:32 2020
From: stefan1 at hofmeir.de (Stefan Hofmeir)
Date: Tue, 16 Jun 2020 15:04:32 +0200
Subject: mailjet Newsletter Blacklistung
Message-ID: <919043764.20200616150432@hofmeir.de>

Hallo,

bei uns eingehende Mails durchlaufen polcyd + spamassassin auf dem
postfix-Mailserver.


1&1 IONOS setzt Mailjet als Whitelabel E-Mail-Marketing-Lösung ein.
Mailjet ist somit oft bei Newsletteraussendungen im Einsatz.
Mailjet-Mailserver stehen jedoch oft auf Blacklisten:

Beispiele:
<helo=o254.p26.mailjet.com>   policyd-weight[...]: decided action=550 I am sorry but you are falling without a chute! Blacklisted.
                              weighted check:  IN_DYN_BARRACUDA=...
<helo=o252.p26.mailjet.com>   policyd-weight[...]: decided action=550 I am sorry but you are falling without a chute! Blacklisted.
<helo=o78.p8.mailjet.com>     OK


Wie handhabt ihr das für ein gewisses Mittelmaß? Mailjet komplett
whitelisten? Das will ich aber eigentlich nicht, andererseits klagen die
Postfachnutzer, dass sie gewisse Newsletter nicht regelmäßig erreichen ...


-- 
VIele Grüße
Stefan Hofmeir



From daniel at mail24.vip  Tue Jun 16 17:44:30 2020
From: daniel at mail24.vip (Daniel)
Date: Tue, 16 Jun 2020 17:44:30 +0200
Subject: AW: mailjet Newsletter Blacklistung
In-Reply-To: <919043764.20200616150432@hofmeir.de>
References: <919043764.20200616150432@hofmeir.de>
Message-ID: <001d01d643f5$0649d9c0$12dd8d40$@mail24.vip>

Moin,

dann solltest deine Wertung prüfen!

Der genannte Eintrag hat die IP 185.189.237.254

Die IP ist gelistet bei:
BACKSCATTERER
BARRACUDA
SORBS SPAM
UCEPROTECTL1

Die IP steht aber auch auf der Whitelist
IP address 185.189.237.254 is whitelisted at dnswl.org with the following details:
DNSWL Id: 22803; Domain: mailjet.com; Sec. Domains: ; Category: Email Marketing Provider (127.0.0.x); Country: FR

Ergo, solltest ggf. barracuda raus nehmen, und auch Whitelist so bei dann die Punkte nicht mehr reichen für Blacklist.

Hier ein Beispiel wie ich es unteranderem verwende

postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites = zen.spamhaus.org*2 swl.spamhaus.org*-2 dnsbl-1.uceprotect.net*1 dnsbl-2.uceprotect.net*1 dnsbl.sorbs.net*1
bl.spamcop.net*1 ix.dnsbl.manitu.net*1 list.dnswl.org*-2

Gruß Daniel

-----Ursprüngliche Nachricht-----
Von: Postfixbuch-users <postfixbuch-users-bounces at listen.jpberlin.de> Im Auftrag von Stefan Hofmeir
Gesendet: Dienstag, 16. Juni 2020 15:05
An: Diskussionen und Support rund um Postfix <postfixbuch-users at listen.jpberlin.de>
Betreff: mailjet Newsletter Blacklistung

Hallo,

bei uns eingehende Mails durchlaufen polcyd + spamassassin auf dem
postfix-Mailserver.


1&1 IONOS setzt Mailjet als Whitelabel E-Mail-Marketing-Lösung ein.
Mailjet ist somit oft bei Newsletteraussendungen im Einsatz.
Mailjet-Mailserver stehen jedoch oft auf Blacklisten:

Beispiele:
<helo=o254.p26.mailjet.com>   policyd-weight[...]: decided action=550 I am sorry but you are falling without a chute! Blacklisted.
                              weighted check:  IN_DYN_BARRACUDA=...
<helo=o252.p26.mailjet.com>   policyd-weight[...]: decided action=550 I am sorry but you are falling without a chute! Blacklisted.
<helo=o78.p8.mailjet.com>     OK


Wie handhabt ihr das für ein gewisses Mittelmaß? Mailjet komplett
whitelisten? Das will ich aber eigentlich nicht, andererseits klagen die
Postfachnutzer, dass sie gewisse Newsletter nicht regelmäßig erreichen ...


-- 
VIele Grüße
Stefan Hofmeir

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 5545 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20200616/9b65cef6/attachment.p7s>

From bjo at schafweide.org  Tue Jun 16 22:12:21 2020
From: bjo at schafweide.org (Bjoern Franke)
Date: Tue, 16 Jun 2020 22:12:21 +0200
Subject: Offtopic: saslauthd + suse
In-Reply-To: <5ECFDDB7020000E9000505F4@weida.hki-jena.de>
References: <5ECFDDB7020000E9000505F4@weida.hki-jena.de>
Message-ID: <5b95c9d4-c4d9-4d07-97c1-44ffc3b40526@schafweide.org>

Moin,
> 
> folgendes Problem. Unser Mailgate verwendet saslauthd um unsere Nutzer 
> die von
> außen Mails einliefern wollen zu authentifizieren.  Das ganze läuft auf 
> einer VM unter
> SuSE SLES 12SP4.
> Nach einiger Zeit (2-6h) steigt die CPU Auslastung an (bis >12 bei 4 
> CPUs). saslauthd geht "noch"
>

Mal mit strace geschaut was saslauthd da macht?

Gruß
Björn


From Peer-Joachim.Koch at hki-jena.de  Wed Jun 17 15:31:42 2020
From: Peer-Joachim.Koch at hki-jena.de (Peer-Joachim Koch)
Date: Wed, 17 Jun 2020 15:31:42 +0200
Subject: Antw: Re: Offtopic: saslauthd + suse
In-Reply-To: <5b95c9d4-c4d9-4d07-97c1-44ffc3b40526@schafweide.org>
References: <5ECFDDB7020000E9000505F4@weida.hki-jena.de>
 <5b95c9d4-c4d9-4d07-97c1-44ffc3b40526@schafweide.org>
Message-ID: <5EEA375E020000E900051A28@weida.hki-jena.de>

Moin, moin,

macht nicht viel. Endlosschleife:

      1 read(8, "", 957)                        = 0
      1 select(9, [8], NULL, NULL, {0, 0})      = 1 (in [8], left {0, 0})

Es gab dazu einen Bugreport (https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/997217). 
Bin mir nicht sicher, ob der im SLES schon eingearbeitet
ist. Ich habe im Moment aber keine Zeit (und Lust) all dazugehörigen sasl Bestandteile
neu zu bauen und dann zu testen. Momentan nutze ich ein Script um den saslauthd
neu zu starten ... - nur ein Workaround, geht aber. Komisch ist nur, das die ältere Version
unter SLES11SP4 nie Probleme gemacht hat.

Ciao 
      Peer

 ____________________________________

Leibniz-Institut für Naturstoff-Forschung und Infektionsbiologie e. V.
Hans-Knöll-Institut (HKI)
Dr. Peer-Joachim Koch
 
Beutenbergstraße 11a
07745 Jena   
Tel.: +49 3641 5321029
Fax.: +49 3641 5322029
e-Mail: Peer-Joachim.Koch at HKI-Jena.de 



>>> Bjoern Franke <bjo at schafweide.org> 16.06.2020 22:12 >>>
Moin,
> 
> folgendes Problem. Unser Mailgate verwendet saslauthd um unsere Nutzer 
> die von
> außen Mails einliefern wollen zu authentifizieren.  Das ganze läuft auf 
> einer VM unter
> SuSE SLES 12SP4.
> Nach einiger Zeit (2-6h) steigt die CPU Auslastung an (bis >12 bei 4 
> CPUs). saslauthd geht "noch"
>

Mal mit strace geschaut was saslauthd da macht?

Gruß
Björn
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20200617/7e0b7535/attachment.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : PJKoch-hki.vcf
Dateityp    : text/x-vcard
Dateigröße  : 664 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20200617/7e0b7535/attachment.vcf>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/x-pkcs7-signature
Dateigröße  : 6018 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20200617/7e0b7535/attachment.bin>

From voelkers at ppp.net  Wed Jun 17 19:16:52 2020
From: voelkers at ppp.net (=?UTF-8?Q?Jan_V=c3=b6lkers?=)
Date: Wed, 17 Jun 2020 19:16:52 +0200
Subject: mailjet Newsletter Blacklistung
In-Reply-To: <919043764.20200616150432@hofmeir.de>
References: <919043764.20200616150432@hofmeir.de>
Message-ID: <2b8bf1f5-d740-3c50-28a4-431e39616716@ppp.net>

Auf jeden Fall die häufig durch Falsepositives auffallende Barracuda BL 
deaktivieren oder zumindest niedrig gewichten.

Jan

Am 16.06.20 um 15:04 schrieb Stefan Hofmeir:
> Hallo,
> 
> bei uns eingehende Mails durchlaufen polcyd + spamassassin auf dem
> postfix-Mailserver.
> 
> 
> 1&1 IONOS setzt Mailjet als Whitelabel E-Mail-Marketing-Lösung ein.
> Mailjet ist somit oft bei Newsletteraussendungen im Einsatz.
> Mailjet-Mailserver stehen jedoch oft auf Blacklisten:
> 
> Beispiele:
> <helo=o254.p26.mailjet.com>   policyd-weight[...]: decided action=550 I am sorry but you are falling without a chute! Blacklisted.
>                                weighted check:  IN_DYN_BARRACUDA=...
> <helo=o252.p26.mailjet.com>   policyd-weight[...]: decided action=550 I am sorry but you are falling without a chute! Blacklisted.
> <helo=o78.p8.mailjet.com>     OK
> 
> 
> Wie handhabt ihr das für ein gewisses Mittelmaß? Mailjet komplett
> whitelisten? Das will ich aber eigentlich nicht, andererseits klagen die
> Postfachnutzer, dass sie gewisse Newsletter nicht regelmäßig erreichen ...
> 
> 


From t.hein at inetsolutions.de  Fri Jun 19 14:14:18 2020
From: t.hein at inetsolutions.de (iNETsolutions.de [T. Hein])
Date: Fri, 19 Jun 2020 12:14:18 +0000
Subject: =?utf-8?q?pl=c3=b6tzlich=20sehr=20viele=20Recipient=20address=20rejected=3a=20unverified=20address=3a=20Address=20verification=20in=20progress?=
Message-ID: <em1299b2f6-9be0-464b-9499-e31f07501f3b@inet-hp>

Sehr geehrte Damen und Herren,

wir haben den
reject_unverified_recipient im smtpd_recipient_restrictions = aktiviert:

smtpd_recipient_restrictions =  permit_mynetworks,
                                 reject_unknown_recipient_domain,
                                 reject_unknown_sender_domain,
                                 reject_unlisted_sender,
                                 reject_unlisted_recipient,
                                 reject_non_fqdn_recipient,
                                 reject_non_fqdn_sender,
                                 permit_sasl_authenticated,
                                 check_recipient_access 
hash:/etc/postfix/recipient_access_cpanel,
                                 check_recipient_access 
hash:/etc/postfix/recipient_access,
                                 check_policy_service 
unix:postgrey/socket,
                                 #deaktiviert 19.06.20 da: Recipient 
address rejected: unverified address: Address verification in progress;
                                 #reject_unverified_recipient,
                                 reject_unauth_destination

Seit Jahren ohne Probleme.
Seit heute ca. 3 Uhr erhalten wir bei fast allen neuen Mails (es sind 
9478 Einträge im log):
cat /var/log/maillog |grep "Address verification in progress" |wc -l

z.B.
  NOQUEUE: reject: RCPT from mail-lj1-f169.google.com[209.85.208.169]:
450 4.1.1 <verschiedenste lokale mailadressen>: Recipient address 
rejected: unverified address: Address verification in progress;


Was kann der Grund dafür sein?
Die verify_cache.db haben wir gelöscht und Postfix neugestartet. Keine 
Änderung.
Wir mussten erstmal "reject_unverified_recipient" deaktivieren.


Vielen Dank schonmal.


Freundliche Grüße
T. Hein
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20200619/53be2390/attachment.htm>

From klaus at tachtler.net  Fri Jun 19 14:58:00 2020
From: klaus at tachtler.net (Klaus Tachtler)
Date: Fri, 19 Jun 2020 14:58:00 +0200
Subject: =?utf-8?b?cGzDtnR6bGljaA==?= sehr viele Recipient address
 rejected: unverified address: Address verification in progress
In-Reply-To: <em1299b2f6-9be0-464b-9499-e31f07501f3b@inet-hp>
Message-ID: <20200619145800.Horde.KzGv93c7r7v7JwBEEW7ETrR@buero.tachtler.net>

Hallo T. Hein,

Unter  
http://www.postfix.org/postconf.5.html#reject_unverified_recipient  
steht nachfolgender Eintrag:

"Reject the request when mail to the RCPT TO address is known to  
bounce, or when the recipient address destination is not reachable."

Siehe auch einen Eintrag in meinem DokuWiki, welchen ich mal für mich  
erstellt habe:
https://dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_centos_7#dynamische_adressen-verifizierung

GRUNDSÄTZLICH, unter dem Begriff Dynamic address verification  
(Dynamische Adressen-Verifizierung) ist die Möglichkeit von Postfix  
gemeint, das dieser sich im Hauptspeicher merkt, ob die e-Mail-Adresse  
existiert oder nicht. Nach einem Postfix reload, restart oder stop  
würden diese Informationen jedoch nicht mehr Verfügbar sein.
--> Deswegen die verify_cache.db

Möglicherweise liegt das Problem etwas anders. Meiner Meinung nach ist  
es doch eher die Frage, warum klappt die Überprüfung der RCPT TO:  
Empfänger im System nicht mehr?


Grüße
Klaus.


> Sehr geehrte Damen und Herren,
>
> wir haben den
> reject_unverified_recipient im smtpd_recipient_restrictions = aktiviert:
>
> smtpd_recipient_restrictions =  permit_mynetworks,
>                                 reject_unknown_recipient_domain,
>                                 reject_unknown_sender_domain,
>                                 reject_unlisted_sender,
>                                 reject_unlisted_recipient,
>                                 reject_non_fqdn_recipient,
>                                 reject_non_fqdn_sender,
>                                 permit_sasl_authenticated,
>                                 check_recipient_access  
> hash:/etc/postfix/recipient_access_cpanel,
>                                 check_recipient_access  
> hash:/etc/postfix/recipient_access,
>                                 check_policy_service unix:postgrey/socket,
>                                 #deaktiviert 19.06.20 da: Recipient  
> address rejected: unverified address: Address verification in  
> progress;
>                                 #reject_unverified_recipient,
>                                 reject_unauth_destination
>
> Seit Jahren ohne Probleme.
> Seit heute ca. 3 Uhr erhalten wir bei fast allen neuen Mails (es  
> sind 9478 Einträge im log):
> cat /var/log/maillog |grep "Address verification in progress" |wc -l
>
> z.B.
>  NOQUEUE: reject: RCPT from mail-lj1-f169.google.com[209.85.208.169]:
> 450 4.1.1 <verschiedenste lokale mailadressen>: Recipient address  
> rejected: unverified address: Address verification in progress;
>
>
> Was kann der Grund dafür sein?
> Die verify_cache.db haben wir gelöscht und Postfix neugestartet.  
> Keine Änderung.
> Wir mussten erstmal "reject_unverified_recipient" deaktivieren.
>
>
> Vielen Dank schonmal.
>
>
> Freundliche Grüße
> T. Hein


----- Ende der Nachricht von "iNETsolutions.de [T. Hein]"  
<t.hein at inetsolutions.de> -----



-- 

---------------------------------------
e-Mail  : klaus at tachtler.net
Homepage: https://www.tachtler.net
DokuWiki: https://dokuwiki.tachtler.net
---------------------------------------
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-keys
Dateigröße  : 3121 bytes
Beschreibung: Öffentlicher PGP-Schlüssel
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20200619/48518ac8/attachment.skr>

From t.hein at inetsolutions.de  Fri Jun 19 15:04:14 2020
From: t.hein at inetsolutions.de (iNETsolutions.de [T. Hein])
Date: Fri, 19 Jun 2020 13:04:14 +0000
Subject: =?utf-8?q?Re=5b2=5d=3a=20pl=c3=b6tzlich=20sehr=20viele=20Recipient=20address=20rejected=3a=20unverified=20address=3a=20Address=20verification=20in=20progress?=
In-Reply-To: <20200619145800.Horde.KzGv93c7r7v7JwBEEW7ETrR@buero.tachtler.net>
References: <em1299b2f6-9be0-464b-9499-e31f07501f3b@inet-hp>
 <20200619145800.Horde.KzGv93c7r7v7JwBEEW7ETrR@buero.tachtler.net>
Message-ID: <em426f78d8-11b5-42d8-9e91-12950c2d1639@inet-hp>

Hallo T. Hein,

Unter
http://www.postfix.org/postconf.5.html#reject_unverified_recipient
steht nachfolgender Eintrag:

"Reject the request when mail to the RCPT TO address is known to
bounce, or when the recipient address destination is not reachable."

Siehe auch einen Eintrag in meinem DokuWiki, welchen ich mal für mich
erstellt habe:
https://dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_centos_7#dynamische_adressen-verifizierung

GRUNDSÄTZLICH, unter dem Begriff Dynamic address verification
(Dynamische Adressen-Verifizierung) ist die Möglichkeit von Postfix
gemeint, das dieser sich im Hauptspeicher merkt, ob die e-Mail-Adresse
existiert oder nicht. Nach einem Postfix reload, restart oder stop
würden diese Informationen jedoch nicht mehr Verfügbar sein.
--> Deswegen die verify_cache.db

Möglicherweise liegt das Problem etwas anders. Meiner Meinung nach ist
es doch eher die Frage, warum klappt die Überprüfung der RCPT TO:
Empfänger im System nicht mehr?

Danke für die Antwort.
Ja der Empfänger ist im System.
Wir erhalten zudem auch tausende (20123) folgende Seite heute Nacht:

Jun 18 23:46:49 postfix/smtpd[51299]: too many errors after RCPT from 
mout.kundenserver.de[217.72.192.74]
too many errors after RCPT...

Wir könnten wir anfangen mit suchen?
Nicht das postfix/smtpd Probleme hat.




Grüße
Klaus.


Sehr geehrte Damen und Herren,

wir haben den
reject_unverified_recipient im smtpd_recipient_restrictions = aktiviert:

smtpd_recipient_restrictions =  permit_mynetworks,
                                 reject_unknown_recipient_domain,
                                 reject_unknown_sender_domain,
                                 reject_unlisted_sender,
                                 reject_unlisted_recipient,
                                 reject_non_fqdn_recipient,
                                 reject_non_fqdn_sender,
                                 permit_sasl_authenticated,
                                 check_recipient_access
hash:/etc/postfix/recipient_access_cpanel,
                                 check_recipient_access
hash:/etc/postfix/recipient_access,
                                 check_policy_service 
unix:postgrey/socket,
                                 #deaktiviert 19.06.20 da: Recipient
address rejected: unverified address: Address verification in
progress;
                                 #reject_unverified_recipient,
                                 reject_unauth_destination

Seit Jahren ohne Probleme.
Seit heute ca. 3 Uhr erhalten wir bei fast allen neuen Mails (es
sind 9478 Einträge im log):
cat /var/log/maillog |grep "Address verification in progress" |wc -l

z.B.
  NOQUEUE: reject: RCPT from mail-lj1-f169.google.com[209.85.208.169]:
450 4.1.1 <verschiedenste lokale mailadressen>: Recipient address
rejected: unverified address: Address verification in progress;


Was kann der Grund dafür sein?
Die verify_cache.db haben wir gelöscht und Postfix neugestartet.
Keine Änderung.
Wir mussten erstmal "reject_unverified_recipient" deaktivieren.


Vielen Dank schonmal.


Freundliche Grüße
T. Hein


----- Ende der Nachricht von "iNETsolutions.de [T. Hein]"
<t.hein at inetsolutions.de> -----



--

---------------------------------------
e-Mail  : klaus at tachtler.net
Homepage: https://www.tachtler.net
DokuWiki: https://dokuwiki.tachtler.net
---------------------------------------
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20200619/1047fe61/attachment.htm>

From list+postfixbuch at gcore.biz  Fri Jun 19 15:04:45 2020
From: list+postfixbuch at gcore.biz (Gerald Galster)
Date: Fri, 19 Jun 2020 15:04:45 +0200
Subject: =?utf-8?Q?Re=3A_pl=C3=B6tzlich_sehr_viele_Recipient_address_rejec?=
 =?utf-8?Q?ted=3A_unverified_address=3A_Address_verification_in_progress?=
In-Reply-To: <em1299b2f6-9be0-464b-9499-e31f07501f3b@inet-hp>
References: <em1299b2f6-9be0-464b-9499-e31f07501f3b@inet-hp>
Message-ID: <4E883640-28EE-47C9-9734-60C077369AB9@gcore.biz>

Hallo,

> wir haben den
> reject_unverified_recipient im smtpd_recipient_restrictions = aktiviert:
> 
> smtpd_recipient_restrictions =  permit_mynetworks,
>                                 reject_unknown_recipient_domain,
>                                 reject_unknown_sender_domain,
>                                 reject_unlisted_sender,
>                                 reject_unlisted_recipient,
>                                 reject_non_fqdn_recipient,
>                                 reject_non_fqdn_sender,
>                                 permit_sasl_authenticated,
>                                 check_recipient_access hash:/etc/postfix/recipient_access_cpanel,
>                                 check_recipient_access hash:/etc/postfix/recipient_access,
>                                 check_policy_service unix:postgrey/socket,
>                                 #deaktiviert 19.06.20 da: Recipient address rejected: unverified address: Address verification in progress;
>                                 #reject_unverified_recipient,
>                                 reject_unauth_destination
> 
> Seit Jahren ohne Probleme.
> Seit heute ca. 3 Uhr erhalten wir bei fast allen neuen Mails (es sind 9478 Einträge im log):
> cat /var/log/maillog |grep "Address verification in progress" |wc -l
> 
> z.B.
>  NOQUEUE: reject: RCPT from mail-lj1-f169.google.com <http://mail-lj1-f169.google.com/>[209.85.208.169]:
> 450 4.1.1 <verschiedenste lokale mailadressen>: Recipient address rejected: unverified address: Address verification in progress; 
> 
> 
> Was kann der Grund dafür sein?

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

address_verify_poll_count (default: normal: 3, overload: 1)
Specify 1 to implement a crude form of greylisting, that is, always defer the first delivery request for a new address.

# postconf | egrep address_verify_poll
address_verify_poll_count = ${stress?{1}:{3}}
address_verify_poll_delay = 3s

Was sagen diese Werte und war das System unter Stress?

Wie werden die Empfänger überprüft und klappt das manuell ohne Verzögerung?
Vielleicht gibt es Probleme mit einer Datenbank, einem weiteren Mailserver, Validierung über IMAP Server, RAID degraded, etc.

Außerdem werden die Daten auch zwischengespeichert, siehe CACHE CONTROLS in http://www.postfix.org/verify.8.html
Da die verify_db schon gelöscht und postfix neu gestartet wurde, liegt das Problem vermutlich anderswo.

Viele Grüße
Gerald Galster

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

From t.hein at inetsolutions.de  Fri Jun 19 16:07:51 2020
From: t.hein at inetsolutions.de (iNETsolutions.de [T. Hein])
Date: Fri, 19 Jun 2020 14:07:51 +0000
Subject: =?utf-8?q?Re=5b2=5d=3a=20pl=c3=b6tzlich=20sehr=20viele=20Recipient=20address=20rejected=3a=20unverified=20address=3a=20Address=20verification=20in=20progress?=
In-Reply-To: <4E883640-28EE-47C9-9734-60C077369AB9@gcore.biz>
References: <em1299b2f6-9be0-464b-9499-e31f07501f3b@inet-hp>
 <4E883640-28EE-47C9-9734-60C077369AB9@gcore.biz>
Message-ID: <em6005da72-7519-4017-ad22-34687d0083a8@inet-hp>

Hallo Gerald,

danke für den Input.
War kein Stress im System.
address_verify_poll_count = ${stress?1}${stress:3}
address_verify_poll_delay = 2s

"Wie werden die Empfänger überprüft und klappt das manuell ohne 
Verzögerung?"
Scheinbar durch den verify des Postfix. Was der genau macht wissen wir 
nicht

Wir glauben wir haben die Ursache, auch wenn etwas "komisch".

Wir haben die resolv.conf nun geändert. Es scheint behoben.
Wir hatten dort 4 Nameserver, wovon ggf. die letzten 2. plötzlich nicht 
mehr erreichbar sind (scheinbar über Nacht abgestellt vom RZ, auch wenn 
die meinen sie haben nichts abgestellt).

Wir haben auch wieder die reject_unverified_recipient aktiviert.
Seit 1h keine Fehler in den Logs.

Komisch ist, dass das Problem damit wirklich scheinbar zu tun hatte.
Wir gingen davon aus, dass wenn einer der DNS in der Liste nicht geht, 
wird einfach ein anderer genommen.
2/4 gingen auf jeden Fall (die 1. beiden).
Auch deuten die Logs ja nicht auf Probleme mit dem DNS.
Auch gingen von der Konsole (SSH) ja die DNS lookups problemlos.

Wir hoffen es lag wirklich daran.


------ Originalnachricht ------
Von: "Gerald Galster" <list+postfixbuch at gcore.biz>
An: "Diskussionen und Support rund um Postfix" 
<postfixbuch-users at listen.jpberlin.de>
Gesendet: 19.06.2020 15:04:45
Betreff: Re: plötzlich sehr viele Recipient address rejected: unverified 
address: Address verification in progress

>Hallo,
>
>>wir haben den
>>reject_unverified_recipient im smtpd_recipient_restrictions = 
>>aktiviert:
>>
>>smtpd_recipient_restrictions =  permit_mynetworks,
>>                                 reject_unknown_recipient_domain,
>>                                 reject_unknown_sender_domain,
>>                                 reject_unlisted_sender,
>>                                 reject_unlisted_recipient,
>>                                 reject_non_fqdn_recipient,
>>                                 reject_non_fqdn_sender,
>>                                 permit_sasl_authenticated,
>>                                 check_recipient_access 
>>hash:/etc/postfix/recipient_access_cpanel,
>>                                 check_recipient_access 
>>hash:/etc/postfix/recipient_access,
>>                                 check_policy_service 
>>unix:postgrey/socket,
>>                                 #deaktiviert 19.06.20 da: Recipient 
>>address rejected: unverified address: Address verification in 
>>progress;
>>                                 #reject_unverified_recipient,
>>                                 reject_unauth_destination
>>
>>Seit Jahren ohne Probleme.
>>Seit heute ca. 3 Uhr erhalten wir bei fast allen neuen Mails (es sind 
>>9478 Einträge im log):
>>cat /var/log/maillog |grep "Address verification in progress" |wc -l
>>
>>z.B.
>>  NOQUEUE: reject: RCPT from mail-lj1-f169.google.com[209.85.208.169]:
>>450 4.1.1 <verschiedenste lokale mailadressen>: Recipient address 
>>rejected: unverified address: Address verification in progress;
>>
>>
>>Was kann der Grund dafür sein?
>
>http://www.postfix.org/postconf.5.html#address_verify_poll_count
>
>address_verify_poll_count (default: normal: 3, overload: 1)
>Specify 1 to implement a crude form of greylisting, that is, always 
>defer the first delivery request for a new address.
>
># postconf | egrep address_verify_poll
>address_verify_poll_count = ${stress?{1}:{3}}
>address_verify_poll_delay = 3s
>
>Was sagen diese Werte und war das System unter Stress?
>
>Wie werden die Empfänger überprüft und klappt das manuell ohne 
>Verzögerung?
>Vielleicht gibt es Probleme mit einer Datenbank, einem weiteren 
>Mailserver, Validierung über IMAP Server, RAID degraded, etc.
>
>Außerdem werden die Daten auch zwischengespeichert, siehe CACHE 
>CONTROLS in http://www.postfix.org/verify.8.html
>Da die verify_db schon gelöscht und postfix neu gestartet wurde, liegt 
>das Problem vermutlich anderswo.
>
>Viele Grüße
>Gerald Galster
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20200619/e5b0f292/attachment.htm>

From list+postfixbuch at gcore.biz  Fri Jun 19 18:29:06 2020
From: list+postfixbuch at gcore.biz (Gerald Galster)
Date: Fri, 19 Jun 2020 18:29:06 +0200
Subject: =?utf-8?Q?Re=3A_pl=C3=B6tzlich_sehr_viele_Recipient_address_rejec?=
 =?utf-8?Q?ted=3A_unverified_address=3A_Address_verification_in_progress?=
In-Reply-To: <em6005da72-7519-4017-ad22-34687d0083a8@inet-hp>
References: <em1299b2f6-9be0-464b-9499-e31f07501f3b@inet-hp>
 <4E883640-28EE-47C9-9734-60C077369AB9@gcore.biz>
 <em6005da72-7519-4017-ad22-34687d0083a8@inet-hp>
Message-ID: <2DA0B71F-34DE-4584-BD60-D6A791408FD2@gcore.biz>

> danke für den Input.
> War kein Stress im System.
> address_verify_poll_count = ${stress?1}${stress:3}
> address_verify_poll_delay = 2s
> 
> "Wie werden die Empfänger überprüft und klappt das manuell ohne Verzögerung?"
> Scheinbar durch den verify des Postfix. Was der genau macht wissen wir nicht

Kommt etwas auf die Konfiguration an. Hier ein Beispiel:

Postfix nimmt eine E-Mail aus dem Internet an, die via SMTP an einen internen Mailserver zugestelt werden soll.
Während die E-Mail eingeliefert wird und die Verbindung nach extern noch besteht, baut postfix eine zweite Verbindung zum internen Mailserver auf und fragt dort nach ob der Empfänger existiert (RCPT TO).
Falls ja wird die E-Mail angenommen, falls nein wird sie abgelehnt und die externe Verbindung beendet. Das Ergebnis merkt sich postfix dann für einige Zeit.
Dadurch muss der Admin des externen postfix nur konfigurieren, dass die betreffende Domain angenommen und vom internen Server XY verwaltet wird. Er braucht selbst keine Datenbank mit aktiven E-Mail Adressen führen, da er einfach nachfragt.

> Wir glauben wir haben die Ursache, auch wenn etwas "komisch".
> 
> Wir haben die resolv.conf nun geändert. Es scheint behoben.
> Wir hatten dort 4 Nameserver, wovon ggf. die letzten 2. plötzlich nicht mehr erreichbar sind (scheinbar über Nacht abgestellt vom RZ, auch wenn die meinen sie haben nichts abgestellt).
> 
> Wir haben auch wieder die reject_unverified_recipient aktiviert.
> Seit 1h keine Fehler in den Logs.

Das klingt plausibel. Ein DNS der nicht oder schlecht antwortet, kann solche Probleme auslösen.

> Komisch ist, dass das Problem damit wirklich scheinbar zu tun hatte.
> Wir gingen davon aus, dass wenn einer der DNS in der Liste nicht geht, wird einfach ein anderer genommen.

Bei TCP bekommt man eine Rückmeldung ob ein Paket angekommen ist. Für DNS wird meist UDP verwendet, das ist einfacher, schneller und hat keinen solchen Mechanismus.
Bekommt man innerhalb von x Sekunden keine Antwort geht man davon aus, dass der Dienst nicht reagiert oder das Paket verloren ging.
Das dauert aber länger als address_verify_poll_delay/count, weshalb die Address verification wohl noch "in progress" war.

> 2/4 gingen auf jeden Fall (die 1. beiden).
> Auch deuten die Logs ja nicht auf Probleme mit dem DNS.
> Auch gingen von der Konsole (SSH) ja die DNS lookups problemlos.

Es kann sein dass die Nameserver in der resolv.conf nacheinander abgefragt werden, es gibt aber auch Optionen für round robin.

Auf Mailservern installiere ich gerne einen eigenen DNS Resolver (z.B. pdns recursor oder unbound), dann kann man 127.0.0.1 in die resolv.conf eintragen und ist unabhängig vom Provider.

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

From ad+lists at uni-x.org  Fri Jun 19 22:47:45 2020
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Fri, 19 Jun 2020 22:47:45 +0200
Subject: =?UTF-8?Q?Re=3a_pl=c3=b6tzlich_sehr_viele_Recipient_address_rejecte?=
 =?UTF-8?Q?d=3a_unverified_address=3a_Address_verification_in_progress?=
In-Reply-To: <em6005da72-7519-4017-ad22-34687d0083a8@inet-hp>
References: <em1299b2f6-9be0-464b-9499-e31f07501f3b@inet-hp>
 <4E883640-28EE-47C9-9734-60C077369AB9@gcore.biz>
 <em6005da72-7519-4017-ad22-34687d0083a8@inet-hp>
Message-ID: <d6daa908-f39b-81e6-195d-502a6ab9fe63@uni-x.org>

Am 19.06.2020 um 16:07 schrieb iNETsolutions.de [T. Hein]:

> Wir haben die resolv.conf nun geändert. Es scheint behoben.
> Wir hatten dort 4 Nameserver, wovon ggf. die letzten 2. plötzlich nicht 
> mehr erreichbar sind (scheinbar über Nacht abgestellt vom RZ, auch wenn 
> die meinen sie haben nichts abgestellt).

Typischerweise berücksichtigt der resolver der glibc maximal die ersten 
3 nameserver Einträge in der resolv.conf. Mehr einzutragen bringt nichts.

>>> Seit heute ca. 3 Uhr erhalten wir bei fast allen neuen Mails (es sind 
>>> 9478 Einträge im log):
>>> cat /var/log/maillog |grep "Address verification in progress" |wc -l

Ganz ehrlich, da stellen sich einem die Nackenhaare auf.

grep -c "Address verification in progress" /var/log/maillog.

Alexander




From infoomatic at gmx.at  Wed Jun 24 15:59:22 2020
From: infoomatic at gmx.at (infoomatic)
Date: Wed, 24 Jun 2020 15:59:22 +0200
Subject: seltsames Zustellproblem
Message-ID: <907fc918-3cc1-122e-2d10-9a4ef04d2c93@gmx.at>

Hello Liste,

Kennt ihr das wenn ihr auf ein Logfile guckt und euch denkt "das gibts
nicht!"?

Nunja, mir gehts grad so, vielleicht kann mir jemand helfen.

Ich habe hier 2 Domains die über Office365 Mails an mich schicken
wollen, bei einer funktionierts, bei der anderen nicht (generell
funktioniert dieses Setup seit über 5 Jahren sehr gut).

Ich reiche relevante Ports per iptables seit eh und je an einen
LXC-Container durch und es funktioniert, a la:

iptables -t nat -A PREROUTING -p tcp --dest 1.Y.Y.Y --dport 25 -j DNAT
--to 192.168.10.17:25


Eine Mail die von der problematischen Domain kommt liefert mir die
relevanten Logeinträge weiter unten [1].

Ich verstehe, dass mir pyspf den Fehler not authorized meldet. Ich
verstehe allerdings nicht wie es dazu kommt dass postscreen eine
Verbindung von meiner externen IP-Adresse 1.Y.Y.Y erhält. Bei jeder
anderen Domain erhalte ich wie unten im Log in den ersten beiden Zeilen
die IP-Adresse des einliefernden hosts (NAT halt...). Logisch, das pyspf
motzt weil ja scheinbar meine externe IP-Adresse versucht mit der
Absenderdomain zu einzuliefern. Ich versteh die Welt nicht mehr!

Bitte um Hilfe!

LG,

Robert

[1]

Jun 24 12:48:16 mail_u16 postfix/postscreen[3859]: CONNECT from
[1.Y.Y.Y]:2946 to [192.168.10.17]:25
Jun 24 12:48:22 mail_u16 postfix/postscreen[3859]: PASS OLD [1.Y.Y.Y]:2946
Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: warning: hostname
mail.PRIMARYDOMAIN does not resolve to address 1.Y.Y.Y
Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: connect from unknown[1.Y.Y.Y]
Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: Anonymous TLS connection
established from unknown[1.Y.Y.Y]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jun 24 12:48:22 mail_u16 policyd-spf[3870]: spfcheck: pyspf result:
"['Fail', 'SPF fail - not authorized', 'helo']"
Jun 24 12:48:22 mail_u16 policyd-spf[3870]: Fail; identity=helo;
client-ip=1.Y.Y.Y; helo=eur04-ZZ.outbound.protection.outlook.com;
envelope-from=USER at SENDER_2_DOMAIN; receiver=infoomatic at DOMAIN
Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: NOQUEUE: reject: RCPT from
unknown[1.Y.Y.Y]: 550 5.7.1 <infoomatic at DOMAIN>: Recipient address
rejected: Message rejected due to: SPF fail - not authorized. Please see
http://www.openspf.net/Why?s=helo;id=eur04-ZZ.outbound.protection.outlook.com;ip=1.Y.Y.Y;r=infoomatic at DOMAIN;
from=<USER at SENDER_2_DOMAIN> to=<infoomatic at DOMAIN> proto=ESMTP
helo=<EUR04-ZZ.outbound.protection.outlook.com>
Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: disconnect from
unknown[1.Y.Y.Y] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6



From driessen at fblan.de  Wed Jun 24 17:03:24 2020
From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Wed, 24 Jun 2020 17:03:24 +0200
Subject: AW: seltsames Zustellproblem
In-Reply-To: <907fc918-3cc1-122e-2d10-9a4ef04d2c93@gmx.at>
References: <907fc918-3cc1-122e-2d10-9a4ef04d2c93@gmx.at>
Message-ID: <015301d64a38$9d525150$d7f6f3f0$@fblan.de>

Im Auftrag von infoomatic

Dur das  Maskieren gehen die wirklich wertvollen Informationen verloren 
Und bei Office365 bekomme ich eh schon graue Haare :-)
Datenschutz und so .....
> 
> [1]
> 
> Jun 24 12:48:16 mail_u16 postfix/postscreen[3859]: CONNECT from
> [1.Y.Y.Y]:2946 to [192.168.10.17]:25
> Jun 24 12:48:22 mail_u16 postfix/postscreen[3859]: PASS OLD [1.Y.Y.Y]:2946
> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: warning: hostname
> mail.PRIMARYDOMAIN does not resolve to address 1.Y.Y.Y


Das Logfile mosert hier DNS an 


> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: connect from
> unknown[1.Y.Y.Y]
> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: Anonymous TLS connection
> established from unknown[1.Y.Y.Y]: TLSv1.2 with cipher

Kein DNS deswegen unknown, PTR ? 

> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Jun 24 12:48:22 mail_u16 policyd-spf[3870]: spfcheck: pyspf result:
> "['Fail', 'SPF fail - not authorized', 'helo']"
> Jun 24 12:48:22 mail_u16 policyd-spf[3870]: Fail; identity=helo;
> client-ip=1.Y.Y.Y; helo=eur04-ZZ.outbound.protection.outlook.com;
> envelope-from=USER at SENDER_2_DOMAIN; receiver=infoomatic at DOMAIN
> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: NOQUEUE: reject: RCPT from
> unknown[1.Y.Y.Y]: 550 5.7.1 <infoomatic at DOMAIN>: Recipient address
> rejected: Message rejected due to: SPF fail - not authorized. Please see
> http://www.openspf.net/Why?s=helo;id=eur04-
> ZZ.outbound.protection.outlook.com;ip=1.Y.Y.Y;r=infoomatic at DOMAIN;
> from=<USER at SENDER_2_DOMAIN> to=<infoomatic at DOMAIN>
> proto=ESMTP
> helo=<EUR04-ZZ.outbound.protection.outlook.com>
> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: disconnect from
> unknown[1.Y.Y.Y] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6

Es sollte reichen den localpart zu maskieren
Ansonsten musst du halt mal schauen ob alle DNS / PTR richtig gesetzt sind auch von den Absenderadressen.
Muss ja nicht an deinem Setup liegen sofern du nix geändert hast  


Mit freundlichen Grüßen

Uwe Drießen
--
Software & Computer

Netzwerke, Server. 
Wir vernetzen Sie und Ihre Rechner !

Uwe Drießen
Lembergstraße 33
67824 Feilbingert

Tel.: 06708660045 

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





From infoomatic at gmx.at  Wed Jun 24 21:52:40 2020
From: infoomatic at gmx.at (infoomatic)
Date: Wed, 24 Jun 2020 21:52:40 +0200
Subject: AW: seltsames Zustellproblem
In-Reply-To: <015301d64a38$9d525150$d7f6f3f0$@fblan.de>
References: <907fc918-3cc1-122e-2d10-9a4ef04d2c93@gmx.at>
 <015301d64a38$9d525150$d7f6f3f0$@fblan.de>
Message-ID: <6da4cd82-d5e4-7f50-483b-ae4bc343a514@gmx.at>

Hi,

Danke für deinen Input! Nach längerem Hirn abschalten und erneutem
Anlauf habe ich beschlossen dem Problem nicht weiter auf den Grund zu
gehn. Das ursprüngliche Problem war eigentlich dass die Mails von der
einen O365Domain an eine andere O365Domain im Spam gelandet sind, und
ich mir Testmails von der Problem-Domain an mich selbst schicken lassen
hab - da konnte ich im Logfile nachsehn. Ich bin nun nicht schlauer
geworden, und die problematische Domain geht mich nichts an.

Ich verstehe wirklich nicht wieso postscreen vorgibt eine Verbindung von
meiner externen IP zum internen Mailserver im Namen des Absenders zu
erhalten ... interessieren würds mich natürlich brennend aber der
Zeitaufwand ist es nicht wert, es war nur die eine Testmail die nicht
durchging, andere Mails von der Problemdomain (hab nen Testaccount
bekommen) kommen nun ohne jegliche Konfig-Änderung wieder wie gewohnt
an. Es ist seltsam ... ich stempel es als Laune der Technik ab.

Schönen Abend!

Robert



On 24.06.20 17:03, Uwe Drießen wrote:
> Im Auftrag von infoomatic
>
> Dur das  Maskieren gehen die wirklich wertvollen Informationen verloren
> Und bei Office365 bekomme ich eh schon graue Haare :-)
> Datenschutz und so .....
>> [1]
>>
>> Jun 24 12:48:16 mail_u16 postfix/postscreen[3859]: CONNECT from
>> [1.Y.Y.Y]:2946 to [192.168.10.17]:25
>> Jun 24 12:48:22 mail_u16 postfix/postscreen[3859]: PASS OLD [1.Y.Y.Y]:2946
>> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: warning: hostname
>> mail.PRIMARYDOMAIN does not resolve to address 1.Y.Y.Y
>
> Das Logfile mosert hier DNS an
>
>
>> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: connect from
>> unknown[1.Y.Y.Y]
>> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: Anonymous TLS connection
>> established from unknown[1.Y.Y.Y]: TLSv1.2 with cipher
> Kein DNS deswegen unknown, PTR ?
>
>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>> Jun 24 12:48:22 mail_u16 policyd-spf[3870]: spfcheck: pyspf result:
>> "['Fail', 'SPF fail - not authorized', 'helo']"
>> Jun 24 12:48:22 mail_u16 policyd-spf[3870]: Fail; identity=helo;
>> client-ip=1.Y.Y.Y; helo=eur04-ZZ.outbound.protection.outlook.com;
>> envelope-from=USER at SENDER_2_DOMAIN; receiver=infoomatic at DOMAIN
>> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: NOQUEUE: reject: RCPT from
>> unknown[1.Y.Y.Y]: 550 5.7.1 <infoomatic at DOMAIN>: Recipient address
>> rejected: Message rejected due to: SPF fail - not authorized. Please see
>> http://www.openspf.net/Why?s=helo;id=eur04-
>> ZZ.outbound.protection.outlook.com;ip=1.Y.Y.Y;r=infoomatic at DOMAIN;
>> from=<USER at SENDER_2_DOMAIN> to=<infoomatic at DOMAIN>
>> proto=ESMTP
>> helo=<EUR04-ZZ.outbound.protection.outlook.com>
>> Jun 24 12:48:22 mail_u16 postfix/smtpd[3864]: disconnect from
>> unknown[1.Y.Y.Y] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6
> Es sollte reichen den localpart zu maskieren
> Ansonsten musst du halt mal schauen ob alle DNS / PTR richtig gesetzt sind auch von den Absenderadressen.
> Muss ja nicht an deinem Setup liegen sofern du nix geändert hast
>
>
> Mit freundlichen Grüßen
>
> Uwe Drießen
> --
> Software & Computer
>
> Netzwerke, Server.
> Wir vernetzen Sie und Ihre Rechner !
>
> Uwe Drießen
> Lembergstraße 33
> 67824 Feilbingert
>
> Tel.: 06708660045
>
> "wenn Digitalisierung den Aufwand im Vergleich zur Analogen Arbeitsweise dermaßen erhöht, das wir nur noch am PC sitzen müssten,
>  dann wird es Zeit sich zu überlegen zur Analogen Arbeitsweise zurückzukehren"
> "Programmierer müssen lernen wie Menschen denken. "
>
>
>