From bjo at nord-west.org  Fri Mar  1 13:35:33 2019
From: bjo at nord-west.org (Bjoern Franke)
Date: Fri, 1 Mar 2019 13:35:33 +0100
Subject: IMAP, Bodystructure und RFC 3501
Message-ID: <dc3bb9bf-66b5-a363-b7d0-c142994c404a@nord-west.org>

Moin,

etwas OT, da nicht direkt mit Postfix verwandt:
FairEMail, einer der wenigen OpenSource-Android-Clients, hat ein Problem
mit unseren Monitoring-Mails. Denen fehlt ein Content-Type und der
Kopano-IMAP-Server liefert auf das FETCH BODYSTRUCTURE (BODYSTRUCTURE
(NIL NIL NIL NIL NIL).

RFC 3501 sagt:
"Such extension data can consist of
zero or more NILs, strings, numbers, or potentially nested
parenthesized lists of such data.  Client implementations that
do a BODYSTRUCTURE fetch MUST be prepared to accept such
extension data."

Der Entwickler sagt:
""(BODYSTRUCTURE (NIL NIL NIL NIL NIL))" can't be correct in any way
because it does not describe a body.
The content type/subtype, the first two NILs and the body encoding, the
last NIL, shouldn't be empty."

Und der Kollege, der mehr im Kopano-Thema involviert ist, sagt: Soll er
halt nicht BODYSTRUCTURE nutzen und im RFC steht nicht, dass nicht alles
NIL sein darf.

Die Preisfrage ist nun: Wer hat den Implementierungsfehler begangen?

Grüße
Björn


From klaus at tachtler.net  Fri Mar  1 14:55:02 2019
From: klaus at tachtler.net (Klaus Tachtler)
Date: Fri, 01 Mar 2019 14:55:02 +0100
Subject: IMAP, Bodystructure und RFC 3501
In-Reply-To: <dc3bb9bf-66b5-a363-b7d0-c142994c404a@nord-west.org>
Message-ID: <20190301145502.Horde.X419Q_gc-Nc3YUXKwn0xP0B@buero.tachtler.net>

Hallo Björn,

für mich würde sich eher die Frage stellen, fixt der Programmierer von  
FairEMail das Problem, oder nicht?

Falls nicht - und das für Euch so wichtig ist - oder - Ihr auf der  
Sender-Seite nichts machen könnt, wählt einen anderen Android-Client:
  - K9-Mail
  - R2Mail2


Grüße
Klaus.


> Moin,
>
> etwas OT, da nicht direkt mit Postfix verwandt:
> FairEMail, einer der wenigen OpenSource-Android-Clients, hat ein Problem
> mit unseren Monitoring-Mails. Denen fehlt ein Content-Type und der
> Kopano-IMAP-Server liefert auf das FETCH BODYSTRUCTURE (BODYSTRUCTURE
> (NIL NIL NIL NIL NIL).
>
> RFC 3501 sagt:
> "Such extension data can consist of
> zero or more NILs, strings, numbers, or potentially nested
> parenthesized lists of such data.  Client implementations that
> do a BODYSTRUCTURE fetch MUST be prepared to accept such
> extension data."
>
> Der Entwickler sagt:
> ""(BODYSTRUCTURE (NIL NIL NIL NIL NIL))" can't be correct in any way
> because it does not describe a body.
> The content type/subtype, the first two NILs and the body encoding, the
> last NIL, shouldn't be empty."
>
> Und der Kollege, der mehr im Kopano-Thema involviert ist, sagt: Soll er
> halt nicht BODYSTRUCTURE nutzen und im RFC steht nicht, dass nicht alles
> NIL sein darf.
>
> Die Preisfrage ist nun: Wer hat den Implementierungsfehler begangen?
>
> Grüße
> Björn


----- Ende der Nachricht von Bjoern Franke <bjo at nord-west.org> -----



-- 

--------------------------------------------
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/20190301/9f8143e3/attachment.skr>

From bjo at nord-west.org  Sun Mar  3 13:03:44 2019
From: bjo at nord-west.org (Bjoern Franke)
Date: Sun, 3 Mar 2019 13:03:44 +0100
Subject: IMAP, Bodystructure und RFC 3501
In-Reply-To: <20190301145502.Horde.X419Q_gc-Nc3YUXKwn0xP0B@buero.tachtler.net>
References: <20190301145502.Horde.X419Q_gc-Nc3YUXKwn0xP0B@buero.tachtler.net>
Message-ID: <7c85a03f-9a5e-6696-9e0e-c27783007204@nord-west.org>

Moin Klaus,

> 
> für mich würde sich eher die Frage stellen, fixt der Programmierer von  
> FairEMail das Problem, oder nicht?

Macht er nicht, er sagt er könne (oder wolle?) das nicht fixen weil es
sich um einen Serverbug handelt. Die Entwickler der JavaMail-API sagen
dagegen, man könne einen Workaround bauen. Allerdings sagen die auch, dass
> * 9852 FETCH (BODYSTRUCTURE (NIL NIL NIL NIL NIL))
"completely bogus" ist. Somit wohl wirklich ein Kopano-Bug.

> Falls nicht - und das für Euch so wichtig ist - oder - Ihr auf der  
> Sender-Seite nichts machen könnt, wählt einen anderen Android-Client:
>   - K9-Mail
>   - R2Mail2

K9-Mail fand ich bisher etwas arg altbacken aussehend, R2Mail2 wurde
lange Zeit nicht weiterentwickelt. Die Tage habe ich mir nun eine
Debug-Build aus dem K9-Master gebaut, schaut mittlerweile ja etwas
moderner aus.

Grüße
Björn




From andre.peters at debinux.de  Sun Mar  3 13:09:01 2019
From: andre.peters at debinux.de (=?utf-8?q?Andr=C3=A9?= Peters)
Date: Sun, 3 Mar 2019 13:09:01 +0100
Subject: IMAP, Bodystructure und RFC 3501
In-Reply-To: <7c85a03f-9a5e-6696-9e0e-c27783007204@nord-west.org>
References: <20190301145502.Horde.X419Q_gc-Nc3YUXKwn0xP0B@buero.tachtler.net>
 <7c85a03f-9a5e-6696-9e0e-c27783007204@nord-west.org>
Message-ID: <AB37F718-F892-48F8-9685-49FD10FB4645@debinux.de>

Halte uns auf dem Laufenden. Klingt witzig. Sollte/könnte man verbloggen. :-) 


> Am 03.03.2019 um 13:03 schrieb Bjoern Franke <bjo at nord-west.org>:
> 
> Moin Klaus,
> 
>> 
>> für mich würde sich eher die Frage stellen, fixt der Programmierer von  
>> FairEMail das Problem, oder nicht?
> 
> Macht er nicht, er sagt er könne (oder wolle?) das nicht fixen weil es
> sich um einen Serverbug handelt. Die Entwickler der JavaMail-API sagen
> dagegen, man könne einen Workaround bauen. Allerdings sagen die auch, dass
>> * 9852 FETCH (BODYSTRUCTURE (NIL NIL NIL NIL NIL))
> "completely bogus" ist. Somit wohl wirklich ein Kopano-Bug.
> 
>> Falls nicht - und das für Euch so wichtig ist - oder - Ihr auf der  
>> Sender-Seite nichts machen könnt, wählt einen anderen Android-Client:
>>  - K9-Mail
>>  - R2Mail2
> 
> K9-Mail fand ich bisher etwas arg altbacken aussehend, R2Mail2 wurde
> lange Zeit nicht weiterentwickelt. Die Tage habe ich mir nun eine
> Debug-Build aus dem K9-Master gebaut, schaut mittlerweile ja etwas
> moderner aus.
> 
> Grüße
> Björn
> 
> 

From driessen at fblan.de  Mon Mar  4 15:31:16 2019
From: driessen at fblan.de (=?iso-8859-1?Q?Uwe_Drie=DFen?=)
Date: Mon, 4 Mar 2019 15:31:16 +0100
Subject: =?iso-8859-1?Q?AW:_Spa=DF_mit_Google?=
In-Reply-To: <1673405.ANNBoj1SKO@tux.boltz.de.vu>
References: <6989318.OheBTfkvfn@tux.boltz.de.vu>
 <3228611.mQrLB4RBpK@tux.boltz.de.vu>
 <ad4a2e67-8a33-78db-5213-a6b5091b44f1@dimejo.at>
 <1673405.ANNBoj1SKO@tux.boltz.de.vu>
Message-ID: <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>

Ähem 

Wollt ihr nicht weiter Spaß mit Google haben ? 

Google Germany GmbH
040 8 08 17 90 00



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 


> -----Ursprüngliche Nachricht-----
> Von: Postfixbuch-users [mailto:postfixbuch-users-
> bounces at listen.jpberlin.de] Im Auftrag von Christian Boltz
> Gesendet: Dienstag, 26. Februar 2019 22:52
> An: postfixbuch-users at listen.jpberlin.de
> Betreff: Re: Spaß mit Google
> 
> Hallo Alex, hallo zusammen,
> 
> Am Dienstag, 26. Februar 2019, 22:09:04 CET schrieb Alex JOST:
> > Am 26.02.2019 um 21:48 schrieb Christian Boltz:
> > > Am Freitag, 22. Februar 2019, 14:41:44 CET schrieb Uwe Drießen:
> > >> Im Auftrag von Grooz, Marc (regio iT)
> > >>
> > >>> Es geht ja nicht darum, wie strikt der SPF ist, sondern das man
> > >>> überhaupt einen hat.
> > >
> > > Nach dieser Definition würde ein   ?all   reichen, oder? ("LMAA" ist
> > > leider im Standard nicht erlaubt ;-)
> >
> > Meinst Du LMAO? Laughing my ass off? :D
> 
> Nicht alle Abkürzungen stehen für englische Texte ;-)
> 
> Ich meine wirklich LMAA - die Abkürzung eines berühmten Zitats vom Götz
> von Berlichingen ;-))
> 
> 
> Gruß
> 
> Christian Boltz
> --
> Personal Firewall bietet Schutz vor klassischen Angriffen -- Was hat
> man unter "klassischen Angriffen" zu verstehen? -- Seltsam angezogene
> Fremde rollen ein riesiges Holzpferd vor Deine Haustür...
> [Johannes Sackmann, Heiko Schlenker, Ralf Bürckner]
> 




From sebastian at debianfan.de  Mon Mar  4 15:37:01 2019
From: sebastian at debianfan.de (sebastian at debianfan.de)
Date: Mon, 04 Mar 2019 15:37:01 +0100
Subject: =?UTF-8?Q?Re=3A_Spa=C3=9F_mit_Google?=
In-Reply-To: <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>
References: <6989318.OheBTfkvfn@tux.boltz.de.vu>
 <3228611.mQrLB4RBpK@tux.boltz.de.vu>
 <ad4a2e67-8a33-78db-5213-a6b5091b44f1@dimejo.at>
 <1673405.ANNBoj1SKO@tux.boltz.de.vu>
 <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>
Message-ID: <702FDBD4-BD83-4E82-9236-2A87D2721A0B@debianfan.de>

Hamburg? 

Am 4. März 2019 15:31:16 MEZ schrieb "Uwe Drießen" <driessen at fblan.de>:
>Ähem 
>
>Wollt ihr nicht weiter Spaß mit Google haben ? 
>
>Google Germany GmbH
>040 8 08 17 90 00
>
>
>
>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 
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Postfixbuch-users [mailto:postfixbuch-users-
>> bounces at listen.jpberlin.de] Im Auftrag von Christian Boltz
>> Gesendet: Dienstag, 26. Februar 2019 22:52
>> An: postfixbuch-users at listen.jpberlin.de
>> Betreff: Re: Spaß mit Google
>> 
>> Hallo Alex, hallo zusammen,
>> 
>> Am Dienstag, 26. Februar 2019, 22:09:04 CET schrieb Alex JOST:
>> > Am 26.02.2019 um 21:48 schrieb Christian Boltz:
>> > > Am Freitag, 22. Februar 2019, 14:41:44 CET schrieb Uwe Drießen:
>> > >> Im Auftrag von Grooz, Marc (regio iT)
>> > >>
>> > >>> Es geht ja nicht darum, wie strikt der SPF ist, sondern das man
>> > >>> überhaupt einen hat.
>> > >
>> > > Nach dieser Definition würde ein   ?all   reichen, oder? ("LMAA"
>ist
>> > > leider im Standard nicht erlaubt ;-)
>> >
>> > Meinst Du LMAO? Laughing my ass off? :D
>> 
>> Nicht alle Abkürzungen stehen für englische Texte ;-)
>> 
>> Ich meine wirklich LMAA - die Abkürzung eines berühmten Zitats vom
>Götz
>> von Berlichingen ;-))
>> 
>> 
>> Gruß
>> 
>> Christian Boltz
>> --
>> Personal Firewall bietet Schutz vor klassischen Angriffen -- Was hat
>> man unter "klassischen Angriffen" zu verstehen? -- Seltsam angezogene
>> Fremde rollen ein riesiges Holzpferd vor Deine Haustür...
>> [Johannes Sackmann, Heiko Schlenker, Ralf Bürckner]
>> 

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190304/160ef0e9/attachment.htm>

From driessen at fblan.de  Mon Mar  4 15:48:10 2019
From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Mon, 4 Mar 2019 15:48:10 +0100
Subject: =?utf-8?Q?AW:_Spa=C3=9F_mit_Google?=
In-Reply-To: <702FDBD4-BD83-4E82-9236-2A87D2721A0B@debianfan.de>
References: <6989318.OheBTfkvfn@tux.boltz.de.vu>
 <3228611.mQrLB4RBpK@tux.boltz.de.vu>
 <ad4a2e67-8a33-78db-5213-a6b5091b44f1@dimejo.at>
 <1673405.ANNBoj1SKO@tux.boltz.de.vu>
 <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>
 <702FDBD4-BD83-4E82-9236-2A87D2721A0B@debianfan.de>
Message-ID: <000f01d4d299$49a61f40$dcf25dc0$@fblan.de>

Klar Hamburg



ABC-Str. 19
20354 Hamburg, Neustadt

    040 49 21 90 77

    E-Mail info at google.de
    Homepage www.google.de




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 


> -----Ursprüngliche Nachricht-----
> Von: Postfixbuch-users [mailto:postfixbuch-users-
> bounces at listen.jpberlin.de] Im Auftrag von sebastian at debianfan.de
> Gesendet: Montag, 4. März 2019 15:37
> An: Diskussionen und Support rund um Postfix
> Betreff: Re: Spaß mit Google
> 
> Hamburg?
> 
> 
> Am 4. März 2019 15:31:16 MEZ schrieb "Uwe Drießen" <driessen at fblan.de>:
> 
> 	Ähem
> 
> 	Wollt ihr nicht weiter Spaß mit Google haben ?
> 
> 	Google Germany GmbH
> 	040 8 08 17 90 00
> 
> 
> 
> 	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
> 
> 
> 
> 		-----Ursprüngliche Nachricht-----
> 		Von: Postfixbuch-users [mailto:postfixbuch-users-
> 		bounces at listen.jpberlin.de] Im Auftrag von Christian Boltz
> 		Gesendet: Dienstag, 26. Februar 2019 22:52
> 		An: postfixbuch-users at listen.jpberlin.de
> 		Betreff: Re: Spaß mit Google
> 
> 		Hallo Alex, hallo zusammen,
> 
> 		Am Dienstag, 26. Februar 2019, 22:09:04 CET schrieb Alex
> JOST:
> 
> 			Am 26.02.2019 um 21:48 schrieb Christian Boltz:
> 
> 				Am Freitag, 22. Februar 2019, 14:41:44 CET
> schrieb Uwe Drießen:
> 
> 					 Im Auftrag von Grooz, Marc (regio iT)
> 
> 
> 						Es geht ja nicht darum, wie
> strikt der SPF ist, sondern das man
> 						überhaupt einen hat.
> 
> 
> 				 Nach dieser Definition würde ein   ?all
> reichen, oder? ("LMAA" ist
> 				 leider im Standard nicht erlaubt ;-)
> 
> 
> 			 Meinst Du LMAO? Laughing my ass off? :D
> 
> 
> 		Nicht alle Abkürzungen stehen für englische Texte ;-)
> 
> 		Ich meine wirklich LMAA - die Abkürzung eines berühmten
> Zitats vom Götz
> 		von Berlichingen ;-))
> 
> 
> 		Gruß
> 
> 		Christian Boltz
> 		--
> 		Personal Firewall bietet Schutz vor klassischen Angriffen --
> Was hat
> 		man unter "klassischen Angriffen" zu verstehen? -- Seltsam
> angezogene
> 		Fremde rollen ein riesiges Holzpferd vor Deine Haustür...
> 		[Johannes Sackmann, Heiko Schlenker, Ralf Bürckner]
> 
> 
> 
> 
> 
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.



From forum at ruhnke.cloud  Tue Mar  5 08:29:57 2019
From: forum at ruhnke.cloud (forum at ruhnke.cloud)
Date: Tue, 05 Mar 2019 08:29:57 +0100
Subject: =?ISO-8859-1?Q?AW:Spa=DF_mit_Google?=
References: <6989318.OheBTfkvfn@tux.boltz.de.vu>
 <3228611.mQrLB4RBpK@tux.boltz.de.vu>
 <ad4a2e67-8a33-78db-5213-a6b5091b44f1@dimejo.at>
 <1673405.ANNBoj1SKO@tux.boltz.de.vu>
 <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>
 <702FDBD4-BD83-4E82-9236-2A87D2721A0B@debianfan.de>
 <000f01d4d299$49a61f40$dcf25dc0$@fblan.de>
Message-ID: <9313eb88.AMAAADCHzH0AAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcfiWV@mailjet.com>

Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190305/d49e2a04/attachment.htm>

From wn at neessen.net  Tue Mar  5 09:00:31 2019
From: wn at neessen.net (Winfried Neessen)
Date: Tue, 5 Mar 2019 09:00:31 +0100
Subject: =?utf-8?Q?Re=3A_Spa=C3=9F_mit_Google?=
In-Reply-To: <9313eb88.AMAAADCHzH0AAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcfiWV@mailjet.com>
References: <6989318.OheBTfkvfn@tux.boltz.de.vu>
 <3228611.mQrLB4RBpK@tux.boltz.de.vu>
 <ad4a2e67-8a33-78db-5213-a6b5091b44f1@dimejo.at>
 <1673405.ANNBoj1SKO@tux.boltz.de.vu>
 <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>
 <702FDBD4-BD83-4E82-9236-2A87D2721A0B@debianfan.de>
 <000f01d4d299$49a61f40$dcf25dc0$@fblan.de>
 <9313eb88.AMAAADCHzH0AAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcfiWV@mailjet.com>
Message-ID: <73DB533E-D8DA-4570-8AD3-78A356A32287@neessen.net>

Hi!

Echt jetzt? Adressen von Google? Telefonnummern? Schlechte Scherze ueber Strassen in Hamburg?
Sorry Leute, aber ich glaube ihr vergesst, dass das hier 'ne oeffentliche Mailingliste zum Thema Postfix ist,
die an 'nen ganzen Schwung Empfaenger geht- und ich kann mir gut vorstellen, dass viele davon (wie ich)
von eurer Privatfehde mit Google ziemlich genervt sind. Das was hier abgeht ist naemlich mittlerweile nicht
mehr "Offtopic", sondern "Thema komplett verfehlt".

Ich wuerde euch bitten, euren Krieg gegen Google auf einer passenden Mailingliste auszutragen oder
ein anderes Medium wie IRC, Slack oder Discord zu waehlen.


Danke!
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/20190305/64f12cda/attachment.asc>

From petry at cypy.de  Tue Mar  5 09:08:49 2019
From: petry at cypy.de (Ralf Petry)
Date: Tue, 5 Mar 2019 09:08:49 +0100
Subject: =?utf-8?Q?Re=3A_Spa=C3=9F_mit_Google?=
In-Reply-To: <73DB533E-D8DA-4570-8AD3-78A356A32287@neessen.net>
References: <6989318.OheBTfkvfn@tux.boltz.de.vu>
 <3228611.mQrLB4RBpK@tux.boltz.de.vu>
 <ad4a2e67-8a33-78db-5213-a6b5091b44f1@dimejo.at>
 <1673405.ANNBoj1SKO@tux.boltz.de.vu>
 <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>
 <702FDBD4-BD83-4E82-9236-2A87D2721A0B@debianfan.de>
 <000f01d4d299$49a61f40$dcf25dc0$@fblan.de>
 <9313eb88.AMAAADCHzH0AAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcfiWV@mailjet.com>
 <73DB533E-D8DA-4570-8AD3-78A356A32287@neessen.net>
Message-ID: <09CB580E-986E-4A07-9789-52FC44A7F4A7@cypy.de>

Berechtigt, aber ich hab mich trotzdem amüsiert...

> Am 05.03.2019 um 09:00 schrieb Winfried Neessen <wn at neessen.net>:
> 
> Hi!
> 
> Echt jetzt? Adressen von Google? Telefonnummern? Schlechte Scherze ueber Strassen in Hamburg?
> Sorry Leute, aber ich glaube ihr vergesst, dass das hier 'ne oeffentliche Mailingliste zum Thema Postfix ist,
> die an 'nen ganzen Schwung Empfaenger geht- und ich kann mir gut vorstellen, dass viele davon (wie ich)
> von eurer Privatfehde mit Google ziemlich genervt sind. Das was hier abgeht ist naemlich mittlerweile nicht
> mehr "Offtopic", sondern "Thema komplett verfehlt".
> 
> Ich wuerde euch bitten, euren Krieg gegen Google auf einer passenden Mailingliste auszutragen oder
> ein anderes Medium wie IRC, Slack oder Discord zu waehlen.
> 
> 
> Danke!
> Winni



From driessen at fblan.de  Tue Mar  5 10:02:50 2019
From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Tue, 5 Mar 2019 10:02:50 +0100
Subject: =?UTF-8?Q?AW:_Spa=C3=9F_mit_Google?=
In-Reply-To: <73DB533E-D8DA-4570-8AD3-78A356A32287@neessen.net>
References: <6989318.OheBTfkvfn@tux.boltz.de.vu>
 <3228611.mQrLB4RBpK@tux.boltz.de.vu>
 <ad4a2e67-8a33-78db-5213-a6b5091b44f1@dimejo.at>
 <1673405.ANNBoj1SKO@tux.boltz.de.vu>
 <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>
 <702FDBD4-BD83-4E82-9236-2A87D2721A0B@debianfan.de>
 <000f01d4d299$49a61f40$dcf25dc0$@fblan.de>
 <9313eb88.AMAAADCHzH0AAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcfiWV@mailjet.com>
 <73DB533E-D8DA-4570-8AD3-78A356A32287@neessen.net>
Message-ID: <003201d4d332$370fe0c0$a52fa240$@fblan.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Im Auftrag von Winfried Neessen
> 
> Echt jetzt? Adressen von Google? Telefonnummern? Schlechte Scherze
> ueber Strassen in Hamburg?
> Sorry Leute, aber ich glaube ihr vergesst, dass das hier 'ne oeffentliche
> Mailingliste zum Thema Postfix ist,
> die an 'nen ganzen Schwung Empfaenger geht- und ich kann mir gut
> vorstellen, dass viele davon (wie ich)
> von eurer Privatfehde mit Google ziemlich genervt sind. Das was hier abgeht
> ist naemlich mittlerweile nicht
> mehr "Offtopic", sondern "Thema komplett verfehlt".
> 
> Ich wuerde euch bitten, euren Krieg gegen Google auf einer passenden
> Mailingliste auszutragen oder
> ein anderes Medium wie IRC, Slack oder Discord zu waehlen.


Sorry da muss was falsch rüber gekommen sein 
Wie suchen nach einer technischen Lösung legitime Mails eigener Kunden an die Kunden eines großen Betreibers zuzustellen Ohne bei dem Betreiber selbst Kunde sein zu müssen.

Dazu gehört Technisch gesehen auch der Versuch mit dem betroffenen Hoster in Kontakt zu treten. Per Mail, Telefon, Brief (sorry Mail geht ja nicht). 

Das hat nichts mit wir mögen den oder wir mögen den nicht zu tun. 
Wir,  diejenigen die Betroffen sind, wollen nur einfach ihrer Verpflichtung nach besten Wissen und Gewissen gegenüber Ihren Kunden nachkommen. 
Was du beschreibst ist was ganz anderes. 
Dass es bei dem einen oder anderen Thema auch mal emotional wird liegt in der Sache selbst.

Und technisch gesehen gibt es auch sieve oder andere Betreff Filter die einen , wenn man es denn möchte, von dem speziellen Thema der Liste  befreien. 

Alles andere, denke ich, muss so eine Liste auch mal aushalten können, ohne Emotionen wird sie Stinklangweilig. 
Da ich technisch, reine Hardware und Softwareebene, KEINE Probleme mehr mit meinem Setup habe würde ich die dann abbestellen.
Das würde dann darauf wie auf Vielen anderen Listen aussehen (1 mal im Monat eine Benachrichtigung das man noch Mitglied ist)  :-)    

Und manchmal schwingt ein Körnchen Hoffnung mit das da  jemand der Kontakte hat mitliest und welcher Art auch immer etwas tun kann bevor es aus Verzweiflung emotional wird. 

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 

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEkT5V0950pM80Xu3sur3LxV3cLvwFAlx+Oy8ACgkQur3LxV3c
LvzJfwgAiwdVYlGDrgf+H9phIxZ7cSRkeAZR0PoDg4TEtRdsy/7ZlgojP5xgTE4N
OW56DZjfDhRw7QeamdBo11Ay6y2kJ9h/HJVtdA0nFWoKWXQE067ZAZ8C/lo80IK9
MQFB9TE1Z5BwqYPnvNuhd7H22Hx4wvIThdhzMa/UOlnXqEpp5OCTz4uc+QFHL5kU
wWhgsceu9LV92Vz/weDy4WtQTrUPSuSURuQAYwVR8JOweXJ4MTglDWRQP22G/u7K
2kvVsvDuhF8VYtjofWxn0vASWG4smVv0GLguwY6J/Xly6hIajOhjsUkBtPAHrlVC
fxH8aa7XwtBCeeGQg1DFnMhEeBbgvg==
=Yi+B
-----END PGP SIGNATURE-----



From gregor at aeppelbroe.de  Tue Mar  5 10:13:43 2019
From: gregor at aeppelbroe.de (Gregor Burck)
Date: Tue, 05 Mar 2019 10:13:43 +0100
Subject: Rechtliche =?utf-8?b?w5xiZXJnYW5n?= der e-Mails und Filterung
Message-ID: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>

Moin,

vor langer Zeit habe ich in einem Vortrag von Peer gelernt, das der  
Verantwortungsübergang der Mails bei Annahme der E-Mails auf dem  
eigenen Mailserver passiert. Der "eigene" Mailserver würde sich nach  
meiner Auffassung aus dem für die Domain Zuständigen im DNS  
eingetragenen Mailserver definieren. Also auch z.B. der 1und1 Server  
oder sonstiger Mail-Provider.

Deswegen dürfen wir über die Restrictions eine Filterung durchführen  
und der ausliefernde Server bekommt ein sauberes OK oder reject.

Was ich zu diesem Thema suche ist eine belastbare Dokumentation. Peer  
hat in dem Vortrag damals erwähnt das er bei Gericht als Gutachter  
tätig war.

Grüße

Gregor



From wn at neessen.net  Tue Mar  5 10:25:21 2019
From: wn at neessen.net (Winfried Neessen)
Date: Tue, 5 Mar 2019 10:25:21 +0100
Subject: =?utf-8?Q?Re=3A_Spa=C3=9F_mit_Google?=
In-Reply-To: <003201d4d332$370fe0c0$a52fa240$@fblan.de>
References: <6989318.OheBTfkvfn@tux.boltz.de.vu>
 <3228611.mQrLB4RBpK@tux.boltz.de.vu>
 <ad4a2e67-8a33-78db-5213-a6b5091b44f1@dimejo.at>
 <1673405.ANNBoj1SKO@tux.boltz.de.vu>
 <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>
 <702FDBD4-BD83-4E82-9236-2A87D2721A0B@debianfan.de>
 <000f01d4d299$49a61f40$dcf25dc0$@fblan.de>
 <9313eb88.AMAAADCHzH0AAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcfiWV@mailjet.com>
 <73DB533E-D8DA-4570-8AD3-78A356A32287@neessen.net>
 <003201d4d332$370fe0c0$a52fa240$@fblan.de>
Message-ID: <55A5D713-9B41-41D2-9CA4-29A3554B50BE@neessen.net>

Hi,

On 5. Mar 2019, at 10:02, Uwe Drießen <driessen at fblan.de> wrote:

> Wir,  diejenigen die Betroffen sind, wollen nur einfach ihrer Verpflichtung nach besten
> Wissen und Gewissen gegenüber Ihren Kunden nachkommen.

Naja, es wurde mehrfach in diesem und anderen Threads (in denen es um Google oder
MS ging) darauf hingewiesen, dass Mailhoster die SPF, DMARC und DKIM einsetzen (wie
es in Googles Guides beschrieben ist), keine Probleme mit dem Mailversand an Google
Kunden haben. Wenn Du von Verpflichtungen gegenueber Deinen Kunden sprichst, solltest
Du dann evtl. erstmal damit anfangen. Wenn es dann noch immer nicht klappt, hast Du
zumindest alle technischen Massnahme umgesetzt, die Dir den Versand ermoeglichen sollen
und dann hast Du noch immer die Moeglichkeit den Hoster zu kontaktieren.

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/20190305/27eec213/attachment.asc>

From r.sander at heinlein-support.de  Tue Mar  5 11:05:19 2019
From: r.sander at heinlein-support.de (Robert Sander)
Date: Tue, 5 Mar 2019 11:05:19 +0100
Subject: =?UTF-8?Q?Re=3a_Rechtliche_=c3=9cbergang_der_e-Mails_und_Filterung?=
In-Reply-To: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
References: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
Message-ID: <b66cf7d1-80f5-cf25-08d9-ce301e081a09@heinlein-support.de>

Hallo,

On 05.03.19 10:13, Gregor Burck wrote:

> Was ich zu diesem Thema suche ist eine belastbare Dokumentation. Peer  
> hat in dem Vortrag damals erwähnt das er bei Gericht als Gutachter  
> tätig war.

Der Heinlein-Blog hat eine Kategorie "Rechtliches", vielleicht findet
sich dort schon das Gesuchte:

https://www.heinlein-support.de/blog/category/recht/

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

https://www.heinlein-support.de

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

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

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

From gregor at aeppelbroe.de  Tue Mar  5 13:54:38 2019
From: gregor at aeppelbroe.de (Gregor Burck)
Date: Tue, 05 Mar 2019 13:54:38 +0100
Subject: Rechtliche =?utf-8?b?w5xiZXJnYW5n?= der e-Mails und Filterung
In-Reply-To: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
References: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
Message-ID: <20190305135438.EGroupware.Dda_NN2TnI3phKctl_vjKWY@heim.aeppelbroe.de>

Danke, genau das was ich gesucht habe.

Der Kommentar von meinem Kollegen: "Aber dann würden das ja 90% aller  
Unternehmen in Deutschland falsch handhaben!" (ohne Wertung über die  
Prozentzahl,...)

Ja ich glaube das der Prozentsatz sehr hoch ist ;-)

Grüße

Gregor

PS, ja NOCH läuft das bei uns über einen Provider und POP Abruf. Ich  
weiß aber auch, warum ich beim Provider sämtliche SPAM/Virusprüfung  
abgestellt habe.



From driessen at fblan.de  Tue Mar  5 17:14:26 2019
From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Tue, 5 Mar 2019 17:14:26 +0100
Subject: =?UTF-8?Q?AW:_Spa=C3=9F_mit_Google?=
In-Reply-To: <003201d4d332$370fe0c0$a52fa240$@fblan.de>
References: <6989318.OheBTfkvfn@tux.boltz.de.vu>
 <3228611.mQrLB4RBpK@tux.boltz.de.vu>
 <ad4a2e67-8a33-78db-5213-a6b5091b44f1@dimejo.at>
 <1673405.ANNBoj1SKO@tux.boltz.de.vu>
 <000a01d4d296$ed2a80a0$c77f81e0$@fblan.de>
 <702FDBD4-BD83-4E82-9236-2A87D2721A0B@debianfan.de>
 <000f01d4d299$49a61f40$dcf25dc0$@fblan.de>
 <9313eb88.AMAAADCHzH0AAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcfiWV@mailjet.com>
 <73DB533E-D8DA-4570-8AD3-78A356A32287@neessen.net>
 <003201d4d332$370fe0c0$a52fa240$@fblan.de>
Message-ID: <004301d4d36e$8134c710$839e5530$@fblan.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dann mal pur Technisch und das alle dran Teilhaben 

DNS Prüfen 

Scheinbar geht Google SEHR tief in die DNS records 

Prüfen mit 

https://zonemaster.net/domain_check

alle Unstimmigkeiten bereinigen 

Soa Records inkl. Gültigkeiten 
DNS Server mit PTR versehen 
Nameserver in 2 unterschiedlichen AS liegen (idealerweise) 
Usw. usw 

Wenn da bestimmte Dinge zusammen kommen die nicht stimmen gibt es eins auf die Glocke :-) 
 


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 

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEkT5V0950pM80Xu3sur3LxV3cLvwFAlx+oFoACgkQur3LxV3c
LvwOsAgAorZYfPltVeBjCW2+gav49hdE/1U1Ja/arffrygO1fHfe9M1Q0W3sxtRB
kMo8XI3B3m1tcsbVQa5PGQn7CRJSVF7bKF6FcSSxyzLKfWmiJXdT30wul5WUiDoG
X48ikt0dxK0fn270VYQvesU1iTHeakvAOEfRtow/KzONz4Wg/LbhW3G23/wwyl/n
Os+nXwZVeA9xtpo68Sm8h+worAktQlefYDTwZDNX+nsqaMpuXtd+z0bJqndJbu3Q
ftL5/4Wxh9fSEqCNzfKFcR6hLJDtQ4OpMa2RP3u2sRmKoMVl+IEkK8gyI0dX+l9j
CIKCSYN4g4CRV148P7SF7/cpWkiQvQ==
=12Yb
-----END PGP SIGNATURE-----



From forum at ruhnke.cloud  Wed Mar  6 16:50:07 2019
From: forum at ruhnke.cloud (Florian Ruhnke)
Date: Wed, 06 Mar 2019 16:50:07 +0100
Subject: Rspamd und fuzzy
Message-ID: <aefda6ee.AMUAADFjxiYAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcf-xC@mailjet.com>

Moin,

ich habe da mal eine Frage zu fuzzy_check, vielleicht ist das auch ein Verständnisproblem.

Soweit ich die Config verstanden habe, soll bei einem "neutralen" resp. unbekannten Ergebnis das Symbol "FUZZY_UNKNOWN" geliefert werden. Bei meiner Config wird aber nix geliefert.
Definiert sind der Standardserver rspamd.com und ein lokaler Server.

Hin und wieder wird eine angelernte Adresse mit "LOCAL_FUZZY_WHITE" gemeldet, aber auch nicht immer.
Was mich auch irritiert ist, dass absolute Müllmails nicht mal von rspamd.com ein denied bekommen, oder wenigstens ein prob.

In der logging.inc habe ich Debug auf fuzzy_backend, fuzzy_check und fuzzy_process_handler, aber bei einer ankommenden Mail taucht nix mit Fuzzy im log auf.
Wenn ich manuell das Spam-Postfach anlernen will, überschlägt sich das log mit "no content to generate fuzzy", was ich auch nicht nachvollziehen kann...

Falls meine config hilft, schieb ich die hier gern rein (dann als Anlage oder im Text?)

Grüße
Florian 
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190306/b83aebe6/attachment.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 655 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190306/b83aebe6/attachment.asc>

From jost+lists at dimejo.at  Wed Mar  6 17:23:26 2019
From: jost+lists at dimejo.at (Alex JOST)
Date: Wed, 6 Mar 2019 17:23:26 +0100
Subject: Rspamd und fuzzy
In-Reply-To: <aefda6ee.AMUAADFjxiYAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcf-xC@mailjet.com>
References: <aefda6ee.AMUAADFjxiYAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcf-xC@mailjet.com>
Message-ID: <f21900a5-2c77-2f53-92e6-9291aad53a91@dimejo.at>

Am 06.03.2019 um 16:50 schrieb Florian Ruhnke:
> Moin,
> 
> ich habe da mal eine Frage zu fuzzy_check, vielleicht ist das auch ein Verständnisproblem.
> 
> Soweit ich die Config verstanden habe, soll bei einem "neutralen" resp. unbekannten Ergebnis das Symbol "FUZZY_UNKNOWN" geliefert werden. Bei meiner Config wird aber nix geliefert.
> Definiert sind der Standardserver rspamd.com und ein lokaler Server.
> 
> Hin und wieder wird eine angelernte Adresse mit "LOCAL_FUZZY_WHITE" gemeldet, aber auch nicht immer.
> Was mich auch irritiert ist, dass absolute Müllmails nicht mal von rspamd.com ein denied bekommen, oder wenigstens ein prob.
> 
> In der logging.inc habe ich Debug auf fuzzy_backend, fuzzy_check und fuzzy_process_handler, aber bei einer ankommenden Mail taucht nix mit Fuzzy im log auf.
> Wenn ich manuell das Spam-Postfach anlernen will, überschlägt sich das log mit "no content to generate fuzzy", was ich auch nicht nachvollziehen kann...

Klingt mal so, als ob es nicht genug Inhalt zum Bewerten gäbe. Wie groß 
bzw. lang sind denn die E-Mails und was hast Du bei 'min_length' und 
'min_bytes' gesetzt?


> Falls meine config hilft, schieb ich die hier gern rein (dann als Anlage oder im Text?)

Konfiguration kann nie schaden :)

	rspamadm configdump fuzzy_check

-- 
Alex JOST


From werner at aloah-from-hell.de  Wed Mar  6 19:41:36 2019
From: werner at aloah-from-hell.de (Werner Detter)
Date: Wed, 6 Mar 2019 19:41:36 +0100
Subject: =?UTF-8?Q?Mailversand_mit_Anh=c3=a4ngen_+_ICMP_host_=24host_unreach?=
 =?UTF-8?Q?able_-_admin_prohibited_filter=2c_length_36?=
Message-ID: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>

Hallo zusammen, 

ich habe hier einen Kunden, der Probleme mit dem Mailserversand hat sobald eine Mail mit
Anhängen versendet wird (> ~5MB). Anbindung über Kabel Deutschland. Das ganze äussert 
sich im Maillog mit 

Mar  6 19:25:49 mail postfix/submission/smtpd[3931]: timeout after DATA (3348514 bytes) from business--xx-xx-xx-xx.pool2.vodafone-ip.de[xx.xx.xx.xx]

Ein TCPDUMP zeigt mir auf dem Mailserver warum er einen timeout bekommt:

18:57:07.816112 IP business-xx-xx-xx-xx.pool2.vodafone-ip.de > mail.example.org: ICMP host business-xx-xx-xx-xx.pool2.vodafone-ip.de unreachable - admin prohibited filter, length 36

Kunde hat eine normale Fritz!Box 6490 mit Kabel-Deutschland als ISP (über Kabel). Hier will
der Mailserver also mit dem Client im Zuge der SMTP-Übertragung kommunizieren aber die Fritz!Box
oder in der Infra von KD existiert ein Filter der entsprechende Probleme macht. 

Jemand ähnliche Erfahrungen mit Kabel Deutschland gemacht oder gar schon eine Lösung parat? 

Besten Dank und viele Grüße,
Werner




From forum at ruhnke.cloud  Wed Mar  6 20:48:46 2019
From: forum at ruhnke.cloud (forum at ruhnke.cloud)
Date: Wed, 06 Mar 2019 20:48:46 +0100
Subject: =?ISO-8859-1?Q?AW:Mailversand_mit_Anh=E4ngen_+_ICMP_host_$host_?=
 =?ISO-8859-1?Q?unreachable_-_admin_prohibited_filter,_length_36?=
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
Message-ID: <f848f94a.AL4AADDgBFIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgCRC@mailjet.com>

Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190306/527d8c30/attachment.htm>

From bjo at nord-west.org  Wed Mar  6 21:10:23 2019
From: bjo at nord-west.org (Bjoern Franke)
Date: Wed, 6 Mar 2019 21:10:23 +0100
Subject: =?UTF-8?Q?Re=3a_Mailversand_mit_Anh=c3=a4ngen_+_ICMP_host_=24host_u?=
 =?UTF-8?Q?nreachable_-_admin_prohibited_filter=2c_length_36?=
In-Reply-To: <f848f94a.AL4AADDgBFIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgCRC@mailjet.com>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
 <f848f94a.AL4AADDgBFIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgCRC@mailjet.com>
Message-ID: <15d9e331-6657-dbda-004b-664944739dc1@nord-west.org>

Am 06.03.19 um 20:48 schrieb forum at ruhnke.cloud:
> Sitzt da eine Firewall dazwischen, die ICMP sperrt?
> Oder aber... Das ist die Fritte selbst. Da die 6490 eigentlich als
> Consumer Gerät konzipiert ist, hat sie selbst ziemlich starke
> "Schutzfunktionen".
> Da müsste ja eigentlich schon für den Mailserver eine Freigabe
> eingerichtet sein, ist da auch ICMP freigegeben?
> Ich habe das so gelöst, dass ich den Reverse Proxy als "exposed host"
> freigegeben habe und die Sicherheit dann auf den Reverse Proxy abgewälzt
> habe. So hab ich keine Ping-Probleme. Vor allem kann ich so steuern wie
> ich will, und nicht wie Vodafone mir erlaubt.

Vertauschst du gerade die Richtung? Werners Aussage hatte ich so
verstanden, dass der Mailserver draussen im Netz ist und ein Client
hinter der Fitte die Probleme hat.

Unter Internet -> Filter -> Listen kann man jedenfalls auf einer 7590
ICMP abschalten, standardmässig ist das aber meines Wissens an.

VG
Björn


From werner at aloah-from-hell.de  Wed Mar  6 21:27:50 2019
From: werner at aloah-from-hell.de (Werner Detter)
Date: Wed, 6 Mar 2019 21:27:50 +0100
Subject: =?UTF-8?Q?Re=3a_Mailversand_mit_Anh=c3=a4ngen_+_ICMP_host_=24host_u?=
 =?UTF-8?Q?nreachable_-_admin_prohibited_filter=2c_length_36?=
In-Reply-To: <15d9e331-6657-dbda-004b-664944739dc1@nord-west.org>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
 <f848f94a.AL4AADDgBFIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgCRC@mailjet.com>
 <15d9e331-6657-dbda-004b-664944739dc1@nord-west.org>
Message-ID: <08f953a9-5d12-43b7-e958-a80dd1d351d4@aloah-from-hell.de>

Hi,

> Vertauschst du gerade die Richtung? Werners Aussage hatte ich so
> verstanden, dass der Mailserver draussen im Netz ist und ein Client
> hinter der Fitte die Probleme hat.

So isses.

> Unter Internet -> Filter -> Listen kann man jedenfalls auf einer 7590
> ICMP abschalten, standardmässig ist das aber meines Wissens an.

Hm, bei der Fritz!Box 6490 Cable kann da hinsichtlich ICMP da nichts
gesetzt werden (aber vielleicht ist das auch nur bei den
Kabel-Deutschland gebrandeten Modellen so?)

Auf jeden Fall scheint das Problem direkt der Fritz!Box oder irgendwo
der Infra von KD zugrunde zu liegen. Noch weitere Ideen ausser die
Fritz!Box rauszuwerfen?

Danke und viele Grüße,
Werner


From forum at ruhnke.cloud  Wed Mar  6 21:39:29 2019
From: forum at ruhnke.cloud (Florian Ruhnke)
Date: Wed, 06 Mar 2019 21:39:29 +0100
Subject: =?UTF-8?Q?Re=3A_Mailversand_mit_Anh=C3=A4ngen_+_ICMP_host_=24host_?=
 =?UTF-8?Q?unreachable_-_admin_prohibited_filter=2C_length_36?=
In-Reply-To: <08f953a9-5d12-43b7-e958-a80dd1d351d4@aloah-from-hell.de>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
 <f848f94a.AL4AADDgBFIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgCRC@mailjet.com>
 <15d9e331-6657-dbda-004b-664944739dc1@nord-west.org>
 <08f953a9-5d12-43b7-e958-a80dd1d351d4@aloah-from-hell.de>
Message-ID: <83d104ad.AM4AADD6v3YAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgDAG@mailjet.com>

Ja, dann hab ich das falsch verstanden. Ich dachte, der Server steht auf der Seite des VF-Business Kunden.

In der 6490 gibt es den Schalter "Firewall im Stealth Modus". Schalter aus: ICMP wird beantwortet. Schalter ein: ICMP wird verworfen.
Darunter dann noch der Schalter "E-Mail
Filter Port 25".
Beide Schalter sind bei meiner 6490 aus, und ich habe keine Probleme. Aber hier sitzt der Mailserver auch hinter der 6490 ;-) 

Am 6. März 2019 21:27:50 MEZ schrieb Werner Detter <werner at aloah-from-hell.de>:
>Hi,
>
>> Vertauschst du gerade die Richtung? Werners Aussage hatte ich so
>> verstanden, dass der Mailserver draussen im Netz ist und ein Client
>> hinter der Fitte die Probleme hat.
>
>So isses.
>
>> Unter Internet -> Filter -> Listen kann man jedenfalls auf einer 7590
>> ICMP abschalten, standardmässig ist das aber meines Wissens an.
>
>Hm, bei der Fritz!Box 6490 Cable kann da hinsichtlich ICMP da nichts
>gesetzt werden (aber vielleicht ist das auch nur bei den
>Kabel-Deutschland gebrandeten Modellen so?)
>
>Auf jeden Fall scheint das Problem direkt der Fritz!Box oder irgendwo
>der Infra von KD zugrunde zu liegen. Noch weitere Ideen ausser die
>Fritz!Box rauszuwerfen?
>
>Danke und viele Grüße,
>Werner

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190306/f4399a92/attachment.htm>

From werner at aloah-from-hell.de  Wed Mar  6 21:50:34 2019
From: werner at aloah-from-hell.de (Werner Detter)
Date: Wed, 6 Mar 2019 21:50:34 +0100
Subject: =?UTF-8?Q?Re=3a_Mailversand_mit_Anh=c3=a4ngen_+_ICMP_host_=24host_u?=
 =?UTF-8?Q?nreachable_-_admin_prohibited_filter=2c_length_36?=
In-Reply-To: <83d104ad.AM4AADD6v3YAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgDAG@mailjet.com>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
 <f848f94a.AL4AADDgBFIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgCRC@mailjet.com>
 <15d9e331-6657-dbda-004b-664944739dc1@nord-west.org>
 <08f953a9-5d12-43b7-e958-a80dd1d351d4@aloah-from-hell.de>
 <83d104ad.AM4AADD6v3YAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgDAG@mailjet.com>
Message-ID: <2c6f5398-15fc-4356-eeaf-084edeebf178@aloah-from-hell.de>

Hi,

Der Mailserver sitzt nicht hinter der 6490 aber der Client. "Firewall im
Stealth-Modus" ist deaktiviert, ebenso der "E-Mail-Filter über Port 25".

Ciao,
Werner




Am 06.03.19 um 21:39 schrieb Florian Ruhnke:
> Ja, dann hab ich das falsch verstanden. Ich dachte, der Server steht auf
> der Seite des VF-Business Kunden.
> 
> In der 6490 gibt es den Schalter "Firewall im Stealth Modus". Schalter
> aus: ICMP wird beantwortet. Schalter ein: ICMP wird verworfen.
> Darunter dann noch der Schalter "E-Mail
> Filter Port 25".
> Beide Schalter sind bei meiner 6490 aus, und ich habe keine Probleme.
> Aber hier sitzt der Mailserver auch hinter der 6490 ;-)
> 
> Am 6. März 2019 21:27:50 MEZ schrieb Werner Detter
> <werner at aloah-from-hell.de>:
> 
>     Hi,
> 
>         Vertauschst du gerade die Richtung? Werners Aussage hatte ich so
>         verstanden, dass der Mailserver draussen im Netz ist und ein Client
>         hinter der Fitte die Probleme hat.
> 
> 
>     So isses.
> 
>         Unter Internet -> Filter -> Listen kann man jedenfalls auf einer
>         7590
>         ICMP abschalten, standardmässig ist das aber meines Wissens an.
> 
> 
>     Hm, bei der Fritz!Box 6490 Cable kann da hinsichtlich ICMP da nichts
>     gesetzt werden (aber vielleicht ist das auch nur bei den
>     Kabel-Deutschland gebrandeten Modellen so?)
> 
>     Auf jeden Fall scheint das Problem direkt der Fritz!Box oder irgendwo
>     der Infra von KD zugrunde zu liegen. Noch weitere Ideen ausser die
>     Fritz!Box rauszuwerfen?
> 
>     Danke und viele Grüße,
>     Werner
> 
> 
> -- 
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.



From forum at ruhnke.cloud  Wed Mar  6 21:51:43 2019
From: forum at ruhnke.cloud (Florian Ruhnke)
Date: Wed, 06 Mar 2019 21:51:43 +0100
Subject: Rspamd und fuzzy
In-Reply-To: <f21900a5-2c77-2f53-92e6-9291aad53a91@dimejo.at>
References: <aefda6ee.AMUAADFjxiYAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcf-xC@mailjet.com>
 <f21900a5-2c77-2f53-92e6-9291aad53a91@dimejo.at>
Message-ID: <b1efb207.AMwAADFCuqIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgDLk@mailjet.com>

Sorry für die jetzt doof formatierte Mail, schreib gerade übers Smartphone. 

min_bytes habe ich schon auf 100 runter gesetzt, min_length habe ich noch gar nicht probiert.

Hier mal ein configdump, habe allerdings _alles_ als json schreiben lassen und dann nach fuzzy aussortiert (und dabei hoffentlich keine Klammern falsch gelöscht, Smartphone halt). Die mime_types resultieren aus verschiedenen Versuchen, ihn doch noch zu überreden. Bis heute morgen war nur * drin. Ebenso retransmits und timeout. 

{
    "fuzzy_check": {
        "retransmits": 7,
        "rule": {
            "FUZZY_CUSTOM": {
                "min_width": 100,
                "symbol": "LOCAL_FUZZY_UNKNOWN",
                "mime_types": [
                    "*",
                    "application/*",
                    "text/*",
                    "text/html",
                    "text/plain",
                    "*/*",
                    "image/*"
                ],
                "fuzzy_map": {
                    "LOCAL_FUZZY_DENIED": {
                        "flag": 11,
                        "max_score": 20
                    },
                    "LOCAL_FUZZY_WHITE": {
                        "flag": 13,
                        "max_score": 2
                    },
                    "LOCAL_FUZZY_PROB": {
                        "flag": 12,
                        "max_score": 10
                    }
                },
                "min_height": 100,
                "short_text_direct_hash": true,
                "max_score": 20,
                "skip_unknown": true,
                "read_only": false,
                "algorithm": "mumhash",
                "servers": "127.0.0.1:11335"
            },
            "rspamd.com": {
                "symbol": "FUZZY_UNKNOWN",
                "mime_types": [
                    "*"
                ],
                "encryption_key": "icy63itbhhni8bq15ntp5n5symuixf73s1kpjh6skaq4e7nx5fiy",
                "read_only": true,
                "fuzzy_map": {
                    "FUZZY_PROB": {
                        "flag": 2,
                        "max_score": 10
                    },
                    "FUZZY_DENIED": {
                        "flag": 1,
                        "max_score": 20
                    },
                    "FUZZY_WHITE": {
                        "flag": 3,
                        "max_score": 2
                    }
                },
                "max_score": 20,
                "short_text_direct_hash": true,
                "skip_unknown": true,
                "algorithm": "mumhash",
                "servers": "round-robin:fuzzy1.rspamd.com:11335,fuzzy2.rspamd.com:11335"
            }
        },
        "timeout": 20,
        "min_bytes": 100
    },
    "group": {
        "fuzzy": {
            "symbols": {
                "LOCAL_FUZZY_UNKNOWN": {
                    "description": "Generic fuzzy hash match, local",
                    "weight": 5
                },
                "LOCAL_FUZZY_WHITE": {
                    "description": "Whitelisted fuzzy hash, local",
                    "weight": -2.100000
                },
                "FUZZY_DENIED": {
                    "description": "Denied fuzzy hash, bl.rspamd.com",
                    "weight": 12
                },
                "FUZZY_WHITE": {
                    "description": "Whitelisted fuzzy hash, bl.rspamd.com",
                    "weight": -2.100000
                },
                "FUZZY_UNKNOWN": {
                    "description": "Generic fuzzy hash match, bl.rspamd.com",
                    "weight": 5
                },
                "FUZZY_PROB": {
                    "description": "Probable fuzzy hash, bl.rspamd.com",
                    "weight": 5
                },
                "LOCAL_FUZZY_PROB": {
                    "description": "Probable fuzzy hash, local",
                    "weight": 5
                },
                "LOCAL_FUZZY_DENIED": {
                    "description": "Denied fuzzy hash, local",
                    "weight": 12
                }
            },
            "max_score": 20
        }
    },
    "worker": [
        {
            "fuzzy": {
                "backend": "redis",
                "expire": 15552000,
                "sync": 60,
                "allow_update": "127.0.0.1, [::1]",
                "db": "2",
                "enabled": true,
                "bind_socket": "localhost:11335",
                "count": 2
            }
        }
    ],
    "milter_headers": {
        "extended_spam_headers": true,
        "use": [
            "x-spamd-bar",
            "x-spam-level",
            "authentication-results",
            "x-spamd-result",
            "x-rspamd-server",
            "x-rspamd-queue-id",
            "fuzzy-hashes",
            "stat-signature"
        ],
        "routines": {
            "fuzzy-hashes": {
                "header": "X-Rspamd-Fuzzy"
            },
        }
    },
    "options": {
        "filters": "chartable,dkim,spf,surbl,regexp,fuzzy_check",
}



Am 6. März 2019 17:23:26 MEZ schrieb Alex JOST <jost+lists at dimejo.at>:
>Am 06.03.2019 um 16:50 schrieb Florian Ruhnke:
>> Moin,
>> 
>> ich habe da mal eine Frage zu fuzzy_check, vielleicht ist das auch
>ein Verständnisproblem.
>> 
>> Soweit ich die Config verstanden habe, soll bei einem "neutralen"
>resp. unbekannten Ergebnis das Symbol "FUZZY_UNKNOWN" geliefert werden.
>Bei meiner Config wird aber nix geliefert.
>> Definiert sind der Standardserver rspamd.com und ein lokaler Server.
>> 
>> Hin und wieder wird eine angelernte Adresse mit "LOCAL_FUZZY_WHITE"
>gemeldet, aber auch nicht immer.
>> Was mich auch irritiert ist, dass absolute Müllmails nicht mal von
>rspamd.com ein denied bekommen, oder wenigstens ein prob.
>> 
>> In der logging.inc habe ich Debug auf fuzzy_backend, fuzzy_check und
>fuzzy_process_handler, aber bei einer ankommenden Mail taucht nix mit
>Fuzzy im log auf.
>> Wenn ich manuell das Spam-Postfach anlernen will, überschlägt sich
>das log mit "no content to generate fuzzy", was ich auch nicht
>nachvollziehen kann...
>
>Klingt mal so, als ob es nicht genug Inhalt zum Bewerten gäbe. Wie groß
>
>bzw. lang sind denn die E-Mails und was hast Du bei 'min_length' und 
>'min_bytes' gesetzt?
>
>
>> Falls meine config hilft, schieb ich die hier gern rein (dann als
>Anlage oder im Text?)
>
>Konfiguration kann nie schaden :)
>
>	rspamadm configdump fuzzy_check
>
>-- 
>Alex JOST

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190306/6e38544a/attachment.htm>

From stse+postfixbuch at fsing.rootsland.net  Wed Mar  6 21:45:24 2019
From: stse+postfixbuch at fsing.rootsland.net (Stephan Seitz)
Date: Wed, 6 Mar 2019 21:45:24 +0100
Subject: Mailversand mit =?iso-8859-1?Q?Anh=E4n?=
 =?iso-8859-1?Q?gen_+_ICMP_hos?= =?iso-8859-1?Q?t?= $host unreachable - admin
 prohibited filter, length 36
In-Reply-To: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
Message-ID: <20190306T213907.GA.a7a52.stse@fsing.rootsland.net>

On Mi, Mär 06, 2019 at 07:41:36 +0100, Werner Detter wrote:
>Ein TCPDUMP zeigt mir auf dem Mailserver warum er einen timeout bekommt:

Du kannst auf dem Mailserver tracen? Kannst du eine komplette 
PCAP-Session zur Verfügung stellen (also nur Filter auf die Vodafone-IP, 
nicht auf Ports)?

>18:57:07.816112 IP business-xx-xx-xx-xx.pool2.vodafone-ip.de > mail.example.org: ICMP host business-xx-xx-xx-xx.pool2.vodafone-ip.de unreachable - admin prohibited filter, length 36

Öh, das ICMP-Paket kommt von Vodafone zu deinem Mailserver? Das klingt 
aber nach einer Antwort auf eine Anfrage vom Mailserver. Ist das 
möglicherweise ein Ident-Request vom Mailserver, sofern es das heute noch 
gibt?

>Kunde hat eine normale Fritz!Box 6490 mit Kabel-Deutschland als ISP 
>(über Kabel). Hier will der Mailserver also mit dem Client im Zuge der 
>SMTP-Übertragung kommunizieren aber die Fritz!Box oder in der Infra von 
>KD existiert ein Filter der entsprechende Probleme macht.

Hm, wie sollte das gehen, wenn es doch von der Größe der Mail abhängt?  
Ich habe dein Mail ja so verstanden, daß kleine Mails kein Problem 
machen.

>Jemand ähnliche Erfahrungen mit Kabel Deutschland gemacht oder gar schon 
>eine Lösung parat?

Ich bin nicht bei Kabel Deutschland, aber ich habe die 7490, mit der ich 
auch bei großen Mails keine Probleme habe.

Shade and sweet water!

	Stephan

-- 
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 3545 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190306/63a65424/attachment.p7s>

From werner at aloah-from-hell.de  Wed Mar  6 22:00:02 2019
From: werner at aloah-from-hell.de (Werner Detter)
Date: Wed, 6 Mar 2019 22:00:02 +0100
Subject: =?UTF-8?Q?Re=3a_Mailversand_mit_Anh=c3=a4ngen_+_ICMP_host_=24host_u?=
 =?UTF-8?Q?nreachable_-_admin_prohibited_filter=2c_length_36?=
In-Reply-To: <20190306T213907.GA.a7a52.stse@fsing.rootsland.net>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
 <20190306T213907.GA.a7a52.stse@fsing.rootsland.net>
Message-ID: <814bbe92-4fe4-c1dc-4b17-b8cac8e0d080@aloah-from-hell.de>

Hi, 

>> 18:57:07.816112 IP business-xx-xx-xx-xx.pool2.vodafone-ip.de >
>> mail.example.org: ICMP host business-xx-xx-xx-xx.pool2.vodafone-ip.de
>> unreachable - admin prohibited filter, length 36

> Öh, das ICMP-Paket kommt von Vodafone zu deinem Mailserver? Das klingt
> aber nach einer Antwort auf eine Anfrage vom Mailserver. Ist das
> möglicherweise ein Ident-Request vom Mailserver, sofern es das heute
> noch gibt?

Genau, das Paket kommt von Vodafone zu dem Mailserver wo Vodafone/KB dem
Mailserver sagt, dass hier wohl was administrativ nicht erlaubt ist. 
Und ich schätze mal sowas wie ICMP-Pakete bzgl. ?fragmentation needed?
was beim Falle von Anhängen notwendig ist. 

> Hm, wie sollte das gehen, wenn es doch von der Größe der Mail abhängt? 
> Ich habe dein Mail ja so verstanden, daß kleine Mails kein Problem machen.

s.o. 

VG, 
Werner



From werner at aloah-from-hell.de  Wed Mar  6 22:03:42 2019
From: werner at aloah-from-hell.de (Werner Detter)
Date: Wed, 6 Mar 2019 22:03:42 +0100
Subject: =?UTF-8?Q?Re=3a_Mailversand_mit_Anh=c3=a4ngen_+_ICMP_host_=24host_u?=
 =?UTF-8?Q?nreachable_-_admin_prohibited_filter=2c_length_36?=
In-Reply-To: <814bbe92-4fe4-c1dc-4b17-b8cac8e0d080@aloah-from-hell.de>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
 <20190306T213907.GA.a7a52.stse@fsing.rootsland.net>
 <814bbe92-4fe4-c1dc-4b17-b8cac8e0d080@aloah-from-hell.de>
Message-ID: <803b34e8-f6a2-54c1-e497-761ce136396f@aloah-from-hell.de>


>>> 18:57:07.816112 IP business-xx-xx-xx-xx.pool2.vodafone-ip.de >
>>> mail.example.org: ICMP host business-xx-xx-xx-xx.pool2.vodafone-ip.de
>>> unreachable - admin prohibited filter, length 36
> 
>> Öh, das ICMP-Paket kommt von Vodafone zu deinem Mailserver? Das klingt
>> aber nach einer Antwort auf eine Anfrage vom Mailserver. Ist das
>> möglicherweise ein Ident-Request vom Mailserver, sofern es das heute
>> noch gibt?
> 
> Genau, das Paket kommt von Vodafone zu dem Mailserver wo Vodafone/KB dem
> Mailserver sagt, dass hier wohl was administrativ nicht erlaubt ist. 
> Und ich schätze mal sowas wie ICMP-Pakete bzgl. ?fragmentation needed?
> was beim Falle von Anhängen notwendig ist. 

... notwendig sein kann.


>> Hm, wie sollte das gehen, wenn es doch von der Größe der Mail abhängt? 
>> Ich habe dein Mail ja so verstanden, daß kleine Mails kein Problem machen.

Nachtrag: Ja, Mails ohne Anhang machen keine Probleme.



From p at sys4.de  Wed Mar  6 22:39:06 2019
From: p at sys4.de (Patrick Ben Koetter)
Date: Wed, 6 Mar 2019 22:39:06 +0100
Subject: Mailversand mit =?utf-8?Q?Anh=C3=A4ngen_+_ICM?= =?utf-8?Q?P?=
 host $host unreachable - admin prohibited filter, length 36
In-Reply-To: <803b34e8-f6a2-54c1-e497-761ce136396f@aloah-from-hell.de>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
 <20190306T213907.GA.a7a52.stse@fsing.rootsland.net>
 <814bbe92-4fe4-c1dc-4b17-b8cac8e0d080@aloah-from-hell.de>
 <803b34e8-f6a2-54c1-e497-761ce136396f@aloah-from-hell.de>
Message-ID: <20190306213906.w74adfu4uvjsuh5y@sys4.de>

* Werner Detter <postfixbuch-users at listen.jpberlin.de>:
> >> Hm, wie sollte das gehen, wenn es doch von der Größe der Mail abhängt? 
> >> Ich habe dein Mail ja so verstanden, daß kleine Mails kein Problem machen.
> 
> Nachtrag: Ja, Mails ohne Anhang machen keine Probleme.

TLS, Payload. ICMP geblocked. "Need to fragment" wird unterdrückt. Client und
Server bekommen die MTU nicht resized. Session wird abgebrochen. Fällt nur
auf bei grossen Streams mit "attachments.

p at rick


-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 


From werner at aloah-from-hell.de  Thu Mar  7 07:40:42 2019
From: werner at aloah-from-hell.de (Werner Detter)
Date: Thu, 7 Mar 2019 07:40:42 +0100
Subject: =?UTF-8?Q?Re=3a_Mailversand_mit_Anh=c3=a4ngen_+_ICMP_host_=24host_u?=
 =?UTF-8?Q?nreachable_-_admin_prohibited_filter=2c_length_36?=
In-Reply-To: <20190306213906.w74adfu4uvjsuh5y@sys4.de>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
 <20190306T213907.GA.a7a52.stse@fsing.rootsland.net>
 <814bbe92-4fe4-c1dc-4b17-b8cac8e0d080@aloah-from-hell.de>
 <803b34e8-f6a2-54c1-e497-761ce136396f@aloah-from-hell.de>
 <20190306213906.w74adfu4uvjsuh5y@sys4.de>
Message-ID: <825f30cf-bfe6-63a2-1579-658830d34e88@aloah-from-hell.de>

Moin, 

> TLS, Payload. ICMP geblocked. "Need to fragment" wird unterdrückt. Client und
> Server bekommen die MTU nicht resized. Session wird abgebrochen. Fällt nur
> auf bei grossen Streams mit "attachments.

Jap, das ist auch meine Vermutung an der Stelle. Und ausser die gebrandete Fritz!Box 
zu tauschen fällt mir auch grad nichts ein (ausser vielleicht die MTU auf dem MX
testweise mal stark zu reduzieren). 

Viele Grüße,
Werner







From cr at ncxs.de  Thu Mar  7 08:17:46 2019
From: cr at ncxs.de (Carsten Rosenberg)
Date: Thu, 7 Mar 2019 08:17:46 +0100
Subject: Rspamd und fuzzy
In-Reply-To: <b1efb207.AMwAADFCuqIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgDLk@mailjet.com>
References: <aefda6ee.AMUAADFjxiYAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcf-xC@mailjet.com>
 <f21900a5-2c77-2f53-92e6-9291aad53a91@dimejo.at>
 <b1efb207.AMwAADFCuqIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgDLk@mailjet.com>
Message-ID: <00113863-a31c-83d3-b091-8641be05b3df@ncxs.de>

Hey,

FUZZY_UNKNOWN ist ein Symbol an den sich der Callback des Plugins dran
hängt und normalerweise nicht angezeigt wird.

Um das FUZZY_UNKNOWN zu bekommen, müsste ein nicht definiertes flag aus
der fuzzy_map zurück geliefert werden und skip_unknown = false gesetzt sein.

Wenn du also skip_unknown = false  setzt und z.B. FUZZY_DENIED
auskommentierst bekommst du bei einem Hit vom eigentlichen FUZZY_DENIED
(flag 1) das FUZZY_UNKNOWN, da es nicht zugeordnet werden kann.

> Hin und wieder wird eine angelernte Adresse mit "LOCAL_FUZZY_WHITE"

Fuzzy ist eine Art Text Pattern matching und File Hashing. Es wirkt also
auf den Inhalt und nicht auf eine Adresse.

viele Grüße

Carsten

On 06.03.19 21:51, Florian Ruhnke wrote:
> Sorry für die jetzt doof formatierte Mail, schreib gerade übers Smartphone.
> 
> min_bytes habe ich schon auf 100 runter gesetzt, min_length habe ich
> noch gar nicht probiert.
> 
> Hier mal ein configdump, habe allerdings _alles_ als json schreiben
> lassen und dann nach fuzzy aussortiert (und dabei hoffentlich keine
> Klammern falsch gelöscht, Smartphone halt). Die mime_types resultieren
> aus verschiedenen Versuchen, ihn doch noch zu überreden. Bis heute
> morgen war nur * drin. Ebenso retransmits und timeout.
> 
> {
> "fuzzy_check": {
> "retransmits": 7,
> "rule": {
> "FUZZY_CUSTOM": {
> "min_width": 100,
> "symbol": "LOCAL_FUZZY_UNKNOWN",
> "mime_types": [
> "*",
> "application/*",
> "text/*",
> "text/html",
> "text/plain",
> "*/*",
> "image/*"
> ],
> "fuzzy_map": {
> "LOCAL_FUZZY_DENIED": {
> "flag": 11,
> "max_score": 20
> },
> "LOCAL_FUZZY_WHITE": {
> "flag": 13,
> "max_score": 2
> },
> "LOCAL_FUZZY_PROB": {
> "flag": 12,
> "max_score": 10
> }
> },
> "min_height": 100,
> "short_text_direct_hash": true,
> "max_score": 20,
> "skip_unknown": true,
> "read_only": false,
> "algorithm": "mumhash",
> "servers": "127.0.0.1:11335"
> },
> "rspamd.com": {
> "symbol": "FUZZY_UNKNOWN",
> "mime_types": [
> "*"
> ],
> "encryption_key": "icy63itbhhni8bq15ntp5n5symuixf73s1kpjh6skaq4e7nx5fiy",
> "read_only": true,
> "fuzzy_map": {
> "FUZZY_PROB": {
> "flag": 2,
> "max_score": 10
> },
> "FUZZY_DENIED": {
> "flag": 1,
> "max_score": 20
> },
> "FUZZY_WHITE": {
> "flag": 3,
> "max_score": 2
> }
> },
> "max_score": 20,
> "short_text_direct_hash": true,
> "skip_unknown": true,
> "algorithm": "mumhash",
> "servers": "round-robin:fuzzy1.rspamd.com:11335,fuzzy2.rspamd.com:11335"
> }
> },
> "timeout": 20,
> "min_bytes": 100
> },
> "group": {
> "fuzzy": {
> "symbols": {
> "LOCAL_FUZZY_UNKNOWN": {
> "description": "Generic fuzzy hash match, local",
> "weight": 5
> },
> "LOCAL_FUZZY_WHITE": {
> "description": "Whitelisted fuzzy hash, local",
> "weight": -2.100000
> },
> "FUZZY_DENIED": {
> "description": "Denied fuzzy hash, bl.rspamd.com",
> "weight": 12
> },
> "FUZZY_WHITE": {
> "description": "Whitelisted fuzzy hash, bl.rspamd.com",
> "weight": -2.100000
> },
> "FUZZY_UNKNOWN": {
> "description": "Generic fuzzy hash match, bl.rspamd.com",
> "weight": 5
> },
> "FUZZY_PROB": {
> "description": "Probable fuzzy hash, bl.rspamd.com",
> "weight": 5
> },
> "LOCAL_FUZZY_PROB": {
> "description": "Probable fuzzy hash, local",
> "weight": 5
> },
> "LOCAL_FUZZY_DENIED": {
> "description": "Denied fuzzy hash, local",
> "weight": 12
> }
> },
> "max_score": 20
> }
> },
> "worker": [
> {
> "fuzzy": {
> "backend": "redis",
> "expire": 15552000,
> "sync": 60,
> "allow_update": "127.0.0.1, [::1]",
> "db": "2",
> "enabled": true,
> "bind_socket": "localhost:11335",
> "count": 2
> }
> }
> ],
> "milter_headers": {
> "extended_spam_headers": true,
> "use": [
> "x-spamd-bar",
> "x-spam-level",
> "authentication-results",
> "x-spamd-result",
> "x-rspamd-server",
> "x-rspamd-queue-id",
> "fuzzy-hashes",
> "stat-signature"
> ],
> "routines": {
> "fuzzy-hashes": {
> "header": "X-Rspamd-Fuzzy"
> },
> }
> },
> "options": {
> "filters": "chartable,dkim,spf,surbl,regexp,fuzzy_check",
> }
> 
> 
> 
> Am 6. März 2019 17:23:26 MEZ schrieb Alex JOST <jost+lists at dimejo.at>:
> 
>     Am 06.03.2019 um 16:50 schrieb Florian Ruhnke:
> 
>         Moin,
> 
>         ich habe da mal eine Frage zu fuzzy_check, vielleicht ist das
>         auch ein Verständnisproblem.
> 
>         Soweit ich die Config verstanden habe, soll bei einem
>         "neutralen" resp. unbekannten Ergebnis das Symbol
>         "FUZZY_UNKNOWN" geliefert werden. Bei meiner Config wird aber
>         nix geliefert.
>         Definiert sind der Standardserver rspamd.com und ein lokaler Server.
> 
>         Hin und wieder wird eine angelernte Adresse mit
>         "LOCAL_FUZZY_WHITE" gemeldet, aber auch nicht immer.
>         Was mich auch irritiert ist, dass absolute Müllmails nicht mal
>         von rspamd.com ein denied bekommen, oder wenigstens ein prob.
> 
>         In der logging.inc habe ich Debug auf fuzzy_backend, fuzzy_check
>         und fuzzy_process_handler, aber bei einer ankommenden Mail
>         taucht nix mit Fuzzy im log auf.
>         Wenn ich manuell das Spam-Postfach anlernen will, überschlägt
>         sich das log mit "no content to generate fuzzy", was ich auch
>         nicht nachvollziehen kann...
> 
> 
>     Klingt mal so, als ob es nicht genug Inhalt zum Bewerten gäbe. Wie groß 
>     bzw. lang sind denn die E-Mails und was hast Du bei 'min_length' und 
>     'min_bytes' gesetzt?
> 
> 
>         Falls meine config hilft, schieb ich die hier gern rein (dann
>         als Anlage oder im Text?)
> 
> 
>     Konfiguration kann nie schaden :)
> 
>     	rspamadm configdump fuzzy_check
> 
> 
> -- 
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


From bjo at nord-west.org  Thu Mar  7 12:14:27 2019
From: bjo at nord-west.org (Bjoern Franke)
Date: Thu, 7 Mar 2019 12:14:27 +0100
Subject: =?UTF-8?Q?Re=3a_Mailversand_mit_Anh=c3=a4ngen_+_ICMP_host_=24host_u?=
 =?UTF-8?Q?nreachable_-_admin_prohibited_filter=2c_length_36?=
In-Reply-To: <825f30cf-bfe6-63a2-1579-658830d34e88@aloah-from-hell.de>
References: <bb5c2896-3f12-0584-605a-3aa8834533dd@aloah-from-hell.de>
 <20190306T213907.GA.a7a52.stse@fsing.rootsland.net>
 <814bbe92-4fe4-c1dc-4b17-b8cac8e0d080@aloah-from-hell.de>
 <803b34e8-f6a2-54c1-e497-761ce136396f@aloah-from-hell.de>
 <20190306213906.w74adfu4uvjsuh5y@sys4.de>
 <825f30cf-bfe6-63a2-1579-658830d34e88@aloah-from-hell.de>
Message-ID: <9d9a6ac4-5fb2-e551-5b03-0c50b046264a@nord-west.org>

Moin,

> 
> Jap, das ist auch meine Vermutung an der Stelle. Und ausser die gebrandete Fritz!Box 
> zu tauschen fällt mir auch grad nichts ein (ausser vielleicht die MTU auf dem MX
> testweise mal stark zu reduzieren). 


Funktioniert http://fritz.box/html/capture.html auf der Fritte?

Dann könntest du schauen, ob die Fritzbox "admin prohibited filter" sendet.

Grüße
Björn


From bluewind at xinu.at  Fri Mar  8 14:30:10 2019
From: bluewind at xinu.at (Florian Pritz)
Date: Fri, 8 Mar 2019 14:30:10 +0100
Subject: Rechtliche =?utf-8?Q?=C3=9Cbergan?= =?utf-8?Q?g?= der e-Mails
 und Filterung
In-Reply-To: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
References: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
Message-ID: <20190308133010.GA20462@xinu.at>

On Tue, Mar 05, 2019 at 10:13:43AM +0100, Gregor Burck <gregor at aeppelbroe.de> wrote:
> Deswegen dürfen wir über die Restrictions eine Filterung durchführen und der
> ausliefernde Server bekommt ein sauberes OK oder reject.
> 
> Was ich zu diesem Thema suche ist eine belastbare Dokumentation. Peer hat in
> dem Vortrag damals erwähnt das er bei Gericht als Gutachter tätig war.

http://www.spiegel.de/netzwelt/web/spam-ordner-geschaeftliche-e-mails-muessen-taeglich-kontrolliert-werden-a-981136.html

bzw. das Urteil dazu direkt:
http://www.justiz.nrw.de/nrwe/lgs/bonn/lg_bonn/j2014/15_O_189_13_Urteil_20140110.html

Ich glaube es steht nicht direkt drinnen wie das mit rejects läuft, aber
es steht dass du deinen Spam-Ordner anschauen musst. Rein logisch würde
ich jetzt mal argumentieren, dass, wenn du keinen hast, du den auch
nicht anschauen kannst. Vielleicht hat da auch noch jemand einen
besseren Link?

Florian
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190308/ef45a067/attachment.asc>

From driessen at fblan.de  Fri Mar  8 16:55:08 2019
From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Fri, 8 Mar 2019 16:55:08 +0100
Subject: =?utf-8?Q?AW:_Rechtliche_=C3=9Cbergang_der_e-Ma?=
 =?utf-8?Q?ils_und_Filterung?=
In-Reply-To: <20190308133010.GA20462@xinu.at>
References: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
 <20190308133010.GA20462@xinu.at>
Message-ID: <002901d4d5c7$4eaa5160$ebfef420$@fblan.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Im Auftrag von Florian Pritz
> 
> On Tue, Mar 05, 2019 at 10:13:43AM +0100, Gregor Burck
> <gregor at aeppelbroe.de> wrote:
> > Deswegen dürfen wir über die Restrictions eine Filterung durchführen und
> der
> > ausliefernde Server bekommt ein sauberes OK oder reject.
> >
> > Was ich zu diesem Thema suche ist eine belastbare Dokumentation. Peer
> hat in
> > dem Vortrag damals erwähnt das er bei Gericht als Gutachter tätig war.
> 
> http://www.spiegel.de/netzwelt/web/spam-ordner-geschaeftliche-e-mails-
> muessen-taeglich-kontrolliert-werden-a-981136.html
> 
> bzw. das Urteil dazu direkt:
> http://www.justiz.nrw.de/nrwe/lgs/bonn/lg_bonn/j2014/15_O_189_13_Urt
> eil_20140110.html
> 
> Ich glaube es steht nicht direkt drinnen wie das mit rejects läuft, aber
> es steht dass du deinen Spam-Ordner anschauen musst. Rein logisch würde
> ich jetzt mal argumentieren, dass, wenn du keinen hast, du den auch
> nicht anschauen kannst. Vielleicht hat da auch noch jemand einen
> besseren Link?
> 
> Florian

Wenn in einen Spamordner/Junk-Mail Ordner  sortiert wird dann muss dieser auch tgl. auf Mails geprüft werden 

Wird eine Mail vom Mailserver abgewiesen dann kann diese nicht in den Verantwortungsbereich des Empfängers gelangen.
Diese Mail wurde nicht zugestellt !
In dem Fall trägt der Absender die Verantwortung wie auch immer er die Mail zum Empfänger bekommt. 
 
Was in deinem Briefkasten liegt hast du zu beachten, der Absender ist allerdings auch nachweispflichtig das dem richtigen Empfänger  zugestellt wurde. 

Reject während der Zustellung ist die einzige saubere Möglichkeit Mails abzulehnen das sie als nicht zugestellt gelten 
Nachträgliches Bounce zählt nicht :-)  (Der Absender hat das 250 OK schon)  oder anders ausgedrückt wenn du Post aus deinem Briefkasten wegwirfst ist das dein Problem auch wenn das dein Empfangsgehilfe(Provider) für dich macht.


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 


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEkT5V0950pM80Xu3sur3LxV3cLvwFAlyCkFQACgkQur3LxV3c
Lvw4sQf9HUwWKp5pfYESR96tsY5LUYjrGgEMEL8nbCvDaz80Zooo1rvmAQKeUJO7
t3V626DZzO1MDUP6ud59IHKWInJAnKe6J5ylXfD4isYQ7Csop0OtyGm0IhkmsBQT
+3tDMUsQvqtCVp8y5gTPG6l++6qBq+ogB52RvAjnWYFFxKiR8yoSfRGX/9c9DDjx
j/yamCpDtFW4i358OERF9FovaAGodo+//KRHtv6yg0N6TUjQb4bP/L6dRoHLblkH
RsdRPJj3PbPLvBHf+hodRsa3Yt6+NknkBz8Erg5fhy7nsPHC4zZ+fnslFofUaAgL
NHBzgxO36c6GVDdpOlo0zQH3XQVJuw==
=qpW4
-----END PGP SIGNATURE-----



From martin at lichtvoll.de  Fri Mar  8 19:05:05 2019
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Fri, 08 Mar 2019 19:05:05 +0100
Subject: Rechtliche =?UTF-8?B?w5xiZXJnYW5n?= der e-Mails und Filterung
In-Reply-To: <002901d4d5c7$4eaa5160$ebfef420$@fblan.de>
References: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
 <20190308133010.GA20462@xinu.at> <002901d4d5c7$4eaa5160$ebfef420$@fblan.de>
Message-ID: <2207717.fTPzj1nguX@merkaba>

Uwe Drießen - 08.03.19, 16:55:
> Im Auftrag von Florian Pritz
> 
> > On Tue, Mar 05, 2019 at 10:13:43AM +0100, Gregor Burck
> > 
> > <gregor at aeppelbroe.de> wrote:
> > > Deswegen dürfen wir über die Restrictions eine Filterung
> > > durchführen und> 
> > der
> > 
> > > ausliefernde Server bekommt ein sauberes OK oder reject.
> > > 
> > > Was ich zu diesem Thema suche ist eine belastbare Dokumentation.
> > > Peer
> > 
> > hat in
> > 
> > > dem Vortrag damals erwähnt das er bei Gericht als Gutachter tätig
> > > war.> 
> > http://www.spiegel.de/netzwelt/web/spam-ordner-geschaeftliche-e-mail
> > s- muessen-taeglich-kontrolliert-werden-a-981136.html
> > 
> > bzw. das Urteil dazu direkt:
> > http://www.justiz.nrw.de/nrwe/lgs/bonn/lg_bonn/j2014/15_O_189_13_Urt
> > eil_20140110.html
> > 
> > Ich glaube es steht nicht direkt drinnen wie das mit rejects läuft,
> > aber es steht dass du deinen Spam-Ordner anschauen musst. Rein
> > logisch würde ich jetzt mal argumentieren, dass, wenn du keinen
> > hast, du den auch nicht anschauen kannst. Vielleicht hat da auch
> > noch jemand einen besseren Link?
[?]
> Wenn in einen Spamordner/Junk-Mail Ordner  sortiert wird dann muss
> dieser auch tgl. auf Mails geprüft werden
> 
> Wird eine Mail vom Mailserver abgewiesen dann kann diese nicht in den
> Verantwortungsbereich des Empfängers gelangen. Diese Mail wurde nicht
> zugestellt !
> In dem Fall trägt der Absender die Verantwortung wie auch immer er die
> Mail zum Empfänger bekommt.

Demnach wäre, was Microsoft mit Office 365 meiner Erfahrung nach mit der 
Spam Quarantäne macht, rechtswidrig in Deutschland:

- Von Spam-Mails, wo sich der (IMHO extrem ineffizient arbeitende) nicht 
sicher ist, erfahre ich erst in eine Spam-Quarantäne-Nachricht am 
*nächsten* Tag.

- Diese Mail enthält nur Links, einerseits Microsoft mit zu teilen, die 
Mail sei kein Spam und sie damit trainieren zu lassen, was meiner 
Erfahrung nach schlicht nichts bringt, und andererseits die Mail doch 
noch zuzustellen.

- Solche Mails in der Spam-Quarantäne hebt Microsoft auch nur 2 Wochen 
auf. Pech bei einem längerem Urlaub mit falschen Positiven, die älter 
als 2 Wochen sind. Die sind dann einfach *weg*.

- Und ja, es gibt falsche Positive. Selten, aber oft genug.


Und nein, ich nutze das nicht privat. :)

Ciao,
-- 
Martin




From martin at lichtvoll.de  Fri Mar  8 20:27:39 2019
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Fri, 08 Mar 2019 20:27:39 +0100
Subject: Rechtliche =?UTF-8?B?w5xiZXJnYW5n?= der e-Mails und Filterung
In-Reply-To: <2207717.fTPzj1nguX@merkaba>
References: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
 <002901d4d5c7$4eaa5160$ebfef420$@fblan.de> <2207717.fTPzj1nguX@merkaba>
Message-ID: <2498369.3uvS4PUr5p@merkaba>

Martin Steigerwald - 08.03.19, 19:05:
> - Von Spam-Mails, wo sich der (IMHO extrem ineffizient arbeitende)

Spam-Filter

> nicht sicher ist, erfahre ich erst in eine Spam-Quarantäne-Nachricht
> am *nächsten* Tag.
-- 
Martin




From driessen at fblan.de  Fri Mar  8 21:27:39 2019
From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Fri, 8 Mar 2019 21:27:39 +0100
Subject: =?utf-8?Q?AW:_Rechtliche_=C3=9Cbergang_der_e-Ma?=
 =?utf-8?Q?ils_und_Filterung?=
In-Reply-To: <2207717.fTPzj1nguX@merkaba>
References: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
 <20190308133010.GA20462@xinu.at> <002901d4d5c7$4eaa5160$ebfef420$@fblan.de>
 <2207717.fTPzj1nguX@merkaba>
Message-ID: <003001d4d5ed$60bb9aa0$2232cfe0$@fblan.de>

Im Auftrag von Martin Steigerwald
> 
> Demnach wäre, was Microsoft mit Office 365 meiner Erfahrung nach mit der
> Spam Quarantäne macht, rechtswidrig in Deutschland:
> 
> - Von Spam-Mails, wo sich der (IMHO extrem ineffizient arbeitende) nicht
> sicher ist, erfahre ich erst in eine Spam-Quarantäne-Nachricht am
> *nächsten* Tag.
> 
> - Diese Mail enthält nur Links, einerseits Microsoft mit zu teilen, die
> Mail sei kein Spam und sie damit trainieren zu lassen, was meiner
> Erfahrung nach schlicht nichts bringt, und andererseits die Mail doch
> noch zuzustellen.
> 
> - Solche Mails in der Spam-Quarantäne hebt Microsoft auch nur 2 Wochen
> auf. Pech bei einem längerem Urlaub mit falschen Positiven, die älter
> als 2 Wochen sind. Die sind dann einfach *weg*.
> 
> - Und ja, es gibt falsche Positive. Selten, aber oft genug.
> 
> 

You get for what you pay 

Wer außerhalb der Deutschen Gerichtsbarkeit, der Europäischen DSVGO Mailprovider nutzt ist 2 mal mehr gefordert diese zu prüfen in wie weit alles den Vorschriften entspricht 
 
In dem Fall haftet ganz klar der Empfänger und seine Empfangsgehilfen.


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 




From pug at felsing.net  Sat Mar  9 10:50:12 2019
From: pug at felsing.net (Christian Felsing)
Date: Sat, 9 Mar 2019 10:50:12 +0100
Subject: =?UTF-8?Q?Re=3a_Rechtliche_=c3=9cbergang_der_e-Mails_und_Filterung?=
In-Reply-To: <b66cf7d1-80f5-cf25-08d9-ce301e081a09@heinlein-support.de>
References: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
 <b66cf7d1-80f5-cf25-08d9-ce301e081a09@heinlein-support.de>
Message-ID: <e9a1c8bd-9981-74ec-7e7d-5ceb7af4b908@felsing.net>

Am 05.03.19 um 11:05 schrieb Robert Sander:
> Der Heinlein-Blog hat eine Kategorie "Rechtliches", vielleicht findet
> sich dort schon das Gesuchte:
> 
> https://www.heinlein-support.de/blog/category/recht/

Hallo zusammen,

lesenswert ist auch dieser Beitrag dazu:
https://www.teltarif.de/outlook-spam-filter-falsch-programmiert/news/65945.html

Ist nicht mehr ganz neu, allerdings dürfte der Kommentar eines
Rechtsanwalts dort dazu alle Fragen diesbezüglich beantworten.

Das ist übrigens auch ein Grund, warum ich Kunden grundsätzlich von
Outlook.live.com abrate. Dort hat man offenbar keine Ahnung, wie man
Spam und Malware richtig filtert.

Viele Grüße
Christian


From martin at lichtvoll.de  Sat Mar  9 11:23:46 2019
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Sat, 09 Mar 2019 11:23:46 +0100
Subject: Rechtliche =?UTF-8?B?w5xiZXJnYW5n?= der e-Mails und Filterung
In-Reply-To: <e9a1c8bd-9981-74ec-7e7d-5ceb7af4b908@felsing.net>
References: <20190305101343.EGroupware.CVEKdJ6_5Y96o6MDhsOAhJG@heim.aeppelbroe.de>
 <b66cf7d1-80f5-cf25-08d9-ce301e081a09@heinlein-support.de>
 <e9a1c8bd-9981-74ec-7e7d-5ceb7af4b908@felsing.net>
Message-ID: <2039987.kLpdaEPisH@merkaba>

Christian Felsing - 09.03.19, 10:50:
> Am 05.03.19 um 11:05 schrieb Robert Sander:
> > Der Heinlein-Blog hat eine Kategorie "Rechtliches", vielleicht
> > findet
> > sich dort schon das Gesuchte:
> > 
> > https://www.heinlein-support.de/blog/category/recht/
[?]
> lesenswert ist auch dieser Beitrag dazu:
> https://www.teltarif.de/outlook-spam-filter-falsch-programmiert/news/6
> 5945.html
> 
> Ist nicht mehr ganz neu, allerdings dürfte der Kommentar eines
> Rechtsanwalts dort dazu alle Fragen diesbezüglich beantworten.
> 
> Das ist übrigens auch ein Grund, warum ich Kunden grundsätzlich von
> Outlook.live.com abrate. Dort hat man offenbar keine Ahnung, wie man
> Spam und Malware richtig filtert.

Danke. 

Auch an Florian.

Schönes Wochenende,
-- 
Martin




From gjn at gjn.priv.at  Wed Mar 13 12:33:29 2019
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Wed, 13 Mar 2019 12:33:29 +0100
Subject: client-initiated renegotiation
Message-ID: <5394512.hO18LxbE1l@techz>

Hallo,

Ich habe mal einige Test Server für meinen Mailserver ausprobiert das einzige 
was dabei bemängelt wird ist "client-initiated renegotiation" nach der 
sucherei was das ist, bin ich nicht recht schlauer geworden.

Das einzige was ich gefunden habe, soll der Parameter sein ?

smtpd_client_new_tls_session_rate_limit = 0

Hängt das damit zusammen wenn ja welchen Wert sollte man da einfügen?

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

  Günther J. Niederwimmer




From wn at neessen.net  Wed Mar 13 15:42:11 2019
From: wn at neessen.net (Winfried Neessen)
Date: Wed, 13 Mar 2019 15:42:11 +0100
Subject: client-initiated renegotiation
In-Reply-To: <5394512.hO18LxbE1l@techz>
References: <5394512.hO18LxbE1l@techz>
Message-ID: <FF46D447-109F-49E0-B333-8DC1588A3AB8@neessen.net>

Hi,

On 13. Mar 2019, at 12:33, Günther J. Niederwimmer <gjn at gjn.priv.at> wrote:

> Ich habe mal einige Test Server für meinen Mailserver ausprobiert das einzige
> was dabei bemängelt wird ist "client-initiated renegotiation" nach der
> sucherei was das ist, bin ich nicht recht schlauer geworden.
> 

Was fuer "Test Server"? Wo wird das bemaengelt? Hast Du Logs?


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/20190313/843ad288/attachment.asc>

From gjn at gjn.priv.at  Wed Mar 13 18:14:46 2019
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Wed, 13 Mar 2019 18:14:46 +0100
Subject: client-initiated renegotiation
In-Reply-To: <FF46D447-109F-49E0-B333-8DC1588A3AB8@neessen.net>
References: <5394512.hO18LxbE1l@techz>
 <FF46D447-109F-49E0-B333-8DC1588A3AB8@neessen.net>
Message-ID: <14379415.6Pghqcuqbq@techz>

Am Mittwoch, 13. März 2019, 15:42:11 CET schrieb Winfried Neessen:
> Hi,
> 
> On 13. Mar 2019, at 12:33, Günther J. Niederwimmer <gjn at gjn.priv.at> wrote:
> > Ich habe mal einige Test Server für meinen Mailserver ausprobiert das
> > einzige was dabei bemängelt wird ist "client-initiated renegotiation"
> > nach der sucherei was das ist, bin ich nicht recht schlauer geworden.
> 
> Was fuer "Test Server"? Wo wird das bemaengelt? Hast Du Logs?
> 
auf 

en.internet.nl

Logs habe ich dazu leider keine, jedenfalls meint das Teil ich bin für Dos 
Attacken offen. aber es gibt ein Beispiel .... ?

Das ist der Bericht dazu.

 Verdict:

At least one of your mail servers allows for client-initiated renegotiation, 
which is not secure.
Test explanation:
We check if a sending mail server can initiate a renegotiation with your 
receiving mail server (MX). There seems to be no need to support client-
initiated renegotiation. Although the option does not bear a risk for 
confidentiality, it does make your mail server vulnerable to DoS attacks 
within the same TLS connection. Therefore you should not support it. See 'TLS 
guidelines from NCSC- NL', guideline B6-2 (in Dutch).

Requirement level: Recommendation

-- 
mit freundliche Grüßen / best regards,

  Günther J. Niederwimmer




From wn at neessen.net  Wed Mar 13 18:48:55 2019
From: wn at neessen.net (Winfried Neessen)
Date: Wed, 13 Mar 2019 18:48:55 +0100
Subject: client-initiated renegotiation
In-Reply-To: <14379415.6Pghqcuqbq@techz>
References: <5394512.hO18LxbE1l@techz>
 <FF46D447-109F-49E0-B333-8DC1588A3AB8@neessen.net>
 <14379415.6Pghqcuqbq@techz>
Message-ID: <81681639-676D-4C75-8EFF-388657E92286@neessen.net>

Hi,

On 13. Mar 2019, at 18:14, Günther J. Niederwimmer <gjn at gjn.priv.at> wrote:

> en.internet.nl
>  [...]
> At least one of your mail servers allows for client-initiated renegotiation,
> which is not secure.
> Test explanation:
> We check if a sending mail server can initiate a renegotiation with your
> receiving mail server (MX). There seems to be no need to support client-
> initiated renegotiation. Although the option does not bear a risk for
> confidentiality, it does make your mail server vulnerable to DoS attacks
> within the same TLS connection. Therefore you should not support it. See 'TLS
> guidelines from NCSC- NL', guideline B6-2 (in Dutch).

Hmm, aktuelle OpenSSL Implementierungen sollten eigentlich nur sichere[3]
TLS renegotiation erlauben. Lt. SSL_CTX_set_options(3) ist dies seit OpenSSL
0.9.8m der Fall.

Du kannst aber auch Postfix sagen, dass Du TLS renegotiation komplett deaktivieren
willst. Das funktioniert mit dem tls_ssl_options parameter. Dem musst Du die
entsprechende OpenSSL set_options Hexmaske uebergeben. Lt. openssl/ssl.h[2]
fuer die aktuelle OpenSSL Version sollte das 0x40000000 sein. In aelteren OpenSSL
Versionen kann es aber auch eine andere Maske sein.

Generell wuerde ich aber davon abraten an den tls_ssl_options zu schrauben.


Winni



[1] = http://www.postfix.org/postconf.5.html#tls_ssl_options <http://www.postfix.org/postconf.5.html#tls_ssl_options>
[2] = https://github.com/openssl/openssl/blob/master/include/openssl/ssl.h <https://github.com/openssl/openssl/blob/master/include/openssl/ssl.h>
[3] = https://www.rfc-editor.org/rfc/rfc5746.txt <https://www.rfc-editor.org/rfc/rfc5746.txt>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190313/7a3e4aab/attachment.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: Message signed with OpenPGP
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190313/7a3e4aab/attachment.asc>

From anmeyer at mailbox.org  Wed Mar 13 23:57:57 2019
From: anmeyer at mailbox.org (Andreas Meyer)
Date: Wed, 13 Mar 2019 23:57:57 +0100
Subject: client-initiated renegotiation
In-Reply-To: <14379415.6Pghqcuqbq@techz>
References: <5394512.hO18LxbE1l@techz>
 <FF46D447-109F-49E0-B333-8DC1588A3AB8@neessen.net>
 <14379415.6Pghqcuqbq@techz>
Message-ID: <20190313235757.34b1f18a@localhost>

Günther J. Niederwimmer <gjn at gjn.priv.at> schrieb am 13.03.19 um 18:14:46 Uhr:

> Am Mittwoch, 13. März 2019, 15:42:11 CET schrieb Winfried Neessen:
> > Hi,
> > 
> > On 13. Mar 2019, at 12:33, Günther J. Niederwimmer <gjn at gjn.priv.at> wrote:  
> > > Ich habe mal einige Test Server für meinen Mailserver ausprobiert das
> > > einzige was dabei bemängelt wird ist "client-initiated renegotiation"
> > > nach der sucherei was das ist, bin ich nicht recht schlauer geworden.  
> > 
> > Was fuer "Test Server"? Wo wird das bemaengelt? Hast Du Logs?
> >   
> auf 
> 
> en.internet.nl
> 
> Logs habe ich dazu leider keine, jedenfalls meint das Teil ich bin für Dos 
> Attacken offen. aber es gibt ein Beispiel .... ?

Ich darf mal zitieren:

The impact of TLS-based attacks on SMTP should not be over-stated. Presently, most SMTP clients don't verify the TLS certificates of SMTP servers. Such clients are already vulnerable to ordinary man-in-the-middle attacks, and TLS renegotiation introduces no new threats for them.

The Postfix SMTP server with OpenSSL is not affected by the TLS renegotiation attack that redirects and modifies SMTP mail, due to accidental details of the Postfix and OpenSSL implementations.

https://blog.kruyt.org/postfix-and-tls-encryption/

Grüße

  Andreas

-- 
PGP-Fingerprint: F004 8EEE 5E54 F2EA 566E B939 22E5 85DD AA14 AC0A
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 228 bytes
Beschreibung: Digitale Signatur von OpenPGP
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190313/26cc3538/attachment.sig>

From andreas.schulze at datev.de  Thu Mar 14 08:19:10 2019
From: andreas.schulze at datev.de (Andreas Schulze)
Date: Thu, 14 Mar 2019 08:19:10 +0100
Subject: client-initiated renegotiation
In-Reply-To: <20190313235757.34b1f18a@localhost>
References: <5394512.hO18LxbE1l@techz>
 <FF46D447-109F-49E0-B333-8DC1588A3AB8@neessen.net>
 <14379415.6Pghqcuqbq@techz> <20190313235757.34b1f18a@localhost>
Message-ID: <f8a8ec30-a817-cb15-56ac-29a76f280b19@datev.de>

Am 13.03.19 um 23:57 schrieb Andreas Meyer:
> The impact of TLS-based attacks on SMTP should not be over-stated. Presently, most SMTP clients don't verify the TLS certificates of SMTP servers. Such clients are already vulnerable to ordinary man-in-the-middle attacks, and TLS renegotiation introduces no new threats for them.

> 
> The Postfix SMTP server with OpenSSL is not affected by the TLS renegotiation attack that redirects and modifies SMTP mail, due to accidental details of the Postfix and OpenSSL implementations.

Moin,

das ist grundsätzlich richtig. Man kann damit keine Maildaten fälschen.
Aber - und das wird auf der Testseite angesagt - eröffnet es die Möglichkeit für einen DoS.

Renegioation ist eine kryptographische Funktion und damit mehr oder weniger CPU-Intensiv. Wenn also ein Client in einer TLS-Session 100 Renegioations pro Sekunde anstößt, /kann/ das schon spürbar sein.
Testen kann man Renegioation mit "openssl s_client -connect mail.example.org:25 -starttls smtp"
In der Session dann jeweils R und ENTER drücken ( siehe man s_client / CONNECTED COMMANDS )

Wie man das ausschaltet muss ich auch gerade passen. Ich vermute aber ebenfalls, via tls_ssl_options.
Wenn jemand näheres weiß, gern über die Liste kippen ....

Übrigens: dieser DoS-Vektor ist wohl der Grund, dass "Client initiated Renegioation" in TLS1.3 über Bord geworfen wurde.
Wer also Postfix mit TLS1.3 only betreibt ist zumindest davor sicher, hat aber ansonsten möglicherweise Interop Probleme :-)

-- 
A. Schulze
DATEV eG


From wn at neessen.net  Thu Mar 14 08:51:05 2019
From: wn at neessen.net (Winfried Neessen)
Date: Thu, 14 Mar 2019 08:51:05 +0100
Subject: client-initiated renegotiation
In-Reply-To: <f8a8ec30-a817-cb15-56ac-29a76f280b19@datev.de>
References: <5394512.hO18LxbE1l@techz>
 <FF46D447-109F-49E0-B333-8DC1588A3AB8@neessen.net>
 <14379415.6Pghqcuqbq@techz> <20190313235757.34b1f18a@localhost>
 <f8a8ec30-a817-cb15-56ac-29a76f280b19@datev.de>
Message-ID: <7D5B038C-A3B6-49A2-B641-519532D2967E@neessen.net>

Hi,

On 14. Mar 2019, at 08:19, Andreas Schulze <andreas.schulze at datev.de> wrote:
> 
> Wie man das ausschaltet muss ich auch gerade passen. Ich vermute aber ebenfalls, via tls_ssl_options.

Mir ist keine SSL_option bekannt, die nur Client initiierte TLS renegotiation ausschaltet. M. W. n. gibt
es nur "SSL_OP_NO_RENEGOTIATION" um TLS renegotiation komplett zu deaktivieren. Generell
bringt das eh nur einen Geschwindigkeitsvorteil, wenn man Verbindungen hat, die weite Strecken
(sprich hoher Roundtrip) hinter sich gelegt haben.

Mit aktueller Hardware halte ich den DoS Vektor aber auch fuer ueberschaubar (acceptable risk).


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/20190314/d0301cb9/attachment.asc>

From maegger at ee.ethz.ch  Thu Mar 14 10:38:53 2019
From: maegger at ee.ethz.ch (Matthias Egger)
Date: Thu, 14 Mar 2019 10:38:53 +0100
Subject: UTF-8 Problem mit HEINLEIN Spamassassin Rules?
Message-ID: <b39af2cb-2710-63c6-9eef-cdba29d99b94@ee.ethz.ch>

Hallo Liste, Hallo Peer

Wir kriegen seit einigen Tagen (genauer seit dem 10.3.2019) jeweils beim
kompilieren der Rules mittels sa-compile eine Fehlermeldung:

---
Wide character in print at /usr/bin/sa-compile line 433, <$fh> line 2408.
---

Schuld daran scheint die folgende Heinlein Datei zu sein:

---
spamassassin_heinlein-support_de/70_HS_body.cf
---

Es gab da anscheinend schon einmal Probleme mit der Heinlein Liste im
letzten November. Im damaligen Bug schrieb diesen Februar Henrik Krohns:

"Well if Heinlein is reading this, do not use UTF8 in rule files. That's
the most simple fix."

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7645#c12

Wenn man bei den normalen SA Rules schaut sind die meisten Files
entweder "ASCII" oder "ISO-8859":

     58 ASCII
      1 data
      2 empty
      1 HTML
      6 ISO-8859

Bei Heinlein:
     2 ASCII
     2 UTF-8

So auch eben die:

spamassassin_heinlein-support_de/70_HS_body.cf: UTF-8 Unicode text, with
overstriking

gibt es irgend einen Workaround den man machen kann bis heinlein die
Listen fixen (wenn überhaupt?)?

An einer veralteten SA Version unsererseits kann es eigentlich auch
nicht liegen:

---
SpamAssassin version 3.4.2
  running on Perl version 5.24.1
---

Lieber Gruss
Matthias

-- 
Matthias Egger
ETH Zurich
Department of Information Technology          maegger at ee.ethz.ch
and Electrical Engineering
IT Support Group (ISG.EE), ETF/D/102          Phone +41 (0)44 632 03 90
Sternwartstrasse 7, CH-8092 Zurich            Fax   +41 (0)44 632 11 95

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 3990 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190314/6221ca74/attachment.p7s>

From gjn at gjn.priv.at  Thu Mar 14 12:50:47 2019
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Thu, 14 Mar 2019 12:50:47 +0100
Subject: client-initiated renegotiation
In-Reply-To: <7D5B038C-A3B6-49A2-B641-519532D2967E@neessen.net>
References: <5394512.hO18LxbE1l@techz>
 <f8a8ec30-a817-cb15-56ac-29a76f280b19@datev.de>
 <7D5B038C-A3B6-49A2-B641-519532D2967E@neessen.net>
Message-ID: <4026433.EgiES5BvD9@techz>

Hallo,

Am Donnerstag, 14. März 2019, 08:51:05 CET schrieb Winfried Neessen:
> Hi,
> 
> On 14. Mar 2019, at 08:19, Andreas Schulze <andreas.schulze at datev.de> wrote:
> > Wie man das ausschaltet muss ich auch gerade passen. Ich vermute aber
> > ebenfalls, via tls_ssl_options.
> Mir ist keine SSL_option bekannt, die nur Client initiierte TLS
> renegotiation ausschaltet. M. W. n. gibt es nur "SSL_OP_NO_RENEGOTIATION"
> um TLS renegotiation komplett zu deaktivieren. Generell bringt das eh nur
> einen Geschwindigkeitsvorteil, wenn man Verbindungen hat, die weite
> Strecken (sprich hoher Roundtrip) hinter sich gelegt haben.
> 
> Mit aktueller Hardware halte ich den DoS Vektor aber auch fuer ueberschaubar
> (acceptable risk).

Ich hatte von dem "Problem" bis jetzt nirgends gelesen, bis ich auf dieser 
Testseite darauf hingewiesen wurde ?

Also Ihr meint man kann es vernachlässigen ?

Was ich noch nicht gefunden habe ist der Sinn / Unsinn diese Parameters 
worüber ich beim suchen gestolpert bin?

smtpd_client_new_tls_session_rate_limit = 0

das ist die Grundeinstellung in postfix, hat der überhaupt was mit dem obigen 
Fall zu tun?

Oder sollte man da einen Wert setzen zb. = 100

Danke für Eure Mithilfe,

-- 
mit freundliche Grüßen / best regards,

  Günther J. Niederwimmer




From gjn at gjn.priv.at  Thu Mar 14 13:12:19 2019
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Thu, 14 Mar 2019 13:12:19 +0100
Subject: Dovecot submission
Message-ID: <1848148.X89xbDbk2M@techz>

Hallo,

Ich bin gerade dabei meinen Mailserver auf einem anderen Rechner aufzusetzen 
und habe mal "CentOS" die neuesten Versionen genommen.

Dabei wir von dovecot  submission automatisch aktiviert.

Nur finde ich eigentlich nichts darüber, wie das mit postfix kombiniert wird ?

Ich habe von Peer gelernt das das ganze für Handy von Vorteil sein sollte aber 
wie man das konfiguriert finde ich nicht!

Kann mich von Euch jemand auf den richtigen Weg bringen.

Danke für jede Hilfe,
-- 
mit freundliche Grüßen / best regards,

  Günther J. Niederwimmer




From forum at ruhnke.cloud  Thu Mar 14 13:49:47 2019
From: forum at ruhnke.cloud (Florian Ruhnke)
Date: Thu, 14 Mar 2019 13:49:47 +0100
Subject: Rspamd und fuzzy
In-Reply-To: <00113863-a31c-83d3-b091-8641be05b3df@ncxs.de>
References: <aefda6ee.AMUAADFjxiYAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcf-xC@mailjet.com>
 <f21900a5-2c77-2f53-92e6-9291aad53a91@dimejo.at>
 <b1efb207.AMwAADFCuqIAAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcgDLk@mailjet.com>
 <00113863-a31c-83d3-b091-8641be05b3df@ncxs.de>
Message-ID: <31509f0a.ANAAADKsFf8AAAAAAAAAAAQhH6UAAAAAHvAAAAAAAAyfGgBcik3v@mailjet.com>

Moin,

dann war es ein Gedankenfehler von mir.
Danke für die Info. Meine Idee war, das Fuzzy vllt besser arbeitet als Bayes, aber dann sehe ich es jetzt nur noch als parallelen Filter zur Erweiterung des Antispam-Kampfes.
Wenn ich (aufgrund der geringen Größe des Mailservers) so was auf community-based suche, von dem ich bisher dachte, dass da Fuzzy die Lösung wäre. 
Soweit ich es jetzt verstanden habe, kann Fuzzy gegen Spam-Wellen funktionieren, wenn genügend Positiv-Meldungen eingehen, bevor die Welle wieder vorbei ist, richtig?

Vllt mal über neuronetwork nachdenken... 

Gruß
Florian 

Am 7. März 2019 08:17:46 MEZ schrieb Carsten Rosenberg <cr at ncxs.de>:
>Hey,
>
>FUZZY_UNKNOWN ist ein Symbol an den sich der Callback des Plugins dran
>hängt und normalerweise nicht angezeigt wird.
>
>Um das FUZZY_UNKNOWN zu bekommen, müsste ein nicht definiertes flag aus
>der fuzzy_map zurück geliefert werden und skip_unknown = false gesetzt
>sein.
>
>Wenn du also skip_unknown = false  setzt und z.B. FUZZY_DENIED
>auskommentierst bekommst du bei einem Hit vom eigentlichen FUZZY_DENIED
>(flag 1) das FUZZY_UNKNOWN, da es nicht zugeordnet werden kann.
>
>> Hin und wieder wird eine angelernte Adresse mit "LOCAL_FUZZY_WHITE"
>
>Fuzzy ist eine Art Text Pattern matching und File Hashing. Es wirkt
>also
>auf den Inhalt und nicht auf eine Adresse.
>
>viele Grüße
>
>Carsten
>
>On 06.03.19 21:51, Florian Ruhnke wrote:
>> Sorry für die jetzt doof formatierte Mail, schreib gerade übers
>Smartphone.
>> 
>> min_bytes habe ich schon auf 100 runter gesetzt, min_length habe ich
>> noch gar nicht probiert.
>> 
>> Hier mal ein configdump, habe allerdings _alles_ als json schreiben
>> lassen und dann nach fuzzy aussortiert (und dabei hoffentlich keine
>> Klammern falsch gelöscht, Smartphone halt). Die mime_types
>resultieren
>> aus verschiedenen Versuchen, ihn doch noch zu überreden. Bis heute
>> morgen war nur * drin. Ebenso retransmits und timeout.
>> 
>> {
>> "fuzzy_check": {
>> "retransmits": 7,
>> "rule": {
>> "FUZZY_CUSTOM": {
>> "min_width": 100,
>> "symbol": "LOCAL_FUZZY_UNKNOWN",
>> "mime_types": [
>> "*",
>> "application/*",
>> "text/*",
>> "text/html",
>> "text/plain",
>> "*/*",
>> "image/*"
>> ],
>> "fuzzy_map": {
>> "LOCAL_FUZZY_DENIED": {
>> "flag": 11,
>> "max_score": 20
>> },
>> "LOCAL_FUZZY_WHITE": {
>> "flag": 13,
>> "max_score": 2
>> },
>> "LOCAL_FUZZY_PROB": {
>> "flag": 12,
>> "max_score": 10
>> }
>> },
>> "min_height": 100,
>> "short_text_direct_hash": true,
>> "max_score": 20,
>> "skip_unknown": true,
>> "read_only": false,
>> "algorithm": "mumhash",
>> "servers": "127.0.0.1:11335"
>> },
>> "rspamd.com": {
>> "symbol": "FUZZY_UNKNOWN",
>> "mime_types": [
>> "*"
>> ],
>> "encryption_key":
>"icy63itbhhni8bq15ntp5n5symuixf73s1kpjh6skaq4e7nx5fiy",
>> "read_only": true,
>> "fuzzy_map": {
>> "FUZZY_PROB": {
>> "flag": 2,
>> "max_score": 10
>> },
>> "FUZZY_DENIED": {
>> "flag": 1,
>> "max_score": 20
>> },
>> "FUZZY_WHITE": {
>> "flag": 3,
>> "max_score": 2
>> }
>> },
>> "max_score": 20,
>> "short_text_direct_hash": true,
>> "skip_unknown": true,
>> "algorithm": "mumhash",
>> "servers":
>"round-robin:fuzzy1.rspamd.com:11335,fuzzy2.rspamd.com:11335"
>> }
>> },
>> "timeout": 20,
>> "min_bytes": 100
>> },
>> "group": {
>> "fuzzy": {
>> "symbols": {
>> "LOCAL_FUZZY_UNKNOWN": {
>> "description": "Generic fuzzy hash match, local",
>> "weight": 5
>> },
>> "LOCAL_FUZZY_WHITE": {
>> "description": "Whitelisted fuzzy hash, local",
>> "weight": -2.100000
>> },
>> "FUZZY_DENIED": {
>> "description": "Denied fuzzy hash, bl.rspamd.com",
>> "weight": 12
>> },
>> "FUZZY_WHITE": {
>> "description": "Whitelisted fuzzy hash, bl.rspamd.com",
>> "weight": -2.100000
>> },
>> "FUZZY_UNKNOWN": {
>> "description": "Generic fuzzy hash match, bl.rspamd.com",
>> "weight": 5
>> },
>> "FUZZY_PROB": {
>> "description": "Probable fuzzy hash, bl.rspamd.com",
>> "weight": 5
>> },
>> "LOCAL_FUZZY_PROB": {
>> "description": "Probable fuzzy hash, local",
>> "weight": 5
>> },
>> "LOCAL_FUZZY_DENIED": {
>> "description": "Denied fuzzy hash, local",
>> "weight": 12
>> }
>> },
>> "max_score": 20
>> }
>> },
>> "worker": [
>> {
>> "fuzzy": {
>> "backend": "redis",
>> "expire": 15552000,
>> "sync": 60,
>> "allow_update": "127.0.0.1, [::1]",
>> "db": "2",
>> "enabled": true,
>> "bind_socket": "localhost:11335",
>> "count": 2
>> }
>> }
>> ],
>> "milter_headers": {
>> "extended_spam_headers": true,
>> "use": [
>> "x-spamd-bar",
>> "x-spam-level",
>> "authentication-results",
>> "x-spamd-result",
>> "x-rspamd-server",
>> "x-rspamd-queue-id",
>> "fuzzy-hashes",
>> "stat-signature"
>> ],
>> "routines": {
>> "fuzzy-hashes": {
>> "header": "X-Rspamd-Fuzzy"
>> },
>> }
>> },
>> "options": {
>> "filters": "chartable,dkim,spf,surbl,regexp,fuzzy_check",
>> }
>> 
>> 
>> 
>> Am 6. März 2019 17:23:26 MEZ schrieb Alex JOST
><jost+lists at dimejo.at>:
>> 
>>     Am 06.03.2019 um 16:50 schrieb Florian Ruhnke:
>> 
>>         Moin,
>> 
>>         ich habe da mal eine Frage zu fuzzy_check, vielleicht ist das
>>         auch ein Verständnisproblem.
>> 
>>         Soweit ich die Config verstanden habe, soll bei einem
>>         "neutralen" resp. unbekannten Ergebnis das Symbol
>>         "FUZZY_UNKNOWN" geliefert werden. Bei meiner Config wird aber
>>         nix geliefert.
>>         Definiert sind der Standardserver rspamd.com und ein lokaler
>Server.
>> 
>>         Hin und wieder wird eine angelernte Adresse mit
>>         "LOCAL_FUZZY_WHITE" gemeldet, aber auch nicht immer.
>>         Was mich auch irritiert ist, dass absolute Müllmails nicht
>mal
>>         von rspamd.com ein denied bekommen, oder wenigstens ein prob.
>> 
>>         In der logging.inc habe ich Debug auf fuzzy_backend,
>fuzzy_check
>>         und fuzzy_process_handler, aber bei einer ankommenden Mail
>>         taucht nix mit Fuzzy im log auf.
>>         Wenn ich manuell das Spam-Postfach anlernen will, überschlägt
>>         sich das log mit "no content to generate fuzzy", was ich auch
>>         nicht nachvollziehen kann...
>> 
>> 
>>     Klingt mal so, als ob es nicht genug Inhalt zum Bewerten gäbe.
>Wie groß 
>>     bzw. lang sind denn die E-Mails und was hast Du bei 'min_length'
>und 
>>     'min_bytes' gesetzt?
>> 
>> 
>>         Falls meine config hilft, schieb ich die hier gern rein (dann
>>         als Anlage oder im Text?)
>> 
>> 
>>     Konfiguration kann nie schaden :)
>> 
>>     	rspamadm configdump fuzzy_check
>> 
>> 
>> -- 
>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190314/314087a0/attachment.htm>

From django at nausch.org  Thu Mar 14 14:05:59 2019
From: django at nausch.org (Django)
Date: Thu, 14 Mar 2019 14:05:59 +0100
Subject: Dovecot submission
In-Reply-To: <1848148.X89xbDbk2M@techz>
References: <1848148.X89xbDbk2M@techz>
Message-ID: <f662b15a-12d9-8c5d-bc20-48254c24864c@nausch.org>

HI!

On 14.03.19 13:12, Günther J. Niederwimmer wrote:

> Ich habe von Peer gelernt das das ganze für Handy von Vorteil sein sollte aber 
> wie man das konfiguriert finde ich nicht!

Nun ja, ich würde mich immr an so einer Übersicht[1] orientieren und dem
MDA das tun lassen was er am besten kann und dem MTA  entsprechend
unterschiedlich konfigurieren, so dass MTA-MTA Trafffic on-the-fly ggf.
entschlüsselt und gescannt wird, bevor die Mail final angenommen wird.

Den eigenen bekannten Usern spendiert man IMHO am besten Port 587
(Submission) und scannt dann später erst nach Annahme der Mail.


jm2ct
Django

[1]
https://dokuwiki.nausch.org/doku.php/centos:mail_c7:mta_1#uebersichtsskizze


From tom-postfixbuch at tom.bn-ulm.de  Thu Mar 14 19:12:10 2019
From: tom-postfixbuch at tom.bn-ulm.de (Thomas Wagner)
Date: Thu, 14 Mar 2019 19:12:10 +0100
Subject: UTF-8 Problem mit HEINLEIN Spamassassin Rules?
In-Reply-To: <b39af2cb-2710-63c6-9eef-cdba29d99b94@ee.ethz.ch>
References: <b39af2cb-2710-63c6-9eef-cdba29d99b94@ee.ethz.ch>
Message-ID: <20190314181210.GF20387@wagner-net.com>

At least this patch eliminates the warning.
To be checked is now, do the resulting files written still work
propperly?
If someone wants to do a run without and then with the patch.
Then check the diff of the files "scanner<number>.re"

======
inspired by
https://stackoverflow.com/questions/47940662/how-to-get-rid-of-wide-character-in-print-at


--- /usr/bin/sa-compile.old    Fr. Okt  5 20:20:25 2018
+++ /usr/bin/sa-compile Do. Mär 14 16:40:41 2019
@@ -394,6 +394,8 @@
     open(my $re, ">scanner${numscans}.re")
       or die "cannot create scanner${numscans}.re: $!";

+    binmode($re, "encoding(UTF-8)");
+
     print $re <<EOT  or die "error writing: $!";
 #define NULL            ((char*) 0)
 #define YYCTYPE         unsigned char
======

Thomas

On Thu, Mar 14, 2019 at 10:38:53AM +0100, Matthias Egger wrote:
> Hallo Liste, Hallo Peer
> 
> Wir kriegen seit einigen Tagen (genauer seit dem 10.3.2019) jeweils beim
> kompilieren der Rules mittels sa-compile eine Fehlermeldung:
> 
> ---
> Wide character in print at /usr/bin/sa-compile line 433, <$fh> line 2408.
> ---
> 
> Schuld daran scheint die folgende Heinlein Datei zu sein:
> 
> ---
> spamassassin_heinlein-support_de/70_HS_body.cf
> ---
> 
> Es gab da anscheinend schon einmal Probleme mit der Heinlein Liste im
> letzten November. Im damaligen Bug schrieb diesen Februar Henrik Krohns:
> 
> "Well if Heinlein is reading this, do not use UTF8 in rule files. That's
> the most simple fix."
> 
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7645#c12
> 
> Wenn man bei den normalen SA Rules schaut sind die meisten Files
> entweder "ASCII" oder "ISO-8859":
> 
>      58 ASCII
>       1 data
>       2 empty
>       1 HTML
>       6 ISO-8859
> 
> Bei Heinlein:
>      2 ASCII
>      2 UTF-8
> 
> So auch eben die:
> 
> spamassassin_heinlein-support_de/70_HS_body.cf: UTF-8 Unicode text, with
> overstriking
> 
> gibt es irgend einen Workaround den man machen kann bis heinlein die
> Listen fixen (wenn überhaupt?)?
> 
> An einer veralteten SA Version unsererseits kann es eigentlich auch
> nicht liegen:
> 
> ---
> SpamAssassin version 3.4.2
>   running on Perl version 5.24.1
> ---
> 
> Lieber Gruss
> Matthias
> 
> -- 
> Matthias Egger
> ETH Zurich
> Department of Information Technology          maegger at ee.ethz.ch
> and Electrical Engineering
> IT Support Group (ISG.EE), ETF/D/102          Phone +41 (0)44 632 03 90
> Sternwartstrasse 7, CH-8092 Zurich            Fax   +41 (0)44 632 11 95
> 



-- 

------------------------------------------------------------------------
New Work!
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Windows(TM)                   TEL: +49-7340-919196, FAX: +49-731-9807711
VoIP, Netzwerke,              MOBILE/CELL: +49-175-2926064
Internet-Security             EMAIL: wagner at wagner-net.com


From p.heinlein at heinlein-support.de  Fri Mar 15 08:47:26 2019
From: p.heinlein at heinlein-support.de (Peer Heinlein)
Date: Fri, 15 Mar 2019 08:47:26 +0100
Subject: UTF-8 Problem mit HEINLEIN Spamassassin Rules?
In-Reply-To: <b39af2cb-2710-63c6-9eef-cdba29d99b94@ee.ethz.ch>
References: <b39af2cb-2710-63c6-9eef-cdba29d99b94@ee.ethz.ch>
Message-ID: <43bea4b8-30b3-ccb5-97c7-8158d32cd0c8@heinlein-support.de>

Am 14.03.19 um 10:38 schrieb Matthias Egger:
> "Well if Heinlein is reading this, do not use UTF8 in rule files. That's
> the most simple fix."

Ich habe die Regel eben wieder rausgenommen.


Aber: Die Spam-Mails HATTEN eben UTF-8 hier im Subject. Hatten sie halt.
"Isso".


Ich muß mal rauskriegen, wie SA sich vorstellt, daß man das dann filtern
können sollund/oder ob das dann am Ende nicht geht soll?


Peer




From maegger at ee.ethz.ch  Fri Mar 15 16:04:01 2019
From: maegger at ee.ethz.ch (Matthias Egger)
Date: Fri, 15 Mar 2019 16:04:01 +0100
Subject: UTF-8 Problem mit HEINLEIN Spamassassin Rules?
In-Reply-To: <20190314181210.GF20387@wagner-net.com>
References: <b39af2cb-2710-63c6-9eef-cdba29d99b94@ee.ethz.ch>
 <20190314181210.GF20387@wagner-net.com>
Message-ID: <95819864-b1d8-97d7-9099-2d9a7c45cfe1@ee.ethz.ch>

Hallo Thomas,

On 14.03.19 19:12, Thomas Wagner wrote:
> At least this patch eliminates the warning.
> To be checked is now, do the resulting files written still work
> propperly?
> If someone wants to do a run without and then with the patch.
> Then check the diff of the files "scanner<number>.re"
> 
> ======
> inspired by
> https://stackoverflow.com/questions/47940662/how-to-get-rid-of-wide-character-in-print-at
> 
> 
> --- /usr/bin/sa-compile.old    Fr. Okt  5 20:20:25 2018
> +++ /usr/bin/sa-compile Do. Mär 14 16:40:41 2019
> @@ -394,6 +394,8 @@
>      open(my $re, ">scanner${numscans}.re")
>        or die "cannot create scanner${numscans}.re: $!";
> 
> +    binmode($re, "encoding(UTF-8)");
> +
>      print $re <<EOT  or die "error writing: $!";
>  #define NULL            ((char*) 0)
>  #define YYCTYPE         unsigned char
> ======

Danke! Muss nächste Woche mal schauen, wie ich das am gescheitesten
mache um Debian nicht aus dem Tritt zu bringen, falls es updates gibt.

Aber werde ich definitiv mal anschauen:

Lieber Gruss
Matthias

-- 
Matthias Egger
ETH Zurich
Department of Information Technology          maegger at ee.ethz.ch
and Electrical Engineering
IT Support Group (ISG.EE), ETF/D/102          Phone +41 (0)44 632 03 90
Sternwartstrasse 7, CH-8092 Zurich            Fax   +41 (0)44 632 11 95

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 3990 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190315/c5d20c65/attachment.p7s>

From vitali at quiering.com  Fri Mar 15 16:06:42 2019
From: vitali at quiering.com (Vitali Quiering)
Date: Fri, 15 Mar 2019 16:06:42 +0100
Subject: Problem mit address verification, virtual_aliases und mydestination
 hinter NAT
Message-ID: <80A622D7-C9D5-4583-BE10-3D80C69F2FD0@quiering.com>

Moin,

ich habe hier ein Problem dem ich noch nicht auf die Schliche kommen konnte. Vielleicht hat von euch ja jemand eine Idee.

Beschreibung meines Setups
Wir haben in einem RZ eine große Groupware als zentrale E-Mail Lösung mit sehr vielen Domains. Außerhalb des RZ betreiben wir eine Menge Mailserver mit klassischem Dovecot, Postfix, AMaViS Geraffel. Der Postfix setzt unter bestimmten Umständen den Transport in Richtung der Groupware was überwiegend Mails für schlagende Herzen sind. Auf den Mailservern selbst bleiben Mails liegen die bspw. maschinell abgeholt und verarbeitet werden.

Ich habe hierfür transport_maps genutzt.

mysql-transport-maps.cf
> SELECT COALESCE(
>   (
>         SELECT 'dovecot' FROM virtual_users
>         LEFT JOIN virtual_domains ON virtual_users.domain_id = virtual_domains.id
>         WHERE concat(virtual_users.user,'@',virtual_domains.name) = '%s' LIMIT 1 ),
>   (
>         SELECT 'smtp' FROM virtual_aliases
>         LEFT JOIN virtual_domains ON virtual_aliases.domain_id = virtual_domains.id
>         WHERE concat(virtual_aliases.source,'@',virtual_domains.name) = '%s' LIMIT 1),
>   (
>         SELECT 'local' FROM virtual_domains
>         WHERE 'localhost' = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>   (
>         SELECT 'smtp:[ip.adresse.der.groupware]:25' FROM virtual_domains
>         WHERE name = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>         'smtp') AS user;


Das funktionierte wunderbar, bis wir einige der externen Mailserver in unser RZ geholt haben.

Jetzt habe ich das Problem festgestellt, dass bei einem Alias smtp als transport verwendet wird. Eigenartigerweise wird mydestination nicht respektiert bzw. die virtual_domains. Es wird also, um die Adresse des Empfängers (Alias) zu überprüfen, eine SMTP Verbindung zu der öffentlichen IP des Mailserver hergestellt die dann wieder auf dem Mailserver selbst endet. Dies resultiert in der Meldung die wir alle lieben ?greeted me with my own hostname?.

Auf den externen Mailserver und im RZ läuft die Version 3.1.8-0+deb9u1.

Log des fehlgeschlagenen Versuches bei dem Server im RZ
> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: CONNECT from [ip.adresse.des.versenders]:38170 to [10.0.0.11]:25
> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: PASS OLD [ip.adresse.des.versenders]:38170
> Mar 15 15:28:53 mx-local postfix/smtpd[112664]: connect from mx.example.com[ip.adresse.des.versenders]
> Mar 15 15:28:54 mx-local postfix/smtpd[112664]: 15B023FDF5: client=mx.example.com[ip.adresse.des.versenders]
> Mar 15 15:28:54 mx-local postfix/cleanup[112670]: 15B023FDF5: message-id=<8529D5D9-70FE-41A4-9187-A2259D35269A at example.com>
> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5: from=<user1 at example.com>, size=2351, nrcpt=1 (queue active)
> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: CONNECT from [10.0.0.1]:36536 to [10.0.0.11]:25
> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: PASS OLD [10.0.0.1]:36536
> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: connect from unknown[10.0.0.1]
> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host mx.example.net[externe.ip.des.servers]:25 greeted me with my own hostname mx.example.net
> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host mx.example.net[externe.ip.des.servers]:25 replied to HELO/EHLO with my own hostname mx.example.net
> Mar 15 15:28:55 mx-local postfix/smtp[112671]: 15B023FDF5: to=<user2 at example.net>, relay=mx.example.net[externe.ip.des.servers]:25, delay=1.8, delays=1.7/0.01/0.13/0, dsn=5.4.6, status=bounced (mail for example.net loops back to myself)
> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from unknown[10.0.0.1] ehlo=1 quit=1 commands=2
> Mar 15 15:28:55 mx-local postfix/cleanup[112670]: C302F3FFDA: message-id=<20190315142855.C302F3FFDA at mx.example.net>
> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: C302F3FFDA: from=<>, size=4707, nrcpt=1 (queue active)
> Mar 15 15:28:55 mx-local postfix/bounce[112676]: 15B023FDF5: sender non-delivery notification: C302F3FFDA
> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5: removed
> Mar 15 15:28:56 mx-local postfix/smtp[112671]: C302F3FFDA: to=<user1 at example.com>, relay=mx.example.com[ip.adresse.des.versenders]:25, delay=0.22, delays=0.01/0/0.14/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as E9ABCD840A5)
> Mar 15 15:28:56 mx-local postfix/qmgr[112638]: C302F3FFDA: removed


Log des erfolgreichen Versuches bei dem Server außerhalb des RZ
> Mar 15 15:46:05 mx postfix/postscreen[27628]: CONNECT from [ip.adresse.des.versenders]:37494 to [ip.adresse.des.empfaengers]:25
> Mar 15 15:46:05 mx postfix/postscreen[27628]: PASS OLD [ip.adresse.des.versenders]:37494
> Mar 15 15:46:05 mx postfix/smtpd[27629]: connect from mx.example.com[ip.adresse.des.versenders]
> Mar 15 15:46:05 mx postfix/smtpd[27629]: 9F28D5F824: client=mx.example.com[ip.adresse.des.versenders]
> Mar 15 15:46:05 mx postfix/cleanup[27634]: 9F28D5F824: message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824: from=<user1 at example.com>, size=2390, nrcpt=1 (queue active)
> Mar 15 15:46:05 mx postfix/smtpd[27629]: disconnect from mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
> Mar 15 15:46:05 mx postfix/smtpd[27638]: connect from localhost[127.0.0.1]
> Mar 15 15:46:05 mx postfix/smtpd[27638]: B5D675F83B: client=localhost[127.0.0.1]
> Mar 15 15:46:05 mx postfix/cleanup[27634]: B5D675F83B: message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B: from=<user1 at example.com>, size=1497, nrcpt=1 (queue active)
> Mar 15 15:46:05 mx postfix/smtpd[27638]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
> Mar 15 15:46:05 mx amavis[28645]: (28645-20) Passed CLEAN {RelayedOpenRelay}, [ip.adresse.des.versenders]:37494 [ip.adresse.des.versenders] <user1 at example.com> -> <alias1 at example.org>, Queue-ID: 9F28D5F824, Message-ID: <D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>, mail_id: AEkFq9VYyvTL, Hits: -, size: 1226, queued_as: B5D675F83B, 78 ms
> Mar 15 15:46:05 mx postfix/smtp[27635]: 9F28D5F824: to=<alias1 at example.org>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.11, delays=0.03/0/0/0.08, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B5D675F83B)
> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824: removed
> Mar 15 15:46:05 mx postfix/smtp[27639]: B5D675F83B: to=<user2 at alias.example.org>, orig_to=<alias1 at example.org>, relay=alias.example.org[ip.ip.ip.ip]:25, delay=0.1, delays=0.01/0/0.07/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as CAEA45F87A)
> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B: removed


Zu guter Letzt noch meine postconf
> address_verify_sender = double-bounce at mx.example.net
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> amavisd_milter = inet:10.0.1.10:8899
> append_dot_mydomain = no
> biff = no
> bounce_queue_lifetime = 3d
> broken_sasl_auth_clients = yes
> disable_vrfy_command = yes
> dovecot_destination_recipient_limit = 1
> inet_interfaces = all
> inet_protocols = ipv4
> local_destination_concurrency_limit = 20
> mailbox_size_limit = 0
> maximal_queue_lifetime = 3d
> message_size_limit = 500000000
> milter_default_action = accept
> milter_protocol = 2
> mydestination = $myhostname, localhost.$mydomain, localhost
> myhostname = mx.example.net
> mynetworks = 127.0.0.0/8 10.0.2.10 10.0.2.1 10.0.2.2 10.0.2.3 10.0.2.4
> myorigin = /etc/mailname
> non_smtpd_milters = inet:localhost:8891
> postscreen_access_list = permit_mynetworks
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*2 bl.spamcop.net spam.dnsbl.sorbs.net=127.0.0.6
> postscreen_dnsbl_threshold = 3
> postscreen_greet_action = enforce
> readme_directory = no
> receive_override_options = no_address_mappings
> recipient_delimiter = +
> relayhost =
> smtp_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
> smtp_mime_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
> smtp_tls_security_level = may
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_pipelining reject_rbl_client bl.spamcop.net
> smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_access.cidr
> smtpd_enforce_tls = yes
> smtpd_milters = inet:localhost:8891
> smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_unknown_recipient_domain,reject_unverified_recipient
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_authenticated_header = yes
> smtpd_sasl_path = private/auth
> smtpd_sasl_type = dovecot
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/letsencrypt/live/mx.example.net/fullchain.pem
> smtpd_tls_key_file = /etc/letsencrypt/live/mx.example.net/privkey.pem
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 , RC4
> smtpd_tls_mandatory_protocols = SSLv3, TLSv1
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> transport_maps = mysql:/etc/postfix/mysql-transport-maps.cf
> unverified_recipient_reject_code = 550
> unverified_recipient_reject_reason = 'Recipient address rejected'
> virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
> virtual_gid_maps = static:5000
> virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
> virtual_uid_maps = static:5000


Meine Fragen
1. Warum wird überhaupt eine smtp Verbindung aufgebaut, wenn ich die Domain doch in den virtual_domains definiert habe?
2. Warum verhält sich Postfix korrekt, wenn die externe IP dem System bekannt ist?
3. Wie kann ich virtual_aliases wieder korrekt nutzen?

Vielen Dank für alle die bis hier gelesen haben und vorab auch vielen Dank für eure Hilfe.

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

From maegger at ee.ethz.ch  Fri Mar 15 16:14:48 2019
From: maegger at ee.ethz.ch (Matthias Egger)
Date: Fri, 15 Mar 2019 16:14:48 +0100
Subject: UTF-8 Problem mit HEINLEIN Spamassassin Rules?
In-Reply-To: <43bea4b8-30b3-ccb5-97c7-8158d32cd0c8@heinlein-support.de>
References: <b39af2cb-2710-63c6-9eef-cdba29d99b94@ee.ethz.ch>
 <43bea4b8-30b3-ccb5-97c7-8158d32cd0c8@heinlein-support.de>
Message-ID: <2f6082f3-8dfc-4bc8-3f26-13e3cab643f0@ee.ethz.ch>

Hallo Peer,

On 15.03.19 08:47, Peer Heinlein wrote:
> Am 14.03.19 um 10:38 schrieb Matthias Egger:
>> "Well if Heinlein is reading this, do not use UTF8 in rule files. That's
>> the most simple fix."
> 
> Ich habe die Regel eben wieder rausgenommen.
Danke.. aber.. hmm:

# UPDATE version 1617

[...]
cd /tmp/.spamassassin158408w1LyOgtmp
reading bases_body_0.in
cd Mail-SpamAssassin-CompiledRegexps-body_0
Wide character in print at /usr/bin/sa-compile line 433, <$fh> line 2408.
[...]

Ist das in einer neueren Version herausgelöscht?

Wenn ich kurzfristig in der "spamassassin_heinlein-support_de.cf" den
70_HS_body.cf auskommentiere:

---
# UPDATE version 1617
include spamassassin_heinlein-support_de/20_blatspammer.cf
#include spamassassin_heinlein-support_de/70_HS_body.cf
include spamassassin_heinlein-support_de/70_HS_header.cf
---

dann rennt das ganze durch...
[...]
cd /tmp/.spamassassin159154pAe3wttmp
reading bases_body_0.in
cd Mail-SpamAssassin-CompiledRegexps-body_0
re2c -i -b -o scanner1.c scanner1.re
[...]


> Aber: Die Spam-Mails HATTEN eben UTF-8 hier im Subject. Hatten sie halt.
> "Isso".
> 
> Ich muß mal rauskriegen, wie SA sich vorstellt, daß man das dann filtern
> können sollund/oder ob das dann am Ende nicht geht soll?
Müsste eigentlich... was machen denn all die Polen etc. mit diesen
Sonderzeichen... dürfen die dann nicht filtern?

http://spamassassin.1065346.n5.nabble.com/UTF8-character-in-doesn-t-match-td154199.html

Hast du vielleicht einen Tipp wie man rausfindet WELCHE Rule denn
überhaupt der Täter ist?

Lieber Gruss
Matthias

-- 
Matthias Egger
ETH Zurich
Department of Information Technology          maegger at ee.ethz.ch
and Electrical Engineering
IT Support Group (ISG.EE), ETF/D/102          Phone +41 (0)44 632 03 90
Sternwartstrasse 7, CH-8092 Zurich            Fax   +41 (0)44 632 11 95

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 3990 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190315/9c243db7/attachment.p7s>

From andreas.schulze at datev.de  Mon Mar 18 09:14:37 2019
From: andreas.schulze at datev.de (Andreas Schulze)
Date: Mon, 18 Mar 2019 09:14:37 +0100
Subject: client-initiated renegotiation
In-Reply-To: <4026433.EgiES5BvD9@techz>
References: <5394512.hO18LxbE1l@techz>
 <f8a8ec30-a817-cb15-56ac-29a76f280b19@datev.de>
 <7D5B038C-A3B6-49A2-B641-519532D2967E@neessen.net> <4026433.EgiES5BvD9@techz>
Message-ID: <e406760d-d934-9e73-b875-8096ac5cb218@datev.de>

Am 14.03.19 um 12:50 schrieb Günther J. Niederwimmer:
> Hallo,
> 
> Am Donnerstag, 14. März 2019, 08:51:05 CET schrieb Winfried Neessen:
>> Hi,
>>
>> On 14. Mar 2019, at 08:19, Andreas Schulze <andreas.schulze at datev.de> wrote:
>>> Wie man das ausschaltet muss ich auch gerade passen. Ich vermute aber
>>> ebenfalls, via tls_ssl_options.
>> Mir ist keine SSL_option bekannt, die nur Client initiierte TLS
>> renegotiation ausschaltet. M. W. n. gibt es nur "SSL_OP_NO_RENEGOTIATION"
>> um TLS renegotiation komplett zu deaktivieren. Generell bringt das eh nur
>> einen Geschwindigkeitsvorteil, wenn man Verbindungen hat, die weite
>> Strecken (sprich hoher Roundtrip) hinter sich gelegt haben.
>>
>> Mit aktueller Hardware halte ich den DoS Vektor aber auch fuer ueberschaubar
>> (acceptable risk).
> 
> Ich hatte von dem "Problem" bis jetzt nirgends gelesen, bis ich auf dieser 
> Testseite darauf hingewiesen wurde ?
weder hardenize.com noch ssllabs bemängeln client initiated renegioation,
für ssllabs muss man einen smtp-server auf port 443 legen und mit
  -o smtpd_tls_security_level=encrypt" sowie
  -o smtpd_tls_wrappermode=on
starten

> Also Ihr meint man kann es vernachlässigen ?
insofern: Ball flachhalten oder auf der engl. postfix-users ML nachfragen...

> Was ich noch nicht gefunden habe ist der Sinn / Unsinn diese Parameters 
> worüber ich beim suchen gestolpert bin?
> 
> smtpd_client_new_tls_session_rate_limit = 0
Das ist meines Erachtens nur ein Limit für neue TLS-Verbindungen incl komplettem TCP Handshake

> das ist die Grundeinstellung in postfix, hat der überhaupt was mit dem obigen 
> Fall zu tun?
> 
> Oder sollte man da einen Wert setzen zb. = 100
kann man machen, wenn man weis was man tut.


-- 
A. Schulze
DATEV eG


From bjo at nord-west.org  Mon Mar 18 12:54:49 2019
From: bjo at nord-west.org (Bjoern Franke)
Date: Mon, 18 Mar 2019 12:54:49 +0100
Subject: rspamd: DKIM double signing
Message-ID: <d74cf0be-eb70-ffc4-8bb8-f17f360a02ed@nord-west.org>

Moin,

rspamd 1.9.0 kann ja nun Ed25519 für DKIM verwenden, leider anscheinend
aber auch nur rspamd. Hat schon jemand ein Setup hinbekommen, sowohl
Ed25519 als auch RSA gleichzeitig zu nutzen?

Meine Versuche, beide Keys jeweils einzubinden, mochte rspamd jedenfalls
nicht.

VG
Björn


From andre.peters at debinux.de  Mon Mar 18 13:10:33 2019
From: andre.peters at debinux.de (=?utf-8?q?Andr=c3=a9=20Peters?=)
Date: Mon, 18 Mar 2019 12:10:33 +0000
Subject: rspamd: DKIM double signing
In-Reply-To: <d74cf0be-eb70-ffc4-8bb8-f17f360a02ed@nord-west.org>
References: <d74cf0be-eb70-ffc4-8bb8-f17f360a02ed@nord-west.org>
Message-ID: <emfca2a4cb-20b9-4873-93ff-1ac0a65a9c53@desktop-hq5fffq>

Hi Björn,

so sollte es funktionieren:

https://github.com/rspamd/rspamd/blob/master/test/functional/configs/dkim_signing/milter.conf#L50

Viele Grüße
André

------ Originalnachricht ------
Von: "Bjoern Franke" <bjo at nord-west.org>
An: postfixbuch-users at listen.jpberlin.de
Gesendet: 18.03.2019 12:54:49
Betreff: rspamd: DKIM double signing

>Moin,
>
>rspamd 1.9.0 kann ja nun Ed25519 für DKIM verwenden, leider anscheinend
>aber auch nur rspamd. Hat schon jemand ein Setup hinbekommen, sowohl
>Ed25519 als auch RSA gleichzeitig zu nutzen?
>
>Meine Versuche, beide Keys jeweils einzubinden, mochte rspamd jedenfalls
>nicht.
>
>VG
>Björn
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20190318/4ab0725d/attachment.htm>

From bjo at nord-west.org  Mon Mar 18 16:18:55 2019
From: bjo at nord-west.org (Bjoern Franke)
Date: Mon, 18 Mar 2019 16:18:55 +0100
Subject: rspamd: DKIM double signing
In-Reply-To: <emfca2a4cb-20b9-4873-93ff-1ac0a65a9c53@desktop-hq5fffq>
References: <d74cf0be-eb70-ffc4-8bb8-f17f360a02ed@nord-west.org>
 <emfca2a4cb-20b9-4873-93ff-1ac0a65a9c53@desktop-hq5fffq>
Message-ID: <360f574d-a934-292f-3a4d-b9a0016375f9@nord-west.org>

Moin André,
> 
> so sollte es funktionieren:
> 
> https://github.com/rspamd/rspamd/blob/master/test/functional/configs/dkim_signing/milter.conf#L50

leider klappt es nicht.

Sowohl mit Default "path = "/etc/dkim/$domain.$selector.key"" als auch
mit explizit gesetztem Pfad beschwert rspamd sich, dass er nicht
"/etc/dkim/nord-west.org.dkim.key" findet, obwohl selector auf "default"
gesetzt ist.

Wahrscheinlich dann doch mal ein Fall für die rspamd-Liste.

Auf jeden Fall aber Danke fürs raussuchen ;)

Grüße
Björn


From cr at ncxs.de  Mon Mar 18 17:59:38 2019
From: cr at ncxs.de (Carsten Rosenberg)
Date: Mon, 18 Mar 2019 17:59:38 +0100
Subject: rspamd: DKIM double signing
In-Reply-To: <360f574d-a934-292f-3a4d-b9a0016375f9@nord-west.org>
References: <d74cf0be-eb70-ffc4-8bb8-f17f360a02ed@nord-west.org>
 <emfca2a4cb-20b9-4873-93ff-1ac0a65a9c53@desktop-hq5fffq>
 <360f574d-a934-292f-3a4d-b9a0016375f9@nord-west.org>
Message-ID: <82d00bda-9301-7ca0-525f-888872a89e6f@ncxs.de>

Hey,

der Test hat da scheinbar einen Syntax-Fehler. In der
modules.d/dkim_signing.conf ist ein funktionierendes Beispiel:

# Domain specific settings
domain {
  example.com {
    selectors [
      { # Private key path
        path = "/var/lib/rspamd/dkim/example.key";
       Selector
        selector = "ds";
      },
      { # multiple dkim signature
        path = "/var/lib/rspamd/dkim/eddsa.key";
        selector = "eddsa";
      }
    ]
  }
}


Authentication-Results: (amavisd-new);
  dkim=pass (2048-bit key) header.d=ncxs.de header.b=eiZnZc3b;
  dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)"
  header.d=ncxs.de header.b=jwkSt2oR

Das neutral könnte einem bei "doofen" Mailservern aber auch auf die Nase
fallen. Ich teste das auch gerade.
--

Viele Grüße

Carsten

On 18.03.19 16:18, Bjoern Franke wrote:
> Moin André,
>>
>> so sollte es funktionieren:
>>
>> https://github.com/rspamd/rspamd/blob/master/test/functional/configs/dkim_signing/milter.conf#L50
> 
> leider klappt es nicht.
> 
> Sowohl mit Default "path = "/etc/dkim/$domain.$selector.key"" als auch
> mit explizit gesetztem Pfad beschwert rspamd sich, dass er nicht
> "/etc/dkim/nord-west.org.dkim.key" findet, obwohl selector auf "default"
> gesetzt ist.
> 
> Wahrscheinlich dann doch mal ein Fall für die rspamd-Liste.
> 
> Auf jeden Fall aber Danke fürs raussuchen ;)
> 
> Grüße
> Björn
> 


From klaus at tachtler.net  Tue Mar 19 08:58:48 2019
From: klaus at tachtler.net (Klaus Tachtler)
Date: Tue, 19 Mar 2019 08:58:48 +0100
Subject: Problem mit address verification, virtual_aliases und
 mydestination hinter NAT
In-Reply-To: <80A622D7-C9D5-4583-BE10-3D80C69F2FD0@quiering.com>
Message-ID: <20190319085848.Horde.IWFfHxwVgq3cUe-0xpigjzs@buero.tachtler.net>

Hallo Vitali,

da Dein Setup doch etwas komplexer ist, ist das ganze nicht so einfach  
von der Ferne aus zu beurteilen. Was mir aber aufgefallen ist, und  
bitte das ist nur eine sehr wage Vermutung, dass ich in Deiner  
Konfiguration keine virtual_transport gesehen habe.

Ich habe für mich mal PosfixAdmin konfiguriert, was ebenfalls die  
Einträge für Domains, Mailboxen und Aliase usw. in einer Datenbank  
ablegt und dies für mich einmal dokumentiert.

https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_admin#virtual_transport

Evtl. ist dies eine Ansatz für eine Richtung in die Du weiter suchen kannst?


Grüße
Klaus.

> Moin,
>
> ich habe hier ein Problem dem ich noch nicht auf die Schliche kommen  
> konnte. Vielleicht hat von euch ja jemand eine Idee.
>
> Beschreibung meines Setups
> Wir haben in einem RZ eine große Groupware als zentrale E-Mail  
> Lösung mit sehr vielen Domains. Außerhalb des RZ betreiben wir eine  
> Menge Mailserver mit klassischem Dovecot, Postfix, AMaViS Geraffel.  
> Der Postfix setzt unter bestimmten Umständen den Transport in  
> Richtung der Groupware was überwiegend Mails für schlagende Herzen  
> sind. Auf den Mailservern selbst bleiben Mails liegen die bspw.  
> maschinell abgeholt und verarbeitet werden.
>
> Ich habe hierfür transport_maps genutzt.
>
> mysql-transport-maps.cf
>> SELECT COALESCE(
>>   (
>>         SELECT 'dovecot' FROM virtual_users
>>         LEFT JOIN virtual_domains ON virtual_users.domain_id =  
>> virtual_domains.id
>>         WHERE concat(virtual_users.user,'@',virtual_domains.name) =  
>> '%s' LIMIT 1 ),
>>   (
>>         SELECT 'smtp' FROM virtual_aliases
>>         LEFT JOIN virtual_domains ON virtual_aliases.domain_id =  
>> virtual_domains.id
>>         WHERE  
>> concat(virtual_aliases.source,'@',virtual_domains.name) = '%s'  
>> LIMIT 1),
>>   (
>>         SELECT 'local' FROM virtual_domains
>>         WHERE 'localhost' = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>>   (
>>         SELECT 'smtp:[ip.adresse.der.groupware]:25' FROM virtual_domains
>>         WHERE name = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>>         'smtp') AS user;
>
>
> Das funktionierte wunderbar, bis wir einige der externen Mailserver  
> in unser RZ geholt haben.
>
> Jetzt habe ich das Problem festgestellt, dass bei einem Alias smtp  
> als transport verwendet wird. Eigenartigerweise wird mydestination  
> nicht respektiert bzw. die virtual_domains. Es wird also, um die  
> Adresse des Empfängers (Alias) zu überprüfen, eine SMTP Verbindung  
> zu der öffentlichen IP des Mailserver hergestellt die dann wieder  
> auf dem Mailserver selbst endet. Dies resultiert in der Meldung die  
> wir alle lieben ?greeted me with my own hostname?.
>
> Auf den externen Mailserver und im RZ läuft die Version 3.1.8-0+deb9u1.
>
> Log des fehlgeschlagenen Versuches bei dem Server im RZ
>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: CONNECT from  
>> [ip.adresse.des.versenders]:38170 to [10.0.0.11]:25
>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: PASS OLD  
>> [ip.adresse.des.versenders]:38170
>> Mar 15 15:28:53 mx-local postfix/smtpd[112664]: connect from  
>> mx.example.com[ip.adresse.des.versenders]
>> Mar 15 15:28:54 mx-local postfix/smtpd[112664]: 15B023FDF5:  
>> client=mx.example.com[ip.adresse.des.versenders]
>> Mar 15 15:28:54 mx-local postfix/cleanup[112670]: 15B023FDF5:  
>> message-id=<8529D5D9-70FE-41A4-9187-A2259D35269A at example.com>
>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5:  
>> from=<user1 at example.com>, size=2351, nrcpt=1 (queue active)
>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: CONNECT from  
>> [10.0.0.1]:36536 to [10.0.0.11]:25
>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from  
>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1  
>> rcpt=1 data=1 quit=1 commands=7
>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: PASS OLD  
>> [10.0.0.1]:36536
>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: connect from  
>> unknown[10.0.0.1]
>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host  
>> mx.example.net[externe.ip.des.servers]:25 greeted me with my own  
>> hostname mx.example.net
>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host  
>> mx.example.net[externe.ip.des.servers]:25 replied to HELO/EHLO with  
>> my own hostname mx.example.net
>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: 15B023FDF5:  
>> to=<user2 at example.net>,  
>> relay=mx.example.net[externe.ip.des.servers]:25, delay=1.8,  
>> delays=1.7/0.01/0.13/0, dsn=5.4.6, status=bounced (mail for  
>> example.net loops back to myself)
>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from  
>> unknown[10.0.0.1] ehlo=1 quit=1 commands=2
>> Mar 15 15:28:55 mx-local postfix/cleanup[112670]: C302F3FFDA:  
>> message-id=<20190315142855.C302F3FFDA at mx.example.net>
>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: C302F3FFDA: from=<>,  
>> size=4707, nrcpt=1 (queue active)
>> Mar 15 15:28:55 mx-local postfix/bounce[112676]: 15B023FDF5: sender  
>> non-delivery notification: C302F3FFDA
>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5: removed
>> Mar 15 15:28:56 mx-local postfix/smtp[112671]: C302F3FFDA:  
>> to=<user1 at example.com>,  
>> relay=mx.example.com[ip.adresse.des.versenders]:25, delay=0.22,  
>> delays=0.01/0/0.14/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok:  
>> queued as E9ABCD840A5)
>> Mar 15 15:28:56 mx-local postfix/qmgr[112638]: C302F3FFDA: removed
>
>
> Log des erfolgreichen Versuches bei dem Server außerhalb des RZ
>> Mar 15 15:46:05 mx postfix/postscreen[27628]: CONNECT from  
>> [ip.adresse.des.versenders]:37494 to [ip.adresse.des.empfaengers]:25
>> Mar 15 15:46:05 mx postfix/postscreen[27628]: PASS OLD  
>> [ip.adresse.des.versenders]:37494
>> Mar 15 15:46:05 mx postfix/smtpd[27629]: connect from  
>> mx.example.com[ip.adresse.des.versenders]
>> Mar 15 15:46:05 mx postfix/smtpd[27629]: 9F28D5F824:  
>> client=mx.example.com[ip.adresse.des.versenders]
>> Mar 15 15:46:05 mx postfix/cleanup[27634]: 9F28D5F824:  
>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824:  
>> from=<user1 at example.com>, size=2390, nrcpt=1 (queue active)
>> Mar 15 15:46:05 mx postfix/smtpd[27629]: disconnect from  
>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1  
>> rcpt=1 data=1 quit=1 commands=7
>> Mar 15 15:46:05 mx postfix/smtpd[27638]: connect from localhost[127.0.0.1]
>> Mar 15 15:46:05 mx postfix/smtpd[27638]: B5D675F83B:  
>> client=localhost[127.0.0.1]
>> Mar 15 15:46:05 mx postfix/cleanup[27634]: B5D675F83B:  
>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B:  
>> from=<user1 at example.com>, size=1497, nrcpt=1 (queue active)
>> Mar 15 15:46:05 mx postfix/smtpd[27638]: disconnect from  
>> localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
>> Mar 15 15:46:05 mx amavis[28645]: (28645-20) Passed CLEAN  
>> {RelayedOpenRelay}, [ip.adresse.des.versenders]:37494  
>> [ip.adresse.des.versenders] <user1 at example.com> ->  
>> <alias1 at example.org>, Queue-ID: 9F28D5F824, Message-ID:  
>> <D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>, mail_id:  
>> AEkFq9VYyvTL, Hits: -, size: 1226, queued_as: B5D675F83B, 78 ms
>> Mar 15 15:46:05 mx postfix/smtp[27635]: 9F28D5F824:  
>> to=<alias1 at example.org>, relay=127.0.0.1[127.0.0.1]:10024,  
>> delay=0.11, delays=0.03/0/0/0.08, dsn=2.0.0, status=sent (250 2.0.0  
>> from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B5D675F83B)
>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824: removed
>> Mar 15 15:46:05 mx postfix/smtp[27639]: B5D675F83B:  
>> to=<user2 at alias.example.org>, orig_to=<alias1 at example.org>,  
>> relay=alias.example.org[ip.ip.ip.ip]:25, delay=0.1,  
>> delays=0.01/0/0.07/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok:  
>> queued as CAEA45F87A)
>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B: removed
>
>
> Zu guter Letzt noch meine postconf
>> address_verify_sender = double-bounce at mx.example.net
>> alias_database = hash:/etc/aliases
>> alias_maps = hash:/etc/aliases
>> amavisd_milter = inet:10.0.1.10:8899
>> append_dot_mydomain = no
>> biff = no
>> bounce_queue_lifetime = 3d
>> broken_sasl_auth_clients = yes
>> disable_vrfy_command = yes
>> dovecot_destination_recipient_limit = 1
>> inet_interfaces = all
>> inet_protocols = ipv4
>> local_destination_concurrency_limit = 20
>> mailbox_size_limit = 0
>> maximal_queue_lifetime = 3d
>> message_size_limit = 500000000
>> milter_default_action = accept
>> milter_protocol = 2
>> mydestination = $myhostname, localhost.$mydomain, localhost
>> myhostname = mx.example.net
>> mynetworks = 127.0.0.0/8 10.0.2.10 10.0.2.1 10.0.2.2 10.0.2.3 10.0.2.4
>> myorigin = /etc/mailname
>> non_smtpd_milters = inet:localhost:8891
>> postscreen_access_list = permit_mynetworks
>> postscreen_dnsbl_action = enforce
>> postscreen_dnsbl_sites = zen.spamhaus.org*3  
>> b.barracudacentral.org*2 bl.spamcop.net  
>> spam.dnsbl.sorbs.net=127.0.0.6
>> postscreen_dnsbl_threshold = 3
>> postscreen_greet_action = enforce
>> readme_directory = no
>> receive_override_options = no_address_mappings
>> recipient_delimiter = +
>> relayhost =
>> smtp_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>> smtp_mime_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>> smtp_tls_security_level = may
>> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
>> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
>> smtpd_client_restrictions = permit_mynetworks  
>> permit_sasl_authenticated reject_unauth_pipelining  
>> reject_rbl_client bl.spamcop.net
>> smtpd_discard_ehlo_keyword_address_maps =  
>> cidr:/etc/postfix/esmtp_access.cidr
>> smtpd_enforce_tls = yes
>> smtpd_milters = inet:localhost:8891
>> smtpd_recipient_restrictions =  
>> permit_mynetworks,permit_sasl_authenticated,reject_unknown_recipient_domain,reject_unverified_recipient
>> smtpd_sasl_auth_enable = yes
>> smtpd_sasl_authenticated_header = yes
>> smtpd_sasl_path = private/auth
>> smtpd_sasl_type = dovecot
>> smtpd_tls_auth_only = yes
>> smtpd_tls_cert_file = /etc/letsencrypt/live/mx.example.net/fullchain.pem
>> smtpd_tls_key_file = /etc/letsencrypt/live/mx.example.net/privkey.pem
>> smtpd_tls_mandatory_ciphers = high
>> smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 , RC4
>> smtpd_tls_mandatory_protocols = SSLv3, TLSv1
>> smtpd_tls_security_level = may
>> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>> transport_maps = mysql:/etc/postfix/mysql-transport-maps.cf
>> unverified_recipient_reject_code = 550
>> unverified_recipient_reject_reason = 'Recipient address rejected'
>> virtual_alias_maps =  
>> mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
>> virtual_gid_maps = static:5000
>> virtual_mailbox_domains =  
>> mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
>> virtual_uid_maps = static:5000
>
>
> Meine Fragen
> 1. Warum wird überhaupt eine smtp Verbindung aufgebaut, wenn ich die  
> Domain doch in den virtual_domains definiert habe?
> 2. Warum verhält sich Postfix korrekt, wenn die externe IP dem  
> System bekannt ist?
> 3. Wie kann ich virtual_aliases wieder korrekt nutzen?
>
> Vielen Dank für alle die bis hier gelesen haben und vorab auch  
> vielen Dank für eure Hilfe.
>
> Vitali


----- Ende der Nachricht von Vitali Quiering <vitali at quiering.com> -----



-- 

--------------------------------------------
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/20190319/abb0b483/attachment.skr>

From bjo at nord-west.org  Tue Mar 19 13:08:54 2019
From: bjo at nord-west.org (Bjoern Franke)
Date: Tue, 19 Mar 2019 13:08:54 +0100
Subject: rspamd: DKIM double signing
In-Reply-To: <82d00bda-9301-7ca0-525f-888872a89e6f@ncxs.de>
References: <d74cf0be-eb70-ffc4-8bb8-f17f360a02ed@nord-west.org>
 <emfca2a4cb-20b9-4873-93ff-1ac0a65a9c53@desktop-hq5fffq>
 <360f574d-a934-292f-3a4d-b9a0016375f9@nord-west.org>
 <82d00bda-9301-7ca0-525f-888872a89e6f@ncxs.de>
Message-ID: <55930b4d-ef0f-648d-cd69-f7b753ce34af@nord-west.org>

Moin Carsten,

> 
> der Test hat da scheinbar einen Syntax-Fehler. In der
> modules.d/dkim_signing.conf ist ein funktionierendes Beispiel:
> 

Dank für den Hinweis, funktioniert nun.

VG
Björn


From Hajo.Locke at gmx.de  Wed Mar 20 09:39:17 2019
From: Hajo.Locke at gmx.de (Hajo Locke)
Date: Wed, 20 Mar 2019 09:39:17 +0100
Subject: =?UTF-8?Q?nicht_existente_Empf=c3=a4nger_vor=c3=bcbergehend_sperren?=
Message-ID: <5d38fe1a-e62e-f228-ee3c-005260fe14b3@gmx.de>

Hallo Liste,

das folgende ist eher theoretischer Natur und wahrscheinlich nicht
sinnvoll umsetzbar. Eventuell gibt es aber ein paar Meinungen dazu.
Verschiedene Empfänger blocken die Annahme, wenn zu viele nicht
existente Empfänger angeschrieben werden. Unglücklicherweise passiert
das schon mal dem einen oder anderen Newsletterversender, wenn trotz
stetiger Hinweise veraltete Adressen verwendet wurden. t-online blockt
beispielsweise ab einer gewissen Schwelle jegliche Annahme und du hast
dann keine Unterscheidungsmöglichkeit mehr.
Ich hatte mir überlegt mit einer Art Dienst das maillog zu lesen und auf
diverse "user unknown" etc. zu reagieren und die Adressen dann über
check_recipient_access >reject direkt zu sperren, so dass nicht
existente Adressen nach und nach gefunden und verboten werden.  Damit
soll die Wahrscheinlichkeit eines kompletten Blocks bei diversen
Empfängern reduziert werden. Mir ist aber leider diesbezüglich nichts
fertiges bekannt und müsste wohl selber gebaut werden.  Weiteres Problem
ist sicherlich, dass nicht existente Adressen irgendwann womöglich mal
existent sind.
Naja, was meint Ihr dazu. Quark?

Danke,
Hajo


From vitali at quiering.com  Wed Mar 20 16:59:03 2019
From: vitali at quiering.com (Vitali Quiering)
Date: Wed, 20 Mar 2019 16:59:03 +0100
Subject: Problem mit address verification, virtual_aliases und
 mydestination hinter NAT
In-Reply-To: <20190319085848.Horde.IWFfHxwVgq3cUe-0xpigjzs@buero.tachtler.net>
References: <20190319085848.Horde.IWFfHxwVgq3cUe-0xpigjzs@buero.tachtler.net>
Message-ID: <96403FFC-C248-4E52-A7C9-C4DC9851B033@quiering.com>

Hallo Klaus,

vielen Dank. So etwas in der Art hatte ich mir schon gedacht. Leider komme ich an der Stelle überhaupt nicht weiter.

Aktuell habe ich smtpd_recipient_restrictions so angepasst, dass Aliases mit permit_auth_destination angenommen werden sollten (so zumindest mein Verständnis), es wird dennoch ein SMTP Probe an den MX mit der öffentlichen IP gemacht was in der Fehlermeldung endet. So als würde Postfix die Settings ignorieren.

smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,permit_auth_destination,reject_unknown_recipient_domain,reject_unverified_recipient

Gruß
Vitali

> Am 19.03.2019 um 08:58 schrieb Klaus Tachtler <klaus at tachtler.net>:
> 
> Hallo Vitali,
> 
> da Dein Setup doch etwas komplexer ist, ist das ganze nicht so einfach
> von der Ferne aus zu beurteilen. Was mir aber aufgefallen ist, und
> bitte das ist nur eine sehr wage Vermutung, dass ich in Deiner
> Konfiguration keine virtual_transport gesehen habe.
> 
> Ich habe für mich mal PosfixAdmin konfiguriert, was ebenfalls die
> Einträge für Domains, Mailboxen und Aliase usw. in einer Datenbank
> ablegt und dies für mich einmal dokumentiert.
> 
> https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_admin#virtual_transport
> 
> Evtl. ist dies eine Ansatz für eine Richtung in die Du weiter suchen kannst?
> 
> 
> Grüße
> Klaus.
> 
>> Moin,
>> 
>> ich habe hier ein Problem dem ich noch nicht auf die Schliche kommen
>> konnte. Vielleicht hat von euch ja jemand eine Idee.
>> 
>> Beschreibung meines Setups
>> Wir haben in einem RZ eine große Groupware als zentrale E-Mail
>> Lösung mit sehr vielen Domains. Außerhalb des RZ betreiben wir eine
>> Menge Mailserver mit klassischem Dovecot, Postfix, AMaViS Geraffel.
>> Der Postfix setzt unter bestimmten Umständen den Transport in
>> Richtung der Groupware was überwiegend Mails für schlagende Herzen
>> sind. Auf den Mailservern selbst bleiben Mails liegen die bspw.
>> maschinell abgeholt und verarbeitet werden.
>> 
>> Ich habe hierfür transport_maps genutzt.
>> 
>> mysql-transport-maps.cf
>>> SELECT COALESCE(
>>>  (
>>>        SELECT 'dovecot' FROM virtual_users
>>>        LEFT JOIN virtual_domains ON virtual_users.domain_id =
>>> virtual_domains.id
>>>        WHERE concat(virtual_users.user,'@',virtual_domains.name) =
>>> '%s' LIMIT 1 ),
>>>  (
>>>        SELECT 'smtp' FROM virtual_aliases
>>>        LEFT JOIN virtual_domains ON virtual_aliases.domain_id =
>>> virtual_domains.id
>>>        WHERE
>>> concat(virtual_aliases.source,'@',virtual_domains.name) = '%s'
>>> LIMIT 1),
>>>  (
>>>        SELECT 'local' FROM virtual_domains
>>>        WHERE 'localhost' = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>>>  (
>>>        SELECT 'smtp:[ip.adresse.der.groupware]:25' FROM virtual_domains
>>>        WHERE name = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>>>        'smtp') AS user;
>> 
>> 
>> Das funktionierte wunderbar, bis wir einige der externen Mailserver
>> in unser RZ geholt haben.
>> 
>> Jetzt habe ich das Problem festgestellt, dass bei einem Alias smtp
>> als transport verwendet wird. Eigenartigerweise wird mydestination
>> nicht respektiert bzw. die virtual_domains. Es wird also, um die
>> Adresse des Empfängers (Alias) zu überprüfen, eine SMTP Verbindung
>> zu der öffentlichen IP des Mailserver hergestellt die dann wieder
>> auf dem Mailserver selbst endet. Dies resultiert in der Meldung die
>> wir alle lieben ?greeted me with my own hostname?.
>> 
>> Auf den externen Mailserver und im RZ läuft die Version 3.1.8-0+deb9u1.
>> 
>> Log des fehlgeschlagenen Versuches bei dem Server im RZ
>>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: CONNECT from
>>> [ip.adresse.des.versenders]:38170 to [10.0.0.11]:25
>>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: PASS OLD
>>> [ip.adresse.des.versenders]:38170
>>> Mar 15 15:28:53 mx-local postfix/smtpd[112664]: connect from
>>> mx.example.com[ip.adresse.des.versenders]
>>> Mar 15 15:28:54 mx-local postfix/smtpd[112664]: 15B023FDF5:
>>> client=mx.example.com[ip.adresse.des.versenders]
>>> Mar 15 15:28:54 mx-local postfix/cleanup[112670]: 15B023FDF5:
>>> message-id=<8529D5D9-70FE-41A4-9187-A2259D35269A at example.com>
>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5:
>>> from=<user1 at example.com>, size=2351, nrcpt=1 (queue active)
>>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: CONNECT from
>>> [10.0.0.1]:36536 to [10.0.0.11]:25
>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from
>>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1
>>> rcpt=1 data=1 quit=1 commands=7
>>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: PASS OLD
>>> [10.0.0.1]:36536
>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: connect from
>>> unknown[10.0.0.1]
>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host
>>> mx.example.net[externe.ip.des.servers]:25 greeted me with my own
>>> hostname mx.example.net
>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host
>>> mx.example.net[externe.ip.des.servers]:25 replied to HELO/EHLO with
>>> my own hostname mx.example.net
>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: 15B023FDF5:
>>> to=<user2 at example.net>,
>>> relay=mx.example.net[externe.ip.des.servers]:25, delay=1.8,
>>> delays=1.7/0.01/0.13/0, dsn=5.4.6, status=bounced (mail for
>>> example.net loops back to myself)
>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from
>>> unknown[10.0.0.1] ehlo=1 quit=1 commands=2
>>> Mar 15 15:28:55 mx-local postfix/cleanup[112670]: C302F3FFDA:
>>> message-id=<20190315142855.C302F3FFDA at mx.example.net>
>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: C302F3FFDA: from=<>,
>>> size=4707, nrcpt=1 (queue active)
>>> Mar 15 15:28:55 mx-local postfix/bounce[112676]: 15B023FDF5: sender
>>> non-delivery notification: C302F3FFDA
>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5: removed
>>> Mar 15 15:28:56 mx-local postfix/smtp[112671]: C302F3FFDA:
>>> to=<user1 at example.com>,
>>> relay=mx.example.com[ip.adresse.des.versenders]:25, delay=0.22,
>>> delays=0.01/0/0.14/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok:
>>> queued as E9ABCD840A5)
>>> Mar 15 15:28:56 mx-local postfix/qmgr[112638]: C302F3FFDA: removed
>> 
>> 
>> Log des erfolgreichen Versuches bei dem Server außerhalb des RZ
>>> Mar 15 15:46:05 mx postfix/postscreen[27628]: CONNECT from
>>> [ip.adresse.des.versenders]:37494 to [ip.adresse.des.empfaengers]:25
>>> Mar 15 15:46:05 mx postfix/postscreen[27628]: PASS OLD
>>> [ip.adresse.des.versenders]:37494
>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: connect from
>>> mx.example.com[ip.adresse.des.versenders]
>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: 9F28D5F824:
>>> client=mx.example.com[ip.adresse.des.versenders]
>>> Mar 15 15:46:05 mx postfix/cleanup[27634]: 9F28D5F824:
>>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824:
>>> from=<user1 at example.com>, size=2390, nrcpt=1 (queue active)
>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: disconnect from
>>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1
>>> rcpt=1 data=1 quit=1 commands=7
>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: connect from localhost[127.0.0.1]
>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: B5D675F83B:
>>> client=localhost[127.0.0.1]
>>> Mar 15 15:46:05 mx postfix/cleanup[27634]: B5D675F83B:
>>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B:
>>> from=<user1 at example.com>, size=1497, nrcpt=1 (queue active)
>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: disconnect from
>>> localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
>>> Mar 15 15:46:05 mx amavis[28645]: (28645-20) Passed CLEAN
>>> {RelayedOpenRelay}, [ip.adresse.des.versenders]:37494
>>> [ip.adresse.des.versenders] <user1 at example.com> ->
>>> <alias1 at example.org>, Queue-ID: 9F28D5F824, Message-ID:
>>> <D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>, mail_id:
>>> AEkFq9VYyvTL, Hits: -, size: 1226, queued_as: B5D675F83B, 78 ms
>>> Mar 15 15:46:05 mx postfix/smtp[27635]: 9F28D5F824:
>>> to=<alias1 at example.org>, relay=127.0.0.1[127.0.0.1]:10024,
>>> delay=0.11, delays=0.03/0/0/0.08, dsn=2.0.0, status=sent (250 2.0.0
>>> from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B5D675F83B)
>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824: removed
>>> Mar 15 15:46:05 mx postfix/smtp[27639]: B5D675F83B:
>>> to=<user2 at alias.example.org>, orig_to=<alias1 at example.org>,
>>> relay=alias.example.org[ip.ip.ip.ip]:25, delay=0.1,
>>> delays=0.01/0/0.07/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok:
>>> queued as CAEA45F87A)
>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B: removed
>> 
>> 
>> Zu guter Letzt noch meine postconf
>>> address_verify_sender = double-bounce at mx.example.net
>>> alias_database = hash:/etc/aliases
>>> alias_maps = hash:/etc/aliases
>>> amavisd_milter = inet:10.0.1.10:8899
>>> append_dot_mydomain = no
>>> biff = no
>>> bounce_queue_lifetime = 3d
>>> broken_sasl_auth_clients = yes
>>> disable_vrfy_command = yes
>>> dovecot_destination_recipient_limit = 1
>>> inet_interfaces = all
>>> inet_protocols = ipv4
>>> local_destination_concurrency_limit = 20
>>> mailbox_size_limit = 0
>>> maximal_queue_lifetime = 3d
>>> message_size_limit = 500000000
>>> milter_default_action = accept
>>> milter_protocol = 2
>>> mydestination = $myhostname, localhost.$mydomain, localhost
>>> myhostname = mx.example.net
>>> mynetworks = 127.0.0.0/8 10.0.2.10 10.0.2.1 10.0.2.2 10.0.2.3 10.0.2.4
>>> myorigin = /etc/mailname
>>> non_smtpd_milters = inet:localhost:8891
>>> postscreen_access_list = permit_mynetworks
>>> postscreen_dnsbl_action = enforce
>>> postscreen_dnsbl_sites = zen.spamhaus.org*3
>>> b.barracudacentral.org*2 bl.spamcop.net
>>> spam.dnsbl.sorbs.net=127.0.0.6
>>> postscreen_dnsbl_threshold = 3
>>> postscreen_greet_action = enforce
>>> readme_directory = no
>>> receive_override_options = no_address_mappings
>>> recipient_delimiter = +
>>> relayhost =
>>> smtp_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>>> smtp_mime_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>>> smtp_tls_security_level = may
>>> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
>>> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
>>> smtpd_client_restrictions = permit_mynetworks
>>> permit_sasl_authenticated reject_unauth_pipelining
>>> reject_rbl_client bl.spamcop.net
>>> smtpd_discard_ehlo_keyword_address_maps =
>>> cidr:/etc/postfix/esmtp_access.cidr
>>> smtpd_enforce_tls = yes
>>> smtpd_milters = inet:localhost:8891
>>> smtpd_recipient_restrictions =
>>> permit_mynetworks,permit_sasl_authenticated,reject_unknown_recipient_domain,reject_unverified_recipient
>>> smtpd_sasl_auth_enable = yes
>>> smtpd_sasl_authenticated_header = yes
>>> smtpd_sasl_path = private/auth
>>> smtpd_sasl_type = dovecot
>>> smtpd_tls_auth_only = yes
>>> smtpd_tls_cert_file = /etc/letsencrypt/live/mx.example.net/fullchain.pem
>>> smtpd_tls_key_file = /etc/letsencrypt/live/mx.example.net/privkey.pem
>>> smtpd_tls_mandatory_ciphers = high
>>> smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 , RC4
>>> smtpd_tls_mandatory_protocols = SSLv3, TLSv1
>>> smtpd_tls_security_level = may
>>> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>>> transport_maps = mysql:/etc/postfix/mysql-transport-maps.cf
>>> unverified_recipient_reject_code = 550
>>> unverified_recipient_reject_reason = 'Recipient address rejected'
>>> virtual_alias_maps =
>>> mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
>>> virtual_gid_maps = static:5000
>>> virtual_mailbox_domains =
>>> mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
>>> virtual_uid_maps = static:5000
>> 
>> 
>> Meine Fragen
>> 1. Warum wird überhaupt eine smtp Verbindung aufgebaut, wenn ich die
>> Domain doch in den virtual_domains definiert habe?
>> 2. Warum verhält sich Postfix korrekt, wenn die externe IP dem
>> System bekannt ist?
>> 3. Wie kann ich virtual_aliases wieder korrekt nutzen?
>> 
>> Vielen Dank für alle die bis hier gelesen haben und vorab auch
>> vielen Dank für eure Hilfe.
>> 
>> Vitali
> 
> 
> ----- Ende der Nachricht von Vitali Quiering <vitali at quiering.com> -----
> 
> 
> 
> --
> 
> --------------------------------------------
> e-Mail  : klaus at tachtler.net
> Homepage: https://www.tachtler.net
> DokuWiki: https://dokuwiki.tachtler.net
> --------------------------------------------
> <Mail-Anhang>

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

From vitali at quiering.com  Thu Mar 21 16:39:35 2019
From: vitali at quiering.com (Vitali Quiering)
Date: Thu, 21 Mar 2019 16:39:35 +0100
Subject: Problem mit address verification, virtual_aliases und
 mydestination hinter NAT
In-Reply-To: <96403FFC-C248-4E52-A7C9-C4DC9851B033@quiering.com>
References: <20190319085848.Horde.IWFfHxwVgq3cUe-0xpigjzs@buero.tachtler.net>
 <96403FFC-C248-4E52-A7C9-C4DC9851B033@quiering.com>
Message-ID: <B877F92B-3B96-4992-8C95-59FB3B3D5E93@quiering.com>

Hallo,

ich bin nun ein klein wenig weiter.

Mit proxy_interfaces habe ich Postfix abgewöhnt eine smtp Verbindung zu der externen IP aufzubauen.

Nun bekomme ich ein "dsn=5.4.6, status=bounced (mail for example.com loops back to myself)?.

Wenn ich die vielen durchforsteten Quellen richtig verstanden habe, kann das nur, und ist auf keinen Fall etwas anderes als mydestinations.
Da ich die eigentlichen Domains ja nun in der MariaDB stehen habe, kann ich dort ja nicht wirklich etwas anderes eintragen als "$myhostname localhost?. Dennoch endet jeder Versuch in dem genannte Fehler.

Zwischenzeitlich habe ich in dieser Diskussion <https://stackoverflow.com/questions/29432375/postfix-transport-maps-and-virtual-mailbox> gelesen, dass virtual_transport und transport_maps in gemeinsamer Verwendung problematisch sein können. Ist das die Ursache meines Problems?

Gruß
Vitali

> Am 20.03.2019 um 16:59 schrieb Vitali Quiering <vitali at quiering.com>:
> 
> Hallo Klaus,
> 
> vielen Dank. So etwas in der Art hatte ich mir schon gedacht. Leider komme ich an der Stelle überhaupt nicht weiter.
> 
> Aktuell habe ich smtpd_recipient_restrictions so angepasst, dass Aliases mit permit_auth_destination angenommen werden sollten (so zumindest mein Verständnis), es wird dennoch ein SMTP Probe an den MX mit der öffentlichen IP gemacht was in der Fehlermeldung endet. So als würde Postfix die Settings ignorieren.
> 
> smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,permit_auth_destination,reject_unknown_recipient_domain,reject_unverified_recipient
> 
> Gruß
> Vitali
> 
>> Am 19.03.2019 um 08:58 schrieb Klaus Tachtler <klaus at tachtler.net <mailto:klaus at tachtler.net>>:
>> 
>> Hallo Vitali,
>> 
>> da Dein Setup doch etwas komplexer ist, ist das ganze nicht so einfach
>> von der Ferne aus zu beurteilen. Was mir aber aufgefallen ist, und
>> bitte das ist nur eine sehr wage Vermutung, dass ich in Deiner
>> Konfiguration keine virtual_transport gesehen habe.
>> 
>> Ich habe für mich mal PosfixAdmin konfiguriert, was ebenfalls die
>> Einträge für Domains, Mailboxen und Aliase usw. in einer Datenbank
>> ablegt und dies für mich einmal dokumentiert.
>> 
>> https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_admin#virtual_transport <https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_admin#virtual_transport>
>> 
>> Evtl. ist dies eine Ansatz für eine Richtung in die Du weiter suchen kannst?
>> 
>> 
>> Grüße
>> Klaus.
>> 
>>> Moin,
>>> 
>>> ich habe hier ein Problem dem ich noch nicht auf die Schliche kommen
>>> konnte. Vielleicht hat von euch ja jemand eine Idee.
>>> 
>>> Beschreibung meines Setups
>>> Wir haben in einem RZ eine große Groupware als zentrale E-Mail
>>> Lösung mit sehr vielen Domains. Außerhalb des RZ betreiben wir eine
>>> Menge Mailserver mit klassischem Dovecot, Postfix, AMaViS Geraffel.
>>> Der Postfix setzt unter bestimmten Umständen den Transport in
>>> Richtung der Groupware was überwiegend Mails für schlagende Herzen
>>> sind. Auf den Mailservern selbst bleiben Mails liegen die bspw.
>>> maschinell abgeholt und verarbeitet werden.
>>> 
>>> Ich habe hierfür transport_maps genutzt.
>>> 
>>> mysql-transport-maps.cf
>>>> SELECT COALESCE(
>>>>  (
>>>>        SELECT 'dovecot' FROM virtual_users
>>>>        LEFT JOIN virtual_domains ON virtual_users.domain_id =
>>>> virtual_domains.id
>>>>        WHERE concat(virtual_users.user,'@',virtual_domains.name) =
>>>> '%s' LIMIT 1 ),
>>>>  (
>>>>        SELECT 'smtp' FROM virtual_aliases
>>>>        LEFT JOIN virtual_domains ON virtual_aliases.domain_id =
>>>> virtual_domains.id
>>>>        WHERE
>>>> concat(virtual_aliases.source,'@',virtual_domains.name) = '%s'
>>>> LIMIT 1),
>>>>  (
>>>>        SELECT 'local' FROM virtual_domains
>>>>        WHERE 'localhost' = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>>>>  (
>>>>        SELECT 'smtp:[ip.adresse.der.groupware]:25' FROM virtual_domains
>>>>        WHERE name = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>>>>        'smtp') AS user;
>>> 
>>> 
>>> Das funktionierte wunderbar, bis wir einige der externen Mailserver
>>> in unser RZ geholt haben.
>>> 
>>> Jetzt habe ich das Problem festgestellt, dass bei einem Alias smtp
>>> als transport verwendet wird. Eigenartigerweise wird mydestination
>>> nicht respektiert bzw. die virtual_domains. Es wird also, um die
>>> Adresse des Empfängers (Alias) zu überprüfen, eine SMTP Verbindung
>>> zu der öffentlichen IP des Mailserver hergestellt die dann wieder
>>> auf dem Mailserver selbst endet. Dies resultiert in der Meldung die
>>> wir alle lieben ?greeted me with my own hostname?.
>>> 
>>> Auf den externen Mailserver und im RZ läuft die Version 3.1.8-0+deb9u1.
>>> 
>>> Log des fehlgeschlagenen Versuches bei dem Server im RZ
>>>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: CONNECT from
>>>> [ip.adresse.des.versenders]:38170 to [10.0.0.11]:25
>>>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: PASS OLD
>>>> [ip.adresse.des.versenders]:38170
>>>> Mar 15 15:28:53 mx-local postfix/smtpd[112664]: connect from
>>>> mx.example.com[ip.adresse.des.versenders]
>>>> Mar 15 15:28:54 mx-local postfix/smtpd[112664]: 15B023FDF5:
>>>> client=mx.example.com[ip.adresse.des.versenders]
>>>> Mar 15 15:28:54 mx-local postfix/cleanup[112670]: 15B023FDF5:
>>>> message-id=<8529D5D9-70FE-41A4-9187-A2259D35269A at example.com>
>>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5:
>>>> from=<user1 at example.com>, size=2351, nrcpt=1 (queue active)
>>>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: CONNECT from
>>>> [10.0.0.1]:36536 to [10.0.0.11]:25
>>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from
>>>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1
>>>> rcpt=1 data=1 quit=1 commands=7
>>>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: PASS OLD
>>>> [10.0.0.1]:36536
>>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: connect from
>>>> unknown[10.0.0.1]
>>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host
>>>> mx.example.net[externe.ip.des.servers]:25 greeted me with my own
>>>> hostname mx.example.net
>>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host
>>>> mx.example.net[externe.ip.des.servers]:25 replied to HELO/EHLO with
>>>> my own hostname mx.example.net
>>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: 15B023FDF5:
>>>> to=<user2 at example.net>,
>>>> relay=mx.example.net[externe.ip.des.servers]:25, delay=1.8,
>>>> delays=1.7/0.01/0.13/0, dsn=5.4.6, status=bounced (mail for
>>>> example.net loops back to myself)
>>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from
>>>> unknown[10.0.0.1] ehlo=1 quit=1 commands=2
>>>> Mar 15 15:28:55 mx-local postfix/cleanup[112670]: C302F3FFDA:
>>>> message-id=<20190315142855.C302F3FFDA at mx.example.net>
>>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: C302F3FFDA: from=<>,
>>>> size=4707, nrcpt=1 (queue active)
>>>> Mar 15 15:28:55 mx-local postfix/bounce[112676]: 15B023FDF5: sender
>>>> non-delivery notification: C302F3FFDA
>>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5: removed
>>>> Mar 15 15:28:56 mx-local postfix/smtp[112671]: C302F3FFDA:
>>>> to=<user1 at example.com>,
>>>> relay=mx.example.com[ip.adresse.des.versenders]:25, delay=0.22,
>>>> delays=0.01/0/0.14/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok:
>>>> queued as E9ABCD840A5)
>>>> Mar 15 15:28:56 mx-local postfix/qmgr[112638]: C302F3FFDA: removed
>>> 
>>> 
>>> Log des erfolgreichen Versuches bei dem Server außerhalb des RZ
>>>> Mar 15 15:46:05 mx postfix/postscreen[27628]: CONNECT from
>>>> [ip.adresse.des.versenders]:37494 to [ip.adresse.des.empfaengers]:25
>>>> Mar 15 15:46:05 mx postfix/postscreen[27628]: PASS OLD
>>>> [ip.adresse.des.versenders]:37494
>>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: connect from
>>>> mx.example.com[ip.adresse.des.versenders]
>>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: 9F28D5F824:
>>>> client=mx.example.com[ip.adresse.des.versenders]
>>>> Mar 15 15:46:05 mx postfix/cleanup[27634]: 9F28D5F824:
>>>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824:
>>>> from=<user1 at example.com>, size=2390, nrcpt=1 (queue active)
>>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: disconnect from
>>>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1
>>>> rcpt=1 data=1 quit=1 commands=7
>>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: connect from localhost[127.0.0.1]
>>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: B5D675F83B:
>>>> client=localhost[127.0.0.1]
>>>> Mar 15 15:46:05 mx postfix/cleanup[27634]: B5D675F83B:
>>>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B:
>>>> from=<user1 at example.com>, size=1497, nrcpt=1 (queue active)
>>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: disconnect from
>>>> localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
>>>> Mar 15 15:46:05 mx amavis[28645]: (28645-20) Passed CLEAN
>>>> {RelayedOpenRelay}, [ip.adresse.des.versenders]:37494
>>>> [ip.adresse.des.versenders] <user1 at example.com> ->
>>>> <alias1 at example.org>, Queue-ID: 9F28D5F824, Message-ID:
>>>> <D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>, mail_id:
>>>> AEkFq9VYyvTL, Hits: -, size: 1226, queued_as: B5D675F83B, 78 ms
>>>> Mar 15 15:46:05 mx postfix/smtp[27635]: 9F28D5F824:
>>>> to=<alias1 at example.org>, relay=127.0.0.1[127.0.0.1]:10024,
>>>> delay=0.11, delays=0.03/0/0/0.08, dsn=2.0.0, status=sent (250 2.0.0
>>>> from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B5D675F83B)
>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824: removed
>>>> Mar 15 15:46:05 mx postfix/smtp[27639]: B5D675F83B:
>>>> to=<user2 at alias.example.org>, orig_to=<alias1 at example.org>,
>>>> relay=alias.example.org[ip.ip.ip.ip]:25, delay=0.1,
>>>> delays=0.01/0/0.07/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok:
>>>> queued as CAEA45F87A)
>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B: removed
>>> 
>>> 
>>> Zu guter Letzt noch meine postconf
>>>> address_verify_sender = double-bounce at mx.example.net
>>>> alias_database = hash:/etc/aliases
>>>> alias_maps = hash:/etc/aliases
>>>> amavisd_milter = inet:10.0.1.10:8899
>>>> append_dot_mydomain = no
>>>> biff = no
>>>> bounce_queue_lifetime = 3d
>>>> broken_sasl_auth_clients = yes
>>>> disable_vrfy_command = yes
>>>> dovecot_destination_recipient_limit = 1
>>>> inet_interfaces = all
>>>> inet_protocols = ipv4
>>>> local_destination_concurrency_limit = 20
>>>> mailbox_size_limit = 0
>>>> maximal_queue_lifetime = 3d
>>>> message_size_limit = 500000000
>>>> milter_default_action = accept
>>>> milter_protocol = 2
>>>> mydestination = $myhostname, localhost.$mydomain, localhost
>>>> myhostname = mx.example.net
>>>> mynetworks = 127.0.0.0/8 10.0.2.10 10.0.2.1 10.0.2.2 10.0.2.3 10.0.2.4
>>>> myorigin = /etc/mailname
>>>> non_smtpd_milters = inet:localhost:8891
>>>> postscreen_access_list = permit_mynetworks
>>>> postscreen_dnsbl_action = enforce
>>>> postscreen_dnsbl_sites = zen.spamhaus.org*3
>>>> b.barracudacentral.org*2 bl.spamcop.net
>>>> spam.dnsbl.sorbs.net=127.0.0.6
>>>> postscreen_dnsbl_threshold = 3
>>>> postscreen_greet_action = enforce
>>>> readme_directory = no
>>>> receive_override_options = no_address_mappings
>>>> recipient_delimiter = +
>>>> relayhost =
>>>> smtp_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>>>> smtp_mime_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>>>> smtp_tls_security_level = may
>>>> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
>>>> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
>>>> smtpd_client_restrictions = permit_mynetworks
>>>> permit_sasl_authenticated reject_unauth_pipelining
>>>> reject_rbl_client bl.spamcop.net
>>>> smtpd_discard_ehlo_keyword_address_maps =
>>>> cidr:/etc/postfix/esmtp_access.cidr
>>>> smtpd_enforce_tls = yes
>>>> smtpd_milters = inet:localhost:8891
>>>> smtpd_recipient_restrictions =
>>>> permit_mynetworks,permit_sasl_authenticated,reject_unknown_recipient_domain,reject_unverified_recipient
>>>> smtpd_sasl_auth_enable = yes
>>>> smtpd_sasl_authenticated_header = yes
>>>> smtpd_sasl_path = private/auth
>>>> smtpd_sasl_type = dovecot
>>>> smtpd_tls_auth_only = yes
>>>> smtpd_tls_cert_file = /etc/letsencrypt/live/mx.example.net/fullchain.pem
>>>> smtpd_tls_key_file = /etc/letsencrypt/live/mx.example.net/privkey.pem
>>>> smtpd_tls_mandatory_ciphers = high
>>>> smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 , RC4
>>>> smtpd_tls_mandatory_protocols = SSLv3, TLSv1
>>>> smtpd_tls_security_level = may
>>>> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>>>> transport_maps = mysql:/etc/postfix/mysql-transport-maps.cf
>>>> unverified_recipient_reject_code = 550
>>>> unverified_recipient_reject_reason = 'Recipient address rejected'
>>>> virtual_alias_maps =
>>>> mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
>>>> virtual_gid_maps = static:5000
>>>> virtual_mailbox_domains =
>>>> mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
>>>> virtual_uid_maps = static:5000
>>> 
>>> 
>>> Meine Fragen
>>> 1. Warum wird überhaupt eine smtp Verbindung aufgebaut, wenn ich die
>>> Domain doch in den virtual_domains definiert habe?
>>> 2. Warum verhält sich Postfix korrekt, wenn die externe IP dem
>>> System bekannt ist?
>>> 3. Wie kann ich virtual_aliases wieder korrekt nutzen?
>>> 
>>> Vielen Dank für alle die bis hier gelesen haben und vorab auch
>>> vielen Dank für eure Hilfe.
>>> 
>>> Vitali
>> 
>> 
>> ----- Ende der Nachricht von Vitali Quiering <vitali at quiering.com> -----
>> 
>> 
>> 
>> --
>> 
>> --------------------------------------------
>> e-Mail  : klaus at tachtler.net
>> Homepage: https://www.tachtler.net
>> DokuWiki: https://dokuwiki.tachtler.net
>> --------------------------------------------
>> <Mail-Anhang>
> 

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

From klaus at tachtler.net  Fri Mar 22 04:16:13 2019
From: klaus at tachtler.net (Klaus Tachtler)
Date: Fri, 22 Mar 2019 04:16:13 +0100
Subject: Problem mit address verification, virtual_aliases und
 mydestination hinter NAT
In-Reply-To: <B877F92B-3B96-4992-8C95-59FB3B3D5E93@quiering.com>
References: <20190319085848.Horde.IWFfHxwVgq3cUe-0xpigjzs@buero.tachtler.net>
 <96403FFC-C248-4E52-A7C9-C4DC9851B033@quiering.com>
 <B877F92B-3B96-4992-8C95-59FB3B3D5E93@quiering.com>
Message-ID: <20190322041613.Horde.H1HZ7CWRmF4Qo-99E-z17jN@buero.tachtler.net>

Hallo Vitali,

was steht bei Dir in mydestination?

Wie sieht das komplette LOG für die Einlieferung einer E-Mail aus,  
wenn Du die Fehlermeldung
"(mail for example.com loops back to myself)" bekommst?

(Bitte cat /var/log/maillog | grep <mail-message-id>)


Grüße
Klaus.

> Hallo,
>
> ich bin nun ein klein wenig weiter.
>
> Mit proxy_interfaces habe ich Postfix abgewöhnt eine smtp Verbindung  
> zu der externen IP aufzubauen.
>
> Nun bekomme ich ein "dsn=5.4.6, status=bounced (mail for example.com  
> loops back to myself)?.
>
> Wenn ich die vielen durchforsteten Quellen richtig verstanden habe,  
> kann das nur, und ist auf keinen Fall etwas anderes als  
> mydestinations.
> Da ich die eigentlichen Domains ja nun in der MariaDB stehen habe,  
> kann ich dort ja nicht wirklich etwas anderes eintragen als  
> "$myhostname localhost?. Dennoch endet jeder Versuch in dem genannte  
> Fehler.
>
> Zwischenzeitlich habe ich in dieser Diskussion  
> <https://stackoverflow.com/questions/29432375/postfix-transport-maps-and-virtual-mailbox> gelesen, dass virtual_transport und transport_maps in gemeinsamer Verwendung problematisch sein können. Ist das die Ursache meines  
> Problems?
>
> Gruß
> Vitali
>
>> Am 20.03.2019 um 16:59 schrieb Vitali Quiering <vitali at quiering.com>:
>>
>> Hallo Klaus,
>>
>> vielen Dank. So etwas in der Art hatte ich mir schon gedacht.  
>> Leider komme ich an der Stelle überhaupt nicht weiter.
>>
>> Aktuell habe ich smtpd_recipient_restrictions so angepasst, dass  
>> Aliases mit permit_auth_destination angenommen werden sollten (so  
>> zumindest mein Verständnis), es wird dennoch ein SMTP Probe an den  
>> MX mit der öffentlichen IP gemacht was in der Fehlermeldung endet.  
>> So als würde Postfix die Settings ignorieren.
>>
>> smtpd_recipient_restrictions =  
>> permit_mynetworks,permit_sasl_authenticated,permit_auth_destination,reject_unknown_recipient_domain,reject_unverified_recipient
>>
>> Gruß
>> Vitali
>>
>>> Am 19.03.2019 um 08:58 schrieb Klaus Tachtler <klaus at tachtler.net  
>>> <mailto:klaus at tachtler.net>>:
>>>
>>> Hallo Vitali,
>>>
>>> da Dein Setup doch etwas komplexer ist, ist das ganze nicht so einfach
>>> von der Ferne aus zu beurteilen. Was mir aber aufgefallen ist, und
>>> bitte das ist nur eine sehr wage Vermutung, dass ich in Deiner
>>> Konfiguration keine virtual_transport gesehen habe.
>>>
>>> Ich habe für mich mal PosfixAdmin konfiguriert, was ebenfalls die
>>> Einträge für Domains, Mailboxen und Aliase usw. in einer Datenbank
>>> ablegt und dies für mich einmal dokumentiert.
>>>
>>> https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_admin#virtual_transport  
>>> <https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_admin#virtual_transport>
>>>
>>> Evtl. ist dies eine Ansatz für eine Richtung in die Du weiter  
>>> suchen kannst?
>>>
>>>
>>> Grüße
>>> Klaus.
>>>
>>>> Moin,
>>>>
>>>> ich habe hier ein Problem dem ich noch nicht auf die Schliche kommen
>>>> konnte. Vielleicht hat von euch ja jemand eine Idee.
>>>>
>>>> Beschreibung meines Setups
>>>> Wir haben in einem RZ eine große Groupware als zentrale E-Mail
>>>> Lösung mit sehr vielen Domains. Außerhalb des RZ betreiben wir eine
>>>> Menge Mailserver mit klassischem Dovecot, Postfix, AMaViS Geraffel.
>>>> Der Postfix setzt unter bestimmten Umständen den Transport in
>>>> Richtung der Groupware was überwiegend Mails für schlagende Herzen
>>>> sind. Auf den Mailservern selbst bleiben Mails liegen die bspw.
>>>> maschinell abgeholt und verarbeitet werden.
>>>>
>>>> Ich habe hierfür transport_maps genutzt.
>>>>
>>>> mysql-transport-maps.cf
>>>>> SELECT COALESCE(
>>>>>  (
>>>>>        SELECT 'dovecot' FROM virtual_users
>>>>>        LEFT JOIN virtual_domains ON virtual_users.domain_id =
>>>>> virtual_domains.id
>>>>>        WHERE concat(virtual_users.user,'@',virtual_domains.name) =
>>>>> '%s' LIMIT 1 ),
>>>>>  (
>>>>>        SELECT 'smtp' FROM virtual_aliases
>>>>>        LEFT JOIN virtual_domains ON virtual_aliases.domain_id =
>>>>> virtual_domains.id
>>>>>        WHERE
>>>>> concat(virtual_aliases.source,'@',virtual_domains.name) = '%s'
>>>>> LIMIT 1),
>>>>>  (
>>>>>        SELECT 'local' FROM virtual_domains
>>>>>        WHERE 'localhost' = (SELECT SUBSTRING_INDEX('%s','@',-1))  
>>>>> LIMIT 1),
>>>>>  (
>>>>>        SELECT 'smtp:[ip.adresse.der.groupware]:25' FROM virtual_domains
>>>>>        WHERE name = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>>>>>        'smtp') AS user;
>>>>
>>>>
>>>> Das funktionierte wunderbar, bis wir einige der externen Mailserver
>>>> in unser RZ geholt haben.
>>>>
>>>> Jetzt habe ich das Problem festgestellt, dass bei einem Alias smtp
>>>> als transport verwendet wird. Eigenartigerweise wird mydestination
>>>> nicht respektiert bzw. die virtual_domains. Es wird also, um die
>>>> Adresse des Empfängers (Alias) zu überprüfen, eine SMTP Verbindung
>>>> zu der öffentlichen IP des Mailserver hergestellt die dann wieder
>>>> auf dem Mailserver selbst endet. Dies resultiert in der Meldung die
>>>> wir alle lieben ?greeted me with my own hostname?.
>>>>
>>>> Auf den externen Mailserver und im RZ läuft die Version 3.1.8-0+deb9u1.
>>>>
>>>> Log des fehlgeschlagenen Versuches bei dem Server im RZ
>>>>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: CONNECT from
>>>>> [ip.adresse.des.versenders]:38170 to [10.0.0.11]:25
>>>>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: PASS OLD
>>>>> [ip.adresse.des.versenders]:38170
>>>>> Mar 15 15:28:53 mx-local postfix/smtpd[112664]: connect from
>>>>> mx.example.com[ip.adresse.des.versenders]
>>>>> Mar 15 15:28:54 mx-local postfix/smtpd[112664]: 15B023FDF5:
>>>>> client=mx.example.com[ip.adresse.des.versenders]
>>>>> Mar 15 15:28:54 mx-local postfix/cleanup[112670]: 15B023FDF5:
>>>>> message-id=<8529D5D9-70FE-41A4-9187-A2259D35269A at example.com>
>>>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5:
>>>>> from=<user1 at example.com>, size=2351, nrcpt=1 (queue active)
>>>>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: CONNECT from
>>>>> [10.0.0.1]:36536 to [10.0.0.11]:25
>>>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from
>>>>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1
>>>>> rcpt=1 data=1 quit=1 commands=7
>>>>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: PASS OLD
>>>>> [10.0.0.1]:36536
>>>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: connect from
>>>>> unknown[10.0.0.1]
>>>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host
>>>>> mx.example.net[externe.ip.des.servers]:25 greeted me with my own
>>>>> hostname mx.example.net
>>>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host
>>>>> mx.example.net[externe.ip.des.servers]:25 replied to HELO/EHLO with
>>>>> my own hostname mx.example.net
>>>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: 15B023FDF5:
>>>>> to=<user2 at example.net>,
>>>>> relay=mx.example.net[externe.ip.des.servers]:25, delay=1.8,
>>>>> delays=1.7/0.01/0.13/0, dsn=5.4.6, status=bounced (mail for
>>>>> example.net loops back to myself)
>>>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from
>>>>> unknown[10.0.0.1] ehlo=1 quit=1 commands=2
>>>>> Mar 15 15:28:55 mx-local postfix/cleanup[112670]: C302F3FFDA:
>>>>> message-id=<20190315142855.C302F3FFDA at mx.example.net>
>>>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: C302F3FFDA: from=<>,
>>>>> size=4707, nrcpt=1 (queue active)
>>>>> Mar 15 15:28:55 mx-local postfix/bounce[112676]: 15B023FDF5: sender
>>>>> non-delivery notification: C302F3FFDA
>>>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5: removed
>>>>> Mar 15 15:28:56 mx-local postfix/smtp[112671]: C302F3FFDA:
>>>>> to=<user1 at example.com>,
>>>>> relay=mx.example.com[ip.adresse.des.versenders]:25, delay=0.22,
>>>>> delays=0.01/0/0.14/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok:
>>>>> queued as E9ABCD840A5)
>>>>> Mar 15 15:28:56 mx-local postfix/qmgr[112638]: C302F3FFDA: removed
>>>>
>>>>
>>>> Log des erfolgreichen Versuches bei dem Server außerhalb des RZ
>>>>> Mar 15 15:46:05 mx postfix/postscreen[27628]: CONNECT from
>>>>> [ip.adresse.des.versenders]:37494 to [ip.adresse.des.empfaengers]:25
>>>>> Mar 15 15:46:05 mx postfix/postscreen[27628]: PASS OLD
>>>>> [ip.adresse.des.versenders]:37494
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: connect from
>>>>> mx.example.com[ip.adresse.des.versenders]
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: 9F28D5F824:
>>>>> client=mx.example.com[ip.adresse.des.versenders]
>>>>> Mar 15 15:46:05 mx postfix/cleanup[27634]: 9F28D5F824:
>>>>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824:
>>>>> from=<user1 at example.com>, size=2390, nrcpt=1 (queue active)
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: disconnect from
>>>>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1
>>>>> rcpt=1 data=1 quit=1 commands=7
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: connect from  
>>>>> localhost[127.0.0.1]
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: B5D675F83B:
>>>>> client=localhost[127.0.0.1]
>>>>> Mar 15 15:46:05 mx postfix/cleanup[27634]: B5D675F83B:
>>>>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B:
>>>>> from=<user1 at example.com>, size=1497, nrcpt=1 (queue active)
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: disconnect from
>>>>> localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
>>>>> Mar 15 15:46:05 mx amavis[28645]: (28645-20) Passed CLEAN
>>>>> {RelayedOpenRelay}, [ip.adresse.des.versenders]:37494
>>>>> [ip.adresse.des.versenders] <user1 at example.com> ->
>>>>> <alias1 at example.org>, Queue-ID: 9F28D5F824, Message-ID:
>>>>> <D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>, mail_id:
>>>>> AEkFq9VYyvTL, Hits: -, size: 1226, queued_as: B5D675F83B, 78 ms
>>>>> Mar 15 15:46:05 mx postfix/smtp[27635]: 9F28D5F824:
>>>>> to=<alias1 at example.org>, relay=127.0.0.1[127.0.0.1]:10024,
>>>>> delay=0.11, delays=0.03/0/0/0.08, dsn=2.0.0, status=sent (250 2.0.0
>>>>> from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B5D675F83B)
>>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824: removed
>>>>> Mar 15 15:46:05 mx postfix/smtp[27639]: B5D675F83B:
>>>>> to=<user2 at alias.example.org>, orig_to=<alias1 at example.org>,
>>>>> relay=alias.example.org[ip.ip.ip.ip]:25, delay=0.1,
>>>>> delays=0.01/0/0.07/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok:
>>>>> queued as CAEA45F87A)
>>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B: removed
>>>>
>>>>
>>>> Zu guter Letzt noch meine postconf
>>>>> address_verify_sender = double-bounce at mx.example.net
>>>>> alias_database = hash:/etc/aliases
>>>>> alias_maps = hash:/etc/aliases
>>>>> amavisd_milter = inet:10.0.1.10:8899
>>>>> append_dot_mydomain = no
>>>>> biff = no
>>>>> bounce_queue_lifetime = 3d
>>>>> broken_sasl_auth_clients = yes
>>>>> disable_vrfy_command = yes
>>>>> dovecot_destination_recipient_limit = 1
>>>>> inet_interfaces = all
>>>>> inet_protocols = ipv4
>>>>> local_destination_concurrency_limit = 20
>>>>> mailbox_size_limit = 0
>>>>> maximal_queue_lifetime = 3d
>>>>> message_size_limit = 500000000
>>>>> milter_default_action = accept
>>>>> milter_protocol = 2
>>>>> mydestination = $myhostname, localhost.$mydomain, localhost
>>>>> myhostname = mx.example.net
>>>>> mynetworks = 127.0.0.0/8 10.0.2.10 10.0.2.1 10.0.2.2 10.0.2.3 10.0.2.4
>>>>> myorigin = /etc/mailname
>>>>> non_smtpd_milters = inet:localhost:8891
>>>>> postscreen_access_list = permit_mynetworks
>>>>> postscreen_dnsbl_action = enforce
>>>>> postscreen_dnsbl_sites = zen.spamhaus.org*3
>>>>> b.barracudacentral.org*2 bl.spamcop.net
>>>>> spam.dnsbl.sorbs.net=127.0.0.6
>>>>> postscreen_dnsbl_threshold = 3
>>>>> postscreen_greet_action = enforce
>>>>> readme_directory = no
>>>>> receive_override_options = no_address_mappings
>>>>> recipient_delimiter = +
>>>>> relayhost =
>>>>> smtp_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>>>>> smtp_mime_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>>>>> smtp_tls_security_level = may
>>>>> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
>>>>> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
>>>>> smtpd_client_restrictions = permit_mynetworks
>>>>> permit_sasl_authenticated reject_unauth_pipelining
>>>>> reject_rbl_client bl.spamcop.net
>>>>> smtpd_discard_ehlo_keyword_address_maps =
>>>>> cidr:/etc/postfix/esmtp_access.cidr
>>>>> smtpd_enforce_tls = yes
>>>>> smtpd_milters = inet:localhost:8891
>>>>> smtpd_recipient_restrictions =
>>>>> permit_mynetworks,permit_sasl_authenticated,reject_unknown_recipient_domain,reject_unverified_recipient
>>>>> smtpd_sasl_auth_enable = yes
>>>>> smtpd_sasl_authenticated_header = yes
>>>>> smtpd_sasl_path = private/auth
>>>>> smtpd_sasl_type = dovecot
>>>>> smtpd_tls_auth_only = yes
>>>>> smtpd_tls_cert_file = /etc/letsencrypt/live/mx.example.net/fullchain.pem
>>>>> smtpd_tls_key_file = /etc/letsencrypt/live/mx.example.net/privkey.pem
>>>>> smtpd_tls_mandatory_ciphers = high
>>>>> smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 , RC4
>>>>> smtpd_tls_mandatory_protocols = SSLv3, TLSv1
>>>>> smtpd_tls_security_level = may
>>>>> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>>>>> transport_maps = mysql:/etc/postfix/mysql-transport-maps.cf
>>>>> unverified_recipient_reject_code = 550
>>>>> unverified_recipient_reject_reason = 'Recipient address rejected'
>>>>> virtual_alias_maps =
>>>>> mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
>>>>> virtual_gid_maps = static:5000
>>>>> virtual_mailbox_domains =
>>>>> mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
>>>>> virtual_uid_maps = static:5000
>>>>
>>>>
>>>> Meine Fragen
>>>> 1. Warum wird überhaupt eine smtp Verbindung aufgebaut, wenn ich die
>>>> Domain doch in den virtual_domains definiert habe?
>>>> 2. Warum verhält sich Postfix korrekt, wenn die externe IP dem
>>>> System bekannt ist?
>>>> 3. Wie kann ich virtual_aliases wieder korrekt nutzen?
>>>>
>>>> Vielen Dank für alle die bis hier gelesen haben und vorab auch
>>>> vielen Dank für eure Hilfe.
>>>>
>>>> Vitali
>>>
>>>
>>> ----- Ende der Nachricht von Vitali Quiering <vitali at quiering.com> -----
>>>
>>>
>>>
>>> --
>>>
>>> --------------------------------------------
>>> e-Mail  : klaus at tachtler.net
>>> Homepage: https://www.tachtler.net
>>> DokuWiki: https://dokuwiki.tachtler.net
>>> --------------------------------------------
>>> <Mail-Anhang>
>>


----- Ende der Nachricht von Vitali Quiering <vitali at quiering.com> -----



-- 

--------------------------------------------
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/20190322/1a984241/attachment.skr>

From klaus at tachtler.net  Fri Mar 22 04:44:55 2019
From: klaus at tachtler.net (Klaus Tachtler)
Date: Fri, 22 Mar 2019 04:44:55 +0100
Subject: Problem mit address verification, virtual_aliases und
 mydestination hinter NAT
In-Reply-To: <B877F92B-3B96-4992-8C95-59FB3B3D5E93@quiering.com>
References: <20190319085848.Horde.IWFfHxwVgq3cUe-0xpigjzs@buero.tachtler.net>
 <96403FFC-C248-4E52-A7C9-C4DC9851B033@quiering.com>
 <B877F92B-3B96-4992-8C95-59FB3B3D5E93@quiering.com>
Message-ID: <20190322044455.Horde.GKBqaHe1BiUgUZY3D5S6gva@buero.tachtler.net>

Hallo Vitali,

wie schon erwähnt, ist Dein Setup nicht gerade so ganz einfach.

Ich habe das bei mir wie folgt gelöst:

transport_maps = btree:/etc/postfix/transport_maps, $relay_domains
virtual_alias_domains = btree:/etc/postfix/virtual_alias_domains

--> /etc/postfix/transport_maps ist bei mir OHNE Inhalt.
--> $relay_domains = /etc/postfix/transport_maps ist bei mir auch OHNE Inhalt.

--- Ab hier sind meine SQL-Abfragen enthalten ---

virtual_alias_maps = btree:/etc/postfix/virtual_alias_maps,  
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf,  
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf,  
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf

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

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

--- Bis hier sind meine SQL-Abfragen enthalten ---

virtual_transport = lmtp:inet:[192.168.0.80]:24


Was mit BEI DIR FEHLT ist virtual_mailbox_domains und virtual_transport.

Falls Du das Buch von Peer Heinlein hast, schau Dir mal die Seiten 371 ff. an.

Meiner Meinung nach, hast Du noch eine Vermischung von klassischen  
Definitionen und virtuellen Definitionen.

p.s. Siehe auch, wie ich PostfixAdmin eingebunden habe:

https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_admin


Grüße
Klaus.

> Hallo,
>
> ich bin nun ein klein wenig weiter.
>
> Mit proxy_interfaces habe ich Postfix abgewöhnt eine smtp Verbindung  
> zu der externen IP aufzubauen.
>
> Nun bekomme ich ein "dsn=5.4.6, status=bounced (mail for example.com  
> loops back to myself)?.
>
> Wenn ich die vielen durchforsteten Quellen richtig verstanden habe,  
> kann das nur, und ist auf keinen Fall etwas anderes als  
> mydestinations.
> Da ich die eigentlichen Domains ja nun in der MariaDB stehen habe,  
> kann ich dort ja nicht wirklich etwas anderes eintragen als  
> "$myhostname localhost?. Dennoch endet jeder Versuch in dem genannte  
> Fehler.
>
> Zwischenzeitlich habe ich in dieser Diskussion  
> <https://stackoverflow.com/questions/29432375/postfix-transport-maps-and-virtual-mailbox> gelesen, dass virtual_transport und transport_maps in gemeinsamer Verwendung problematisch sein können. Ist das die Ursache meines  
> Problems?
>
> Gruß
> Vitali
>
>> Am 20.03.2019 um 16:59 schrieb Vitali Quiering <vitali at quiering.com>:
>>
>> Hallo Klaus,
>>
>> vielen Dank. So etwas in der Art hatte ich mir schon gedacht.  
>> Leider komme ich an der Stelle überhaupt nicht weiter.
>>
>> Aktuell habe ich smtpd_recipient_restrictions so angepasst, dass  
>> Aliases mit permit_auth_destination angenommen werden sollten (so  
>> zumindest mein Verständnis), es wird dennoch ein SMTP Probe an den  
>> MX mit der öffentlichen IP gemacht was in der Fehlermeldung endet.  
>> So als würde Postfix die Settings ignorieren.
>>
>> smtpd_recipient_restrictions =  
>> permit_mynetworks,permit_sasl_authenticated,permit_auth_destination,reject_unknown_recipient_domain,reject_unverified_recipient
>>
>> Gruß
>> Vitali
>>
>>> Am 19.03.2019 um 08:58 schrieb Klaus Tachtler <klaus at tachtler.net  
>>> <mailto:klaus at tachtler.net>>:
>>>
>>> Hallo Vitali,
>>>
>>> da Dein Setup doch etwas komplexer ist, ist das ganze nicht so einfach
>>> von der Ferne aus zu beurteilen. Was mir aber aufgefallen ist, und
>>> bitte das ist nur eine sehr wage Vermutung, dass ich in Deiner
>>> Konfiguration keine virtual_transport gesehen habe.
>>>
>>> Ich habe für mich mal PosfixAdmin konfiguriert, was ebenfalls die
>>> Einträge für Domains, Mailboxen und Aliase usw. in einer Datenbank
>>> ablegt und dies für mich einmal dokumentiert.
>>>
>>> https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_admin#virtual_transport  
>>> <https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_admin#virtual_transport>
>>>
>>> Evtl. ist dies eine Ansatz für eine Richtung in die Du weiter  
>>> suchen kannst?
>>>
>>>
>>> Grüße
>>> Klaus.
>>>
>>>> Moin,
>>>>
>>>> ich habe hier ein Problem dem ich noch nicht auf die Schliche kommen
>>>> konnte. Vielleicht hat von euch ja jemand eine Idee.
>>>>
>>>> Beschreibung meines Setups
>>>> Wir haben in einem RZ eine große Groupware als zentrale E-Mail
>>>> Lösung mit sehr vielen Domains. Außerhalb des RZ betreiben wir eine
>>>> Menge Mailserver mit klassischem Dovecot, Postfix, AMaViS Geraffel.
>>>> Der Postfix setzt unter bestimmten Umständen den Transport in
>>>> Richtung der Groupware was überwiegend Mails für schlagende Herzen
>>>> sind. Auf den Mailservern selbst bleiben Mails liegen die bspw.
>>>> maschinell abgeholt und verarbeitet werden.
>>>>
>>>> Ich habe hierfür transport_maps genutzt.
>>>>
>>>> mysql-transport-maps.cf
>>>>> SELECT COALESCE(
>>>>>  (
>>>>>        SELECT 'dovecot' FROM virtual_users
>>>>>        LEFT JOIN virtual_domains ON virtual_users.domain_id =
>>>>> virtual_domains.id
>>>>>        WHERE concat(virtual_users.user,'@',virtual_domains.name) =
>>>>> '%s' LIMIT 1 ),
>>>>>  (
>>>>>        SELECT 'smtp' FROM virtual_aliases
>>>>>        LEFT JOIN virtual_domains ON virtual_aliases.domain_id =
>>>>> virtual_domains.id
>>>>>        WHERE
>>>>> concat(virtual_aliases.source,'@',virtual_domains.name) = '%s'
>>>>> LIMIT 1),
>>>>>  (
>>>>>        SELECT 'local' FROM virtual_domains
>>>>>        WHERE 'localhost' = (SELECT SUBSTRING_INDEX('%s','@',-1))  
>>>>> LIMIT 1),
>>>>>  (
>>>>>        SELECT 'smtp:[ip.adresse.der.groupware]:25' FROM virtual_domains
>>>>>        WHERE name = (SELECT SUBSTRING_INDEX('%s','@',-1)) LIMIT 1),
>>>>>        'smtp') AS user;
>>>>
>>>>
>>>> Das funktionierte wunderbar, bis wir einige der externen Mailserver
>>>> in unser RZ geholt haben.
>>>>
>>>> Jetzt habe ich das Problem festgestellt, dass bei einem Alias smtp
>>>> als transport verwendet wird. Eigenartigerweise wird mydestination
>>>> nicht respektiert bzw. die virtual_domains. Es wird also, um die
>>>> Adresse des Empfängers (Alias) zu überprüfen, eine SMTP Verbindung
>>>> zu der öffentlichen IP des Mailserver hergestellt die dann wieder
>>>> auf dem Mailserver selbst endet. Dies resultiert in der Meldung die
>>>> wir alle lieben ?greeted me with my own hostname?.
>>>>
>>>> Auf den externen Mailserver und im RZ läuft die Version 3.1.8-0+deb9u1.
>>>>
>>>> Log des fehlgeschlagenen Versuches bei dem Server im RZ
>>>>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: CONNECT from
>>>>> [ip.adresse.des.versenders]:38170 to [10.0.0.11]:25
>>>>> Mar 15 15:28:53 mx-local postfix/postscreen[112663]: PASS OLD
>>>>> [ip.adresse.des.versenders]:38170
>>>>> Mar 15 15:28:53 mx-local postfix/smtpd[112664]: connect from
>>>>> mx.example.com[ip.adresse.des.versenders]
>>>>> Mar 15 15:28:54 mx-local postfix/smtpd[112664]: 15B023FDF5:
>>>>> client=mx.example.com[ip.adresse.des.versenders]
>>>>> Mar 15 15:28:54 mx-local postfix/cleanup[112670]: 15B023FDF5:
>>>>> message-id=<8529D5D9-70FE-41A4-9187-A2259D35269A at example.com>
>>>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5:
>>>>> from=<user1 at example.com>, size=2351, nrcpt=1 (queue active)
>>>>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: CONNECT from
>>>>> [10.0.0.1]:36536 to [10.0.0.11]:25
>>>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from
>>>>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1
>>>>> rcpt=1 data=1 quit=1 commands=7
>>>>> Mar 15 15:28:55 mx-local postfix/postscreen[112663]: PASS OLD
>>>>> [10.0.0.1]:36536
>>>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: connect from
>>>>> unknown[10.0.0.1]
>>>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host
>>>>> mx.example.net[externe.ip.des.servers]:25 greeted me with my own
>>>>> hostname mx.example.net
>>>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: warning: host
>>>>> mx.example.net[externe.ip.des.servers]:25 replied to HELO/EHLO with
>>>>> my own hostname mx.example.net
>>>>> Mar 15 15:28:55 mx-local postfix/smtp[112671]: 15B023FDF5:
>>>>> to=<user2 at example.net>,
>>>>> relay=mx.example.net[externe.ip.des.servers]:25, delay=1.8,
>>>>> delays=1.7/0.01/0.13/0, dsn=5.4.6, status=bounced (mail for
>>>>> example.net loops back to myself)
>>>>> Mar 15 15:28:55 mx-local postfix/smtpd[112664]: disconnect from
>>>>> unknown[10.0.0.1] ehlo=1 quit=1 commands=2
>>>>> Mar 15 15:28:55 mx-local postfix/cleanup[112670]: C302F3FFDA:
>>>>> message-id=<20190315142855.C302F3FFDA at mx.example.net>
>>>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: C302F3FFDA: from=<>,
>>>>> size=4707, nrcpt=1 (queue active)
>>>>> Mar 15 15:28:55 mx-local postfix/bounce[112676]: 15B023FDF5: sender
>>>>> non-delivery notification: C302F3FFDA
>>>>> Mar 15 15:28:55 mx-local postfix/qmgr[112638]: 15B023FDF5: removed
>>>>> Mar 15 15:28:56 mx-local postfix/smtp[112671]: C302F3FFDA:
>>>>> to=<user1 at example.com>,
>>>>> relay=mx.example.com[ip.adresse.des.versenders]:25, delay=0.22,
>>>>> delays=0.01/0/0.14/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok:
>>>>> queued as E9ABCD840A5)
>>>>> Mar 15 15:28:56 mx-local postfix/qmgr[112638]: C302F3FFDA: removed
>>>>
>>>>
>>>> Log des erfolgreichen Versuches bei dem Server außerhalb des RZ
>>>>> Mar 15 15:46:05 mx postfix/postscreen[27628]: CONNECT from
>>>>> [ip.adresse.des.versenders]:37494 to [ip.adresse.des.empfaengers]:25
>>>>> Mar 15 15:46:05 mx postfix/postscreen[27628]: PASS OLD
>>>>> [ip.adresse.des.versenders]:37494
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: connect from
>>>>> mx.example.com[ip.adresse.des.versenders]
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: 9F28D5F824:
>>>>> client=mx.example.com[ip.adresse.des.versenders]
>>>>> Mar 15 15:46:05 mx postfix/cleanup[27634]: 9F28D5F824:
>>>>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824:
>>>>> from=<user1 at example.com>, size=2390, nrcpt=1 (queue active)
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27629]: disconnect from
>>>>> mx.example.com[ip.adresse.des.versenders] ehlo=2 starttls=1 mail=1
>>>>> rcpt=1 data=1 quit=1 commands=7
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: connect from  
>>>>> localhost[127.0.0.1]
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: B5D675F83B:
>>>>> client=localhost[127.0.0.1]
>>>>> Mar 15 15:46:05 mx postfix/cleanup[27634]: B5D675F83B:
>>>>> message-id=<D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>
>>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B:
>>>>> from=<user1 at example.com>, size=1497, nrcpt=1 (queue active)
>>>>> Mar 15 15:46:05 mx postfix/smtpd[27638]: disconnect from
>>>>> localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
>>>>> Mar 15 15:46:05 mx amavis[28645]: (28645-20) Passed CLEAN
>>>>> {RelayedOpenRelay}, [ip.adresse.des.versenders]:37494
>>>>> [ip.adresse.des.versenders] <user1 at example.com> ->
>>>>> <alias1 at example.org>, Queue-ID: 9F28D5F824, Message-ID:
>>>>> <D5793ECA-36A4-43BA-B036-4C699EDAF278 at example.com>, mail_id:
>>>>> AEkFq9VYyvTL, Hits: -, size: 1226, queued_as: B5D675F83B, 78 ms
>>>>> Mar 15 15:46:05 mx postfix/smtp[27635]: 9F28D5F824:
>>>>> to=<alias1 at example.org>, relay=127.0.0.1[127.0.0.1]:10024,
>>>>> delay=0.11, delays=0.03/0/0/0.08, dsn=2.0.0, status=sent (250 2.0.0
>>>>> from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B5D675F83B)
>>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: 9F28D5F824: removed
>>>>> Mar 15 15:46:05 mx postfix/smtp[27639]: B5D675F83B:
>>>>> to=<user2 at alias.example.org>, orig_to=<alias1 at example.org>,
>>>>> relay=alias.example.org[ip.ip.ip.ip]:25, delay=0.1,
>>>>> delays=0.01/0/0.07/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok:
>>>>> queued as CAEA45F87A)
>>>>> Mar 15 15:46:05 mx postfix/qmgr[22574]: B5D675F83B: removed
>>>>
>>>>
>>>> Zu guter Letzt noch meine postconf
>>>>> address_verify_sender = double-bounce at mx.example.net
>>>>> alias_database = hash:/etc/aliases
>>>>> alias_maps = hash:/etc/aliases
>>>>> amavisd_milter = inet:10.0.1.10:8899
>>>>> append_dot_mydomain = no
>>>>> biff = no
>>>>> bounce_queue_lifetime = 3d
>>>>> broken_sasl_auth_clients = yes
>>>>> disable_vrfy_command = yes
>>>>> dovecot_destination_recipient_limit = 1
>>>>> inet_interfaces = all
>>>>> inet_protocols = ipv4
>>>>> local_destination_concurrency_limit = 20
>>>>> mailbox_size_limit = 0
>>>>> maximal_queue_lifetime = 3d
>>>>> message_size_limit = 500000000
>>>>> milter_default_action = accept
>>>>> milter_protocol = 2
>>>>> mydestination = $myhostname, localhost.$mydomain, localhost
>>>>> myhostname = mx.example.net
>>>>> mynetworks = 127.0.0.0/8 10.0.2.10 10.0.2.1 10.0.2.2 10.0.2.3 10.0.2.4
>>>>> myorigin = /etc/mailname
>>>>> non_smtpd_milters = inet:localhost:8891
>>>>> postscreen_access_list = permit_mynetworks
>>>>> postscreen_dnsbl_action = enforce
>>>>> postscreen_dnsbl_sites = zen.spamhaus.org*3
>>>>> b.barracudacentral.org*2 bl.spamcop.net
>>>>> spam.dnsbl.sorbs.net=127.0.0.6
>>>>> postscreen_dnsbl_threshold = 3
>>>>> postscreen_greet_action = enforce
>>>>> readme_directory = no
>>>>> receive_override_options = no_address_mappings
>>>>> recipient_delimiter = +
>>>>> relayhost =
>>>>> smtp_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>>>>> smtp_mime_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
>>>>> smtp_tls_security_level = may
>>>>> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
>>>>> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
>>>>> smtpd_client_restrictions = permit_mynetworks
>>>>> permit_sasl_authenticated reject_unauth_pipelining
>>>>> reject_rbl_client bl.spamcop.net
>>>>> smtpd_discard_ehlo_keyword_address_maps =
>>>>> cidr:/etc/postfix/esmtp_access.cidr
>>>>> smtpd_enforce_tls = yes
>>>>> smtpd_milters = inet:localhost:8891
>>>>> smtpd_recipient_restrictions =
>>>>> permit_mynetworks,permit_sasl_authenticated,reject_unknown_recipient_domain,reject_unverified_recipient
>>>>> smtpd_sasl_auth_enable = yes
>>>>> smtpd_sasl_authenticated_header = yes
>>>>> smtpd_sasl_path = private/auth
>>>>> smtpd_sasl_type = dovecot
>>>>> smtpd_tls_auth_only = yes
>>>>> smtpd_tls_cert_file = /etc/letsencrypt/live/mx.example.net/fullchain.pem
>>>>> smtpd_tls_key_file = /etc/letsencrypt/live/mx.example.net/privkey.pem
>>>>> smtpd_tls_mandatory_ciphers = high
>>>>> smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 , RC4
>>>>> smtpd_tls_mandatory_protocols = SSLv3, TLSv1
>>>>> smtpd_tls_security_level = may
>>>>> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>>>>> transport_maps = mysql:/etc/postfix/mysql-transport-maps.cf
>>>>> unverified_recipient_reject_code = 550
>>>>> unverified_recipient_reject_reason = 'Recipient address rejected'
>>>>> virtual_alias_maps =
>>>>> mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
>>>>> virtual_gid_maps = static:5000
>>>>> virtual_mailbox_domains =
>>>>> mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
>>>>> virtual_uid_maps = static:5000
>>>>
>>>>
>>>> Meine Fragen
>>>> 1. Warum wird überhaupt eine smtp Verbindung aufgebaut, wenn ich die
>>>> Domain doch in den virtual_domains definiert habe?
>>>> 2. Warum verhält sich Postfix korrekt, wenn die externe IP dem
>>>> System bekannt ist?
>>>> 3. Wie kann ich virtual_aliases wieder korrekt nutzen?
>>>>
>>>> Vielen Dank für alle die bis hier gelesen haben und vorab auch
>>>> vielen Dank für eure Hilfe.
>>>>
>>>> Vitali
>>>
>>>
>>> ----- Ende der Nachricht von Vitali Quiering <vitali at quiering.com> -----
>>>
>>>
>>>
>>> --
>>>
>>> --------------------------------------------
>>> e-Mail  : klaus at tachtler.net
>>> Homepage: https://www.tachtler.net
>>> DokuWiki: https://dokuwiki.tachtler.net
>>> --------------------------------------------
>>> <Mail-Anhang>
>>


----- Ende der Nachricht von Vitali Quiering <vitali at quiering.com> -----



-- 

--------------------------------------------
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/20190322/86949032/attachment.skr>

From Hajo.Locke at gmx.de  Fri Mar 22 09:23:28 2019
From: Hajo.Locke at gmx.de (Hajo Locke)
Date: Fri, 22 Mar 2019 09:23:28 +0100
Subject: Rechte und Pflichten zur Spamfilterung
Message-ID: <017f73a6-c45e-7399-598b-8852cb0bb17e@gmx.de>

Hallo,

viele von Euch kennen sicherlich dieses Dokument:
https://www.eco.de/wp-content/blogs.dir/28/files/gutachten_provider_gegen_spam2007_final.pdf
Nur eine kurze Frage dazu: Ist das so heute noch anwendbar oder hat sich
da signifikant etwas getan?
Speziell geht es mir um den Bereich der Rechte und Pflichten ausgehende
Mails einer Spamprüfung zu unterziehen und ablehnen zu dürfen.
Mal provokant gesagt: Haben eventuell Datenschutzbestimmungen so an
Bedeutung gewonnen, dass ausgehende Mails nicht mehr angefasst werden
dürfen?

Danke,
Hajo


From p at sys4.de  Fri Mar 22 12:08:19 2019
From: p at sys4.de (Patrick Ben Koetter)
Date: Fri, 22 Mar 2019 12:08:19 +0100
Subject: Rechte und Pflichten zur Spamfilterung
In-Reply-To: <017f73a6-c45e-7399-598b-8852cb0bb17e@gmx.de>
References: <017f73a6-c45e-7399-598b-8852cb0bb17e@gmx.de>
Message-ID: <20190322110819.hq6aiilp7dtvgcym@sys4.de>

Hallo Hajo,

* Hajo Locke <postfixbuch-users at listen.jpberlin.de>:
> viele von Euch kennen sicherlich dieses Dokument:
> https://www.eco.de/wp-content/blogs.dir/28/files/gutachten_provider_gegen_spam2007_final.pdf
> Nur eine kurze Frage dazu: Ist das so heute noch anwendbar oder hat sich
> da signifikant etwas getan?

nach meinem Kenntnisstand hat sich das nicht getan. Die dort vertretene
Rechtsauffassung findet AFAIK immer noch Anwendung. Wenn es signifikaten
Änderungen geben würde, würden wir (eco) das Gutachten erneuern.


> Speziell geht es mir um den Bereich der Rechte und Pflichten ausgehende
> Mails einer Spamprüfung zu unterziehen und ablehnen zu dürfen. Mal provokant
> gesagt: Haben eventuell Datenschutzbestimmungen so an Bedeutung gewonnen,
> dass ausgehende Mails nicht mehr angefasst werden dürfen?

Mein letzter Stand ist: Du darfst ausgehende Nachrichten automatisiert prüfen,
wenn Du eine entsprechende, rechtliche Grundlage (z.B. Dienstvereinbarung)
dafür geschaffen hast.

Endgültiges und rechtlich Wirksames kann Dir natürlich nur ein zugelassender
Anwalt sagen. Alle anderen (mich eingeschlossen) werden bei solchen Aussagen
standesrechtlich er? mahnt. ;-)

p at rick
Kompetenzgruppenleiter E-Mail bei der eco
<https://www.eco.de/themen/e-mail/>


-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 


From Hajo.Locke at gmx.de  Mon Mar 25 08:16:56 2019
From: Hajo.Locke at gmx.de (Hajo Locke)
Date: Mon, 25 Mar 2019 08:16:56 +0100
Subject: Rechte und Pflichten zur Spamfilterung
In-Reply-To: <20190322110819.hq6aiilp7dtvgcym@sys4.de>
References: <017f73a6-c45e-7399-598b-8852cb0bb17e@gmx.de>
 <20190322110819.hq6aiilp7dtvgcym@sys4.de>
Message-ID: <36fce00d-1f02-0645-5eb8-7bad361a94c3@gmx.de>

Hallo,

Am 22.03.2019 um 12:08 schrieb Patrick Ben Koetter:
> Hallo Hajo,
>
> * Hajo Locke <postfixbuch-users at listen.jpberlin.de>:
>> viele von Euch kennen sicherlich dieses Dokument:
>> https://www.eco.de/wp-content/blogs.dir/28/files/gutachten_provider_gegen_spam2007_final.pdf
>> Nur eine kurze Frage dazu: Ist das so heute noch anwendbar oder hat sich
>> da signifikant etwas getan?
> nach meinem Kenntnisstand hat sich das nicht getan. Die dort vertretene
> Rechtsauffassung findet AFAIK immer noch Anwendung. Wenn es signifikaten
> Änderungen geben würde, würden wir (eco) das Gutachten erneuern.
Alles klar, danke. Schön wenn man sich so gegenseitig unterstützt und
auf etwas verlassen kann.
>
>
>> Speziell geht es mir um den Bereich der Rechte und Pflichten ausgehende
>> Mails einer Spamprüfung zu unterziehen und ablehnen zu dürfen. Mal provokant
>> gesagt: Haben eventuell Datenschutzbestimmungen so an Bedeutung gewonnen,
>> dass ausgehende Mails nicht mehr angefasst werden dürfen?
> Mein letzter Stand ist: Du darfst ausgehende Nachrichten automatisiert prüfen,
> wenn Du eine entsprechende, rechtliche Grundlage (z.B. Dienstvereinbarung)
> dafür geschaffen hast.
>
> Endgültiges und rechtlich Wirksames kann Dir natürlich nur ein zugelassender
> Anwalt sagen. Alle anderen (mich eingeschlossen) werden bei solchen Aussagen
> standesrechtlich er? mahnt. ;-)
>
> p at rick
> Kompetenzgruppenleiter E-Mail bei der eco
> <https://www.eco.de/themen/e-mail/>
>
>

Danke,
Hajo



From postfix_ml at rirasoft.de  Tue Mar 26 17:22:55 2019
From: postfix_ml at rirasoft.de (postfix_ml at rirasoft.de)
Date: Tue, 26 Mar 2019 17:22:55 +0100
Subject: major988 Loginversuche
Message-ID: <96a34a3c-2dd1-6892-1d56-daba33343bc5@rirasoft.de>

Hallo zusammen, 

in letzter Zeit tauchen sehr häufig in der /var/log/maillog folgende
Zeilen auf:

dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs):
user=<major988 at meine_domain.de>, method=PLAIN, rip=177.52.249.103,
lip=192.168.2.13, TLS, TLSv1.2 with cipher DHE-RSA-A 
ES256-GCM-SHA384 (256/256 bits) 

dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs):
user=<major988>, method=PLAIN, rip=177.128.209.58, lip=192.168.2.13,
TLS, TLSv1.2 with cipher DHE-RSA-AES256-GCM-SH 
A384 (256/256 bits) 

Immer mit wechselnden IP-Adressen. Ist ein da Bot im Internet unterwegs?


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

From driessen at fblan.de  Tue Mar 26 17:57:42 2019
From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Tue, 26 Mar 2019 17:57:42 +0100
Subject: AW: major988 Loginversuche
In-Reply-To: <96a34a3c-2dd1-6892-1d56-daba33343bc5@rirasoft.de>
References: <96a34a3c-2dd1-6892-1d56-daba33343bc5@rirasoft.de>
Message-ID: <018b01d4e3f5$074349d0$15c9dd70$@fblan.de>

> -----Ursprüngliche Nachricht-----
> Von: Postfixbuch-users [mailto:postfixbuch-users-
> bounces at listen.jpberlin.de] Im Auftrag von postfix_ml at rirasoft.de
> Gesendet: Dienstag, 26. März 2019 17:23
> An: postfixbuch-users at listen.jpberlin.de
> Betreff: major988 Loginversuche
> 
> Hallo zusammen,
> 
> in letzter Zeit tauchen sehr häufig in der /var/log/maillog folgende Zeilen auf:
> 
> dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs):
> user=<major988 at meine_domain.de>, method=PLAIN, rip=177.52.249.103,
> lip=192.168.2.13, TLS, TLSv1.2 with cipher DHE-RSA-A
> ES256-GCM-SHA384 (256/256 bits)
> dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs):
> user=<major988>, method=PLAIN, rip=177.128.209.58, lip=192.168.2.13, TLS,
> TLSv1.2 with cipher DHE-RSA-AES256-GCM-SH
> A384 (256/256 bits)
> 
> Immer mit wechselnden IP-Adressen. Ist ein da Bot im Internet unterwegs?
> 
> Gruß
> Andreas

Einer ??? 


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 





From michael at linuxfox.de  Tue Mar 26 18:10:13 2019
From: michael at linuxfox.de (Michael Grundmann)
Date: Tue, 26 Mar 2019 18:10:13 +0100
Subject: major988 Loginversuche
In-Reply-To: <96a34a3c-2dd1-6892-1d56-daba33343bc5@rirasoft.de>
References: <96a34a3c-2dd1-6892-1d56-daba33343bc5@rirasoft.de>
Message-ID: <e46b585b-81c2-837a-9f66-a247ab7317a6@linuxfox.de>

Am 26.03.19 um 17:22 schrieb postfix_ml at rirasoft.de:

Hallo Andreas,

ich setze an dieser Stelle auf fail2ban

> Hallo zusammen,
> 
> in letzter Zeit tauchen sehr häufig in der /var/log/maillog folgende 
> Zeilen auf:
> 
> dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): 
> user=<major988 at meine_domain.de>, method=PLAIN, rip=177.52.249.103, 
> lip=192.168.2.13, TLS, TLSv1.2 with cipher DHE-RSA-A
> ES256-GCM-SHA384 (256/256 bits)
> dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): 
> user=<major988>, method=PLAIN, rip=177.128.209.58, lip=192.168.2.13, 
> TLS, TLSv1.2 with cipher DHE-RSA-AES256-GCM-SH
> A384 (256/256 bits)
> Immer mit wechselnden IP-Adressen. Ist ein da Bot im Internet unterwegs?
> Gruß
> Andreas


-- 
Gruß Michael

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


From ad+lists at uni-x.org  Tue Mar 26 21:46:10 2019
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Tue, 26 Mar 2019 21:46:10 +0100
Subject: major988 Loginversuche
In-Reply-To: <e46b585b-81c2-837a-9f66-a247ab7317a6@linuxfox.de>
References: <96a34a3c-2dd1-6892-1d56-daba33343bc5@rirasoft.de>
 <e46b585b-81c2-837a-9f66-a247ab7317a6@linuxfox.de>
Message-ID: <882f3ff2-f708-34a1-31ef-b64b4cb88f79@uni-x.org>

Am 26.03.2019 um 18:10 schrieb Michael Grundmann:
> ich setze an dieser Stelle auf fail2ban

Das heißt, Du blockst bereits nach dem 1. Fehler? Ungeachtet dessen, 
dass dies problematisch ist, wenn Du eine Userbasis hast, was soll das 
bringen, wenn die zugreifenden Clients ständig wechseln, Client IP 
Adressen also ständig andere sind?

Alexander



From ad+lists at uni-x.org  Tue Mar 26 21:54:32 2019
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Tue, 26 Mar 2019 21:54:32 +0100
Subject: major988 Loginversuche
In-Reply-To: <96a34a3c-2dd1-6892-1d56-daba33343bc5@rirasoft.de>
References: <96a34a3c-2dd1-6892-1d56-daba33343bc5@rirasoft.de>
Message-ID: <d814cefe-684a-b064-15c8-0f3bf6bbcaf9@uni-x.org>



Am 26.03.2019 um 17:22 schrieb postfix_ml at rirasoft.de:
> Hallo zusammen,
> 
> in letzter Zeit tauchen sehr häufig in der /var/log/maillog folgende
> Zeilen auf:
> 
> dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs):
> user=<major988 at meine_domain.de>, method=PLAIN, rip=177.52.249.103,
> lip=192.168.2.13, TLS, TLSv1.2 with cipher DHE-RSA-A
> ES256-GCM-SHA384 (256/256 bits)
> 
> dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs):
> user=<major988>, method=PLAIN, rip=177.128.209.58, lip=192.168.2.13,
> TLS, TLSv1.2 with cipher DHE-RSA-AES256-GCM-SH
> A384 (256/256 bits)
> 
> Immer mit wechselnden IP-Adressen. Ist ein da Bot im Internet unterwegs?
> 
> 
> Gruß
> Andreas
> 

Ja, sehe ich auch bei mir in letzter Zeit. Interessant ist, dass 
wirklich immer neue Client IP Adressen aufschlagen. Die Frequenz ist bei 
mir klein, die Zahl der Usernamen, mit denen Logins versucht werden aber 
klein und zielsicher. Das ist kein blindes Brute Forcen der Loginkennungen.

Dafür sind die verwendeten Passwörter erschreckend einfältig. Ich habe 
mal einen überschaubaren Zeitraum raum lang dovecot im Debug Modus 
mitloggen lassen, um einen Eindruck zu erhalten, welche Muster die 
ausprobierten Passwörter zeigen.

~]# egrep -o '(SHA512-CRYPT\(.*\))' /var/log/maillog-20190324 | sort | 
uniq -c
       2 SHA512-CRYPT(00000000)
       1 SHA512-CRYPT(123qweasd)
       2 SHA512-CRYPT(a)
       1 SHA512-CRYPT(ad07)
       1 SHA512-CRYPT(ad1992)
       1 SHA512-CRYPT(ad2008)
       1 SHA512-CRYPT(ads)
       1 SHA512-CRYPT(alexander07)
       1 SHA512-CRYPT(alexander16)
       1 SHA512-CRYPT(alexander7)
       1 SHA512-CRYPT(amanda)
       1 SHA512-CRYPT(amores)
       1 SHA512-CRYPT(hunter)
       2 SHA512-CRYPT(jackson)
       1 SHA512-CRYPT(jennifer)
       2 SHA512-CRYPT(jesus)
       1 SHA512-CRYPT(michelle)
       2 SHA512-CRYPT(money)
       2 SHA512-CRYPT(mustang)
       1 SHA512-CRYPT(princess)
       1 SHA512-CRYPT(qwertyuiop)
       1 SHA512-CRYPT(rosemary)
       2 SHA512-CRYPT(test)
       1 SHA512-CRYPT(tigger)

Das mag nicht für alle Opfer repräsentativ sein und sich in Zukunft ändern.

Alexander


From michael at linuxfox.de  Wed Mar 27 07:23:09 2019
From: michael at linuxfox.de (Michael Grundmann)
Date: Wed, 27 Mar 2019 07:23:09 +0100
Subject: major988 Loginversuche
In-Reply-To: <882f3ff2-f708-34a1-31ef-b64b4cb88f79@uni-x.org>
References: <96a34a3c-2dd1-6892-1d56-daba33343bc5@rirasoft.de>
 <e46b585b-81c2-837a-9f66-a247ab7317a6@linuxfox.de>
 <882f3ff2-f708-34a1-31ef-b64b4cb88f79@uni-x.org>
Message-ID: <ab3cbbd9-0f50-d91a-c201-be58c970052a@linuxfox.de>

Am 26.03.19 um 21:46 schrieb Alexander Dalloz:
> Am 26.03.2019 um 18:10 schrieb Michael Grundmann:
>> ich setze an dieser Stelle auf fail2ban
> 
> Das heißt, Du blockst bereits nach dem 1. Fehler? Ungeachtet dessen, 
> dass dies problematisch ist, wenn Du eine Userbasis hast, was soll das 
> bringen, wenn die zugreifenden Clients ständig wechseln, Client IP 
> Adressen also ständig andere sind?
> 
> Alexander
> 
Hi,
wenn ich so eine spezielle Welle vor mir habe, schraube ich das 
tatsächlich auf eins runter. Ich lege ja nicht permanent neue Konten an, 
bei denen sich die User beim Einrichten vertippen.


-- 
Gruß Michael

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


From ffiene at veka.com  Wed Mar 27 20:18:46 2019
From: ffiene at veka.com (Frank Fiene)
Date: Wed, 27 Mar 2019 20:18:46 +0100
Subject: Rspamd mit dem alten Postfix-Reject
 reject_unknown_reverse_client_hostname
Message-ID: <309FBC5B-116D-4894-AD3B-6065E2EF5EC3@veka.com>

Hallo, ich würde gerne die Postfix-Regel reject_unknown_reverse_client_hostname <http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname> in Rspamd hart rejecten, also mit force actions.

Wenn ich es richtig verstehe, kann ich nur den hfilter benutzen, der aber auch FcrDNS beinhaltet, also den stärkeren reject_unknown_client_hostname <>

Wie kann man das machen?



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

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

From cr at ncxs.de  Thu Mar 28 12:48:08 2019
From: cr at ncxs.de (Carsten Rosenberg)
Date: Thu, 28 Mar 2019 12:48:08 +0100
Subject: Rspamd mit dem alten Postfix-Reject
 reject_unknown_reverse_client_hostname
In-Reply-To: <309FBC5B-116D-4894-AD3B-6065E2EF5EC3@veka.com>
References: <309FBC5B-116D-4894-AD3B-6065E2EF5EC3@veka.com>
Message-ID: <5068f685-7143-4d5f-8a5f-b7c3426f2905@ncxs.de>

Hallo Frank,

HFILTER_HOSTNAME_UNKNOWN macht genau das.

Es wird dort kein forward confirm gemacht sondern nur geprüft ob Postfix
via Milter Protokoll einen Hostnamen zur Client-IP gemeldet hat.

https://rspamd.com/doc/lua/rspamd_task.html#m8a697

Viele Grüße

Carsten

On 27.03.19 20:18, Frank Fiene wrote:
> Hallo, ich würde gerne die
> Postfix-Regel reject_unknown_reverse_client_hostname
> <http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname> in
> Rspamd hart rejecten, also mit force actions.
> 
> Wenn ich es richtig verstehe, kann ich nur den hfilter benutzen, der
> aber auch FcrDNS beinhaltet, also den
> stärkeren *reject_unknown_client_hostname*
> *
> *
> *Wie kann man das machen?*
> *
> *
> *
> *
> *
> *
> 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
> 


From ffiene at veka.com  Thu Mar 28 18:01:22 2019
From: ffiene at veka.com (Frank fiene)
Date: Thu, 28 Mar 2019 18:01:22 +0100
Subject: Rspamd mit dem alten Postfix-Reject
 reject_unknown_reverse_client_hostname
In-Reply-To: <5068f685-7143-4d5f-8a5f-b7c3426f2905@ncxs.de>
References: <309FBC5B-116D-4894-AD3B-6065E2EF5EC3@veka.com>
 <5068f685-7143-4d5f-8a5f-b7c3426f2905@ncxs.de>
Message-ID: <C4857788-0558-444F-93F8-E97039F986E9@veka.com>

Danke Carsten,

Dann steht das in der Datei hfilter_group.conf falsch:

"HFILTER_HOSTNAME_UNKNOWN" { 
        weight = 2.50; 
        description = "Unknown client hostname (PTR or FCrDNS verification failed)"; 
} 

Ich habe aber auch das Gefühl, dass es Falsee Positives gibt, das kann doch eigentlich nicht sein, oder?
Ich habe also mit host <ip> und host <hostname> getestet und es werden beide Richtungen aufgelöst. :-(

Viele Grüße! Frankl

-- 
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: 20419C64
PGP-Fingerprint: 93FB 5525 88C0 8F40 E7FD  EAB5 BBB4 435F 2041 9C64

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

> Am 28.03.2019 um 12:48 schrieb Carsten Rosenberg <cr at ncxs.de>:
> 
> HFILTER_HOSTNAME_UNKNOWN



From ffiene at veka.com  Thu Mar 28 18:03:13 2019
From: ffiene at veka.com (Frank fiene)
Date: Thu, 28 Mar 2019 18:03:13 +0100
Subject: Frage zu Rspamd und olefy
Message-ID: <C1CCF2FE-8B90-4135-B2D3-F6676206A01F@veka.com>

Noch eine weitere Frage:

Nachdem uns Carsten in der Schulung die oletools gezeigt hat, habe ich das mal konfiguriert.

Es kommen aber alle paar Sekunden Fehlermeldungen, die mich nervös machen, ob das überhaupt funktioniert. Ich habe die Konfiguration belassen wie im Standard.

Log:
ar 28 17:59:23 smtp1 rspamd[1991]: <>; ; lua_tcp_push_data: callback call failed: /usr/share/rspamd/lualib/lua_scanners/oletools
.lua:133: attempt to get length of field 'analysis' (a userdata value)

Was könnte das sein?

Viele Grüße! Frankl
-- 
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: 20419C64
PGP-Fingerprint: 93FB 5525 88C0 8F40 E7FD  EAB5 BBB4 435F 2041 9C64

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  Thu Mar 28 22:25:58 2019
From: cr at ncxs.de (Carsten Rosenberg)
Date: Thu, 28 Mar 2019 22:25:58 +0100
Subject: Rspamd mit dem alten Postfix-Reject
 reject_unknown_reverse_client_hostname
In-Reply-To: <C4857788-0558-444F-93F8-E97039F986E9@veka.com>
References: <309FBC5B-116D-4894-AD3B-6065E2EF5EC3@veka.com>
 <5068f685-7143-4d5f-8a5f-b7c3426f2905@ncxs.de>
 <C4857788-0558-444F-93F8-E97039F986E9@veka.com>
Message-ID: <b9ed478f-eac4-667f-3b93-eb54bf2334f0@ncxs.de>

Hey,

sorry, ich lag falsch. Die description ist richtig. Postfix übermittelt
in dem verwendeten {client_name} nur den FcrDNS oder unknown.

Es gibt auch den einfachen {client_ptr} aber der wird per default nicht
übermittelt und vom Rspamd nicht ausgewertet.

http://www.postfix.org/MILTER_README.html

Ich find die einfache Variante aber auch sinnvoll. Ich schau mal wie man
das am Sinnvollsten mit rein bekommt.

VG c

On 28.03.19 18:01, Frank fiene wrote:
> Danke Carsten,
> 
> Dann steht das in der Datei hfilter_group.conf falsch:
> 
> "HFILTER_HOSTNAME_UNKNOWN" { 
>         weight = 2.50; 
>         description = "Unknown client hostname (PTR or FCrDNS verification failed)"; 
> } 
> 
> Ich habe aber auch das Gefühl, dass es Falsee Positives gibt, das kann doch eigentlich nicht sein, oder?
> Ich habe also mit host <ip> und host <hostname> getestet und es werden beide Richtungen aufgelöst. :-(
> 
> Viele Grüße! Frankl
> 


From cr at ncxs.de  Thu Mar 28 22:36:49 2019
From: cr at ncxs.de (Carsten Rosenberg)
Date: Thu, 28 Mar 2019 22:36:49 +0100
Subject: Frage zu Rspamd und olefy
In-Reply-To: <C1CCF2FE-8B90-4135-B2D3-F6676206A01F@veka.com>
References: <C1CCF2FE-8B90-4135-B2D3-F6676206A01F@veka.com>
Message-ID: <868d30de-ad7e-99c4-628d-731d90d63ee8@ncxs.de>

Hallo Frank,

da fehlen wohl noch 1-2 Fehlerabfragen. Wir grübeln noch ein bißchen ob
wir bei dem Ansatz bleiben, gleich auf HTTP gehen oder doch auf sowas
wie Laikaboss setzen. Wenn das klar ist, wird das auch sattelfest gemacht.

Du hast bestimmt kein Debian und dein Python3 Pfad ist anders. Schau mal
in der /etc/olefy.conf

journalctl -u olefy sollte dir auch Fehlermeldungen dazu ausgeben.

Ich hab in unser olefy.py Skript eine Abfrage dazu eingebaut. Das
startet jetzt gar nicht mehr wenn die Pfade nicht passen.

Viele Grüße

Carsten

On 28.03.19 18:03, Frank fiene wrote:
> Noch eine weitere Frage:
> 
> Nachdem uns Carsten in der Schulung die oletools gezeigt hat, habe ich das mal konfiguriert.
> 
> Es kommen aber alle paar Sekunden Fehlermeldungen, die mich nervös machen, ob das überhaupt funktioniert. Ich habe die Konfiguration belassen wie im Standard.
> 
> Log:
> ar 28 17:59:23 smtp1 rspamd[1991]: <>; ; lua_tcp_push_data: callback call failed: /usr/share/rspamd/lualib/lua_scanners/oletools
> .lua:133: attempt to get length of field 'analysis' (a userdata value)
> 
> Was könnte das sein?
> 
> Viele Grüße! Frankl
> 


From ffiene at veka.com  Fri Mar 29 12:03:04 2019
From: ffiene at veka.com (Frank Fiene)
Date: Fri, 29 Mar 2019 12:03:04 +0100
Subject: Frage zu Rspamd und olefy
In-Reply-To: <868d30de-ad7e-99c4-628d-731d90d63ee8@ncxs.de>
References: <C1CCF2FE-8B90-4135-B2D3-F6676206A01F@veka.com>
 <868d30de-ad7e-99c4-628d-731d90d63ee8@ncxs.de>
Message-ID: <A8FA04BA-4787-4B05-8997-950E2D3EE3F6@veka.com>

Ich habe mir mal die neue Version gepullt.

BTW: du könntest noch in die Readme einfügen, dass man User und Gruppe anlegen sollte.

Pfade passen, ist Ubuntu.

root at smtp1:/usr/src/olefy# which python3
/usr/bin/python3


Jetzt kommen noch zusätzlich (wahrscheinlich wurden die ersten Dateien zum olefy geschickt):

Mar 29 11:55:46 smtp1 rspamd[1993]: <4fa1f2>; lua; oletools.lua:72: oletools: failed to scan, maximum retransmits exceed - err: Socket error detected: Connection refused
Mar 29 11:55:46 smtp1 rspamd[1993]: <4fa1f2>; lua; common.lua:90: oletools: office macro found: "failed to scan, maximum retransmits exceed - err: Socket error detected: Connection refused - score: 0"


Prozess läuft:
22327 ?        Ss     0:00 /usr/bin/python3 /usr/local/bin/olefy.py

Telnet auf den Port 10050 geht auch, ich weiß aber nicht, ob man den mit Texteingaben zu einer Reaktion bringen kann.



Jetzt hab ich noch den hier gesehen, ist der neu?

Mar 29 11:59:36 smtp1 python3[22327]: olefy ERROR eof_received Protocol ERROR: no OLEFY/1.0 found)


Viele Grüße! Frank


> Am 28.03.2019 um 22:36 schrieb Carsten Rosenberg <cr at ncxs.de>:
> 
> Hallo Frank,
> 
> da fehlen wohl noch 1-2 Fehlerabfragen. Wir grübeln noch ein bißchen ob
> wir bei dem Ansatz bleiben, gleich auf HTTP gehen oder doch auf sowas
> wie Laikaboss setzen. Wenn das klar ist, wird das auch sattelfest gemacht.
> 
> Du hast bestimmt kein Debian und dein Python3 Pfad ist anders. Schau mal
> in der /etc/olefy.conf
> 
> journalctl -u olefy sollte dir auch Fehlermeldungen dazu ausgeben.
> 
> Ich hab in unser olefy.py Skript eine Abfrage dazu eingebaut. Das
> startet jetzt gar nicht mehr wenn die Pfade nicht passen.
> 
> Viele Grüße
> 
> Carsten
> 
> On 28.03.19 18:03, Frank fiene wrote:
>> Noch eine weitere Frage:
>> 
>> Nachdem uns Carsten in der Schulung die oletools gezeigt hat, habe ich das mal konfiguriert.
>> 
>> Es kommen aber alle paar Sekunden Fehlermeldungen, die mich nervös machen, ob das überhaupt funktioniert. Ich habe die Konfiguration belassen wie im Standard.
>> 
>> Log:
>> ar 28 17:59:23 smtp1 rspamd[1991]: <>; ; lua_tcp_push_data: callback call failed: /usr/share/rspamd/lualib/lua_scanners/oletools
>> .lua:133: attempt to get length of field 'analysis' (a userdata value)
>> 
>> Was könnte das sein?
>> 
>> Viele Grüße! Frankl
>> 

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/20190329/fc37fbd8/attachment.htm>