From ffiene at veka.com  Thu May  2 12:37:28 2019
From: ffiene at veka.com (Frank Fiene)
Date: Thu, 2 May 2019 12:37:28 +0200
Subject: =?utf-8?Q?Problem_mit_DNS-Aufl=C3=B6sung_in_Postfix_=28was=3A_Re?=
 =?utf-8?Q?=3A_Frage_zu_HFILTER=5FHOSTNAME=5FUNKNOWN=29?=
In-Reply-To: <5cada805-855c-68b6-1d18-2568d77e218b@ncxs.de>
References: <B1B5B073-E273-4286-9926-7C618A288F51@veka.com>
 <5cada805-855c-68b6-1d18-2568d77e218b@ncxs.de>
Message-ID: <A86FF73B-5A52-4267-AE3F-CE92EC0FB7A5@veka.com>

Ich hänge mal das Log an:

May  2 11:26:14 smtp1 postfix/smtpd[25965]: connect from unknown[199.122.127.224]
May  2 11:26:15 smtp1 postfix/smtpd[25965]: Anonymous TLS connection established from unknown[199.122.127.224]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
May  2 11:26:15 smtp1 postfix/smtpd[25965]: B34661048F: client=unknown[199.122.127.224]
May  2 11:26:16 smtp1 postfix/smtpd[25965]: disconnect from unknown[199.122.127.224] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

Das kann man auch ohne debug im rspamd erkennen! :-)

Jetzt frage ich mich, warum postfix keine DNS-Auflösung macht, rspamd und der Rest des OS aber sehr wohl.

Der smtpd läuft nicht im chroot, ich habe keine Idee mehr und sehe den Wald vor lauter Bäumen nicht. :-(


Viele Grüße! Frank







> Am 30.04.2019 um 14:00 schrieb Carsten Rosenberg <cr at ncxs.de>:
> 
> Hallo Frank,
> 
> HFILTER löst die IP nicht selbst auf sondern verläßt sich auf die Angabe
> von Postfix, der das via Milter mitliefert.
> 
> Wenn du bei debug_modules milter hinzu fügst, kannst du das genau
> beobachten.
> 
> Viele Grüße
> 
> Carsten
> 
> On 29.04.19 16:25, Frank Fiene wrote:
>> Ich habe folgendes Problem, hier der Auszug aus dem Log (Ich habe den
>> Score für HFILTER_HOSTNAME_UNKNOWN auf 4,5 erhöht, nicht wundern):
>> 
>> smtp3 rspamd[24840]: <7925f1>; proxy; rspamd_task_write_log: id:
>> <1454046738 at vekauk.com <mailto:1454046738 at vekauk.com>>, qid:
>> <302BF16B41>, ip: 213.246.110.84, from: <noreply at vekauk.com
>> <mailto:noreply at vekauk.com>>, (default: T (add header): [11.18/12.00]
>> [HFILTER_HOSTNAME_UNKNOWN(4.50){},
>> 
>> 
>> Wenn ich jetzt auf den Mailgateways teste, wird der Host aber FcrDNS
>> aufgelöst:
>> 
>> gauss:~ ffiene$ host 213.246.110.84
>> 84.110.246.213.in <http://84.110.246.213.in>-addr.arpa domain name
>> pointer server6.thinkap.co.uk <http://server6.thinkap.co.uk>.
>> gauss:~ ffiene$ host server6.thinkap.co.uk <http://server6.thinkap.co.uk>
>> server6.thinkap.co.uk <http://server6.thinkap.co.uk> has address
>> 213.246.110.84
>> 
>> Wie kommt es dann, dass das Modul überhaupt anschlägt?
>> 
>> 
>> 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 <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 AG
>> Dieselstr. 8
>> 48324 Sendenhorst
>> Deutschland/Germany
>> 
>> Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
>> Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr.
>> Werner Schuler,
>> Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
>> 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 AG
Dieselstr. 8
48324 Sendenhorst
Deutschland/Germany

Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler,
Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
HRB 8282 AG Münster/District Court of Münster

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

From r.wagner at licoho.de  Thu May  2 17:08:41 2019
From: r.wagner at licoho.de (Ronny Wagner)
Date: Thu, 2 May 2019 15:08:41 +0000
Subject: Postscreen und mehrere IP-Instanzen
Message-ID: <e2868517506443b1ae54f8e15d7e9d84@licoho.de>

Hallo Zusammen,

ich bin aktuelle am Testen von Postscreen auf meinem Server mit mehrere IPv4 & IPv6 Adressen und bin hier auf ein "Problem" für mich gestoßen.

master.cf
IPv4:25	inet	n	-	n	-	1	postscreen
    -o smtpd_sasl_auth_enable=no
    -o syslog_name=postfix-ipv4_25
[1te IPv6]:25	inet	n	-	n	-	1	postscreen
    -o smtpd_sasl_auth_enable=no
    -o syslog_name=postfix-ipv6_1_25
[2te IPv6]:25	inet	n	-	n	-	1	postscreen
    -o smtpd_sasl_auth_enable=no
    -o syslog_name=postfix-ipv6_2_25
smtpd     pass  -       -       n       -       -       smtpd
dnsblog   unix  -       -       n       -       0       dnsblog
tlsproxy  unix  -       -       n       -       0       tlsproxy

Fehlermeldung:
May  2 12:01:57 server postfix-ipv6_1_25/postscreen[22023]: fatal: btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily unavailable
May  2 12:01:58 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid 22023 exit status 1
May  2 12:01:58 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command startup -- throttling
May  2 12:02:58 server postfix-ipv6_1_25/postscreen[22615]: fatal: btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily unavailable
May  2 12:02:59 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid 22615 exit status 1
May  2 12:02:59 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command startup -- throttling
May  2 12:03:59 server postfix-ipv6_1_25/postscreen[22638]: fatal: btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily unavailable
May  2 12:04:00 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid 22638 exit status 1
May  2 12:04:00 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command startup -- throttling

Habt Ihr mir einen Tipp wie ich diese Thematik lösen könnte, ohne das es in der master.cf nur " smtp      inet  n       -       -       -       1       postscreen" heißt?

Vielen Dank für Eure Hilfe im Voraus.

Mit freundlichen Grüßen/Best Regards
Ronny Wagner
Betriebswirt (VWA)

Tel.: (+49)160/4431965
E-Mail: r.wagner at licoho.de

LiCoHo
Jooßstraße 7
D-73433 Aalen/Wasseralfingen
E-Mail: info at licoho.de
Internet: http://www.licoho.de
Anti-Spam: https://as.licoho.de

Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte sofort den Absender und löschen danach die E-Mail. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


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

From forum at ruhnke.cloud  Thu May  2 17:32:52 2019
From: forum at ruhnke.cloud (forum at ruhnke.cloud)
Date: Thu, 02 May 2019 15:32:52 +0000
Subject: Postscreen und mehrere IP-Instanzen
In-Reply-To: <e2868517506443b1ae54f8e15d7e9d84@licoho.de>
References: <e2868517506443b1ae54f8e15d7e9d84@licoho.de>
Message-ID: <9723002810eae1d570b5b13c6980c282@ruhnke.cloud>

Moin,

früher ging es mit memcache, aber es sollte ab Version 2.8 oder 2.9 (weiß ich grad nicht genau) mit 
> postscreen_cache_map = proxy:btree:/var/lib/postfix/postscreen_cache
funktionieren, das mehrere Postcreen-Instanzen auf eine Datei zugreifen können.

Gruß
Florian

2. Mai 2019 17:08, "Ronny Wagner" <r.wagner at licoho.de> schrieb:

> Hallo Zusammen,
> 
> ich bin aktuelle am Testen von Postscreen auf meinem Server mit mehrere IPv4 & IPv6 Adressen und
> bin hier auf ein "Problem" für mich gestoßen.
> 
> master.cf
> IPv4:25 inet n - n - 1 postscreen
> -o smtpd_sasl_auth_enable=no
> -o syslog_name=postfix-ipv4_25
> [1te IPv6]:25 inet n - n - 1 postscreen
> -o smtpd_sasl_auth_enable=no
> -o syslog_name=postfix-ipv6_1_25
> [2te IPv6]:25 inet n - n - 1 postscreen
> -o smtpd_sasl_auth_enable=no
> -o syslog_name=postfix-ipv6_2_25
> smtpd pass - - n - - smtpd
> dnsblog unix - - n - 0 dnsblog
> tlsproxy unix - - n - 0 tlsproxy
> 
> Fehlermeldung:
> May 2 12:01:57 server postfix-ipv6_1_25/postscreen[22023]: fatal:
> btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily
> unavailable
> May 2 12:01:58 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid
> 22023 exit status 1
> May 2 12:01:58 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command
> startup -- throttling
> May 2 12:02:58 server postfix-ipv6_1_25/postscreen[22615]: fatal:
> btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily
> unavailable
> May 2 12:02:59 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid
> 22615 exit status 1
> May 2 12:02:59 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command
> startup -- throttling
> May 2 12:03:59 server postfix-ipv6_1_25/postscreen[22638]: fatal:
> btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily
> unavailable
> May 2 12:04:00 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid
> 22638 exit status 1
> May 2 12:04:00 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command
> startup -- throttling
> 
> Habt Ihr mir einen Tipp wie ich diese Thematik lösen könnte, ohne das es in der master.cf nur "
> smtp inet n - - - 1 postscreen" heißt?
> 
> Vielen Dank für Eure Hilfe im Voraus.
> 
> Mit freundlichen Grüßen/Best Regards
> Ronny Wagner
> Betriebswirt (VWA)
> 
> Tel.: (+49)160/4431965
> E-Mail: r.wagner at licoho.de
> 
> LiCoHo
> Jooßstraße 7
> D-73433 Aalen/Wasseralfingen
> E-Mail: info at licoho.de
> Internet: http://www.licoho.de
> Anti-Spam: https://as.licoho.de
> 
> Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls
> diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte sofort den Absender und
> löschen danach die E-Mail. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht
> gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie
> eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an.
> 
> This e-mail may contain confidential and/or privileged information. If you are not the intended
> recipient (or have received this e-mail in error) please notify the sender immediately and destroy
> this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is
> strictly forbidden.


From forum at ruhnke.cloud  Thu May  2 17:24:09 2019
From: forum at ruhnke.cloud (forum at ruhnke.cloud)
Date: Thu, 02 May 2019 15:24:09 +0000
Subject: =?utf-8?B?UmVsYXlob3N0IG51ciBmw7xyIGJlc3RpbW10ZSBFbXBmw6Q=?=
 =?utf-8?B?bmdlcmRvbWFpbnM=?=
Message-ID: <18432fa0f86da70e061476ac6c14f865@ruhnke.cloud>

Moin,

entweder stelle ich mich zu blöd an, oder ich frage Google die falschen Fragen...

Mein Problem:
Der Mailserver sitzt hinter einer dynamischen IPv4. Die steht (logischerweise) auf vielen Spamlists und löst auch nicht auf meine Domain auf.
Um das zu umschiffen, kann ich auf Relayhosts von Mailgun, Mailjet, Sendgrid und Socketlabs zurückgreifen. Die wiederum haben das Problem, dass sie den Envelope verändern (mal ganz davon ab, dass sie die Mails zusätzlich ein weiteres Mal DKIM-signieren, was aber an sich ja nicht schlimm ist und nur die Header aufbläht). Mit einem Umschlag, der nicht zu meiner Domain gehört, zicken aber z.B. Mailman-Listen gern rum.

Meine Idee ist daher: Die Relays nur benutzen, wenn ich es brauche (erst versuchen, die Mail direkt zu senden und wenn z.B. "554 refused to talk to me" kommt, die Zustellung über ein Relay zu machn) und z.B. wenn eine IPv6-Verbindung möglich ist, gar nicht.
Also, wie sender_dependent_relayhost_maps, nur als reciptient_dependent_relayhost_maps. Irgendwie entweder per Hand eine Liste führen, welche Mailserver für mich nicht direkt erreichbar sind, oder ein automatisches Fallback, wenn die Mail ohne Relay nicht zugestellt werden kann.

Oder ich finde ein Relay, welches den envelope nicht verändert bzw. sich nicht zu erkennen gibt... (vermutlich ist es dann einfacher, sich eine feste IPv4 zu organisieren)


Gruß
Florian


From andreas.schulze at datev.de  Thu May  2 19:48:50 2019
From: andreas.schulze at datev.de (Andreas Schulze)
Date: Thu, 2 May 2019 19:48:50 +0200
Subject: Postscreen und mehrere IP-Instanzen
In-Reply-To: <e2868517506443b1ae54f8e15d7e9d84@licoho.de>
References: <e2868517506443b1ae54f8e15d7e9d84@licoho.de>
Message-ID: <b48956c9-1397-09d9-a9f2-a48ceaecabc9@datev.de>

Am 02.05.2019 um 17:08 schrieb Ronny Wagner:
> Hallo Zusammen,
>
> ich bin aktuelle am Testen von Postscreen auf meinem Server mit mehrere IPv4 & IPv6 Adressen und bin hier auf ein "Problem" für mich gestoßen.
>
> master.cf
> IPv4:25	inet	n	-	n	-	1	postscreen
>      -o smtpd_sasl_auth_enable=no
>      -o syslog_name=postfix-ipv4_25
> [1te IPv6]:25	inet	n	-	n	-	1	postscreen
>      -o smtpd_sasl_auth_enable=no
>      -o syslog_name=postfix-ipv6_1_25
> [2te IPv6]:25	inet	n	-	n	-	1	postscreen
>      -o smtpd_sasl_auth_enable=no
>      -o syslog_name=postfix-ipv6_2_25
> smtpd     pass  -       -       n       -       -       smtpd
> dnsblog   unix  -       -       n       -       0       dnsblog
> tlsproxy  unix  -       -       n       -       0       tlsproxy

ich habe noch nie "postscreen" auf IPs gebunden und dann mehrer 
Instanzen auf diese Art gestartet.
Normal habe ich einen Postscreen, der auf MX-Adresse. Die 
Submission-Adressen laufen ohne Postscreen, so wie's in "man 8 
postscreen" empfohlen ist.

Oder ich baue gleich 2 Postfix-Instanzen ...

Andreas
>
> Fehlermeldung:
> May  2 12:01:57 server postfix-ipv6_1_25/postscreen[22023]: fatal: btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily unavailable
> May  2 12:01:58 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid 22023 exit status 1
> May  2 12:01:58 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command startup -- throttling
> May  2 12:02:58 server postfix-ipv6_1_25/postscreen[22615]: fatal: btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily unavailable
> May  2 12:02:59 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid 22615 exit status 1
> May  2 12:02:59 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command startup -- throttling
> May  2 12:03:59 server postfix-ipv6_1_25/postscreen[22638]: fatal: btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily unavailable
> May  2 12:04:00 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid 22638 exit status 1
> May  2 12:04:00 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command startup -- throttling
>
> Habt Ihr mir einen Tipp wie ich diese Thematik lösen könnte, ohne das es in der master.cf nur " smtp      inet  n       -       -       -       1       postscreen" heißt?
>
> Vielen Dank für Eure Hilfe im Voraus.
>
> Mit freundlichen Grüßen/Best Regards
> Ronny Wagner
> Betriebswirt (VWA)
>
> Tel.: (+49)160/4431965
> E-Mail: r.wagner at licoho.de
>
> LiCoHo
> Jooßstraße 7
> D-73433 Aalen/Wasseralfingen
> E-Mail: info at licoho.de
> Internet: http://www.licoho.de
> Anti-Spam: https://as.licoho.de
>
> Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte sofort den Absender und löschen danach die E-Mail. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an.
>
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>
>



From michael at linuxfox.de  Thu May  2 20:22:46 2019
From: michael at linuxfox.de (Michael Grundmann)
Date: Thu, 2 May 2019 20:22:46 +0200
Subject: =?UTF-8?Q?Re=3a_Relayhost_nur_f=c3=bcr_bestimmte_Empf=c3=a4ngerdoma?=
 =?UTF-8?Q?ins?=
In-Reply-To: <18432fa0f86da70e061476ac6c14f865@ruhnke.cloud>
References: <18432fa0f86da70e061476ac6c14f865@ruhnke.cloud>
Message-ID: <4587ad4d-012c-d0ec-7db9-cf91624804a7@linuxfox.de>

Am 02.05.19 um 17:24 schrieb forum at ruhnke.cloud:

Moin,

> entweder stelle ich mich zu blöd an, oder ich frage Google die falschen Fragen...

analog Al Bundy: https://www.youtube.com/watch?v=Jy4gdM6ya0U - hier a 
... sorry

> Also, wie sender_dependent_relayhost_maps, nur als reciptient_dependent_relayhost_maps. Irgendwie entweder per Hand eine Liste führen, welche Mailserver für mich nicht direkt erreichbar sind, oder ein automatisches Fallback, wenn die Mail ohne Relay nicht zugestellt werden kann.

sollten so jenseits der 98% Mailserver sein

> Oder ich finde ein Relay, welches den envelope nicht verändert bzw. sich nicht zu erkennen gibt... (vermutlich ist es dann einfacher, sich eine feste IPv4 zu organisieren)

gute Idee - echter Mailserver/Relay mit ordentlichem PTR und kein 
SchnickSchncak ;)


-- 
Gruß Michael

Wenn du verstehst, was du tust, wirst du nichts lernen
BTW: Produktionsbremsen sind immer die Bürokraten


From ffiene at veka.com  Thu May  2 21:13:31 2019
From: ffiene at veka.com (Frank Fiene)
Date: Thu, 2 May 2019 21:13:31 +0200
Subject: =?utf-8?Q?Re=3A_Problem_mit_DNS-Aufl=C3=B6sung_in_Postfix_=28was?=
 =?utf-8?Q?=3A_Re=3A_Frage_zu_HFILTER=5FHOSTNAME=5FUNKNOWN=29?=
In-Reply-To: <A86FF73B-5A52-4267-AE3F-CE92EC0FB7A5@veka.com>
References: <B1B5B073-E273-4286-9926-7C618A288F51@veka.com>
 <5cada805-855c-68b6-1d18-2568d77e218b@ncxs.de>
 <A86FF73B-5A52-4267-AE3F-CE92EC0FB7A5@veka.com>
Message-ID: <5191146D-5640-4CAF-B0B9-C68205A898E8@veka.com>

So, der Baum ist gefunden, smtp lief sehr wohl im chroot.

Also chroot ausgeschaltet und dann funktioniert es.

Komisch nur, dass die Dateien für den DNS-Zugriff alle schön in /var/spool/postfix vorhanden waren.
Also Libraries, resolve.conf und so weiter. Sehr komisch.


Viele Grüße! Frank


> Am 02.05.2019 um 12:37 schrieb Frank Fiene <ffiene at veka.com>:
> 
> Ich hänge mal das Log an:
> 
> May  2 11:26:14 smtp1 postfix/smtpd[25965]: connect from unknown[199.122.127.224]
> May  2 11:26:15 smtp1 postfix/smtpd[25965]: Anonymous TLS connection established from unknown[199.122.127.224]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> May  2 11:26:15 smtp1 postfix/smtpd[25965]: B34661048F: client=unknown[199.122.127.224]
> May  2 11:26:16 smtp1 postfix/smtpd[25965]: disconnect from unknown[199.122.127.224] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
> 
> Das kann man auch ohne debug im rspamd erkennen! :-)
> 
> Jetzt frage ich mich, warum postfix keine DNS-Auflösung macht, rspamd und der Rest des OS aber sehr wohl.
> 
> Der smtpd läuft nicht im chroot, ich habe keine Idee mehr und sehe den Wald vor lauter Bäumen nicht. :-(
> 
> 
> Viele Grüße! Frank
> 
> 
> 
> 
> 
> 
> 
>> Am 30.04.2019 um 14:00 schrieb Carsten Rosenberg <cr at ncxs.de <mailto:cr at ncxs.de>>:
>> 
>> Hallo Frank,
>> 
>> HFILTER löst die IP nicht selbst auf sondern verläßt sich auf die Angabe
>> von Postfix, der das via Milter mitliefert.
>> 
>> Wenn du bei debug_modules milter hinzu fügst, kannst du das genau
>> beobachten.
>> 
>> Viele Grüße
>> 
>> Carsten
>> 
>> On 29.04.19 16:25, Frank Fiene wrote:
>>> Ich habe folgendes Problem, hier der Auszug aus dem Log (Ich habe den
>>> Score für HFILTER_HOSTNAME_UNKNOWN auf 4,5 erhöht, nicht wundern):
>>> 
>>> smtp3 rspamd[24840]: <7925f1>; proxy; rspamd_task_write_log: id:
>>> <1454046738 at vekauk.com <mailto:1454046738 at vekauk.com> <mailto:1454046738 at vekauk.com <mailto:1454046738 at vekauk.com>>>, qid:
>>> <302BF16B41>, ip: 213.246.110.84, from: <noreply at vekauk.com <mailto:noreply at vekauk.com>
>>> <mailto:noreply at vekauk.com <mailto:noreply at vekauk.com>>>, (default: T (add header): [11.18/12.00]
>>> [HFILTER_HOSTNAME_UNKNOWN(4.50){},
>>> 
>>> 
>>> Wenn ich jetzt auf den Mailgateways teste, wird der Host aber FcrDNS
>>> aufgelöst:
>>> 
>>> gauss:~ ffiene$ host 213.246.110.84
>>> 84.110.246.213.in <http://84.110.246.213.in/> <http://84.110.246.213.in <http://84.110.246.213.in/>>-addr.arpa domain name
>>> pointer server6.thinkap.co.uk <http://server6.thinkap.co.uk/> <http://server6.thinkap.co.uk <http://server6.thinkap.co.uk/>>.
>>> gauss:~ ffiene$ host server6.thinkap.co.uk <http://server6.thinkap.co.uk/> <http://server6.thinkap.co.uk <http://server6.thinkap.co.uk/>>
>>> server6.thinkap.co.uk <http://server6.thinkap.co.uk/> <http://server6.thinkap.co.uk <http://server6.thinkap.co.uk/>> has address
>>> 213.246.110.84
>>> 
>>> Wie kommt es dann, dass das Modul überhaupt anschlägt?
>>> 
>>> 
>>> 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 <mailto:ffiene at veka.com> <mailto:ffiene at veka.com <mailto:ffiene at veka.com>>
>>> http://www.veka.com <http://www.veka.com/>
>>> 
>>> PGP-ID: 62112A51
>>> PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51
>>> Threema: VZK5NDWW
>>> 
>>> VEKA AG
>>> Dieselstr. 8
>>> 48324 Sendenhorst
>>> Deutschland/Germany
>>> 
>>> Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
>>> Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr.
>>> Werner Schuler,
>>> Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
>>> 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 <mailto:ffiene at veka.com>
> http://www.veka.com <http://www.veka.com/>
> 
> PGP-ID: 62112A51
> PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51
> Threema: VZK5NDWW
> 
> VEKA AG
> Dieselstr. 8
> 48324 Sendenhorst
> Deutschland/Germany
> 
> Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
> Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler,
> Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
> 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 AG
Dieselstr. 8
48324 Sendenhorst
Deutschland/Germany

Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler,
Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
HRB 8282 AG Münster/District Court of Münster

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

From r.wagner at licoho.de  Fri May  3 10:18:45 2019
From: r.wagner at licoho.de (Ronny Wagner)
Date: Fri, 3 May 2019 08:18:45 +0000
Subject: AW: Postscreen und mehrere IP-Instanzen
In-Reply-To: <9723002810eae1d570b5b13c6980c282@ruhnke.cloud>
References: <e2868517506443b1ae54f8e15d7e9d84@licoho.de>
 <9723002810eae1d570b5b13c6980c282@ruhnke.cloud>
Message-ID: <57d1737be7d24e7a86867fd351642eda@licoho.de>

Hallo Florian,

danke, hat Top geholfen der Tip.

Danke

Mit freundlichen Grüßen/Best Regards
Ronny 


-----Ursprüngliche Nachricht-----
Von: Postfixbuch-users <postfixbuch-users-bounces at listen.jpberlin.de> Im Auftrag von forum at ruhnke.cloud
Gesendet: Donnerstag, 2. Mai 2019 17:33
An: Diskussionen und Support rund um Postfix <postfixbuch-users at listen.jpberlin.de>
Betreff: Re: Postscreen und mehrere IP-Instanzen

Moin,

früher ging es mit memcache, aber es sollte ab Version 2.8 oder 2.9 (weiß ich grad nicht genau) mit 
> postscreen_cache_map = proxy:btree:/var/lib/postfix/postscreen_cache
funktionieren, das mehrere Postcreen-Instanzen auf eine Datei zugreifen können.

Gruß
Florian

2. Mai 2019 17:08, "Ronny Wagner" <r.wagner at licoho.de> schrieb:

> Hallo Zusammen,
> 
> ich bin aktuelle am Testen von Postscreen auf meinem Server mit mehrere IPv4 & IPv6 Adressen und
> bin hier auf ein "Problem" für mich gestoßen.
> 
> master.cf
> IPv4:25 inet n - n - 1 postscreen
> -o smtpd_sasl_auth_enable=no
> -o syslog_name=postfix-ipv4_25
> [1te IPv6]:25 inet n - n - 1 postscreen
> -o smtpd_sasl_auth_enable=no
> -o syslog_name=postfix-ipv6_1_25
> [2te IPv6]:25 inet n - n - 1 postscreen
> -o smtpd_sasl_auth_enable=no
> -o syslog_name=postfix-ipv6_2_25
> smtpd pass - - n - - smtpd
> dnsblog unix - - n - 0 dnsblog
> tlsproxy unix - - n - 0 tlsproxy
> 
> Fehlermeldung:
> May 2 12:01:57 server postfix-ipv6_1_25/postscreen[22023]: fatal:
> btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily
> unavailable
> May 2 12:01:58 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid
> 22023 exit status 1
> May 2 12:01:58 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command
> startup -- throttling
> May 2 12:02:58 server postfix-ipv6_1_25/postscreen[22615]: fatal:
> btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily
> unavailable
> May 2 12:02:59 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid
> 22615 exit status 1
> May 2 12:02:59 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command
> startup -- throttling
> May 2 12:03:59 server postfix-ipv6_1_25/postscreen[22638]: fatal:
> btree:/var/lib/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily
> unavailable
> May 2 12:04:00 server postfix/master[28844]: warning: process /usr/lib/postfix/sbin/postscreen pid
> 22638 exit status 1
> May 2 12:04:00 server postfix/master[28844]: warning: /usr/lib/postfix/sbin/postscreen: bad command
> startup -- throttling
> 
> Habt Ihr mir einen Tipp wie ich diese Thematik lösen könnte, ohne das es in der master.cf nur "
> smtp inet n - - - 1 postscreen" heißt?
> 
> Vielen Dank für Eure Hilfe im Voraus.
> 
> Mit freundlichen Grüßen/Best Regards
> Ronny Wagner
> Betriebswirt (VWA)
> 
> Tel.: (+49)160/4431965
> E-Mail: r.wagner at licoho.de
> 
> LiCoHo
> Jooßstraße 7
> D-73433 Aalen/Wasseralfingen
> E-Mail: info at licoho.de
> Internet: http://www.licoho.de
> Anti-Spam: https://as.licoho.de
> 
> Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls
> diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte sofort den Absender und
> löschen danach die E-Mail. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht
> gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie
> eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an.
> 
> This e-mail may contain confidential and/or privileged information. If you are not the intended
> recipient (or have received this e-mail in error) please notify the sender immediately and destroy
> this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is
> strictly forbidden.
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 2100 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190503/7f2c495c/attachment.p7s>

From Hajo.Locke at gmx.de  Mon May  6 08:53:42 2019
From: Hajo.Locke at gmx.de (Hajo Locke)
Date: Mon, 6 May 2019 08:53:42 +0200
Subject: postfix - opendkim milter
Message-ID: <821ab2e0-fa37-af31-9cd5-7a1c508f4329@gmx.de>

Hallo Liste,

habe hier komisches Verhalten von postfix mit opendkim milter.
opemdkim ist normal über den socket mit postfix verbunden:

milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:/var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock

Klappt auch alles wunderbar, bis auf eine Ausnahme.
opendkim hat wohl ein Größenlimit für den Header, konfigurierbar per 
MaximumHeaders
Per default steht das auf 64k

Ist der Header größer, dann reagiert opendkim im Log mit: 
opendkim[5032]: too much header data
Das Problem habe ich dann speziell bei Mails die per php erzeugt wurden. 
Diese Mails kommen dann aus dem maildrop Ordner nicht heraus und würden 
dort wohl ewig liegen, wenn ich das nicht entdeckt hätte, die 
Verarbeitung geht dann keinen Schritt weiter. Die Mails lagen aber auch 
jetzt schon länger als maximal_queue_lifetime im maildrop.
Hatte das schon mal jemand? Ich habe das Größenlimit erst mal 
aufgehoben.  Eine Lösung mit Limit und gleichzeitig nicht blockierten 
Mails wäre mir aber lieber. Kann mir da jemand bitte einen Tipp geben?
In der opendkim.conf habe ich nur die notwendigen Zeilen:

Mode                    sv
Socket                  local:/var/run/opendkim/opendkim.sock
UserID                  opendkim:opendkim
UMask                   002
PidFile                 /var/run/opendkim/opendkim.pid
AutoRestart             yes
AutoRestartRate         10/1h
Syslog                  yes
SyslogSuccess           yes
LogWhy                  yes
Canonicalization        relaxed/relaxed
ExternalIgnoreList      refile:/etc/opendkim/trusted
InternalHosts           refile:/etc/opendkim/trusted
SigningTable            refile:/etc/opendkim/signing.table
KeyTable                /etc/opendkim/key.table
SignatureAlgorithm      rsa-sha256
OversignHeaders         From
RemoveOldSignatures     True
SubDomains              True


Danke,
Hajo

From wn at neessen.net  Mon May  6 09:03:32 2019
From: wn at neessen.net (Winfried Neessen)
Date: Mon, 6 May 2019 09:03:32 +0200
Subject: postfix - opendkim milter
In-Reply-To: <821ab2e0-fa37-af31-9cd5-7a1c508f4329@gmx.de>
References: <821ab2e0-fa37-af31-9cd5-7a1c508f4329@gmx.de>
Message-ID: <3464097E-5681-45C3-91D8-2691653DD381@neessen.net>

Hi Hajo,

On 6. May 2019, at 08:53, Hajo Locke <Hajo.Locke at gmx.de> wrote:

> Klappt auch alles wunderbar, bis auf eine Ausnahme.
> opendkim hat wohl ein Größenlimit für den Header, konfigurierbar per MaximumHeaders
> Per default steht das auf 64k
> 
> Hatte das schon mal jemand? Ich habe das Größenlimit erst mal aufgehoben.  Eine Lösung mit Limit und gleichzeitig
> nicht blockierten Mails wäre mir aber lieber. Kann mir da jemand bitte einen Tipp geben?
> 
Hatte ich noch nicht, aber wo liegt das Problem das Limit anzuheben? Das Header Limit ist eine Art Schutz vor DoS,
falls mal ein Client verbindet, der uebergrosse Header sendet. Solang Du das Limit mit "0" nicht abschaltest sondern
einen sinnvollen, groesseren Wert einsetzt, der fuer Dich passt, sollte es kein Problem sein das Limit anzuheben. Die
Standardwerte der Entwickler sind ja nur Empfehlungen - die koennen ja auch nicht jeden speziellen Fall (wie bei Dir
den PHP Kram) abdecken.


Winni


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

From andreas.schulze at datev.de  Mon May  6 09:14:15 2019
From: andreas.schulze at datev.de (Andreas Schulze)
Date: Mon, 6 May 2019 09:14:15 +0200
Subject: postfix - opendkim milter
In-Reply-To: <821ab2e0-fa37-af31-9cd5-7a1c508f4329@gmx.de>
References: <821ab2e0-fa37-af31-9cd5-7a1c508f4329@gmx.de>
Message-ID: <4e1b96b6-35bf-b620-081d-95579d8f1a09@datev.de>

Am 06.05.19 um 08:53 schrieb Hajo Locke:


> milter_protocol = 6
das ist default, muss also eigentlich nicht in der main.cf stehen ...

> Das Problem habe ich dann speziell bei Mails die per php erzeugt wurdenIch denke, Dein PHP-Schript ist buggy. Header sind selten > 64k
Ich vermute, dass die Mails an den Zeilenenden irgendwo falsche Zeilenumbrüche hat oder die Grenze zwischen Header und Body nicht sauber ist.
Der Mailbody wird dadurch weiterhin als Header interpretiert und triggert deine Fehlermeldung.

Andreas



-- 
A. Schulze
DATEV eG


From Hajo.Locke at gmx.de  Mon May  6 09:14:34 2019
From: Hajo.Locke at gmx.de (Hajo Locke)
Date: Mon, 6 May 2019 09:14:34 +0200
Subject: postfix - opendkim milter
In-Reply-To: <3464097E-5681-45C3-91D8-2691653DD381@neessen.net>
References: <821ab2e0-fa37-af31-9cd5-7a1c508f4329@gmx.de>
 <3464097E-5681-45C3-91D8-2691653DD381@neessen.net>
Message-ID: <a8760658-cfa5-337d-82c2-f5bca3d97bb6@gmx.de>

Hallo,

Am 06.05.2019 um 09:03 schrieb Winfried Neessen:
> Hi Hajo,
>
> On 6. May 2019, at 08:53, Hajo Locke <Hajo.Locke at gmx.de> wrote:
>
>> Klappt auch alles wunderbar, bis auf eine Ausnahme.
>> opendkim hat wohl ein Größenlimit für den Header, konfigurierbar per MaximumHeaders
>> Per default steht das auf 64k
>>
>> Hatte das schon mal jemand? Ich habe das Größenlimit erst mal aufgehoben.  Eine Lösung mit Limit und gleichzeitig
>> nicht blockierten Mails wäre mir aber lieber. Kann mir da jemand bitte einen Tipp geben?
>>
> Hatte ich noch nicht, aber wo liegt das Problem das Limit anzuheben? Das Header Limit ist eine Art Schutz vor DoS,
> falls mal ein Client verbindet, der uebergrosse Header sendet. Solang Du das Limit mit "0" nicht abschaltest sondern
> einen sinnvollen, groesseren Wert einsetzt, der fuer Dich passt, sollte es kein Problem sein das Limit anzuheben. Die
> Standardwerte der Entwickler sind ja nur Empfehlungen - die koennen ja auch nicht jeden speziellen Fall (wie bei Dir
> den PHP Kram) abdecken.
Ja, auf eine sinnvolle Erhöhung wird es hinauslaufen. Ich würde aber
gern verstehen, was genau das Problem war. Das die Verarbeitung komplett
stockt und die Mails ewig liegen würden, darf eigentlich nicht sein.
>
>
> Winni
>
>
Hajo


From Hajo.Locke at gmx.de  Mon May  6 10:15:40 2019
From: Hajo.Locke at gmx.de (Hajo Locke)
Date: Mon, 6 May 2019 10:15:40 +0200
Subject: postfix - opendkim milter
In-Reply-To: <4e1b96b6-35bf-b620-081d-95579d8f1a09@datev.de>
References: <821ab2e0-fa37-af31-9cd5-7a1c508f4329@gmx.de>
 <4e1b96b6-35bf-b620-081d-95579d8f1a09@datev.de>
Message-ID: <31dd622f-8174-558d-1173-1516c71b5619@gmx.de>

Hallo,

Am 06.05.2019 um 09:14 schrieb Andreas Schulze:
> Am 06.05.19 um 08:53 schrieb Hajo Locke:
>
>
>> milter_protocol = 6
> das ist default, muss also eigentlich nicht in der main.cf stehen ...
>
>> Das Problem habe ich dann speziell bei Mails die per php erzeugt wurdenIch denke, Dein PHP-Schript ist buggy. Header sind selten > 64k
> Ich vermute, dass die Mails an den Zeilenenden irgendwo falsche Zeilenumbrüche hat oder die Grenze zwischen Header und Body nicht sauber ist.
> Der Mailbody wird dadurch weiterhin als Header interpretiert und triggert deine Fehlermeldung.
Wäre auch eine Möglichkeit, ich probier das mal nachzustellen.
Ich teste auch mal die Direktive "On-Default              accept"
Dann muss ich das Limit eventuell nicht anheben, wenn dass den Fehler
überstimmt.
>
> Andreas
>
>
>
Hajo


From kai_postfix at fuerstenberg.ws  Wed May  8 12:44:55 2019
From: kai_postfix at fuerstenberg.ws (=?UTF-8?Q?Kai_F=c3=bcrstenberg?=)
Date: Wed, 8 May 2019 12:44:55 +0200
Subject: Postfix stellt Mails an einen bestimmten Benutzer nicht zu
In-Reply-To: <64221421-0563-cce6-7ce1-10ece44614d7@rmr.tu-darmstadt.de>
References: <2a92cf15-542a-5b85-47c3-d1eed9f5caf6@rmr.tu-darmstadt.de>
 <d7d749c3-f9d4-4fd7-36d3-8c09ddbe7d32@fuerstenberg.ws>
 <2b0afcef-1cbb-a3a5-c809-581655cea976@rmr.tu-darmstadt.de>
 <5251031c-d503-b997-d82f-f4bc431e4567@fuerstenberg.ws>
 <f0177ab7-9850-9d81-0406-c40e13a0677a@rmr.tu-darmstadt.de>
 <8142cd34-c1f4-1bac-7f0c-9f6b2200c5fa@fuerstenberg.ws>
 <64221421-0563-cce6-7ce1-10ece44614d7@rmr.tu-darmstadt.de>
Message-ID: <d1af4101-8946-fb8d-e85b-6acb207d9c25@fuerstenberg.ws>

Hi Sylvia,

zunächst habe ich mich einmal geirrt: Postfix loggt kein "queued as", er
gibt dieses aber an den einliefernden Server zurück, der es seinerseits
loggt oder loggen kann.

Am 08.05.2019 um 11:53 schrieb Sylvia Gelman:
> vielen Dank für die Hinweise. postfix flush habe ich natürlich schon 
> x-mal versucht. In Kurzform:
> 
> May  8 11:46:01 glia postfix/qmgr[25181]: 1AD5F240CBB: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: AFECC240FAC: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: 8D67B24092E: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: 9B5BE2412F2: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: E57042401C0: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: 6591B240C30: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: 4B1C92401BE: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: 887BE2414AF: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: 1017B24014C: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: 56DBF240F35: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: 78BE1240A20: skipped, still 
> being delivered
> May  8 11:46:01 glia postfix/qmgr[25181]: C133624159E: skipped, still 
> being delivered
> 
> nach Einschalten des -vv bei qmgr, kommt das Log unten heraus.

Bitte kein verbose und kein rumgeschnippsel mehr.
Ich hätte gerne mal ein komplettes Log in ganz normaler Form.

Nimm also bitte mal alle -vv raus aus der master.cf, postfix reload,
postfix flush und poste den kompletten Logausschnmitt am besten so wie
es ist, ohne Auslassungen oder Ergänzungen.

Bzw. liefere mal eine neue Mail an den Empfänger ein und poste den
kompletten Logausschnmitt am besten so wie es ist, ohne Auslassungen
oder Ergänzungen.

>> mich irritiert, dass es keine Logeinträge gibt. Mich irritiert auch,
>> dass unter mailq keine Angaben zur Verzögerung eingetragen sind.
>> Normalerweise steht da, warum es länger dauert oder ob die Mail of HOLD
>> steht.
> ja das irritiert mich ja auch, es müsste schon längst der Sender 
> informiert worden sein, dass die Mail nicht zugestellt werden konnte.
>>   Evtl. vorher den
>> Loglevel von Cyrus höhersetzen.
> 
> Wo setze ich den Loglevel von Cyrus höher? Finde dazu nichts.

Der Loglevel von Cyrus wird über syslogd gesteuert. In der Cyrus-Zeile
musst du debug gesondert setzen.

Wie gesagt, ist ewig her, dass ich den benutzt habe...

-- 
Kai Fürstenberg

PM an: kai at fuerstenberg punkt ws




From michael at linuxfox.de  Thu May  9 09:16:09 2019
From: michael at linuxfox.de (Michael Grundmann)
Date: Thu, 9 May 2019 09:16:09 +0200
Subject: =?UTF-8?Q?nach_Milter-Einbindung_keine_bcc-Aktionen_mehr_m=c3=b6gli?=
 =?UTF-8?Q?ch?=
Message-ID: <696a5d41-00d0-8793-d54b-69a1fe1d30b8@linuxfox.de>

Hallo zusammen,

gestern hatte ich ein merkwürdiges Problem - folgenden Aufbau hatte ich:

Postfix der via Proxyfilter auf externen Virenscanner zustellt. 
Irgendwann habe ich den rspamd noch als besseren Spamschutz dahinter 
geschaltet via milter.
So weit so gut, funktioniert alles, bis darauf, dass der rspamd nicht 
seine volle "Kraft" an den Tag legt, da er z. B. die Mails vom 
Virenscanner aus dem LAN zugestellt bekommt.

Da ich die volle Funktionalität vom rspamd nutzen wollte, habe ich das 
System so umgestellt, dass sowohl der lokale rspamd als auch der 
Virenscanner via milter angesteuert wurden:

smtpd_milters = inet:127.0.0.1:11332,
                 inet:192.168.1.1:10025
non_smtpd_milters =     inet:localhost:11332

milter_connect_macros = j _ {daemon_name} {if_name} {if_addr}
milter_helo_macros = {tls_version} {cipher} {cipher_bits} {cert_subject} 
{cert_issuer}
milter_mail_macros = i {auth_type} {auth_authen} {auth_ssf} 
{auth_author} {mail_mailer} {mail_host} {mail_addr} {cl$
milter_rcpt_macros = {rcpt_mailer} {rcpt_host} {rcpt_addr}
milter_default_action = tempfail
milter_protocol = 6
milter_connect_timeout=180
milter_command_timeout=180
milter_content_timeout=600

Diese weiteren milter-Optionen wurden vom Virenscanner vorgegeben und 
funktionieren auf einem anderen System perfekt.

Nach der Umstellung funktionierte das hier auch alles, aber sämtliche 
eingestellte bcc-Funktionen wurden nicht mehr ausgeführt:

recipient_bcc_maps = mysql:/etc/postfix/recipient_bcc_mysql.cf (Anfragen 
an die DB kamen aber an)
always_bcc=xxxx at xxxxx.xxxxx

Leider kann ich das postconf -n z. Z. nicht mitgeben, da ich das alte 
System wieder aktiviert habe.

Hat jemand eine Idee, warum meine bcc nicht mehr ausführt wurden?

-- 
Gruß Michael

Wenn du verstehst, was du tust, wirst du nichts lernen
BTW: Produktionsbremsen sind immer die Bürokraten


From sebastian at debianfan.de  Sat May 11 10:57:49 2019
From: sebastian at debianfan.de (sebastian at debianfan.de)
Date: Sat, 11 May 2019 10:57:49 +0200
Subject: Kontakt zu Tbits.net
Message-ID: <df47402f-34d3-48f2-3a04-047508f89d67@debianfan.de>

Moin,

ich probiere es jetzt mal mit dem "Vorschlaghammer" - liesst hier jemand 
von der Firma Tbits.net mit und könnte sich "zeitnah" bei mir melden ?

address:        Tbits.net GmbH
address:        Bruehlweg 9
address:        73553 Alfdorf

Herzliche Grüße

Sebastian




From mailinglisten at pothe.de  Sat May 11 13:59:15 2019
From: mailinglisten at pothe.de (Andreas Pothe)
Date: Sat, 11 May 2019 13:59:15 +0200
Subject: Kontakt zu Tbits.net
In-Reply-To: <df47402f-34d3-48f2-3a04-047508f89d67@debianfan.de>
References: <df47402f-34d3-48f2-3a04-047508f89d67@debianfan.de>
Message-ID: <4c904bd3-ef44-adc6-1999-ecd5f0c9e165@pothe.de>

Hi,

ist das nicht eine Satireseite? "Nussletter". "IT-Sicherheit". Aber die
eigenen Mailserver können nicht mal TLS. Laut
https://mxtoolbox.com/domain/tbits.net/ könnten sie sogar Open Relays sein.
Unwahrscheinlich, dass hier jemand mitliest, der dafür verantwortlich ist.

CU
Andreas

Am 11.05.2019 um 10:57 schrieb sebastian at debianfan.de:
> Moin,
>
> ich probiere es jetzt mal mit dem "Vorschlaghammer" - liesst hier
> jemand von der Firma Tbits.net mit und könnte sich "zeitnah" bei mir
> melden ?
>
> address:        Tbits.net GmbH
> address:        Bruehlweg 9
> address:        73553 Alfdorf
>
> Herzliche Grüße
>
> Sebastian
>
>



From ffiene at veka.com  Wed May 15 09:54:54 2019
From: ffiene at veka.com (Frank Fiene)
Date: Wed, 15 May 2019 09:54:54 +0200
Subject: rspamd / multimaps Reihenfolge
Message-ID: <2E7A71F3-77AA-46AF-AC9D-FA12A6AE6620@veka.com>

Moin,

Ich habe mal wieder eine Frage zu rspamd.

Ich habe in multimaps eine Domain-Blacklist gepflegt, um z.B. Eingänge von meinen eigenen Domains direkt abzuweisen.
Die können da nicht reinkommen, es sei denn von ein paar freigegebenen IP-Adressen.

Dazu habe ich eine Whitelist auf Basis von IP-Adresse vor der Domain-Blacklist gepflegt.

Das klappt irgendwie nicht. Gibt es da keine Reihenfolge, wie die multimaps bearbeitet werden?


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 AG
Dieselstr. 8
48324 Sendenhorst
Deutschland/Germany

Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler,
Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
HRB 8282 AG Münster/District Court of Münster



From cr at ncxs.de  Wed May 15 16:28:57 2019
From: cr at ncxs.de (Carsten Rosenberg)
Date: Wed, 15 May 2019 16:28:57 +0200
Subject: rspamd / multimaps Reihenfolge
In-Reply-To: <2E7A71F3-77AA-46AF-AC9D-FA12A6AE6620@veka.com>
References: <2E7A71F3-77AA-46AF-AC9D-FA12A6AE6620@veka.com>
Message-ID: <06d7bd71-7937-9dfd-5171-fea6459e6305@ncxs.de>

Hi Frank,

Ich glaube die Ausführung der Multimaps läßt sich in der Config nicht
einstellen. GGf. wäre das mit dependencies möglich.

Ich denke der bessere Weg wäre aber in multimap keine action zu
definieren, sondern nur ein Symbol zu setzen und die Symbole in
force_actions abzufragen:

  MY_BLACKLIST {
    # This is the action we want to force
    action = "reject";
    # If the following combination of symbols is present:
    expression = "!IS_IN_WHITELIST & BLACKLIST_DOMAIN";
  }

Oder DMARC/DKIM ;)

Viele Grüße

Carsten

On 15.05.19 09:54, Frank Fiene wrote:
> Moin,
> 
> Ich habe mal wieder eine Frage zu rspamd.
> 
> Ich habe in multimaps eine Domain-Blacklist gepflegt, um z.B. Eingänge von meinen eigenen Domains direkt abzuweisen.
> Die können da nicht reinkommen, es sei denn von ein paar freigegebenen IP-Adressen.
> 
> Dazu habe ich eine Whitelist auf Basis von IP-Adresse vor der Domain-Blacklist gepflegt.
> 
> Das klappt irgendwie nicht. Gibt es da keine Reihenfolge, wie die multimaps bearbeitet werden?
> 
> 
> Viele Grüße!
> Frank
> 


From ffiene at veka.com  Wed May 15 19:56:53 2019
From: ffiene at veka.com (Frank Fiene)
Date: Wed, 15 May 2019 19:56:53 +0200
Subject: rspamd / multimaps Reihenfolge
In-Reply-To: <06d7bd71-7937-9dfd-5171-fea6459e6305@ncxs.de>
References: <2E7A71F3-77AA-46AF-AC9D-FA12A6AE6620@veka.com>
 <06d7bd71-7937-9dfd-5171-fea6459e6305@ncxs.de>
Message-ID: <DFF29163-63FA-4C72-88C2-87F09E90A480@veka.com>

Oh ja, gute Idee, Carsten.

Thx!



> Am 15.05.2019 um 16:28 schrieb Carsten Rosenberg <cr at ncxs.de>:
> 
> Hi Frank,
> 
> Ich glaube die Ausführung der Multimaps läßt sich in der Config nicht
> einstellen. GGf. wäre das mit dependencies möglich.
> 
> Ich denke der bessere Weg wäre aber in multimap keine action zu
> definieren, sondern nur ein Symbol zu setzen und die Symbole in
> force_actions abzufragen:
> 
>  MY_BLACKLIST {
>    # This is the action we want to force
>    action = "reject";
>    # If the following combination of symbols is present:
>    expression = "!IS_IN_WHITELIST & BLACKLIST_DOMAIN";
>  }
> 
> Oder DMARC/DKIM ;)
> 
> Viele Grüße
> 
> Carsten
> 
> On 15.05.19 09:54, Frank Fiene wrote:
>> Moin,
>> 
>> Ich habe mal wieder eine Frage zu rspamd.
>> 
>> Ich habe in multimaps eine Domain-Blacklist gepflegt, um z.B. Eingänge von meinen eigenen Domains direkt abzuweisen.
>> Die können da nicht reinkommen, es sei denn von ein paar freigegebenen IP-Adressen.
>> 
>> Dazu habe ich eine Whitelist auf Basis von IP-Adresse vor der Domain-Blacklist gepflegt.
>> 
>> Das klappt irgendwie nicht. Gibt es da keine Reihenfolge, wie die multimaps bearbeitet werden?
>> 
>> 
>> Viele Grüße!
>> Frank
>> 

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 AG
Dieselstr. 8
48324 Sendenhorst
Deutschland/Germany

Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler,
Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
HRB 8282 AG Münster/District Court of Münster

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

From Hajo.Locke at gmx.de  Tue May 21 10:18:44 2019
From: Hajo.Locke at gmx.de (Hajo Locke)
Date: Tue, 21 May 2019 10:18:44 +0200
Subject: spezielle catch-all verarbeitung
Message-ID: <5a1e577e-cb04-1fef-db2a-29508b49df57@gmx.de>

Hallo Liste,

ich habe folgendes Szenario:
Über die virtual habe ich eine globale Weiterleitung einer subdomain auf
eine domain eingerichtet:

@sub.example.com @example.com

@example.com selbst ist eine Weiterleitung an eine externe Adresse.
Zusätzlich existiert das benannte Postfach mybox at example.com
Auf Systemen mit Postfix 3.1 funktioniert das bisher so:
Sende ich an beliebige Adressen der Catch-All Subdomain, geht alles an
die externe Adresse. Sende ich an mybox at sub.example.com geht die Mail
über die Weiterleitung und auch an das lokale Postfach
mybox at example.com, da Postfix über das Catch-all mybox at sub.example.com
auf mybox at example.com mappt.

Ich habe nun Server mit Postfix 3.3, welche die selbe main.cf verwenden.
Hier klappt das Ganze aber nun nicht mehr. Die Mail geht nur nach
extern, weil das mapping mybox at sub.example.com auf mybox at example.com
nicht mehr greift.

Es muss sich doch hier zwischen den Versionen ein default geändert
haben, der das ganze veranlasst, ich finde aber leider nichts passendes.
Ist hier jemandem eine Direktive bekannt mit der ich testen könnte?

Danke,
Hajo



From klaus at tachtler.net  Tue May 21 14:24:01 2019
From: klaus at tachtler.net (Klaus Tachtler)
Date: Tue, 21 May 2019 14:24:01 +0200
Subject: spezielle catch-all verarbeitung
In-Reply-To: <5a1e577e-cb04-1fef-db2a-29508b49df57@gmx.de>
Message-ID: <20190521142401.Horde.sDY3KAs28UVm3asTdio0o2e@buero.tachtler.net>

Hallo Hajo,

was sagt denn jeweils ein --> postconf -d <-- auf dem Postfix 3.1 und  
dem Postfix 3.3?

Gibt es eine Fehlermeldung im LOG?

Hast Du Einstellungen bei  
http://www.postfix.org/postconf.5.html#compatibility_level gesetzt?

Schau mal hier: http://www.postfix.org/COMPATIBILITY_README.html

Nachfolgende Einstellungen haben sich definitiv geändert:

- append_dot_mydomain=yes
- smtpd_relay_restrictions = (empty)
- mynetworks_style=subnet
- relay_domains=$mydestination
- smtputf8_enable=no

Siehe auch mein DokuWiki, welches ich mal für mich erstellt habe
(Ist zwar von Postfix 2.x auf 3.x, aber vielleicht hilft es Dir auch weiter):

https://dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_centos_7_-_migration_von_version_2.x_auf_3.x


Grüße
Klaus.

> Hallo Liste,
>
> ich habe folgendes Szenario:
> Über die virtual habe ich eine globale Weiterleitung einer subdomain auf
> eine domain eingerichtet:
>
> @sub.example.com @example.com
>
> @example.com selbst ist eine Weiterleitung an eine externe Adresse.
> Zusätzlich existiert das benannte Postfach mybox at example.com
> Auf Systemen mit Postfix 3.1 funktioniert das bisher so:
> Sende ich an beliebige Adressen der Catch-All Subdomain, geht alles an
> die externe Adresse. Sende ich an mybox at sub.example.com geht die Mail
> über die Weiterleitung und auch an das lokale Postfach
> mybox at example.com, da Postfix über das Catch-all mybox at sub.example.com
> auf mybox at example.com mappt.
>
> Ich habe nun Server mit Postfix 3.3, welche die selbe main.cf verwenden.
> Hier klappt das Ganze aber nun nicht mehr. Die Mail geht nur nach
> extern, weil das mapping mybox at sub.example.com auf mybox at example.com
> nicht mehr greift.
>
> Es muss sich doch hier zwischen den Versionen ein default geändert
> haben, der das ganze veranlasst, ich finde aber leider nichts passendes.
> Ist hier jemandem eine Direktive bekannt mit der ich testen könnte?
>
> Danke,
> Hajo


----- Ende der Nachricht von Hajo Locke <Hajo.Locke at gmx.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/20190521/3226ef08/attachment.skr>

From gjn at gjn.priv.at  Thu May 23 12:59:09 2019
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Thu, 23 May 2019 12:59:09 +0200
Subject: postscreen_cache shared
Message-ID: <1599770.jWLJodW6lR@techz>

Hallo,

Da ich auf einmal Probleme mit postfix bekommen habe, habe ich mich 
entschlossen auf die 3.4.5 Version umzusteigen.

Da scheint mein Problem mit "aliases"! wieder zu funktionieren?

Jetzt zu meiner Frage, ich habe zwei mailserver laufen mx01,mx02 und würde 
gerne den postcreen_cache auf beiden Servern synchronisieren, da ich bemerkt 
habe, funktioniert der eine nicht geht man auf den anderen.

Was ich bis jetzt gelesen habe (?), sollte man dazu jetzt "proxy" statt 
"memcache" verwenden nur ich finde dazu einfach kein Beispiel wie das 
konfiguriert werden muss.

Kann einer von Euch mir da auf die Sprünge helfen.

Besten Dank für eine Antwort,
-- 
mit freundliche Grüßen / best regards,

  Günther J. Niederwimmer




From klaus at tachtler.net  Thu May 23 15:12:29 2019
From: klaus at tachtler.net (Klaus Tachtler)
Date: Thu, 23 May 2019 15:12:29 +0200
Subject: postscreen_cache shared
In-Reply-To: <1599770.jWLJodW6lR@techz>
Message-ID: <20190523151229.Horde.7Dio66tf1qMw6bb7eK9qZyo@buero.tachtler.net>

Hallo Günther,

siehe auch: http://www.postfix.org/memcache_table.5.html

Evtl. meinst Du nachfolgende Konfiguration mit "proxy" und dem Teilen  
des postscreen_cache via memcacheD:

---- %< ----

# Non-shared postscreen cache.
backup = btree:/var/lib/postfix/postscreen_cache_map

# Shared postscreen cache for processes on the SAME HOST.
backup = proxy:btree:/var/lib/postfix/postscreen_cache_map

===> Access to remote proxymap servers is under development. <===

---- >% ----

a.) Teilen zwischen Postfix-Instanzen NUR auf dem selben Host
---> Siehe auch: http://www.postfix.org/MULTI_INSTANCE_README.html

b.) !!! "Access to remote proxymap servers is under development." !!!


Grüße
Klaus.


> Hallo,
>
> Da ich auf einmal Probleme mit postfix bekommen habe, habe ich mich
> entschlossen auf die 3.4.5 Version umzusteigen.
>
> Da scheint mein Problem mit "aliases"! wieder zu funktionieren?
>
> Jetzt zu meiner Frage, ich habe zwei mailserver laufen mx01,mx02 und würde
> gerne den postcreen_cache auf beiden Servern synchronisieren, da ich bemerkt
> habe, funktioniert der eine nicht geht man auf den anderen.
>
> Was ich bis jetzt gelesen habe (?), sollte man dazu jetzt "proxy" statt
> "memcache" verwenden nur ich finde dazu einfach kein Beispiel wie das
> konfiguriert werden muss.
>
> Kann einer von Euch mir da auf die Sprünge helfen.
>
> Besten Dank für eine Antwort,
> --
> mit freundliche Grüßen / best regards,
>
>   Günther J. Niederwimmer



-- 

--------------------------------------------
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/20190523/a4bd1fbd/attachment.skr>

From klaus at tachtler.net  Thu May 23 15:41:29 2019
From: klaus at tachtler.net (Klaus Tachtler)
Date: Thu, 23 May 2019 15:41:29 +0200
Subject: Frage zu: append_dot_mydomain und append_at_myorigin
Message-ID: <20190523154129.Horde.43l7sb9DUYo0ChQeb94KVqJ@buero.tachtler.net>

Hallo Liste,

ich habe versucht einen Postfix 3.4.5 so zu konfigurieren, das dieser  
NUR lokale E-Mails annimmt, wenn ein @domain.tld mit angegeben wird  
und auch NUR pml125.home.tachtler.net als @domain.tld (final  
destination) erlaubt.

Beispiel:
========

E-Mail's an den lokalen Benutzer klaus sollen NICHT angenommen werden,  
wenn z.B. im
   rcpt to: <klaus>
OHNE domain.tld (@pml125.home.tachtler.net) angegeben wird.

Meine Annahme war, das wenn ich
- append_dot_mydomain = no
und/oder
- append_at_myorigin = no
setze, das ich dies damit erreichen könnte.

Ergebnis:
========

Leider konnte ich es NUR damit erreichen, das ich
- mydestination = pml125.home.tachtler.net
- myorigin = localhost
auf zwei verschiedene Werte gesetzt habe.

http://www.postfix.org/postconf.5.html#append_at_myorigin
http://www.postfix.org/postconf.5.html#append_dot_mydomain

Irgendwie stehe ich gerade auf dem Schlauch, obwohl ich den "manpages"  
gelesen haben.

Danke, schon in Voraus!


----- %< -----

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
authorized_submit_users =
command_directory = /usr/sbin
compatibility_level = 2
config_directory = /etc/postfix-eth0
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix-eth0
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
html_directory = no
inet_interfaces = 192.168.178.23
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
master_service_disable =
meta_directory = /etc/postfix
multi_instance_enable = yes
multi_instance_group = mta
multi_instance_name = postfix-eth0
mydestination = pml125.home.tachtler.net
myorigin = localhost
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix-eth0
readme_directory = /usr/share/doc/postfix-3.4.5/README_FILES
sample_directory = /usr/share/doc/postfix-3.4.5/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtpd_recipient_restrictions = reject_unauth_destination
unknown_local_recipient_reject_code = 550

----- >% -----


Grüße
Klaus.

-- 

--------------------------------------------
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/20190523/14dedeeb/attachment.skr>

From holger.coenen at gmx.de  Thu May 23 16:13:10 2019
From: holger.coenen at gmx.de (holger.coenen at gmx.de)
Date: Thu, 23 May 2019 16:13:10 +0200 (CEST)
Subject: =?UTF-8?Q?Einladung_zur_verschl=C3=BCsselten_Kommunikation_angenommen?=
Message-ID: <trinity-sys-NET-76278c7d-05d5-4226-8e97-640b2559ac3a-1558620790187@msvc-msubmit-portal001>

Verschlüsselte Kommunikation
------------------------------------------------------------------

Guten Tag,

Holger Coenen hat Ihre Einladung zur verschlüsselten
Kommunikation angenommen.

Bitte bestätigen Sie jetzt diesen Kontakt. Danach können Sie
direkt mit ihm verschlüsselt kommunizieren.

Weitere Details zum Sicherheitsverfahren finden Sie auf unserer
Informationsseite.
https://www.gmx.net/mail/sicherheit/pgp/

Mit freundlichen Grüßen

Ihr
GMX Kundenmanagement

------------------------------------------------------------------

GMX Kundenmanagement

Sie haben Fragen?
09??00? 10??00? 8?7?7 (3,99 EUR pro Anruf, nur aus dem deutschen Festnetz erreichbar)
Weitere Infos finden Sie ?hier: 
https://hilfe.gmx.net/

Bei dieser E-Mail handelt es sich um eine automatisch versendete
Nachricht.

Eine Antwort auf diese E-Mail ist nicht möglich, da die
Absenderadresse nur zum Nachrichtenversand eingerichtet ist.

Impressum https://www.gmx.net/impressum
© 1&1 Mail & Media GmbH

Zweigniederlassung Karlsruhe
Brauerstr. 48, 76135 Karlsruhe, Deutschland

Geschäftsführer: Alexander Charles, Thomas Ludwig, Jan Oetjen, Sascha Vollmer


Hauptsitz Montabaur, Amtsgericht Montabaur, 
HRB 7666, UST-Id. DE243413002

------------------------------------------------------------------
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190523/f41026d4/attachment.htm>
-------------- nächster Teil --------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: Mailvelope v3.2.0
Comment: https://www.mailvelope.com

xsFNBFZS6XUBEAC4PVrkcnZzqX6O8jztD48qP4xfXVLslYz2nrzxtCFmTfKS
cclbJpl1GT5lNaP5Asad3mGqvJBiS3L7FHoL7xbAyBU17nZNpGOrAAJNIUGO
kjQFPAaQc5rEH+AHVLus7hDePH/oCkQhYapgqUFMwVajL4cFA35h5h89yzRR
iMb3ItGXK+9KjMP86QPxW3E2CwZlmePRfyuTS4tsKXCiGzphO/yZZ4x99xTr
HV1TLTsObt+QqKJNNWkGWuPSylnIJvxoSif+KJLe7g0Xgg99Kw7E3UKQD0mt
/bUxnhwzibhcK3uJxaZeMEcfiLvl+iOBfoyD0LYz2Pt/DuQHIWN008EYmGbu
yG83EBvOjOVWejjgL9ZQjB18xAnlXPLIFfZvaCzqQ3r9MjBxEpDn0HcPNaU7
NwxB62uEzX2fXmmoIwJf7y4qH8WgRDYNv5RJilMJIFzfiOq7LGMhTt665riL
pSmPKa9znQ+RXFuF1o6oDqoZ9JVBpcqPZa/1q3KDraR2dozsRcQNMoB905Bh
xir3NxahdOo428lV/V2lQIW9xjzmEfpGp8SCPMTvqho/j32sEsxrWDMk16Mx
+wOHE7yUhn9ayeiGcsvCem5TZJ6JwDkz4N2PlRJZb6m6kLuc8Vcda6nKrlgu
1WCDe4v4WPROjn6jLqTDQFwTgPL66Ftoj9wdLQARAQABzSRIb2xnZXIgQ29l
bmVuIDxob2xnZXIuY29lbmVuQGdteC5kZT7CwX8EEAEIACkFAlZS6YoGCwkI
BwMCCRBj0RJ8EL3UbwQVCAIKAxYCAQIZAQIbAwIeAQAKCRBj0RJ8EL3Ub3EM
EACHuwAxH/h7pMlvagQXJr6/SlWsZHtDm1QVg8USBs0IiiyvmFb49Ik3OWdG
IxXYqYEBPvXRspYBONQ5ncou48WTCzC7ve+U4DkJJUdqFySpybXIiwWzSALu
aDCq2BywGJ3tp6HWV2VaLpXGfodpxsrBN7gjhzNjNuvp3XCCzMLNEaCbfelL
Jf1jJFUMAZSj4Xp6ZIAcWy+Hn2tozusMlHR21FSrPZK5bTDHMAYUgmV/4UUt
E3YArkxpV2SoPPWm8aDpkwDt2iJkQDkCdhbLRvEMVDP2hmus8M+wmY0ZvwXN
H3/Y+rUrQ+KFiDkRIVGWolRM7SZYk9qBB/AQG9yA5PSbZJhxaaSpShvJ0p6L
LrlqJRmWgbg/V/wD53F1J+UKYLx0vPYxyTshHRGyaVzQWXCFPsYbQl5xdufb
S70TZ2jasVNr59DV4MtvyWKWnc9/YMIXztmDDB3vQlwE7dYIKwm4PHP1OSJV
n2YVYRl6fyb6ho4G2iGe7IW8lt5zwXNh5QLjepIl0Hwa3DHr3TgXf5PpLQyR
7iySMhoKvVOGtL6Z1DW67n1dkacsjwUc1iaC+fXhw+9faJYdjLIcp8iDrvYr
iljdk/Lh2JImnaKaY+4YMmt3k51QGpDMAl8ljjL08pr62askPQcK5xNJCV7O
D/3hES8v8GaQdIutaafjhW8SDs7BTQRWUul1ARAAw4LxarnDJauxHnRJm+vU
9Rsd/uydv88EfffexlGTwP4EkJz5TYq3kFiOKGiOUs18IIoxe64pAl7e8/ff
+ZfrHcZ2F/Ou0j8c4AjTnV/uGzggPurHMsL/1I2rPYQ1w0dpSJrO+2AjV5e7
8fXV8DHzUQTqBh/tccMCktCmXpdvX37IHNd9mov1LTl+31GnN7eO5dyeSEtR
6WU7D53WpJ/D7poOEwb+6Jw2YtaQRBofJpN+yGPfDQPpxnciMrfF8yZfQfza
w0k7rQPXVFcoKLvi0WtNIIscgy621EDW/9QNxJKYUPchyNwu9mTzQGI0tbvM
7SFP3VTC8wAH5Z6Jx4CwmVBkagrye7yeORc4+Dw2RD7/GjXiS8cAL/6VHv/B
mJa1NdMqlF9+p/guSd3sRls1NiB2L5n7s4TNwbq+e5kP0Fi3SOmvQ1vBDE9E
hjc7JkbfaRxGIP8EaTqaiNINjSKAt6N4Dikr3h2ZME42qcoWvYeSClSBrLrc
+cC4xZ+GTr55+eIMzwMCBc67wq5/9Fe4ri7HVm4dP4hqQQGI/SsOeLoGQLLz
g8kn6kf+fVOiOMWZ5aEIRlenQxg5hu8NgDhO9v/rIbXpZXWNvAXmtv+4G/9J
VFhrmvymWPctoG4M9n2izFDd57qthQAPmvLArCZaOnz3yWVvydA7JncQU2qe
oucAEQEAAcLBaQQYAQgAEwUCVlLpiwkQY9ESfBC91G8CGwwACgkQY9ESfBC9
1G9n+A/8DZ5lzj2fwCShBy5Jphg+2/Oa/PgStxT5NhpJWsG9gjV4O+YLjsR9
ol4UkNeXNjIDJlateaaDp+k8gn0g2qgKNdDMvfJElXpng5L0ELwJdSbb7stx
9KVbzES2R1uDTvATAqA80dBHh1ea4RMW7cE6mf613zZdJMowxT2F7+ZBLyBL
w5mX3w8h0FlLqODYBti2wmaA4iU9O947/Ja/Dran1B4BnWbE2lagACkNA/3h
8mCOjQlz2PDhCW2Vc7LCh2GvQM1gG6hagY673go5p8HhVIzVQKVC/RdP9rUd
s096UB1yXIz0dB5VfJGqeaIHTP3TWtoR0HZFuSonLWDuAdKLj8M2Uclc6YFB
3Ep1ipTNZtpwUFV42QFtCLKWyL2PBvl6Ph2b9iWnbGXHudAdhiwtWySE7KXB
BVgMzFKtKy0Xx0bD239tWMr9Yrfa8LAaignGlHjN7MB6nU/UglJDMbhpSfKm
bfD8ndX11qZbwNqUfLAgH3gysLbaVW550DaaClQLXTPO0FnYonPdX0IKkvuo
1THCL1z1ykItiaxFkDG+n2AFdRosy52oCUGTBj1dWsVPoHil0dKxXdYrSJzZ
c4NERWLmprY3jU76jrXXI3OvKDIfk3CCCDEJVbfjcwabdjAMX6bU6BwBeVhL
q8erMzwtyAQbFNxsJyzzYM8t8gUEXys=
=d8dD
-----END PGP PUBLIC KEY BLOCK-----

From stickybit at myhm.de  Fri May 24 15:31:44 2019
From: stickybit at myhm.de (Andre)
Date: Fri, 24 May 2019 15:31:44 +0200
Subject: SSL_accept error from: Connection timed out
Message-ID: <924ba905-cb13-b2f3-2508-15019d9526c8@myhm.de>

Hallo,

ein Kunde beschwert sich, dass er Mails über smtp auth sehr oft nur nach
mehreren Versuchen versendet bekommt. Dabei sieht der Debug-Log etwa so aus:

2019-05-24T05:31:50+02:00 connect from clienthost[XX.XXX.XX.XX]
2019-05-24T05:31:50+02:00 smtp_stream_setup: maxtime=10 enable_deadline=1
2019-05-24T05:31:50+02:00 auto_clnt_open: connected to private/tlsmgr
2019-05-24T05:31:50+02:00 send attr request = seed
2019-05-24T05:31:50+02:00 send attr size = 32
2019-05-24T05:31:50+02:00 private/tlsmgr: wanted attribute: status
2019-05-24T05:31:50+02:00 input attribute name: status
2019-05-24T05:31:50+02:00 input attribute value: 0
2019-05-24T05:31:50+02:00 private/tlsmgr: wanted attribute: seed
2019-05-24T05:31:50+02:00 input attribute name: seed
2019-05-24T05:31:50+02:00 input attribute value:
z+kyNjdUi7HoxJCIGPJVRy4nCC40UWWBu/q4XtSU9PI=
2019-05-24T05:31:50+02:00 private/tlsmgr: wanted attribute: (list
terminator)
2019-05-24T05:31:50+02:00 input attribute name: (end)
2019-05-24T05:32:00+02:00 SSL_accept error from
clienthost[XX.XXX.XX.XX]: Connection timed out
2019-05-24T05:32:00+02:00 match_hostname:
smtpd_client_event_limit_exceptions: clienthost ~? [fd00::]/64
2019-05-24T05:32:00+02:00 match_hostaddr:
smtpd_client_event_limit_exceptions: XX.XXX.XX.XX ~? [fd00::]/64
2019-05-24T05:32:00+02:00 match_list_match: clienthost: no match
2019-05-24T05:32:00+02:00 match_list_match: XX.XXX.XX.XX: no match
2019-05-24T05:32:00+02:00 send attr request = disconnect
2019-05-24T05:32:00+02:00 send attr ident = smtps:XX.XXX.XX.XX
2019-05-24T05:32:00+02:00 private/anvil: wanted attribute: status
2019-05-24T05:32:00+02:00 input attribute name: status
2019-05-24T05:32:00+02:00 input attribute value: 0
2019-05-24T05:32:00+02:00 private/anvil: wanted attribute: (list terminator)
2019-05-24T05:32:00+02:00 input attribute name: (end)
2019-05-24T05:32:00+02:00 lost connection after CONNECT from
clienthost[XX.XXX.XX.XX]
2019-05-24T05:32:00+02:00 disconnect from clienthost[XX.XXX.XX.XX]
ehlo=1 auth=0/1 commands=1/2

# TLS parameters aus der main.cf

smtpd_enforce_tls = yes
smtpd_tls_security_level = encrypt
smtpd_tls_cert_file = /etc/postfix/cert.crt
smtpd_tls_key_file = /etc/postfix/cert.key
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_security_level = none

Eine Idee wo man was nachschauen kann?

-- 
LG
Andre


From Ralf.Hildebrandt at charite.de  Fri May 24 15:38:43 2019
From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt)
Date: Fri, 24 May 2019 15:38:43 +0200
Subject: [ext] SSL_accept error from: Connection timed out
In-Reply-To: <924ba905-cb13-b2f3-2508-15019d9526c8@myhm.de>
References: <924ba905-cb13-b2f3-2508-15019d9526c8@myhm.de>
Message-ID: <20190524133841.ooez56gghtnqjvkl@charite.de>

* Andre <stickybit at myhm.de>:
> Hallo,
> 
> ein Kunde beschwert sich, dass er Mails über smtp auth sehr oft nur nach
> mehreren Versuchen versendet bekommt. Dabei sieht der Debug-Log etwa so aus:
> 
> 2019-05-24T05:31:50+02:00 connect from clienthost[XX.XXX.XX.XX]
> 2019-05-24T05:32:00+02:00 SSL_accept error from clienthost[XX.XXX.XX.XX]: Connection timed out
> 2019-05-24T05:32:00+02:00 lost connection after CONNECT from clienthost[XX.XXX.XX.XX]
> 2019-05-24T05:32:00+02:00 disconnect from clienthost[XX.XXX.XX.XX] ehlo=1 auth=0/1 commands=1/2

Ich sehe da ein timeout nach 10s. Bissel kurz, oder? Womit sendet der
Kunde denn?

Interessanter wäre jetzt wie das Log aussieht WENN es klappt.
Debugging ("-v") muss dafür nicht an sein -- sinnvoller ist 

debug_peer_list = XX.XXX.XX.XX
 
-- 
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 klaus at tachtler.net  Fri May 24 15:59:11 2019
From: klaus at tachtler.net (Klaus Tachtler)
Date: Fri, 24 May 2019 15:59:11 +0200
Subject: SSL_accept error from: Connection timed out
In-Reply-To: <924ba905-cb13-b2f3-2508-15019d9526c8@myhm.de>
Message-ID: <20190524155911.Horde.2GAJOKsaZryQWAW9qofIh_4@buero.tachtler.net>

Hallo Andre,

hatte ein - aber bitte nur evtl. - ähnliches Problem auf der  
Dovecot-Mailingliste gelesen:

https://listen.jpberlin.de/pipermail/dovecot/2019-May/001781.html

Lösung war hier, das auf dem Client die Installation der  
Cipher-Bibliotheken der verwendeten Client Software noch einmal  
durchgeführt / "upgedatet" werden mussten, danach lief die Verbindung.  
(Client war dort eine aktuelles Android Handy mit K9-Mail)

Das ist jetzt leider keine echte Hilfe in Bezug auf die Ursache, aber  
evtl. bringt ja ein, wie von Ralf vorgeschlagen, DEBUG mit  
debug_peer_level = 2 (oder höher z.B. 4) und debug_peer_list =  
XX.XXX.XX.XX etwas mehr Licht ins Dunkle.

Siehe auch:

http://www.postfix.org/DEBUG_README.html
http://www.postfix.org/postconf.5.html#debug_peer_level
http://www.postfix.org/postconf.5.html#debug_peer_list


Grüße
Klaus.

> Hallo,
>
> ein Kunde beschwert sich, dass er Mails über smtp auth sehr oft nur nach
> mehreren Versuchen versendet bekommt. Dabei sieht der Debug-Log etwa so aus:
>
> 2019-05-24T05:31:50+02:00 connect from clienthost[XX.XXX.XX.XX]
> 2019-05-24T05:31:50+02:00 smtp_stream_setup: maxtime=10 enable_deadline=1
> 2019-05-24T05:31:50+02:00 auto_clnt_open: connected to private/tlsmgr
> 2019-05-24T05:31:50+02:00 send attr request = seed
> 2019-05-24T05:31:50+02:00 send attr size = 32
> 2019-05-24T05:31:50+02:00 private/tlsmgr: wanted attribute: status
> 2019-05-24T05:31:50+02:00 input attribute name: status
> 2019-05-24T05:31:50+02:00 input attribute value: 0
> 2019-05-24T05:31:50+02:00 private/tlsmgr: wanted attribute: seed
> 2019-05-24T05:31:50+02:00 input attribute name: seed
> 2019-05-24T05:31:50+02:00 input attribute value:
> z+kyNjdUi7HoxJCIGPJVRy4nCC40UWWBu/q4XtSU9PI=
> 2019-05-24T05:31:50+02:00 private/tlsmgr: wanted attribute: (list
> terminator)
> 2019-05-24T05:31:50+02:00 input attribute name: (end)
> 2019-05-24T05:32:00+02:00 SSL_accept error from
> clienthost[XX.XXX.XX.XX]: Connection timed out
> 2019-05-24T05:32:00+02:00 match_hostname:
> smtpd_client_event_limit_exceptions: clienthost ~? [fd00::]/64
> 2019-05-24T05:32:00+02:00 match_hostaddr:
> smtpd_client_event_limit_exceptions: XX.XXX.XX.XX ~? [fd00::]/64
> 2019-05-24T05:32:00+02:00 match_list_match: clienthost: no match
> 2019-05-24T05:32:00+02:00 match_list_match: XX.XXX.XX.XX: no match
> 2019-05-24T05:32:00+02:00 send attr request = disconnect
> 2019-05-24T05:32:00+02:00 send attr ident = smtps:XX.XXX.XX.XX
> 2019-05-24T05:32:00+02:00 private/anvil: wanted attribute: status
> 2019-05-24T05:32:00+02:00 input attribute name: status
> 2019-05-24T05:32:00+02:00 input attribute value: 0
> 2019-05-24T05:32:00+02:00 private/anvil: wanted attribute: (list terminator)
> 2019-05-24T05:32:00+02:00 input attribute name: (end)
> 2019-05-24T05:32:00+02:00 lost connection after CONNECT from
> clienthost[XX.XXX.XX.XX]
> 2019-05-24T05:32:00+02:00 disconnect from clienthost[XX.XXX.XX.XX]
> ehlo=1 auth=0/1 commands=1/2
>
> # TLS parameters aus der main.cf
>
> smtpd_enforce_tls = yes
> smtpd_tls_security_level = encrypt
> smtpd_tls_cert_file = /etc/postfix/cert.crt
> smtpd_tls_key_file = /etc/postfix/cert.key
> smtpd_tls_received_header = yes
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtp_tls_security_level = none
>
> Eine Idee wo man was nachschauen kann?
>
> --
> LG
> Andre


----- Ende der Nachricht von Andre <stickybit at myhm.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/20190524/28187e80/attachment.skr>

From Hajo.Locke at gmx.de  Mon May 27 09:20:10 2019
From: Hajo.Locke at gmx.de (Hajo Locke)
Date: Mon, 27 May 2019 09:20:10 +0200
Subject: spezielle catch-all verarbeitung
In-Reply-To: <20190521142401.Horde.sDY3KAs28UVm3asTdio0o2e@buero.tachtler.net>
References: <20190521142401.Horde.sDY3KAs28UVm3asTdio0o2e@buero.tachtler.net>
Message-ID: <9c9b9020-11d8-b5d4-0b55-45ad7ef67ffb@gmx.de>

Hallo,

Am 21.05.2019 um 14:24 schrieb Klaus Tachtler:
> Hallo Hajo,
>
> was sagt denn jeweils ein --> postconf -d <-- auf dem Postfix 3.1 und
> dem Postfix 3.3?
>
> Gibt es eine Fehlermeldung im LOG?
>
> Hast Du Einstellungen bei
> http://www.postfix.org/postconf.5.html#compatibility_level gesetzt?
>
> Schau mal hier: http://www.postfix.org/COMPATIBILITY_README.html
>
> Nachfolgende Einstellungen haben sich definitiv geändert:
>
> - append_dot_mydomain=yes
> - smtpd_relay_restrictions = (empty)
> - mynetworks_style=subnet
> - relay_domains=$mydestination
> - smtputf8_enable=no
>
Danke für deine Tipps, leider ist es unverändert. Diese Optionen hatte
ich damals beim Wechsel von 2.x auf 3.x auch verwendet und sind in
beiden Configs unter 3.1 und 3.3 vertreten.
Ich tappe weiterhin im Dunkeln. Ist kein schlimmes Problem, eher eine
Herausforderung.
> Siehe auch mein DokuWiki, welches ich mal für mich erstellt habe
> (Ist zwar von Postfix 2.x auf 3.x, aber vielleicht hilft es Dir auch
> weiter):
>
> https://dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_centos_7_-_migration_von_version_2.x_auf_3.x
>
>
>
> Grüße
> Klaus.
>
>> Hallo Liste,
>>
>> ich habe folgendes Szenario:
>> Über die virtual habe ich eine globale Weiterleitung einer subdomain auf
>> eine domain eingerichtet:
>>
>> @sub.example.com @example.com
>>
>> @example.com selbst ist eine Weiterleitung an eine externe Adresse.
>> Zusätzlich existiert das benannte Postfach mybox at example.com
>> Auf Systemen mit Postfix 3.1 funktioniert das bisher so:
>> Sende ich an beliebige Adressen der Catch-All Subdomain, geht alles an
>> die externe Adresse. Sende ich an mybox at sub.example.com geht die Mail
>> über die Weiterleitung und auch an das lokale Postfach
>> mybox at example.com, da Postfix über das Catch-all mybox at sub.example.com
>> auf mybox at example.com mappt.
>>
>> Ich habe nun Server mit Postfix 3.3, welche die selbe main.cf verwenden.
>> Hier klappt das Ganze aber nun nicht mehr. Die Mail geht nur nach
>> extern, weil das mapping mybox at sub.example.com auf mybox at example.com
>> nicht mehr greift.
>>
>> Es muss sich doch hier zwischen den Versionen ein default geändert
>> haben, der das ganze veranlasst, ich finde aber leider nichts passendes.
>> Ist hier jemandem eine Direktive bekannt mit der ich testen könnte?
>>
>> Danke,
>> Hajo
>
>
> ----- Ende der Nachricht von Hajo Locke <Hajo.Locke at gmx.de> -----
>
>
>
Danke,
Hajo


From andreas at grabmueller.bayern  Fri May 31 15:06:12 2019
From: andreas at grabmueller.bayern (=?UTF-8?Q?Andreas_Grabm=c3=bcller?=)
Date: Fri, 31 May 2019 15:06:12 +0200
Subject: Mails nicht annehmen, bis die Weiterleitung erfolgreich war
Message-ID: <97c51f6f-0ced-48f7-efc6-5f01475870e5@grabmueller.bayern>

Hallo zusammen,

ich habe folgende Problemstellung und finde weder im Buch noch über Google etwas passendes - vielleicht geht's auch gar 
nicht oder ich denke falsch.

Wir haben für einen Kunden eine E-Mail-Verschlüsselungs-Appliance im Einsatz, die Mails annimmt, verarbeitet und an den 
jeweiligen Ziel-Mailserver weiterleitet. Die Appliance hat zwar Spam- und Virenfilter, aber die sind nicht sonderlich 
konfigurierbar und leisten nicht das, was ich mir vorstelle.

Meine Idee wäre nun, da einen Postfix als MX davorzusetzen, der als erste Instanz eine Spam- und Virenprüfung macht. Der 
würde dann über transport-Regeln je nach Domain an die Verschlüsselungs-Appliance oder die normalen Mailserver 
weiterleiten. Das Problem bei der Lösung ist aber, dass dann der MX-Server die Mail annimmt und in die Warteschlange 
aufnimmt, die Appliance die Mail aber noch ablehnen könnte (wenn in der entschlüsselten Mail ein Virus gefunden werden 
sollte zum Beispiel). Das würde dann entweder bedeuten, für eine schon angenommen Mail einen NDR zu schicken oder die 
Mail zu verschlucken, beides ist problematisch. Wenn ich eine Mail nicht zustellen kann, will ich sie gar nicht annehmen.

Gibt es eine Möglichkeit, dass der MX-Postfix die Mail erst dann als angenommen bestätigt wenn sie zugestellt worden 
ist, sie also nicht über Queue zuzustellt sondern direkt? Und wenn der nächste Mailserver einen Fehler ausgibt, den an 
den ursprünglich einliefernden Mailserver als Fehler zurückgibt?

Danke und Gruß,
Andreas



From michael at linuxfox.de  Fri May 31 15:43:12 2019
From: michael at linuxfox.de (Michael Grundmann)
Date: Fri, 31 May 2019 15:43:12 +0200
Subject: Mails nicht annehmen, bis die Weiterleitung erfolgreich war
In-Reply-To: <97c51f6f-0ced-48f7-efc6-5f01475870e5@grabmueller.bayern>
References: <97c51f6f-0ced-48f7-efc6-5f01475870e5@grabmueller.bayern>
Message-ID: <6cd83c83-c02d-9d9a-ce53-99d9da383ae8@linuxfox.de>

Am 31.05.19 um 15:06 schrieb Andreas Grabmüller:

> Gibt es eine Möglichkeit, dass der MX-Postfix die Mail erst dann als 
> angenommen bestätigt wenn sie zugestellt worden ist, sie also nicht über 
> Queue zuzustellt sondern direkt? Und wenn der nächste Mailserver einen 
> Fehler ausgibt, den an den ursprünglich einliefernden Mailserver als 
> Fehler zurückgibt?


klar - den Virenscanner via milter oder gar als proxy einbinden

-o smtpd_proxy_filter=x.x.x.x:xxxxx

-- 
Gruß Michael

Wenn du verstehst, was du tust, wirst du nichts lernen
BTW: Produktionsbremsen sind immer die Bürokraten


From andreas at grabmueller.bayern  Fri May 31 21:49:17 2019
From: andreas at grabmueller.bayern (=?UTF-8?Q?Andreas_Grabm=c3=bcller?=)
Date: Fri, 31 May 2019 21:49:17 +0200
Subject: Mails nicht annehmen, bis die Weiterleitung erfolgreich war
In-Reply-To: <6cd83c83-c02d-9d9a-ce53-99d9da383ae8@linuxfox.de>
References: <97c51f6f-0ced-48f7-efc6-5f01475870e5@grabmueller.bayern>
 <6cd83c83-c02d-9d9a-ce53-99d9da383ae8@linuxfox.de>
Message-ID: <e0e2a4d2-1494-0c95-8102-a2a65414bcb7@grabmueller.bayern>

Hallo Michael,

danke. Ich hatte mir das mit dem proxy_filter schon mal angeschaut, dann aber gedanklich verworfen weil ich damit nicht 
steuern kann für welche Empfänger das gelten soll und auch zumindest die Dokumentation den Eindruck erweckt, dass man 
die Mail dann wieder beim Original-Postfix einliefern muss.

Ich schaue mir das nochmal genauer an und mache einen Test-Aufbau. :)

Gruß,
Andreas

Am 31.05.2019 um 15:43 schrieb Michael Grundmann:
> Am 31.05.19 um 15:06 schrieb Andreas Grabmüller:
>
>> Gibt es eine Möglichkeit, dass der MX-Postfix die Mail erst dann als angenommen bestätigt wenn sie zugestellt worden 
>> ist, sie also nicht über Queue zuzustellt sondern direkt? Und wenn der nächste Mailserver einen Fehler ausgibt, den 
>> an den ursprünglich einliefernden Mailserver als Fehler zurückgibt?
>
>
> klar - den Virenscanner via milter oder gar als proxy einbinden
>
> -o smtpd_proxy_filter=x.x.x.x:xxxxx
>