From lists at xunil.at Mon Jul 1 07:45:12 2019 From: lists at xunil.at (Stefan G. Weichinger) Date: Mon, 1 Jul 2019 07:45:12 +0200 Subject: Rspamd Grundsatzfrage? In-Reply-To: <335d2c62-64ae-ce54-03f6-e0c78947c507@ncxs.de> References: <2171741.LxjekthhAQ@techz> <55786760.6fbtKWpXNd@merkaba> <335d2c62-64ae-ce54-03f6-e0c78947c507@ncxs.de> Message-ID: <1785ea86-3c9b-e7c6-4e3d-149aefff96dd@xunil.at> Am 30.06.19 um 16:40 schrieb Carsten Rosenberg: > On 30.06.19 11:34, Martin Steigerwald wrote: >> Hi Stefan. >> >> Stefan G. Weichinger - 30.06.19, 11:01: >>> Am 17.06.19 um 09:30 schrieb André Peters: >>>> Vor allem kann es auch alles. Da braucht es fast nichts Externes. >>>> Abgesehen von AVs etc. >>>> >>>> Was fehlt, kann via LUA API integriert werden. >>> >>> Ad "alles": >>> >>> ein Kunde von mir hat nach GeoIP-Scoring gefragt, er möchte etwas ala >>> >>> wenn aus IP-Range RUS/China/oä., dann höher scoren, bzw. wegsortieren >>> in Ordner "Verdächtig" >>> >>> Ich hab noch nicht detailliert geforscht, auf die Schnelle aber nix >>> eindeutig passendes gefunden bei rspamd. > > Multimap mit map type Country. > > https://rspamd.com/doc/modules/multimap.html#map-types ah, nice, danke für den Link From dirk.jakobsmeier at wige.com Tue Jul 2 06:29:41 2019 From: dirk.jakobsmeier at wige.com (Dirk Jakobsmeier) Date: Tue, 2 Jul 2019 06:29:41 +0200 Subject: [ext] Re: seit gestern "poor reputation" In-Reply-To: <20190627095353.csgvn4hoqws3gxwg@charite.de> References: <20190626075045.GB27968@neumodr.wige.com> <20190627085633.GA4798@neumodr.wige.com> <20190627095353.csgvn4hoqws3gxwg@charite.de> Message-ID: <20190702042941.GA13791@neumodr.wige.com> Hallo, ich war ein paar Tage nicht im Büro, melde mich deshalb jetzt erst wieder. Das Problem ist nicht wieder aufgetaucht, den Absender der Mail konnte ich jedoch auch noch nicht wegen der u.U. falschen Mailadresse befragen. Das Problem würde ich auch beim Empfänger sehen da dieser einen Fehler zurück meldet der nicht "Rückmeldenswert" ist. Wo soll denn sowas hinführen. Nur - schon mal versucht bei einem solchen Konzern dahingehend etwas zu erreichen? Keine Chance. Solche Konzerne löschen auch ungefragt Attachments aus e-Mails und erst nach Wochen fällt dann entweder dem Absender oder dem Empfänger etwas auf. Auch werden teilweise e-Mails erst angenommen, status=sent, und dann z.B. bei Spamverdacht einfach entsorgt ohne den Empfänger zu benachrichtigen. Auch der Absender erhält dann natürlich keine Info mehr. Große Konzerne schreiben trotz RFC's ihre eigenen Regeln. On Thu, Jun 27, 2019 at 11:53:55AM +0200, Ralf Hildebrandt wrote: > * Dirk Jakobsmeier : > > Hallo Zusammen, > > > > holla die Waldfee, die Reputation ist auf Neutral. > > > > talosintelligence sagt dass das System nicht manuell zu ändern ist, wenn einer drin ist, ist er drin. Ursache dürfte meiner Meinung nach eine > > > > --- falsche e-Mailadresse --- > > > > ja, wirklich, keine falsch formatierte oder sowas, einfach eine falsche Adresse. Die wird über den Spooler natürlich mehrfach zugestellt und nach dem zweiten Versuch kommt dann die Einstufung auf "poor". Das muss ich derzeit leider aus meinen Logfiles schliessen. > > > > Jun 25 11:51:30 relay=two.mail-in.daimler.com[141.113.8.25]:25, delay=1.7, delays=0.09/0.01/1.5/0.08, dsn=4.0.0, status=deferred (host two.mail-in.daimler.com[141.113.8.25] said: 451 #4.1.2 Requested action aborted: Validation error validating destination mailbox address. (in reply to RCPT TO command)) > > Jun 25 11:58:35 relay=one.mail-in.daimler.com[141.113.0.25]:25, delay=427, delays=426/0.01/0.84/0.09, dsn=4.0.0, status=deferred (host one.mail-in.daimler.com[141.113.0.25] said: 451 #4.1.2 Requested action aborted: Validation error validating destination mailbox address. (in reply to RCPT TO command)) > > Jun 25 12:08:34 relay=mail-in.daimler.com[141.113.0.26]:25, delay=1026, delays=1026/0.01/0.6/0, dsn=4.0.0, status=deferred (host mail-in.daimler.com[141.113.0.26] refused to talk to me: 554-one.mail-in.daimler.com 554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. I > > Wobei da das Problem bei Daimler liegt, denn warum geben die einen > temporären Fehler zurück? > > Was du gegen solche Setups machen kannst: > > smtp_reply_filter = pcre:/etc/postfix/smtp_reply_filter.pcre > > /^450 4\.1\.1 (<.*@dhzb\.de>: Recipient address rejected: User unknown in relay recipient table.*)/ 554 5.1.1 ${1} > > -- > Ralf Hildebrandt > Geschäftsbereich IT | Abteilung Netzwerk > Charité - Universitätsmedizin Berlin > Campus Benjamin Franklin > Hindenburgdamm 30 | D-12203 Berlin > Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 > ralf.hildebrandt at charite.de | https://www.charite.de > -- Mit freundlichem Gruß Dirk Jakobsmeier Tel.: +49 751 36609-29 Fax: +49 751 36609-66 Mail: Dirk.Jakobsmeier at wige.com WIGE Konstruktionen GmbH & Co. KG Persönlich haftende Gesellschafterin: Sitz Ravensburg WIGE Konstruktionen Verwaltungsgesellschaft mbH Amtsgericht Ravensburg HRA Nr. 1493 Amtsgericht Ravensburg HRB Nr. 2534 Schwanenstrasse 4, 88214 Ravensburg Geschäftsführer: Thomas & Jochen Geschwentner Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly forbidden. Before printing, think about ENVIRONMENTAL responsibility From Hajo.Locke at gmx.de Wed Jul 3 09:19:28 2019 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Wed, 3 Jul 2019 09:19:28 +0200 Subject: Frage zu postfix-policyd-spf-python Message-ID: <24178a50-da2c-1651-db7c-9c14663661f6@gmx.de> Hallo Liste, ich teste gerade unter Ubuntu postfix-policyd-spf-python in Postfix einzubinden. Ich nehme an diese Software verwenden einige von Euch. Prinzipiell ist das nicht schwer und es funktioniert. Ich wollte erst mal einen Testlauf machen und beobachten. Dazu hat der postfix-policyd-spf-python die Option defaultSeedOnly. Auf 0 gesetzt soll dies ein Testmodus sein, die SPF Erkenntnisse werden in den Header gepackt, die Mail aber trotzdem bei einem Fail durchgelassen. Letzteres funktioniert, Headereinträge finde ich nicht. Kann der Dienst überhaupt den Header der Mail ändern, wenn er über die master.cf als service angebunden ist? Typische Installation sieht so aus: https://www.netways.de/blog/2017/11/15/postfix-spf-dkim-und-dmarc/ (oben) Müsste es nicht ein milter sein, um den Header der Mail verändern zu können. Ich hab auch mal die neueste Version probiert. Laut Readme im Paket heißt die Option dann TestOnly, der Dienst im Paket kennt dies aber nicht. Was sagt Ihr dazu? Danke, Hajo From juri at koschikode.com Wed Jul 3 09:58:23 2019 From: juri at koschikode.com (Juri Haberland) Date: Wed, 3 Jul 2019 09:58:23 +0200 Subject: Frage zu postfix-policyd-spf-python In-Reply-To: <24178a50-da2c-1651-db7c-9c14663661f6@gmx.de> References: <24178a50-da2c-1651-db7c-9c14663661f6@gmx.de> Message-ID: <638ebc2d-f472-f0ed-e4c7-a0fae80768c3@koschikode.com> On 03/07/2019 09:19, Hajo Locke wrote: > Hallo Liste, > > ich teste gerade unter Ubuntu postfix-policyd-spf-python in Postfix > einzubinden. Ich nehme an diese Software verwenden einige von Euch. > Prinzipiell ist das nicht schwer und es funktioniert. > Ich wollte erst mal einen Testlauf machen und beobachten. Dazu hat der > postfix-policyd-spf-python die Option defaultSeedOnly. > Auf 0 gesetzt soll dies ein Testmodus sein, die SPF Erkenntnisse werden > in den Header gepackt, die Mail aber trotzdem bei einem Fail durchgelassen. > Letzteres funktioniert, Headereinträge finde ich nicht. Kann der Dienst > überhaupt den Header der Mail ändern, wenn er über die master.cf als > service angebunden ist? > Typische Installation sieht so aus: > https://www.netways.de/blog/2017/11/15/postfix-spf-dkim-und-dmarc/ (oben) > Müsste es nicht ein milter sein, um den Header der Mail verändern zu können. > Ich hab auch mal die neueste Version probiert. Laut Readme im Paket > heißt die Option dann TestOnly, der Dienst im Paket kennt dies aber nicht. > > Was sagt Ihr dazu? Nein, auch ein policy-Daemon kann Header einfügen. Suche nach Received-SPF oder Authentication-Results, je nachdem, was du für Header_Type gesetzt hast. Ich würde hier AR empfehlen. Bei defaultSeedOnly=0 bin ich mir nach der Beschreibung in der example.conf nicht sicher, ob die Mail überhaupt angefaßt wird und das Ergebnis nur im Log zu sehen ist. Wenn dem so ist, kannst du auch folgendes machen: defaultSeedOnly = 1 HELO_reject = False Mail_From_reject = False PermError_reject = False TempError_Defer = False Header_Type = AR Gruß, Juri From Hajo.Locke at gmx.de Wed Jul 3 11:05:19 2019 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Wed, 3 Jul 2019 11:05:19 +0200 Subject: Frage zu postfix-policyd-spf-python In-Reply-To: <638ebc2d-f472-f0ed-e4c7-a0fae80768c3@koschikode.com> References: <24178a50-da2c-1651-db7c-9c14663661f6@gmx.de> <638ebc2d-f472-f0ed-e4c7-a0fae80768c3@koschikode.com> Message-ID: Hallo, Am 03.07.2019 um 09:58 schrieb Juri Haberland: > On 03/07/2019 09:19, Hajo Locke wrote: >> Hallo Liste, >> >> ich teste gerade unter Ubuntu postfix-policyd-spf-python in Postfix >> einzubinden. Ich nehme an diese Software verwenden einige von Euch. >> Prinzipiell ist das nicht schwer und es funktioniert. >> Ich wollte erst mal einen Testlauf machen und beobachten. Dazu hat der >> postfix-policyd-spf-python die Option defaultSeedOnly. >> Auf 0 gesetzt soll dies ein Testmodus sein, die SPF Erkenntnisse werden >> in den Header gepackt, die Mail aber trotzdem bei einem Fail durchgelassen. >> Letzteres funktioniert, Headereinträge finde ich nicht. Kann der Dienst >> überhaupt den Header der Mail ändern, wenn er über die master.cf als >> service angebunden ist? >> Typische Installation sieht so aus: >> https://www.netways.de/blog/2017/11/15/postfix-spf-dkim-und-dmarc/ (oben) >> Müsste es nicht ein milter sein, um den Header der Mail verändern zu können. >> Ich hab auch mal die neueste Version probiert. Laut Readme im Paket >> heißt die Option dann TestOnly, der Dienst im Paket kennt dies aber nicht. >> >> Was sagt Ihr dazu? > Nein, auch ein policy-Daemon kann Header einfügen. Suche nach Received-SPF > oder Authentication-Results, je nachdem, was du für Header_Type gesetzt > hast. Ich würde hier AR empfehlen. > > Bei defaultSeedOnly=0 bin ich mir nach der Beschreibung in der example.conf > nicht sicher, ob die Mail überhaupt angefaßt wird und das Ergebnis nur im > Log zu sehen ist. Wenn dem so ist, kannst du auch folgendes machen: > > defaultSeedOnly = 1 > HELO_reject = False > Mail_From_reject = False > PermError_reject = False > TempError_Defer = False > Header_Type = AR > > > Gruß, > Juri > Du hast Recht, mit der Config geht es. Ich habe mich wohl von der manpage zu defaultSeedOnly verwirren lassen: "...Headers are prepended in messages..." Ich bin aber weiterhin der Meinung, dass nicht der policyd selbst die Header einfügt, sondern das Postfix nur die response verwertet. Danke, Hajo From juri at koschikode.com Wed Jul 3 16:07:50 2019 From: juri at koschikode.com (Juri Haberland) Date: Wed, 3 Jul 2019 16:07:50 +0200 Subject: Frage zu postfix-policyd-spf-python In-Reply-To: References: <24178a50-da2c-1651-db7c-9c14663661f6@gmx.de> <638ebc2d-f472-f0ed-e4c7-a0fae80768c3@koschikode.com> Message-ID: <433e1510-8cdc-28d1-7056-727f3fa01abe@koschikode.com> Hallo Hajo, On 03/07/2019 11:05, Hajo Locke wrote: > Am 03.07.2019 um 09:58 schrieb Juri Haberland: >> defaultSeedOnly = 1 >> HELO_reject = False >> Mail_From_reject = False >> PermError_reject = False >> TempError_Defer = False >> Header_Type = AR > Du hast Recht, mit der Config geht es. Ich habe mich wohl von der > manpage zu defaultSeedOnly verwirren lassen: "...Headers are prepended > in messages..." > Ich bin aber weiterhin der Meinung, dass nicht der policyd selbst die > Header einfügt, sondern das Postfix nur die response verwertet. du hast insofern Recht, als dass das policyd-Protokoll von Postfix den Befehl "PREPEND headername: headertext" kennt, wodurch dann von Postfix der entsprechende Header und Inhalt der Mail vorangestellt wird - der Policy-Daemon bekommt den Inhalt der Mail nicht zu sehen, sondern nur Metadaten... Gruß, Juri From gjn at gjn.priv.at Sat Jul 13 15:03:58 2019 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sat, 13 Jul 2019 15:03:58 +0200 Subject: rspamd opensuse.org Message-ID: <2286850.ZeneayqdfO@techz> Hallo, eine Frage an die Profis ;-) kann mir jemand sagen warum rspamd Probleme mit opensuse Mailinglisten hat. Ich habe etliche Mails die als Spam eingestuft werden von opensuse.org Bei rspamd gibt es ja eine liste wo Mailinglisten eingetragen werden, das hätte ich auch getan ABER... Etwas eigenartig da anscheinend nur opensuse.org Mailinglisten Probleme machen. Bei den anderen ist es mir noch nicht aufgefallen. Danke für eine Antwort, -- mit freundliche Grüßen / best regards, Günther J. Niederwimmer From andre.peters at debinux.de Sat Jul 13 15:05:30 2019 From: andre.peters at debinux.de (=?utf-8?q?Andr=c3=a9=20Peters?=) Date: Sat, 13 Jul 2019 13:05:30 +0000 Subject: rspamd opensuse.org In-Reply-To: <2286850.ZeneayqdfO@techz> References: <2286850.ZeneayqdfO@techz> Message-ID: Poste doch mal die Symbole. :) Bestimmt DKIM putt. ------ Originalnachricht ------ Von: "Günther J. Niederwimmer" An: postfixbuch-users at listi.jpberlin.de Gesendet: 13.07.2019 15:03:58 Betreff: rspamd opensuse.org >Hallo, > >eine Frage an die Profis ;-) > >kann mir jemand sagen warum rspamd Probleme mit opensuse Mailinglisten hat. > >Ich habe etliche Mails die als Spam eingestuft werden von opensuse.org > >Bei rspamd gibt es ja eine liste wo Mailinglisten eingetragen werden, das >hätte ich auch getan ABER... > >Etwas eigenartig da anscheinend nur opensuse.org Mailinglisten Probleme >machen. Bei den anderen ist es mir noch nicht aufgefallen. > >Danke für eine Antwort, >-- >mit freundliche Grüßen / best regards, > > Günther J. Niederwimmer > > From news.listener at googlemail.com Sat Jul 13 20:39:12 2019 From: news.listener at googlemail.com (Nobody is Perfekt) Date: Sat, 13 Jul 2019 20:39:12 +0200 Subject: Postfix Umzug auf DMZ / ports 465 & 587 weiterleiten von Public auf Private IP Message-ID: Servus ! Mein Vorhaben: Postfix Umzug auf DMZ / ports 465 & 587 weiterleiten von Public auf Private IP Für IMAP / IMAPs & POPs setze ich Perdition, aber wie mache ich mit SMTPS & SUBMISSION (465 & 587) ? Danke für Euer Tips From karol at babioch.de Sat Jul 13 22:50:54 2019 From: karol at babioch.de (Karol Babioch) Date: Sat, 13 Jul 2019 22:50:54 +0200 Subject: Postfix Umzug auf DMZ / ports 465 & 587 weiterleiten von Public auf Private IP In-Reply-To: References: Message-ID: Hallo, Am 13.07.19 um 20:39 schrieb Nobody is Perfekt: > Danke für Euer Tips Erster Tipp: Vernünftige Frage(n) stellen, und die Ausgangslage nachvollziehbar beschreiben. Mit den bisherigen Vorgaben dürfte quasi niemandem klar sein worum es geht und was dein Problem ist. Ports kann man "weiterleiten" (Stichwort: DNAT). Dabei gibt es bei Mailservern aber Dinge zu beachten, siehe z.B. [1]. Mit freundlichen Grüßen, Karol Babioch [1]: http://www.postfix.org/BASIC_CONFIGURATION_README.html#proxy_interfaces -------------- 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 : From gjn at gjn.priv.at Mon Jul 15 14:20:03 2019 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Mon, 15 Jul 2019 14:20:03 +0200 Subject: rspamd opensuse.org In-Reply-To: References: <2286850.ZeneayqdfO@techz> Message-ID: <5340576.0THaAKLOoS@techz> Hallo, Am Samstag, 13. Juli 2019, 15:05:30 CEST schrieb André Peters: > Poste doch mal die Symbole. :) Bestimmt DKIM putt. Jetzt habe ich endlich eine Abgewiesene Mail gefunden 2019-07-15 11:36:27 #3110(rspamd_proxy) <591aef>; proxy; rspamd_task_write_log: id: , qid: , ip: 195.135.221.145, from: , (default: T (reject): [16.55/15.00] [BROKEN_HEADERS(10.00){},BAYES_SPAM(7.71) {98.79%;},IP_SCORE(-2.13){ip: (-5.70), ipnet: 195.135.220.0/22(-2.86), asn: 29298(-2.10), country: DE(-0.03);},FORGED_RECIPIENTS(2.00){opensuse- de at opensuse.org;gjn at gjn.priv.at;},SIGNED_SMIME(-2.00){},AUTH_NA(1.00) {},FORGED_SENDER(0.30){werner.flamme at ufz.de;opensuse- de at opensuse.org;},MIME_GOOD(-0.20){multipart/signed;text/ plain;},RCVD_IN_DNSWL_MED(-0.20){145.221.135.195.list.dnswl.org : 127.0.9.2;},RCVD_NO_TLS_LAST(0.10){},HAS_LIST_UNSUB(-0.01){},MX_GOOD(-0.01) {mx1.suse.de;mx2.suse.de;},ARC_NA(0.00){},ASN(0.00){asn:29298, ipnet: 195.135.220.0/22, country:DE;},DMARC_NA(0.00){ufz.de;},FROM_HAS_DN(0.00) {},FROM_NEQ_ENVFROM(0.00){werner.flamme at ufz.de;opensuse- de at opensuse.org;},HAS_ATTACHMENT(0.00){},MID_RHS_MATCH_FROM(0.00) {},MIME_TRACE(0.00){0:+;1:+;2:~;3:+;},PRECEDENCE_BULK(0.00) {},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_TWELVE(0.00) {12;},RCVD_VIA_SMTP_AUTH(0.00){},R_DKIM_NA(0.00){},R_SPF_NA(0.00) {},TAGGED_FROM(0.00){bounces-106112-gjn=gjn.priv.at;},TO_DN_NONE(0.00){}]), len: 13555, time: 700.260ms real, 19.935ms virtual, dns req: 22, digest: , rcpts: , mime_rcpts: Was ich noch gefunden habe für opensuse.org werden die meisten Mails mit 2019-07-15 13:44:07 #3110(rspamd_proxy) <10d5a5>; proxy; rspamd_task_write_log: id: <3f1f45b1-7532-41eb-a439-9c6229bf09ec at zawodsky.at>, qid: <1896D1F99E>, ip: 2620:113:80c0:8::18, from: , (default: F (soft reject): [6.97/15.00] [BAYES_SPAM(3.89) {90.71%;},FORGED_RECIPIENTS(2.00){opensuse- de at opensuse.org;gjn at gjn.priv.at;},AUTH_NA(1.00){},FORGED_SENDER(0.30) {norbert at zawodsky.at;opensuse-de at opensuse.org;},IP_SCORE(-0.20){ip: (0.72), ipnet: 2620:113:80c0::/48(0.38), asn: 29298(-2.10), country: DE(-0.03);},MIME_GOOD(-0.10){text/plain;},RCVD_NO_TLS_LAST(0.10) {},HAS_LIST_UNSUB(-0.01){},MX_GOOD(-0.01){cached: mx1.suse.de;},ARC_NA(0.00) {},ASN(0.00){asn:29298, ipnet:2620:113:80c0::/48, country:DE;},DMARC_NA(0.00) {zawodsky.at;},FROM_HAS_DN(0.00){},FROM_NEQ_ENVFROM(0.00) {norbert at zawodsky.at;opensuse-de at opensuse.org;},GREYLIST(0.00){greylisted;Mon, 15 Jul 2019 11:49:07 GMT;new record;},MID_RHS_MATCH_FROM(0.00) {},MIME_TRACE(0.00){0:+;},PRECEDENCE_BULK(0.00){},RCPT_COUNT_ONE(0.00) {1;},RCVD_COUNT_SEVEN(0.00){9;},R_DKIM_NA(0.00){},R_SPF_NA(0.00) {},TAGGED_FROM(0.00){bounces-106113-gjn=gjn.priv.at;},TO_DN_NONE(0.00){}]), len: 4149, time: 940.387ms real, 18.160ms virtual, dns req: 23, digest: <25a9c90ad23b85bdf5e83682320562e3>, rcpts: , mime_rcpts: , forced: soft reject "Try again later"; score=nan (set by greylist) in die Warteschleife geschickt ? Warum ist das eigentlich nur bei opensuse.org? Ich verstehe von dem ganzen noch zu wenig damit ich da was ändern könnte :-(. -- mit freundliche Grüßen / best regards, Günther J. Niederwimmer From philipp at trulson.de Wed Jul 17 13:19:47 2019 From: philipp at trulson.de (Philipp Trulson) Date: Wed, 17 Jul 2019 13:19:47 +0200 Subject: =?UTF-8?Q?Kein_Versand_von_Push-Mails_von_Fritzbox_m=c3=b6glich?= Message-ID: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> Hallo liebe Liste, ich betreibe nun seit einer Weile den Stack von mailcow [1] (beinhaltet Postfix 3.3.0 von Ubuntu 18.04) mit Docker und hatte bisher auch keinerlei Probleme damit. Nun wollte ich den Versand von Push-Mails meiner Fritz!Box einrichten, scheitere aber leider komplett daran. Mein Verdacht liegt darin, dass der Mail-Client der Fritz!Box die modernen Ciphers nicht unterstützt, da ich folgende Logausgabe bekomme: Jul 17 13:06:27 mail postfix/smtpd[378]: connect from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] Jul 17 13:06:27 mail postfix/smtpd[378]: setting up TLS connection from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] Jul 17 13:06:27 mail postfix/smtpd[378]: p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:before SSL initialization Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:before SSL initialization Jul 17 13:06:27 mail postfix/smtpd[378]: SSL3 alert write:fatal:handshake failure Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:error in error Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept error from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187]: -1 Jul 17 13:06:27 mail postfix/smtpd[378]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2253: Jul 17 13:06:27 mail postfix/smtpd[378]: lost connection after CONNECT from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] Jul 17 13:06:27 mail postfix/smtpd[378]: disconnect from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] commands=0/0 Aber das kann doch irgendwie nicht sein, sonst wäre ich nicht der erste mit diesem Problem. Die verwendete main.cf [2] hat zwar die "high" Ciphers gesetzt, aber selbst wenn ich viel auskommentiere und damit die Defaults benutze klappt es nicht. Hat jemand eine Idee was ich noch probieren könnte? Mit AVM stehe ich schon in Kontakt, aber dort hat man die Ciphers nur als Verbesserungsvorschlag entgegen genommen und konnte mir nicht sagen, welche unterstützt werden. Viele Grüße, Philipp [1] https://github.com/mailcow/mailcow-dockerized [2] https://raw.githubusercontent.com/mailcow/mailcow-dockerized/master/data/conf/postfix/main.cf -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From stse+postfixbuch at fsing.rootsland.net Wed Jul 17 13:28:56 2019 From: stse+postfixbuch at fsing.rootsland.net (Stephan Seitz) Date: Wed, 17 Jul 2019 13:28:56 +0200 Subject: Kein Versand von =?iso-8859-1?Q?Push-M?= =?iso-8859-1?Q?ails_von_Fritzbox_m=F6glich?= In-Reply-To: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> References: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> Message-ID: <20190717T132735.GA.ac7d1.stse@fsing.rootsland.net> On Mi, Jul 17, 2019 at 01:19:47 +0200, Philipp Trulson wrote: >ich betreibe nun seit einer Weile den Stack von mailcow > [1] (beinhaltet Postfix >3.3.0 von Ubuntu 18.04) mit Docker und hatte bisher auch keinerlei Kannst du da mit tshark/tcpdump mitschnüffeln? Dann könnte man im SSL-Handshake sehen, welche Ciphers die Fritzbox im Client Hello mitschickt. 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 : From andre.peters at debinux.de Wed Jul 17 13:55:56 2019 From: andre.peters at debinux.de (=?utf-8?q?Andr=C3=A9?= Peters) Date: Wed, 17 Jul 2019 13:55:56 +0200 Subject: =?utf-8?Q?Re:_Kein_Versand_von_Push-Mails_von_Fritzbox_m=C3=B6gl?= =?utf-8?Q?ich?= In-Reply-To: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> References: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> Message-ID: Hi, will die Box etwa SSLv3 verwenden? :) Ist es eine ältere Fritzbox? Kann dir testweise eine Mailbox auf meiner Testmaschine einrichten. Viele Grüße André > Am 17.07.2019 um 13:19 schrieb Philipp Trulson : > > Hallo liebe Liste, > > ich betreibe nun seit einer Weile den Stack von mailcow [1] (beinhaltet Postfix 3.3.0 von Ubuntu 18.04) mit Docker und hatte bisher auch keinerlei Probleme damit. Nun wollte ich den Versand von Push-Mails meiner Fritz!Box einrichten, scheitere aber leider komplett daran. Mein Verdacht liegt darin, dass der Mail-Client der Fritz!Box die modernen Ciphers nicht unterstützt, da ich folgende Logausgabe bekomme: > > Jul 17 13:06:27 mail postfix/smtpd[378]: connect from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] > Jul 17 13:06:27 mail postfix/smtpd[378]: setting up TLS connection from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] > Jul 17 13:06:27 mail postfix/smtpd[378]: p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:before SSL initialization > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:before SSL initialization > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL3 alert write:fatal:handshake failure > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:error in error > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept error from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187]: -1 > Jul 17 13:06:27 mail postfix/smtpd[378]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2253: > Jul 17 13:06:27 mail postfix/smtpd[378]: lost connection after CONNECT from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] > Jul 17 13:06:27 mail postfix/smtpd[378]: disconnect from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] commands=0/0 > > Aber das kann doch irgendwie nicht sein, sonst wäre ich nicht der erste mit diesem Problem. Die verwendete main.cf [2] hat zwar die "high" Ciphers gesetzt, aber selbst wenn ich viel auskommentiere und damit die Defaults benutze klappt es nicht. Hat jemand eine Idee was ich noch probieren könnte? Mit AVM stehe ich schon in Kontakt, aber dort hat man die Ciphers nur als Verbesserungsvorschlag entgegen genommen und konnte mir nicht sagen, welche unterstützt werden. > > Viele Grüße, > Philipp > > [1] https://github.com/mailcow/mailcow-dockerized > [2] https://raw.githubusercontent.com/mailcow/mailcow-dockerized/master/data/conf/postfix/main.cf -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From buettnerp at web.de Wed Jul 17 14:06:08 2019 From: buettnerp at web.de (Peter Buettner) Date: Wed, 17 Jul 2019 14:06:08 +0200 Subject: =?UTF-8?Q?Re=3a_Kein_Versand_von_Push-Mails_von_Fritzbox_m=c3=b6gli?= =?UTF-8?Q?ch?= In-Reply-To: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> References: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> Message-ID: <4a83ea93-e373-ff08-8e58-245099b8d7d2@web.de> Meine Fritte 7390 arbeitet ipv4 only (feste IP) und versendet an port 465 mit ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Vielleicht hilft das ja schon. Interessant wären noch die Einstellungen in der master.cf Gruß Peter Büttner Am 17.07.19 um 13:19 schrieb Philipp Trulson: > Hallo liebe Liste, > > ich betreibe nun seit einer Weile den Stack von mailcow > [1] (beinhaltet Postfix > 3.3.0 von Ubuntu 18.04) mit Docker und hatte bisher auch keinerlei > Probleme damit. Nun wollte ich den Versand von Push-Mails meiner > Fritz!Box einrichten, scheitere aber leider komplett daran. Mein > Verdacht liegt darin, dass der Mail-Client der Fritz!Box die modernen > Ciphers nicht unterstützt, da ich folgende Logausgabe bekomme: > > Jul 17 13:06:27 mail postfix/smtpd[378]: connect from > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] > Jul 17 13:06:27 mail postfix/smtpd[378]: setting up TLS connection from > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] > Jul 17 13:06:27 mail postfix/smtpd[378]: > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187]: TLS cipher list > "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:before SSL > initialization > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:before SSL > initialization > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL3 alert > write:fatal:handshake failure > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:error in error > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept error from > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187]: -1 > Jul 17 13:06:27 mail postfix/smtpd[378]: warning: TLS library problem: > error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared > cipher:../ssl/statem/statem_srvr.c:2253: > Jul 17 13:06:27 mail postfix/smtpd[378]: lost connection after CONNECT > from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] > Jul 17 13:06:27 mail postfix/smtpd[378]: disconnect from > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] commands=0/0 > > Aber das kann doch irgendwie nicht sein, sonst wäre ich nicht der erste > mit diesem Problem. Die verwendete main.cf > > [2] hat zwar die "high" Ciphers gesetzt, aber selbst wenn ich viel > auskommentiere und damit die Defaults benutze klappt es nicht. Hat > jemand eine Idee was ich noch probieren könnte? Mit AVM stehe ich schon > in Kontakt, aber dort hat man die Ciphers nur als Verbesserungsvorschlag > entgegen genommen und konnte mir nicht sagen, welche unterstützt werden. > > Viele Grüße, > Philipp > > [1] https://github.com/mailcow/mailcow-dockerized > [2] > https://raw.githubusercontent.com/mailcow/mailcow-dockerized/master/data/conf/postfix/main.cf > > > From buettnerp at web.de Wed Jul 17 15:01:09 2019 From: buettnerp at web.de (Peter Buettner) Date: Wed, 17 Jul 2019 15:01:09 +0200 Subject: =?UTF-8?Q?Re=3a_Kein_Versand_von_Push-Mails_von_Fritzbox_m=c3=b6gli?= =?UTF-8?Q?ch?= In-Reply-To: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> References: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> Message-ID: <4a0f7b81-12af-5a92-e7d2-5cac96235644@web.de> Hinter smtpd_tls_mandatory_ciphers = high fehlt noch die Definition der tls_high_cipherlist z.B.: tls_high_cipherlist=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:EDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:EDH+CAMELLIA:ECDHE+CAMELLIA:!aNULL:!eNULL:!EXPORT:-DES:!RC4:!MD5:!PSK:!aECDH:EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA Gruß Peter Büttner Am 17.07.19 um 13:19 schrieb Philipp Trulson: > Hallo liebe Liste, > > ich betreibe nun seit einer Weile den Stack von mailcow > [1] (beinhaltet Postfix > 3.3.0 von Ubuntu 18.04) mit Docker und hatte bisher auch keinerlei > Probleme damit. Nun wollte ich den Versand von Push-Mails meiner > Fritz!Box einrichten, scheitere aber leider komplett daran. Mein > Verdacht liegt darin, dass der Mail-Client der Fritz!Box die modernen > Ciphers nicht unterstützt, da ich folgende Logausgabe bekomme: > > Jul 17 13:06:27 mail postfix/smtpd[378]: connect from > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] > Jul 17 13:06:27 mail postfix/smtpd[378]: setting up TLS connection from > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] > Jul 17 13:06:27 mail postfix/smtpd[378]: > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187]: TLS cipher list > "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:before SSL > initialization > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:before SSL > initialization > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL3 alert > write:fatal:handshake failure > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept:error in error > Jul 17 13:06:27 mail postfix/smtpd[378]: SSL_accept error from > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187]: -1 > Jul 17 13:06:27 mail postfix/smtpd[378]: warning: TLS library problem: > error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared > cipher:../ssl/statem/statem_srvr.c:2253: > Jul 17 13:06:27 mail postfix/smtpd[378]: lost connection after CONNECT > from p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] > Jul 17 13:06:27 mail postfix/smtpd[378]: disconnect from > p2E5A5DBB.dip0.t-ipconnect.de[46.90.93.187] commands=0/0 > > Aber das kann doch irgendwie nicht sein, sonst wäre ich nicht der erste > mit diesem Problem. Die verwendete main.cf > > [2] hat zwar die "high" Ciphers gesetzt, aber selbst wenn ich viel > auskommentiere und damit die Defaults benutze klappt es nicht. Hat > jemand eine Idee was ich noch probieren könnte? Mit AVM stehe ich schon > in Kontakt, aber dort hat man die Ciphers nur als Verbesserungsvorschlag > entgegen genommen und konnte mir nicht sagen, welche unterstützt werden. > > Viele Grüße, > Philipp > > [1] https://github.com/mailcow/mailcow-dockerized > [2] > https://raw.githubusercontent.com/mailcow/mailcow-dockerized/master/data/conf/postfix/main.cf > > > From stse+postfixbuch at fsing.rootsland.net Wed Jul 17 15:14:09 2019 From: stse+postfixbuch at fsing.rootsland.net (Stephan Seitz) Date: Wed, 17 Jul 2019 15:14:09 +0200 Subject: Kein Versand von =?iso-8859-1?Q?Push-M?= =?iso-8859-1?Q?ails_von_Fritzbox_m=F6glich?= In-Reply-To: <4a0f7b81-12af-5a92-e7d2-5cac96235644@web.de> References: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> <4a0f7b81-12af-5a92-e7d2-5cac96235644@web.de> Message-ID: <20190717T151258.GA.768cc.stse@fsing.rootsland.net> On Mi, Jul 17, 2019 at 03:01:09 +0200, Peter Buettner wrote: >Hinter smtpd_tls_mandatory_ciphers = high >fehlt noch die Definition der tls_high_cipherlist Warum? # postconf -d | grep tls_high_cipherlist tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH Da gibst einen Default-Wert. 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 : From philipp at trulson.de Wed Jul 17 15:23:26 2019 From: philipp at trulson.de (Philipp Trulson) Date: Wed, 17 Jul 2019 15:23:26 +0200 Subject: =?UTF-8?Q?Re=3a_Kein_Versand_von_Push-Mails_von_Fritzbox_m=c3=b6gli?= =?UTF-8?Q?ch?= Message-ID: Ich hoffe mal die Antwort klappt, habe aus Versehen nur die Zusammenfassung ausgewählt und damit keine E-Mail auf die ich direkt antworten kann :/ Erstmal danke für die schnelle Rückmeldung! Es handelt sich um die Fritz!Box 7590 mit dem 7.11 OS, also alles aktuell. Mit der Test-Mailbox von André (die ja scheinbar auch auf mailcow basiert) hat der Versand ohne Probleme geklappt, allerdings bietet sie mir auch weitaus mehr Ciphers an. Ich habe sie zur Übersicht beide in den Anhang gepackt, dabei ist mir aufgefallen, dass meine Konfiguration mit der vorher verlinkten main.cf lediglich Ciphers mit elliptischen Kurven anbietet. Das ist zwar modern und sicher, entspricht aber nicht dem, was die Fritz!Box anbietet. Wenn ich den tcpdump im Anhang richtig interpretiere kann die Box nur Ciphers mit RSA, bin aber kein Verschlüsselungsexperte. -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : dump.pcap Dateityp : application/octet-stream Dateigröße : 1062 bytes Beschreibung: nicht verfügbar URL : -------------- nächster Teil -------------- docker run -ti drwetter/testssl.sh -E mail.trlsn.de:465 SSLv2 SSLv3 TLS 1 xc00a ECDHE-ECDSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA xc009 ECDHE-ECDSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS 1.1 xc00a ECDHE-ECDSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA xc009 ECDHE-ECDSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS 1.2 xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 xc024 ECDHE-ECDSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 xc00a ECDHE-ECDSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA xcca9 ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 xc0af ECDHE-ECDSA-AES256-CCM8 ECDH 253 AESCCM8 256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 xc0ad ECDHE-ECDSA-AES256-CCM ECDH 253 AESCCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM xc073 ECDHE-ECDSA-CAMELLIA256-SHA384 ECDH 256 Camellia 256 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 xc05d ECDHE-ECDSA-ARIA256-GCM-SHA384 ECDH 253 ARIAGCM 256 TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 xc023 ECDHE-ECDSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 xc009 ECDHE-ECDSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA xc0ae ECDHE-ECDSA-AES128-CCM8 ECDH 253 AESCCM8 128 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 xc0ac ECDHE-ECDSA-AES128-CCM ECDH 253 AESCCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_CCM xc072 ECDHE-ECDSA-CAMELLIA128-SHA256 ECDH 256 Camellia 128 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 xc05c ECDHE-ECDSA-ARIA128-GCM-SHA256 ECDH 253 ARIAGCM 128 TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 TLS 1.3 x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256 docker run -ti drwetter/testssl.sh -E mx.mailcow.email:465 SSLv2 SSLv3 TLS 1 xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA x88 DHE-RSA-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA x84 CAMELLIA256-SHA RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA x45 DHE-RSA-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA x41 CAMELLIA128-SHA RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA TLS 1.1 xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA x88 DHE-RSA-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA x84 CAMELLIA256-SHA RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA x45 DHE-RSA-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA x41 CAMELLIA128-SHA RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA TLS 1.2 xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x9f DHE-RSA-AES256-GCM-SHA384 DH 2048 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 xccaa DHE-RSA-CHACHA20-POLY1305 DH 2048 ChaCha20 256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 xc0a3 DHE-RSA-AES256-CCM8 DH 2048 AESCCM8 256 TLS_DHE_RSA_WITH_AES_256_CCM_8 xc09f DHE-RSA-AES256-CCM DH 2048 AESCCM 256 TLS_DHE_RSA_WITH_AES_256_CCM x6b DHE-RSA-AES256-SHA256 DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA xc077 ECDHE-RSA-CAMELLIA256-SHA384 ECDH 256 Camellia 256 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 xc4 DHE-RSA-CAMELLIA256-SHA256 DH 2048 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 x88 DHE-RSA-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384 xc0a1 AES256-CCM8 RSA AESCCM8 256 TLS_RSA_WITH_AES_256_CCM_8 xc09d AES256-CCM RSA AESCCM 256 TLS_RSA_WITH_AES_256_CCM x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256 x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA xc0 CAMELLIA256-SHA256 RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 x84 CAMELLIA256-SHA RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA xc051 ARIA256-GCM-SHA384 RSA ARIAGCM 256 TLS_RSA_WITH_ARIA_256_GCM_SHA384 xc053 DHE-RSA-ARIA256-GCM-SHA384 DH 2048 ARIAGCM 256 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 xc061 ECDHE-ARIA256-GCM-SHA384 ECDH 253 ARIAGCM 256 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc027 ECDHE-RSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x9e DHE-RSA-AES128-GCM-SHA256 DH 2048 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 xc0a2 DHE-RSA-AES128-CCM8 DH 2048 AESCCM8 128 TLS_DHE_RSA_WITH_AES_128_CCM_8 xc09e DHE-RSA-AES128-CCM DH 2048 AESCCM 128 TLS_DHE_RSA_WITH_AES_128_CCM xc0a0 AES128-CCM8 RSA AESCCM8 128 TLS_RSA_WITH_AES_128_CCM_8 xc09c AES128-CCM RSA AESCCM 128 TLS_RSA_WITH_AES_128_CCM x67 DHE-RSA-AES128-SHA256 DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA xc076 ECDHE-RSA-CAMELLIA128-SHA256 ECDH 256 Camellia 128 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 xbe DHE-RSA-CAMELLIA128-SHA256 DH 2048 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 x45 DHE-RSA-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256 x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256 x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA xba CAMELLIA128-SHA256 RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 x41 CAMELLIA128-SHA RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA xc050 ARIA128-GCM-SHA256 RSA ARIAGCM 128 TLS_RSA_WITH_ARIA_128_GCM_SHA256 xc052 DHE-RSA-ARIA128-GCM-SHA256 DH 2048 ARIAGCM 128 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 xc060 ECDHE-ARIA128-GCM-SHA256 ECDH 253 ARIAGCM 128 TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 TLS 1.3 x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256 From buettnerp at web.de Wed Jul 17 15:24:27 2019 From: buettnerp at web.de (Peter Buettner) Date: Wed, 17 Jul 2019 15:24:27 +0200 Subject: =?UTF-8?Q?Re=3a_Kein_Versand_von_Push-Mails_von_Fritzbox_m=c3=b6gli?= =?UTF-8?Q?ch?= In-Reply-To: <20190717T151258.GA.768cc.stse@fsing.rootsland.net> References: <79426a97-ab70-a3e2-0a8b-a3c42e6c6ec7@trulson.de> <4a0f7b81-12af-5a92-e7d2-5cac96235644@web.de> <20190717T151258.GA.768cc.stse@fsing.rootsland.net> Message-ID: <1f0aa083-de26-2787-5193-88ff788eb32f@web.de> Am 17.07.19 um 15:14 schrieb Stephan Seitz: > On Mi, Jul 17, 2019 at 03:01:09 +0200, Peter Buettner wrote: >> Hinter smtpd_tls_mandatory_ciphers = high >> fehlt noch die Definition der tls_high_cipherlist > > Warum? Weil es dann mit meiner Fritte funktioniert. > # postconf -d | grep tls_high_cipherlist > tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH > > Da gibst einen Default-Wert. > > Shade and sweet water! > >     Stephan > From buettnerp at web.de Wed Jul 17 15:39:13 2019 From: buettnerp at web.de (Peter Buettner) Date: Wed, 17 Jul 2019 15:39:13 +0200 Subject: =?UTF-8?Q?Re=3a_Kein_Versand_von_Push-Mails_von_Fritzbox_m=c3=b6gli?= =?UTF-8?Q?ch?= In-Reply-To: References: Message-ID: <06b91068-c178-d79a-abfc-89f98f8d9d61@web.de> Modern ist chick und fein, aber manchmal muß man auch abwärtskompatibel sein. Sonst bekommt man nur noch wenig Mails. In einer vorherigen Mail hatte ich beschrieben, daß man mit tls_high_cipherlist die angebotenen Cipher steuern kann. Hier muß man sich halt einmal die Mühe machen und die Cipher, die man anbieten will, zu definieren: Erst die "modernen und sicheren", dann nach Bedarf z.B. ECDHE-RSA-AES256-GCM-SHA384 für die Fritten, etc. Gruß Peter Büttner Am 17.07.19 um 15:23 schrieb Philipp Trulson: > Ich hoffe mal die Antwort klappt, habe aus Versehen nur die > Zusammenfassung ausgewählt und damit keine E-Mail auf die ich direkt > antworten kann :/ > > Erstmal danke für die schnelle Rückmeldung! Es handelt sich um die > Fritz!Box 7590 mit dem 7.11 OS, also alles aktuell. > > Mit der Test-Mailbox von André (die ja scheinbar auch auf mailcow > basiert) hat der Versand ohne Probleme geklappt, allerdings bietet sie > mir auch weitaus mehr Ciphers an. Ich habe sie zur Übersicht beide in > den Anhang gepackt, dabei ist mir aufgefallen, dass meine Konfiguration > mit der vorher verlinkten main.cf lediglich Ciphers mit elliptischen > Kurven anbietet. Das ist zwar modern und sicher, entspricht aber nicht > dem, was die Fritz!Box anbietet. Wenn ich den tcpdump im Anhang richtig > interpretiere kann die Box nur Ciphers mit RSA, bin aber kein > Verschlüsselungsexperte. > From stse+postfixbuch at fsing.rootsland.net Wed Jul 17 15:52:04 2019 From: stse+postfixbuch at fsing.rootsland.net (Stephan Seitz) Date: Wed, 17 Jul 2019 15:52:04 +0200 Subject: Kein Versand von =?iso-8859-1?Q?Push-M?= =?iso-8859-1?Q?ails_von_Fritzbox_m=F6glich?= In-Reply-To: References: Message-ID: <20190717T155014.GA.90189.stse@fsing.rootsland.net> On Mi, Jul 17, 2019 at 03:23:26 +0200, Philipp Trulson wrote: >entspricht aber nicht dem, was die Fritz!Box anbietet. Wenn ich den >tcpdump im Anhang richtig interpretiere kann die Box nur Ciphers mit >RSA, bin aber kein Verschlüsselungsexperte. Wenn du schon in Kontakt mit AVM stehst, kannst du sie ja auch auf https://blog.trailofbits.com/2019/07/08/fuck-rsa/ verweisen, warum man heute kein RSA mehr verwenden sollte. In TLSv1.3 gibt es auch keine RSA-Ciphers mehr. 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 : From andre.peters at debinux.de Wed Jul 17 16:03:16 2019 From: andre.peters at debinux.de (=?utf-8?q?Andr=C3=A9?= Peters) Date: Wed, 17 Jul 2019 16:03:16 +0200 Subject: =?utf-8?Q?Re:_Kein_Versand_von_Push-Mails_von_Fritzbox_m=C3=B6gl?= =?utf-8?Q?ich?= In-Reply-To: <06b91068-c178-d79a-abfc-89f98f8d9d61@web.de> References: <06b91068-c178-d79a-abfc-89f98f8d9d61@web.de> Message-ID: <729C997F-F17B-4211-B289-D8FA5C0E4AE9@debinux.de> mailcow spricht inter-MTA auch ältere Cipher. Es geht hier um die mandatory ciphers. > Am 17.07.2019 um 15:39 schrieb Peter Buettner : > > Modern ist chick und fein, aber manchmal muß man auch abwärtskompatibel > sein. Sonst bekommt man nur noch wenig Mails. > > In einer vorherigen Mail hatte ich beschrieben, daß man mit > tls_high_cipherlist > die angebotenen Cipher steuern kann. > Hier muß man sich halt einmal die Mühe machen und die Cipher, die man > anbieten will, zu definieren: Erst die "modernen und sicheren", dann > nach Bedarf z.B. ECDHE-RSA-AES256-GCM-SHA384 für die Fritten, etc. > > Gruß > Peter Büttner > >> Am 17.07.19 um 15:23 schrieb Philipp Trulson: >> Ich hoffe mal die Antwort klappt, habe aus Versehen nur die >> Zusammenfassung ausgewählt und damit keine E-Mail auf die ich direkt >> antworten kann :/ >> >> Erstmal danke für die schnelle Rückmeldung! Es handelt sich um die >> Fritz!Box 7590 mit dem 7.11 OS, also alles aktuell. >> >> Mit der Test-Mailbox von André (die ja scheinbar auch auf mailcow >> basiert) hat der Versand ohne Probleme geklappt, allerdings bietet sie >> mir auch weitaus mehr Ciphers an. Ich habe sie zur Übersicht beide in >> den Anhang gepackt, dabei ist mir aufgefallen, dass meine Konfiguration >> mit der vorher verlinkten main.cf lediglich Ciphers mit elliptischen >> Kurven anbietet. Das ist zwar modern und sicher, entspricht aber nicht >> dem, was die Fritz!Box anbietet. Wenn ich den tcpdump im Anhang richtig >> interpretiere kann die Box nur Ciphers mit RSA, bin aber kein >> Verschlüsselungsexperte. >> From philipp at trulson.de Wed Jul 17 16:41:31 2019 From: philipp at trulson.de (Philipp Trulson) Date: Wed, 17 Jul 2019 16:41:31 +0200 Subject: =?UTF-8?Q?Re=3a_Kein_Versand_von_Push-Mails_von_Fritzbox_m=c3=b6gli?= =?UTF-8?Q?ch?= In-Reply-To: <729C997F-F17B-4211-B289-D8FA5C0E4AE9@debinux.de> References: <06b91068-c178-d79a-abfc-89f98f8d9d61@web.de> <729C997F-F17B-4211-B289-D8FA5C0E4AE9@debinux.de> Message-ID: Problem "gelöst": Ich hatte mir via Let's Encrypt ein ECDSA Zertifikat mit 384 Bits besorgt, in Browsern funktioniert das auch ganz wunderbar. Allerdings können damit nun mal auch nur ECDSA Ciphers angeboten werden - wenn ein Client die nicht unterstützt siehts düster aus. Deshalb habe ich mir nun ein zweites RSA Zertifikat für den Mailserver erstellt, jetzt läuft alles einwandfrei. Darauf gekommen bin ich durch folgenden Blog-Eintrag, dabei geht es darum wie man RSA & ECDSA simultan anbieten kann: https://www.kuketz-blog.de/postfix-ecdsa-rsa-keys-und-tls-konfiguration/ Ich werde AVM trotzdem darum bitten irgendwann mal auch elliptische Kurven zu unterstützen, aber ich denke nicht, dass das weit oben auf der Liste stehen wird. Vielen Dank an alle für die Mithilfe! From stse+postfixbuch at fsing.rootsland.net Wed Jul 17 20:51:06 2019 From: stse+postfixbuch at fsing.rootsland.net (Stephan Seitz) Date: Wed, 17 Jul 2019 20:51:06 +0200 Subject: Kein Versand von =?iso-8859-1?Q?Push-M?= =?iso-8859-1?Q?ails_von_Fritzbox_m=F6glich?= In-Reply-To: References: <06b91068-c178-d79a-abfc-89f98f8d9d61@web.de> <729C997F-F17B-4211-B289-D8FA5C0E4AE9@debinux.de> Message-ID: <20190717T204847.GA.ec2dc.stse@fsing.rootsland.net> On Mi, Jul 17, 2019 at 04:41:31 +0200, Philipp Trulson wrote: >Deshalb habe ich mir nun ein zweites RSA Zertifikat für den Mailserver >erstellt, jetzt läuft alles einwandfrei. Darauf gekommen bin ich durch Hm, ich habe auch nur einen ECDSA-Key (mit dehydrated und let?s encrypt). Weiß jemand, wie ich auf diese Weise für die selbe Domain zwei Schlüssel erstellen kann? >Ich werde AVM trotzdem darum bitten irgendwann mal auch elliptische >Kurven zu unterstützen, aber ich denke nicht, dass das weit oben auf der >Liste stehen wird. Vielen Dank an alle für die Mithilfe! Ich motze bei denen auch mal. ;-) 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 : From thom_schu at gmx.de Tue Jul 23 13:44:29 2019 From: thom_schu at gmx.de (thom_schu at gmx.de) Date: Tue, 23 Jul 2019 13:44:29 +0200 Subject: Server-basiertes "redirect" abschalten Message-ID: Hallo, wir betreiben einen Mail-Server mit postfix und Cyrus Imap. Aus Datenschutzgründen soll es nun in unserer Firma untersagt werden, dass Mails serverbasiert weitergeleitet werden an Mail-Adressen außerhalb des Hauses. (im Haus laufen mehrere Mail-Server unter verschiedenen Subdomains) Mit serverbasierter Weiterleitung ist das redirect gemeint, welches ein Nutzer mittels sieve-Scripte einrichten kann. Ist es möglich, Weiterleitungen, die durch ein solches sieve-Script ausgelöst werden zu unterbinden ? Vielen Dank th From ad+lists at uni-x.org Tue Jul 23 14:01:04 2019 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Tue, 23 Jul 2019 14:01:04 +0200 Subject: Server-basiertes "redirect" abschalten In-Reply-To: References: Message-ID: <5151c52a9c1afd7d3641e766a14c46e5@uni-x.org> Am 2019-07-23 13:44, schrieb thom_schu at gmx.de: > Hallo, > wir betreiben einen Mail-Server mit postfix und Cyrus Imap. > Aus Datenschutzgründen soll es nun in unserer Firma untersagt werden, > dass Mails serverbasiert weitergeleitet werden an Mail-Adressen > außerhalb des Hauses. (im Haus laufen mehrere Mail-Server unter > verschiedenen Subdomains) > Mit serverbasierter Weiterleitung ist das redirect gemeint, welches > ein Nutzer mittels sieve-Scripte einrichten kann. > > Ist es möglich, Weiterleitungen, die durch ein solches sieve-Script > ausgelöst werden zu unterbinden ? > > Vielen Dank > > th http://www.postfix.org/postconf.5.html#authorized_submit_users wäre eine Möglichkeit, den cyrus-imapd User gar nicht mehr per sendmail Direktaufruf submitten zu lassen. Alexander From ad+lists at uni-x.org Tue Jul 23 14:13:22 2019 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Tue, 23 Jul 2019 14:13:22 +0200 Subject: Server-basiertes "redirect" abschalten In-Reply-To: <5151c52a9c1afd7d3641e766a14c46e5@uni-x.org> References: <5151c52a9c1afd7d3641e766a14c46e5@uni-x.org> Message-ID: Am 2019-07-23 14:01, schrieb Alexander Dalloz: [ ... ] > http://www.postfix.org/postconf.5.html#authorized_submit_users > > wäre eine Möglichkeit, den cyrus-imapd User gar nicht mehr per > sendmail Direktaufruf submitten zu lassen. > > Alexander Oder etwas chirurgischer: Definiere den Aufruf des sendmail Binaries im cyrus-imapd um und zeige auf einen Wrapper. https://www.cyrusimap.org/dev/imap/reference/admin/sieve.html#configure-outgoing-mail Im Wrapper kannst Du prüfen, ob die Zieladresse extern ist und den Versuch blockieren. Alexander From Christian.Schmidt at chemie.uni-hamburg.de Tue Jul 23 15:03:01 2019 From: Christian.Schmidt at chemie.uni-hamburg.de (Christian Schmidt) Date: Tue, 23 Jul 2019 15:03:01 +0200 Subject: Server-basiertes "redirect" abschalten In-Reply-To: References: Message-ID: thom_schu at gmx.de, 23.07.19: > Ist es möglich, Weiterleitungen, die durch ein solches sieve-Script ausgelöst werden zu unterbinden ? Wie pflegen die Benutzer denn ihre auf dem Server hinterlegten Sieve-Skripte? Beim horde-Webmail-System beispielsweise kann man das Anlegen von (neuen) Regeln zur Weiterleitung per Konfiguration unterbinden. Mit freundlichen Grüßen Christian Schmidt -- No signature available. -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 5444 bytes Beschreibung: S/MIME Cryptographic Signature URL : From thom_schu at gmx.de Tue Jul 23 18:53:38 2019 From: thom_schu at gmx.de (thom_schu at gmx.de) Date: Tue, 23 Jul 2019 18:53:38 +0200 Subject: Server-basiertes "redirect" abschalten In-Reply-To: References: Message-ID: Am 23. Juli 2019 um 15:03 Uhr schrieb Christian Schmidt: > Wie pflegen die Benutzer denn ihre auf dem Server hinterlegten > Sieve-Skripte? mit squirrelmail, leider immernoch ... > Beim horde-Webmail-System beispielsweise kann man das Anlegen von > (neuen) Regeln zur Weiterleitung per Konfiguration unterbinden. würde aber auch die firmen-interne Weiterleitung abschalten ? Vielen Dank th   From thom_schu at gmx.de Tue Jul 23 18:59:06 2019 From: thom_schu at gmx.de (thom_schu at gmx.de) Date: Tue, 23 Jul 2019 18:59:06 +0200 Subject: Server-basiertes "redirect" abschalten In-Reply-To: References: <5151c52a9c1afd7d3641e766a14c46e5@uni-x.org> Message-ID: Am Dienstag, 23. Juli 2019 um 14:13 Uhr schrieb Alexander: > Oder etwas chirurgischer: Definiere den Aufruf des sendmail Binaries im > cyrus-imapd um und zeige auf einen Wrapper. Der Wrapper klingt nach einer Lösung. Dagegen mit "authorized_submit_users" würde ich auch die firmen-interne Weiterleitung abschalten ? Vielen Dank th From webmaster at fitonbit.de Tue Jul 23 20:37:30 2019 From: webmaster at fitonbit.de (Mathias Jung) Date: Tue, 23 Jul 2019 20:37:30 +0200 Subject: Absender Fake verhindern Message-ID: <52cb55c52dbf6c9348313d67ca9325a0@fitonbit.de> Hallo zusammen, bei mir kommt es immer öfter vor das SPAM Mails durchkommen. Nach einem Blick in die Header der Mails ist mir das hier aufgefallen: From: Bei der Email selbst wird bei der normalen Ansicht die fake@ Adresse als Absender angezeigt. Die org@ ist aber die welche durch meine Einstellungen/Filter in der main.cf geprüft wird. Wenn bei der org@ Adresse dann zB. der SPF passt, kommt die Email an. Kann ich das verhindern? Aktuell habe ich absolut keine Idee wie ich die 1. Adresse (ebenfalls) auswerten kann.... Gruß Mathias -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From ad+lists at uni-x.org Tue Jul 23 21:15:37 2019 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Tue, 23 Jul 2019 21:15:37 +0200 Subject: Absender Fake verhindern In-Reply-To: <52cb55c52dbf6c9348313d67ca9325a0@fitonbit.de> References: <52cb55c52dbf6c9348313d67ca9325a0@fitonbit.de> Message-ID: <2fd48aed-440d-7a32-4918-0c5f6207ea4e@uni-x.org> Am 23.07.2019 um 20:37 schrieb Mathias Jung: > Hallo zusammen, > bei mir kommt es immer öfter vor das SPAM Mails durchkommen. > Nach einem Blick in die Header der Mails ist mir das hier aufgefallen: > From: > Bei der Email selbst wird bei der normalen Ansicht die fake@ Adresse als > Absender angezeigt. > Die org@ ist aber die welche durch meine Einstellungen/Filter in der > main.cf geprüft wird. > Wenn bei der org@ Adresse dann zB. der SPF passt, kommt die Email an. > Kann ich das verhindern? > Aktuell habe ich absolut keine Idee wie ich die 1. Adresse (ebenfalls) > auswerten kann.... > Gruß > Mathias Hallo, ist es Zufall, dass Du in dem Zusammenhang SPF erwähnst, oder der irrige Glaube, SPF könnte oder müsste gar da irgendwas ausrichten? SPF ist der From Header herzlich egal. Prüfe doch besser mal, welche MTAs solche Mails bei Dir einliefern und auf welcher Grundlage Du die Mails von ihnen annimmst. Solange es keine missbrauchten, validen Mailserver sind, besteht die Chance mit Postscreen vielen Spam abzuwehren. Alexander From webmaster at fitonbit.de Tue Jul 23 21:33:18 2019 From: webmaster at fitonbit.de (Mathias Jung) Date: Tue, 23 Jul 2019 21:33:18 +0200 Subject: Absender Fake verhindern In-Reply-To: <2fd48aed-440d-7a32-4918-0c5f6207ea4e@uni-x.org> References: <52cb55c52dbf6c9348313d67ca9325a0@fitonbit.de> <2fd48aed-440d-7a32-4918-0c5f6207ea4e@uni-x.org> Message-ID: Am 23.07.2019 21:15, schrieb Alexander Dalloz: > Am 23.07.2019 um 20:37 schrieb Mathias Jung: >> Hallo zusammen, >> bei mir kommt es immer öfter vor das SPAM Mails durchkommen. >> Nach einem Blick in die Header der Mails ist mir das hier aufgefallen: >> From: >> Bei der Email selbst wird bei der normalen Ansicht die fake@ Adresse >> als >> Absender angezeigt. >> Die org@ ist aber die welche durch meine Einstellungen/Filter in der >> main.cf geprüft wird. >> Wenn bei der org@ Adresse dann zB. der SPF passt, kommt die Email an. >> Kann ich das verhindern? >> Aktuell habe ich absolut keine Idee wie ich die 1. Adresse (ebenfalls) >> auswerten kann.... >> Gruß >> Mathias > > Hallo, > > ist es Zufall, dass Du in dem Zusammenhang SPF erwähnst, oder der > irrige Glaube, SPF könnte oder müsste gar da irgendwas ausrichten? SPF > ist der From Header herzlich egal. > Prüfe doch besser mal, welche MTAs solche Mails bei Dir einliefern und > auf welcher Grundlage Du die Mails von ihnen annimmst. Solange es > keine missbrauchten, validen Mailserver sind, besteht die Chance mit > Postscreen vielen Spam abzuwehren. > > Alexander Ja da hast Du recht, das war unüberlegt getippt. Ich schau mir die Logs nochmals genauer an. Gruß Mathias From stickybit at myhm.de Fri Jul 26 00:28:47 2019 From: stickybit at myhm.de (Andre) Date: Fri, 26 Jul 2019 00:28:47 +0200 Subject: 454 4.7.1 bei Relay access denied Message-ID: <2aa22ce7-16a1-bd0a-8367-1a5cc345358c@myhm.de> Hallo, hier eine Zeile aus dem Log: mail:info smtpd[18282]: NOQUEUE: reject: RCPT from XXX: 454 4.7.1 : Relay access denied; from= to= proto=ESMTP helo= Diese ist zu sehen wenn eingehende Mails an eine bei mir nicht existente Adresse kommen. Wie kann ich es denn einrichten dass solche Versuche mit anstatt 4XX-Error mit 5XX-Error beantwortet werden? Ich meine, wenn die E-Mail-Adresse nicht existiert, warum soll der Absenderserver immer wieder versuchen? Danke! -- LG Andre From gregor at a-mazing.de Fri Jul 26 08:19:48 2019 From: gregor at a-mazing.de (Gregor Hermens) Date: Fri, 26 Jul 2019 08:19:48 +0200 Subject: 454 4.7.1 bei Relay access denied In-Reply-To: <2aa22ce7-16a1-bd0a-8367-1a5cc345358c@myhm.de> References: <2aa22ce7-16a1-bd0a-8367-1a5cc345358c@myhm.de> Message-ID: <1805834.urBHZFu9Ob@rawindra> Hallo Andre, Am Freitag, 26. Juli 2019, 00:28:47 CEST schrieb Andre: > hier eine Zeile aus dem Log: > > mail:info smtpd[18282]: NOQUEUE: reject: RCPT from XXX: 454 4.7.1 > : Relay access denied; from= to= > proto=ESMTP helo= > > Diese ist zu sehen wenn eingehende Mails an eine bei mir nicht existente > Adresse kommen. Wie kann ich es denn einrichten dass solche Versuche mit > anstatt 4XX-Error mit 5XX-Error beantwortet werden? > > Ich meine, wenn die E-Mail-Adresse nicht existiert, warum soll der > Absenderserver immer wieder versuchen? das muss in deiner Konfiguration geändert sein. Default ist 554: http://www.postfix.org/postconf.5.html#relay_domains_reject_code Gruß, Gregor -- @mazing fon +49 8142 6528665 Gregor Hermens fax +49 8142 6528669 Brucker Strasse 12 gregor.hermens at a-mazing.de D-82216 Gernlinden https://www.a-mazing.de/ -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From jra at byte.cx Fri Jul 26 12:50:09 2019 From: jra at byte.cx (Jens Adam) Date: Fri, 26 Jul 2019 12:50:09 +0200 Subject: 454 4.7.1 bei Relay access denied In-Reply-To: <1805834.urBHZFu9Ob@rawindra> References: <2aa22ce7-16a1-bd0a-8367-1a5cc345358c@myhm.de> <1805834.urBHZFu9Ob@rawindra> Message-ID: <11AA38D6-AE64-4DE2-932C-5B0B79DEC8E0@byte.cx> Davon abgesehen würde ich auch erwarten, dass bei einem unbekannten Adressaten eine Meldung in der Art "550 5.1.1 : Recipient address rejected: User unknown in [...] table" kommt. Mit dem "Relay access" scheint mir da in der Reihenfolge der Restrictions was nicht so ganz zu passen. postconf -n? --byte From Hajo.Locke at gmx.de Fri Jul 26 13:46:21 2019 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Fri, 26 Jul 2019 13:46:21 +0200 Subject: 454 4.7.1 bei Relay access denied In-Reply-To: <11AA38D6-AE64-4DE2-932C-5B0B79DEC8E0@byte.cx> References: <2aa22ce7-16a1-bd0a-8367-1a5cc345358c@myhm.de> <1805834.urBHZFu9Ob@rawindra> <11AA38D6-AE64-4DE2-932C-5B0B79DEC8E0@byte.cx> Message-ID: Hallo, Am 26.07.2019 um 12:50 schrieb Jens Adam: > Davon abgesehen würde ich auch erwarten, dass bei einem unbekannten Adressaten eine Meldung in der Art "550 5.1.1 : Recipient address rejected: User unknown in [...] table" kommt. Mit dem "Relay access" scheint mir da in der Reihenfolge der Restrictions was nicht so ganz zu passen. > > postconf -n? > > --byte > > ich kenne das nur, wenn der MX auf dich zeigt, du aber keinerlei Konfiguration zur Domain hast. Ein "User unknown" kommt erst, wenn zumindest die Domain lokal angelegt wurde. Hajo From daniel at mail24.vip Mon Jul 29 04:26:07 2019 From: daniel at mail24.vip (Daniel) Date: Mon, 29 Jul 2019 04:26:07 +0200 Subject: =?iso-8859-1?Q?Nervens=E4gen_blocken?= Message-ID: <001701d545b5$005d2880$01177980$@mail24.vip> Hallo Liste, wie geht ihr mit Nervensägen um welche Logs zumüllen durch tagelange Versuche an wahllose und hunderte sinnlose Versuche an Postfächer zuzustellen welche es nicht gibt. Also es gibt z.B. User, es wird versucht zuzustellen an User123, Userur, User333, usw. in zich Varianten. Beim Auswerten der Log nervt es einfach wenn da soviele reject stehen, da bei Spamhaus und/oder uceprotect in RBL stehen. Annehmen und verwerfen ist schlechte Idee, dann kommt da wohl mit Zeit noch mehr weil denken haben Erfolg, und zudem rechtlich riskant. Also besser direkt in Firewall blocken. Aktuell sind es bei mir welche ich direkt geblockt habe: 37.120.150.0 45.82.34.0 134.73.76.0 212.7.222.0 217.112.128.0 Macht ihr sowas manuell? Script mit IPban und co.? Gruß Daniel From buettnerp at web.de Mon Jul 29 08:30:23 2019 From: buettnerp at web.de (Peter Buettner) Date: Mon, 29 Jul 2019 08:30:23 +0200 Subject: =?UTF-8?Q?Re=3a_Nervens=c3=a4gen_blocken?= In-Reply-To: <001701d545b5$005d2880$01177980$@mail24.vip> References: <001701d545b5$005d2880$01177980$@mail24.vip> Message-ID: <8561d1d2-e307-dc89-d419-828dcaf9f8f8@web.de> Hallo Daniel, bi mir werden unbekannte User mit 550 zurückgewiesen und dann alle 550'er mit fail2ban gleich nach dem ersten Versuch geblockt. Gruß Peter Büttner Am 29.07.19 um 04:26 schrieb Daniel: > Hallo Liste, > > wie geht ihr mit Nervensägen um welche Logs zumüllen durch tagelange Versuche an wahllose und hunderte sinnlose Versuche an > Postfächer zuzustellen welche es nicht gibt. > > Also es gibt z.B. User, es wird versucht zuzustellen an User123, Userur, User333, usw. in zich Varianten. > > Beim Auswerten der Log nervt es einfach wenn da soviele reject stehen, da bei Spamhaus und/oder uceprotect in RBL stehen. > > Annehmen und verwerfen ist schlechte Idee, dann kommt da wohl mit Zeit noch mehr weil denken haben Erfolg, und zudem rechtlich > riskant. > > Also besser direkt in Firewall blocken. Aktuell sind es bei mir welche ich direkt geblockt habe: > 37.120.150.0 > 45.82.34.0 > 134.73.76.0 > 212.7.222.0 > 217.112.128.0 > > Macht ihr sowas manuell? Script mit IPban und co.? > > Gruß Daniel > > From kai_postfix at fuerstenberg.ws Mon Jul 29 09:33:48 2019 From: kai_postfix at fuerstenberg.ws (=?UTF-8?Q?Kai_F=c3=bcrstenberg?=) Date: Mon, 29 Jul 2019 09:33:48 +0200 Subject: =?UTF-8?Q?Re=3a_Nervens=c3=a4gen_blocken?= In-Reply-To: <8561d1d2-e307-dc89-d419-828dcaf9f8f8@web.de> References: <001701d545b5$005d2880$01177980$@mail24.vip> <8561d1d2-e307-dc89-d419-828dcaf9f8f8@web.de> Message-ID: Am 29.07.2019 um 08:30 schrieb Peter Buettner: > Hallo Daniel, > > bi mir werden unbekannte User mit 550 zurückgewiesen und dann alle > 550'er mit fail2ban gleich nach dem ersten Versuch geblockt. das finde ich etwas übertrieben. Jeder kann sich mal bei einer E-Mail-Adresse vertippen und will dann gleich mit der richtigen neu versenden. Bei 5x sehe ich das aber anders ... Gruß Kai > > Gruß Peter Büttner > > Am 29.07.19 um 04:26 schrieb Daniel: >> Hallo Liste, >> >> wie geht ihr mit Nervensägen um welche Logs zumüllen durch tagelange Versuche an wahllose und hunderte sinnlose Versuche an >> Postfächer zuzustellen welche es nicht gibt. >> >> Also es gibt z.B. User, es wird versucht zuzustellen an User123, Userur, User333, usw. in zich Varianten. >> >> Beim Auswerten der Log nervt es einfach wenn da soviele reject stehen, da bei Spamhaus und/oder uceprotect in RBL stehen. >> >> Annehmen und verwerfen ist schlechte Idee, dann kommt da wohl mit Zeit noch mehr weil denken haben Erfolg, und zudem rechtlich >> riskant. >> >> Also besser direkt in Firewall blocken. Aktuell sind es bei mir welche ich direkt geblockt habe: >> 37.120.150.0 >> 45.82.34.0 >> 134.73.76.0 >> 212.7.222.0 >> 217.112.128.0 >> >> Macht ihr sowas manuell? Script mit IPban und co.? >> >> Gruß Daniel >> >> -- Kai Fürstenberg PM an: kai at fuerstenberg punkt ws From klaus at tachtler.net Tue Jul 30 09:00:25 2019 From: klaus at tachtler.net (Klaus Tachtler) Date: Tue, 30 Jul 2019 09:00:25 +0200 Subject: =?utf-8?b?TmVydmVuc8OkZ2Vu?= blocken In-Reply-To: References: <001701d545b5$005d2880$01177980$@mail24.vip> <8561d1d2-e307-dc89-d419-828dcaf9f8f8@web.de> Message-ID: <20190730090025.Horde.LkmIhu6DgQjmaZIVFYPT33I@buero.tachtler.net> Hallo, ich finde auch das bei 5x (Standard in Fail2Ban) eine Blockierung o.k. ist. Bei Fail2ban in /etc/fail2ban/filter.d/postfix.conf kann ganz leicht die RegEx hinzugefügt werden: /etc/fail2ban/filter.d/postfix.conf =================================== ... failregex = ... ^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[\]: 577 5\.1\.1 <\S+>: Recipient address rejected: .*$ ... /etc/postfix/main.cf ==================== ... unverified_recipient_reject_code = 577 ... für: ==== Jul 30 08:35:29 server60 postfix/smtpd[14520]: NOQUEUE: reject: RCPT from spam.test.net[xxx.xxx.xxx.xxx]: 577 5.1.1 : Recipient address rejected: undeliverable address: host xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx] said: 550 5.1.1 User doesn't exist: unknown at tachtler.net (in reply to RCPT TO command); from= to= proto=ESMTP helo= erzeugt dann in /var/log/fail2ban.log: ====================================== 2019-07-30 08:37:15,026 fail2ban.filter [19384]: INFO [postfix] Found xxx.xxx.xxx.xxx Grüße Klaus. > Am 29.07.2019 um 08:30 schrieb Peter Buettner: >> Hallo Daniel, >> >> bi mir werden unbekannte User mit 550 zurückgewiesen und dann alle >> 550'er mit fail2ban gleich nach dem ersten Versuch geblockt. > > das finde ich etwas übertrieben. Jeder kann sich mal bei einer > E-Mail-Adresse vertippen und will dann gleich mit der richtigen neu > versenden. > > Bei 5x sehe ich das aber anders ... > > Gruß > Kai > > >> >> Gruß Peter Büttner >> >> Am 29.07.19 um 04:26 schrieb Daniel: >>> Hallo Liste, >>> >>> wie geht ihr mit Nervensägen um welche Logs zumüllen durch >>> tagelange Versuche an wahllose und hunderte sinnlose Versuche an >>> Postfächer zuzustellen welche es nicht gibt. >>> >>> Also es gibt z.B. User, es wird versucht zuzustellen an User123, >>> Userur, User333, usw. in zich Varianten. >>> >>> Beim Auswerten der Log nervt es einfach wenn da soviele reject >>> stehen, da bei Spamhaus und/oder uceprotect in RBL stehen. >>> >>> Annehmen und verwerfen ist schlechte Idee, dann kommt da wohl mit >>> Zeit noch mehr weil denken haben Erfolg, und zudem rechtlich >>> riskant. >>> >>> Also besser direkt in Firewall blocken. Aktuell sind es bei mir >>> welche ich direkt geblockt habe: >>> 37.120.150.0 >>> 45.82.34.0 >>> 134.73.76.0 >>> 212.7.222.0 >>> 217.112.128.0 >>> >>> Macht ihr sowas manuell? Script mit IPban und co.? >>> >>> Gruß Daniel >>> >>> > > > -- > Kai Fürstenberg > > PM an: kai at fuerstenberg punkt ws ----- Ende der Nachricht von Kai Fürstenberg ----- -- -------------------------------------------- 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 : From Hajo.Locke at gmx.de Tue Jul 30 10:21:12 2019 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Tue, 30 Jul 2019 10:21:12 +0200 Subject: frage zu bcc und header Message-ID: Hallo Liste, habe eine Frage zu bcc die an mich herangetragen wurde und ich mir selber noch keine Gedanken gemacht habe. Mail geht an Adresse a und in bcc an Adresse b. Adresse b ist nur ein Alias und bedient letztendlich die gleiche Mailbox wie Adresse a. Im Endeffekt hab ich im Postfach der Adresse a 2 mal die identische Mail. Im Header gibt es kein bcc sondern in beiden Fällen entspricht das To: der Adresse a. Delivered-To: ist auch identisch mit Username at Servername, da die virtual direkt auf lokale User verweist und ich kann als Empfänger nicht mehr erkennen, dass eine BCC Adresse angeschrieben wurde. Gäbe es da noch Einstellungsmöglichkeiten, um die BCC Adresse im Header erscheinen zu lassen? Bei der Frage geht es darum, dass der Empfänger der nur mit einer Mailbox arbeitet intern die Mails dann an seine eigenen Mitarbeiter verteilen will. Danke, From klaus at tachtler.net Tue Jul 30 11:17:13 2019 From: klaus at tachtler.net (Klaus Tachtler) Date: Tue, 30 Jul 2019 11:17:13 +0200 Subject: frage zu bcc und header In-Reply-To: Message-ID: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> Hallo, ist es nicht so, dass die TO-Adresse, CC-Adresse, genau so wie die BCC-Adresse, nur im E-Mail-Programm (MUA) unterschieden werden. SMTP-Server (MDA) kennen nur die RCPT TO: Adressen? Grüße Klaus. > Hallo Liste, > > habe eine Frage zu bcc die an mich herangetragen wurde und ich mir > selber noch keine Gedanken gemacht habe. > Mail geht an Adresse a und in bcc an Adresse b. Adresse b ist nur ein > Alias und bedient letztendlich die gleiche Mailbox wie Adresse a. > Im Endeffekt hab ich im Postfach der Adresse a 2 mal die identische Mail. > Im Header gibt es kein bcc sondern in beiden Fällen entspricht das To: > der Adresse a. > Delivered-To: ist auch identisch mit Username at Servername, da die virtual > direkt auf lokale User verweist und ich kann als Empfänger nicht mehr > erkennen, dass eine BCC Adresse angeschrieben wurde. > Gäbe es da noch Einstellungsmöglichkeiten, um die BCC Adresse im Header > erscheinen zu lassen? Bei der Frage geht es darum, dass der Empfänger > der nur mit einer Mailbox arbeitet intern die Mails dann an seine > eigenen Mitarbeiter verteilen will. > > Danke, -- -------------------------------------------- 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 : From Hajo.Locke at gmx.de Tue Jul 30 11:40:37 2019 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Tue, 30 Jul 2019 11:40:37 +0200 Subject: frage zu bcc und header In-Reply-To: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> References: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> Message-ID: Hallo, Am 30.07.2019 um 11:17 schrieb Klaus Tachtler: > Hallo, > > ist es nicht so, dass die TO-Adresse, CC-Adresse, genau so wie die > BCC-Adresse, nur im E-Mail-Programm (MUA) unterschieden werden. > > SMTP-Server (MDA) kennen nur die RCPT TO: Adressen? Würde das nicht aber bedeuten, dass vom Client die BCC Adresse zur To: Adresse gemacht werden muss, damit der MX diese korrekt zustellen kann? Im Header der angekommenen Mail ist aber nichts dergleichen zu finden, beide Header waren identisch. Postfix müsste ja wissen, was es verbergen soll. Aus meiner Sicht läuft das so, dass Postfix erst nach der Annahme den BCC entfernt und die Mail an die vorher ermittelten User zustellt. Der Header der beiden zugestellten Mails ist dann identisch, wenn beide ins gleiche Postfach fließen. Ich hab mal in der main.cf diesen Wert gesetzt: message_drop_headers=content-length, resent-bcc, return-path per default wäre noch bcc in der liste. Wenn ich nun die Testmail analog schreibe, dann ist das X-Original-To wirklich unterschiedlich bei beiden Mails.  In der einen Mail entspricht es dem To. In der anderen Mail ist das X-Original-To der BCC recipient. Also irgendwie muss postfix ja wissen, wer ein bcc Empfänger ist und ich glaube noch nicht dass der Client einfach mehrere Ziele per "rcpt to" angibt, denn dann würde ich immer im To: die jeweilige andere Adresse sehen. > > > Grüße > Klaus. > >> Hallo Liste, >> >> habe eine Frage zu bcc die an mich herangetragen wurde und ich mir >> selber noch keine Gedanken gemacht habe. >> Mail geht an Adresse a und in bcc an Adresse b. Adresse b ist nur ein >> Alias und bedient letztendlich die gleiche Mailbox wie Adresse a. >> Im Endeffekt hab ich im Postfach der Adresse a 2 mal die identische >> Mail. >> Im Header gibt es kein bcc sondern in beiden Fällen entspricht das To: >> der Adresse a. >> Delivered-To: ist auch identisch mit Username at Servername, da die virtual >> direkt auf lokale User verweist und ich kann als Empfänger nicht mehr >> erkennen, dass eine BCC Adresse angeschrieben wurde. >> Gäbe es da noch Einstellungsmöglichkeiten, um die BCC Adresse im Header >> erscheinen zu lassen? Bei der Frage geht es darum, dass der Empfänger >> der nur mit einer Mailbox arbeitet intern die Mails dann an seine >> eigenen Mitarbeiter verteilen will. >> >> Danke, > > Hajo From jc.pfbk15 at cynix.net Tue Jul 30 12:20:58 2019 From: jc.pfbk15 at cynix.net (Juergen Christoffel) Date: Tue, 30 Jul 2019 12:20:58 +0200 Subject: frage zu bcc und header In-Reply-To: References: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> Message-ID: <20190730102058.GA12531@unser.net> On Tue, Jul 30, 2019 at 11:40:37AM +0200, Hajo Locke wrote: >>SMTP-Server (MDA) kennen nur die RCPT TO: Adressen? >Würde das nicht aber bedeuten, dass vom Client die BCC Adresse zur To: >Adresse gemacht werden muss, damit der MX diese korrekt zustellen kann? Bcc-Adressen werden in den Evelope gesteckt, das sind die Adressen, die die Emails tatsächlich erhalten. Aber sie werden in der Regel nicht in einem sichtbaren Header transportiert, sonst wären sie ja nicht "blind." Siehe https://tools.ietf.org/pdf/rfc5322.pdf sagt auf S. 24 The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains addresses of recipients of the message whose addresses are not to be revealed to other recipients of the message. There are three ways in which the "Bcc:" field is used. [...] >Im Header der angekommenen Mail ist aber nichts dergleichen zu finden, Ja, "blind" halt. Theoretisch (siehe RFC, d.h. "implementation dependend") kann der Bcc-Empfänger auch eine Kopie mit dem Bcc-Header erhalten. Habe ich aber in über 30 Jahren noch nie bewusst gesehen. Gruss, JC -- Doctorow's Law: Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit. From Hajo.Locke at gmx.de Tue Jul 30 12:39:05 2019 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Tue, 30 Jul 2019 12:39:05 +0200 Subject: frage zu bcc und header In-Reply-To: <20190730102058.GA12531@unser.net> References: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> <20190730102058.GA12531@unser.net> Message-ID: <13a1b0bf-001a-84eb-d581-df6495a53576@gmx.de> Hallo, Am 30.07.2019 um 12:20 schrieb Juergen Christoffel: > On Tue, Jul 30, 2019 at 11:40:37AM +0200, Hajo Locke wrote: >>> SMTP-Server (MDA) kennen nur die RCPT TO: Adressen? >> Würde das nicht aber bedeuten, dass vom Client die BCC Adresse zur To: >> Adresse gemacht werden muss, damit der MX diese korrekt zustellen kann? > > Bcc-Adressen werden in den Evelope gesteckt, das sind die Adressen, > die die > Emails tatsächlich erhalten. Aber sie werden in der Regel nicht in einem > sichtbaren Header transportiert, sonst wären sie ja nicht "blind." Siehe > https://tools.ietf.org/pdf/rfc5322.pdf sagt auf S. 24 Danke, es wird mir nun etwas klarer. In der Standardpostfixkonfiguration hat der Empfänger dann aber keine Chance so einen bcc Empfänger zu unterscheiden, wenn ein gemeinsames Postfach genutzt wird. In dem Fall müsste ich wirklich message_drop_headers umkonfigurieren, damit ich den angepassten X-Original-To zu sehen bekomme. > >   The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains >   addresses of recipients of the message whose addresses are not to be >   revealed to other recipients of the message.  There are three ways in >   which the "Bcc:" field is used. [...] > >> Im Header der angekommenen Mail ist aber nichts dergleichen zu finden, > > Ja, "blind" halt. Theoretisch (siehe RFC, d.h. "implementation > dependend") > kann der Bcc-Empfänger auch eine Kopie mit dem Bcc-Header erhalten. Habe > ich aber in über 30 Jahren noch nie bewusst gesehen. > > Gruss, JC > Danke, Hajo From klaus at tachtler.net Tue Jul 30 13:44:38 2019 From: klaus at tachtler.net (Klaus Tachtler) Date: Tue, 30 Jul 2019 13:44:38 +0200 Subject: frage zu bcc und header In-Reply-To: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> References: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> Message-ID: <20190730134438.Horde.q84fpOg45D2lRdARih5Vfbj@buero.tachtler.net> Hallo, Es soll als Beispiel eine E-Mail TO: root at localhost und an BCC: klaus at localhost versendet werden: # mail -s "Test" -r sender at loclahost -b klaus at localhost root at localhost . EOT Null message body; hope that's ok -s = Subject -r from -b bcc Im /var/log/maillog sieht das ganze dann so aus: ================================================ # cat /var/log/maillog | grep 0B74610C6E59 Jul 30 13:31:48 pml125 postfix/pickup[4708]: 0B74610C6E59: uid=0 from= Jul 30 13:31:48 pml125 postfix/cleanup[7084]: 0B74610C6E59: message-id=<5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: from=, size=431, nrcpt=2 (queue active) Jul 30 13:31:48 pml125 postfix/local[7085]: 0B74610C6E59: to=, relay=local, delay=0.06, delays=0.04/0/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox) Jul 30 13:31:48 pml125 postfix/local[7268]: 0B74610C6E59: to=, relay=local, delay=0.07, delays=0.04/0/0/0.03, dsn=2.0.0, status=sent (delivered to mailbox) Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: removed Die eingegangenen E-Mails unter /var/spool/mail/root und /var/spool/mail/klaus sehen so aus: ============================================================================================ # cat /var/spool/mail/root /var/spool/mail/klaus From sender at loclahost Tue Jul 30 13:31:48 2019 Return-Path: X-Original-To: root at localhost Delivered-To: root at localhost Received: by pml125.home.tachtler.net (Postfix, from userid 0) id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 +0200 (CEST) Date: Tue, 30 Jul 2019 13:31:48 +0200 From: sender at loclahost To: root at localhost Subject: Test Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable = From sender at loclahost Tue Jul 30 13:31:48 2019 Return-Path: X-Original-To: klaus at localhost Delivered-To: klaus at localhost Received: by pml125.home.tachtler.net (Postfix, from userid 0) id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 +0200 (CEST) Date: Tue, 30 Jul 2019 13:31:48 +0200 From: sender at loclahost To: root at localhost Subject: Test Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable = Der Unterschied beider E-Mail sieht wie folgt aus: ================================================== # diff /var/spool/mail/root /var/spool/mail/klaus 3,4c3,4 < X-Original-To: root at localhost < Delivered-To: root at localhost --- > X-Original-To: klaus at localhost > Delivered-To: klaus at localhost Das bedeutet, dass der der (MUA), hier mail(x) im ENVELOP immer RCPT TO: verwendet und nur im X-Original-To: zu erkennen ist, wer der ursprüngliche Empfänger war. Voraussetzung: enable_original_recipient = yes Siehe auch: http://www.postfix.org/postconf.5.html#enable_original_recipient Grüße Klaus. > Hallo, > > ist es nicht so, dass die TO-Adresse, CC-Adresse, genau so wie die > BCC-Adresse, nur im E-Mail-Programm (MUA) unterschieden werden. > > SMTP-Server (MDA) kennen nur die RCPT TO: Adressen? > > > Grüße > Klaus. > >> Hallo Liste, >> >> habe eine Frage zu bcc die an mich herangetragen wurde und ich mir >> selber noch keine Gedanken gemacht habe. >> Mail geht an Adresse a und in bcc an Adresse b. Adresse b ist nur ein >> Alias und bedient letztendlich die gleiche Mailbox wie Adresse a. >> Im Endeffekt hab ich im Postfach der Adresse a 2 mal die identische Mail. >> Im Header gibt es kein bcc sondern in beiden Fällen entspricht das To: >> der Adresse a. >> Delivered-To: ist auch identisch mit Username at Servername, da die virtual >> direkt auf lokale User verweist und ich kann als Empfänger nicht mehr >> erkennen, dass eine BCC Adresse angeschrieben wurde. >> Gäbe es da noch Einstellungsmöglichkeiten, um die BCC Adresse im Header >> erscheinen zu lassen? Bei der Frage geht es darum, dass der Empfänger >> der nur mit einer Mailbox arbeitet intern die Mails dann an seine >> eigenen Mitarbeiter verteilen will. >> >> Danke, > > > -- > > -------------------------------------------- > e-Mail : klaus at tachtler.net > Homepage: https://www.tachtler.net > DokuWiki: https://dokuwiki.tachtler.net > -------------------------------------------- ----- Ende der Nachricht von Klaus Tachtler ----- -- -------------------------------------------- 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 : From Hajo.Locke at gmx.de Tue Jul 30 14:40:56 2019 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Tue, 30 Jul 2019 14:40:56 +0200 Subject: frage zu bcc und header In-Reply-To: <20190730134438.Horde.q84fpOg45D2lRdARih5Vfbj@buero.tachtler.net> References: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> <20190730134438.Horde.q84fpOg45D2lRdARih5Vfbj@buero.tachtler.net> Message-ID: <9f765add-f553-5882-6f67-edb0ff723117@gmx.de> Hallo, Am 30.07.2019 um 13:44 schrieb Klaus Tachtler: > Hallo, > > Es soll als Beispiel eine E-Mail TO: root at localhost und an BCC: > klaus at localhost versendet werden: > > # mail -s "Test" -r sender at loclahost -b klaus at localhost root at localhost > . > EOT > Null message body; hope that's ok > > -s = Subject > -r from > -b bcc > > Im /var/log/maillog sieht das ganze dann so aus: > ================================================ > > # cat /var/log/maillog | grep 0B74610C6E59 > Jul 30 13:31:48 pml125 postfix/pickup[4708]: 0B74610C6E59: uid=0 > from= > Jul 30 13:31:48 pml125 postfix/cleanup[7084]: 0B74610C6E59: > message-id=<5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> > Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: > from=, size=431, nrcpt=2 (queue active) > Jul 30 13:31:48 pml125 postfix/local[7085]: 0B74610C6E59: > to=, relay=local, delay=0.06, delays=0.04/0/0/0.02, > dsn=2.0.0, status=sent (delivered to mailbox) > Jul 30 13:31:48 pml125 postfix/local[7268]: 0B74610C6E59: > to=, relay=local, delay=0.07, delays=0.04/0/0/0.03, > dsn=2.0.0, status=sent (delivered to mailbox) > Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: removed > > Die eingegangenen E-Mails unter /var/spool/mail/root und > /var/spool/mail/klaus sehen so aus: > ============================================================================================ > > > # cat /var/spool/mail/root /var/spool/mail/klaus > From sender at loclahost  Tue Jul 30 13:31:48 2019 > Return-Path: > X-Original-To: root at localhost > Delivered-To: root at localhost > Received: by pml125.home.tachtler.net (Postfix, from userid 0) >     id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 +0200 (CEST) > Date: Tue, 30 Jul 2019 13:31:48 +0200 > From: sender at loclahost > To: root at localhost > Subject: Test > Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> > User-Agent: Heirloom mailx 12.5 7/5/10 > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: quoted-printable > > = > > From sender at loclahost  Tue Jul 30 13:31:48 2019 > Return-Path: > X-Original-To: klaus at localhost > Delivered-To: klaus at localhost > Received: by pml125.home.tachtler.net (Postfix, from userid 0) >     id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 +0200 (CEST) > Date: Tue, 30 Jul 2019 13:31:48 +0200 > From: sender at loclahost > To: root at localhost > Subject: Test > Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> > User-Agent: Heirloom mailx 12.5 7/5/10 > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: quoted-printable > > = > > > Der Unterschied beider E-Mail sieht wie folgt aus: > ================================================== > > # diff /var/spool/mail/root /var/spool/mail/klaus > 3,4c3,4 > < X-Original-To: root at localhost > < Delivered-To: root at localhost > --- >> X-Original-To: klaus at localhost >> Delivered-To: klaus at localhost > > > Das bedeutet, dass der der (MUA), hier mail(x) im ENVELOP immer RCPT > TO: verwendet und nur im X-Original-To: zu erkennen ist, wer der > ursprüngliche Empfänger war. > > Voraussetzung: enable_original_recipient = yes enable_original_recipient haben wir auch auf yes. Was sagt bei dir message_drop_headers ? Im Log sieht das bei mir auch so aus, aber nicht im Header. Postfix Version ist 3.1.0 Bei mir verweist die virtual auf die lokalen User: b at example.com a at example.com a at example.com myusername Daher ist in den beiden Mails delivered-to username at servername und keine original Mailadresse mehr. X-Original-To änderte sich erst, nachdem ich bcc aus der Liste für message_drop_headers entfernt habe. Ich nehme an bei uns herrscht ein etwas ungünstiges virtual-setup... > > Siehe auch: > http://www.postfix.org/postconf.5.html#enable_original_recipient > Hajo From klaus at tachtler.net Tue Jul 30 15:08:45 2019 From: klaus at tachtler.net (Klaus Tachtler) Date: Tue, 30 Jul 2019 15:08:45 +0200 Subject: frage zu bcc und header In-Reply-To: <9f765add-f553-5882-6f67-edb0ff723117@gmx.de> References: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> <20190730134438.Horde.q84fpOg45D2lRdARih5Vfbj@buero.tachtler.net> <9f765add-f553-5882-6f67-edb0ff723117@gmx.de> Message-ID: <20190730150845.Horde.GbUrJtlG6noqGWoKavogr3j@buero.tachtler.net> Hallo Hajo, ich habe den Standard: # postmulti -i - -x postconf -d | grep message_drop_headers message_drop_headers = bcc, content-length, resent-bcc, return-path # rpm -q postfix postfix-3.4.6-1.el7.x86_64 Grüße Klaus. > Hallo, > > Am 30.07.2019 um 13:44 schrieb Klaus Tachtler: >> Hallo, >> >> Es soll als Beispiel eine E-Mail TO: root at localhost und an BCC: >> klaus at localhost versendet werden: >> >> # mail -s "Test" -r sender at loclahost -b klaus at localhost root at localhost >> . >> EOT >> Null message body; hope that's ok >> >> -s = Subject >> -r from >> -b bcc >> >> Im /var/log/maillog sieht das ganze dann so aus: >> ================================================ >> >> # cat /var/log/maillog | grep 0B74610C6E59 >> Jul 30 13:31:48 pml125 postfix/pickup[4708]: 0B74610C6E59: uid=0 >> from= >> Jul 30 13:31:48 pml125 postfix/cleanup[7084]: 0B74610C6E59: >> message-id=<5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> >> Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: >> from=, size=431, nrcpt=2 (queue active) >> Jul 30 13:31:48 pml125 postfix/local[7085]: 0B74610C6E59: >> to=, relay=local, delay=0.06, delays=0.04/0/0/0.02, >> dsn=2.0.0, status=sent (delivered to mailbox) >> Jul 30 13:31:48 pml125 postfix/local[7268]: 0B74610C6E59: >> to=, relay=local, delay=0.07, delays=0.04/0/0/0.03, >> dsn=2.0.0, status=sent (delivered to mailbox) >> Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: removed >> >> Die eingegangenen E-Mails unter /var/spool/mail/root und >> /var/spool/mail/klaus sehen so aus: >> ============================================================================================ >> >> >> # cat /var/spool/mail/root /var/spool/mail/klaus >> From sender at loclahost  Tue Jul 30 13:31:48 2019 >> Return-Path: >> X-Original-To: root at localhost >> Delivered-To: root at localhost >> Received: by pml125.home.tachtler.net (Postfix, from userid 0) >>     id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 >> +0200 (CEST) >> Date: Tue, 30 Jul 2019 13:31:48 +0200 >> From: sender at loclahost >> To: root at localhost >> Subject: Test >> Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> >> User-Agent: Heirloom mailx 12.5 7/5/10 >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: quoted-printable >> >> = >> >> From sender at loclahost  Tue Jul 30 13:31:48 2019 >> Return-Path: >> X-Original-To: klaus at localhost >> Delivered-To: klaus at localhost >> Received: by pml125.home.tachtler.net (Postfix, from userid 0) >>     id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 >> +0200 (CEST) >> Date: Tue, 30 Jul 2019 13:31:48 +0200 >> From: sender at loclahost >> To: root at localhost >> Subject: Test >> Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> >> User-Agent: Heirloom mailx 12.5 7/5/10 >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: quoted-printable >> >> = >> >> >> Der Unterschied beider E-Mail sieht wie folgt aus: >> ================================================== >> >> # diff /var/spool/mail/root /var/spool/mail/klaus >> 3,4c3,4 >> < X-Original-To: root at localhost >> < Delivered-To: root at localhost >> --- >>> X-Original-To: klaus at localhost >>> Delivered-To: klaus at localhost >> >> >> Das bedeutet, dass der der (MUA), hier mail(x) im ENVELOP immer RCPT >> TO: verwendet und nur im X-Original-To: zu erkennen ist, wer der >> ursprüngliche Empfänger war. >> >> Voraussetzung: enable_original_recipient = yes > enable_original_recipient haben wir auch auf yes. Was sagt bei dir > message_drop_headers ? > Im Log sieht das bei mir auch so aus, aber nicht im Header. > Postfix Version ist 3.1.0 > Bei mir verweist die virtual auf die lokalen User: > > b at example.com a at example.com > a at example.com myusername > > Daher ist in den beiden Mails delivered-to username at servername und keine > original Mailadresse mehr. > X-Original-To änderte sich erst, nachdem ich bcc aus der Liste für > message_drop_headers entfernt habe. > Ich nehme an bei uns herrscht ein etwas ungünstiges virtual-setup... >> >> Siehe auch: >> http://www.postfix.org/postconf.5.html#enable_original_recipient >> > Hajo -- -------------------------------------------- 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 : From klaus at tachtler.net Tue Jul 30 15:11:01 2019 From: klaus at tachtler.net (Klaus Tachtler) Date: Tue, 30 Jul 2019 15:11:01 +0200 Subject: frage zu bcc und header In-Reply-To: <9f765add-f553-5882-6f67-edb0ff723117@gmx.de> References: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> <20190730134438.Horde.q84fpOg45D2lRdARih5Vfbj@buero.tachtler.net> <9f765add-f553-5882-6f67-edb0ff723117@gmx.de> Message-ID: <20190730151101.Horde.y6f3Y0CmFQkYli3brkyISGA@buero.tachtler.net> Hallo Hajo, da dies ein Test-System ist, ist die /etc/postfix/virtual OHNE Einträge. Grüße Klaus > Hallo, > > Am 30.07.2019 um 13:44 schrieb Klaus Tachtler: >> Hallo, >> >> Es soll als Beispiel eine E-Mail TO: root at localhost und an BCC: >> klaus at localhost versendet werden: >> >> # mail -s "Test" -r sender at loclahost -b klaus at localhost root at localhost >> . >> EOT >> Null message body; hope that's ok >> >> -s = Subject >> -r from >> -b bcc >> >> Im /var/log/maillog sieht das ganze dann so aus: >> ================================================ >> >> # cat /var/log/maillog | grep 0B74610C6E59 >> Jul 30 13:31:48 pml125 postfix/pickup[4708]: 0B74610C6E59: uid=0 >> from= >> Jul 30 13:31:48 pml125 postfix/cleanup[7084]: 0B74610C6E59: >> message-id=<5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> >> Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: >> from=, size=431, nrcpt=2 (queue active) >> Jul 30 13:31:48 pml125 postfix/local[7085]: 0B74610C6E59: >> to=, relay=local, delay=0.06, delays=0.04/0/0/0.02, >> dsn=2.0.0, status=sent (delivered to mailbox) >> Jul 30 13:31:48 pml125 postfix/local[7268]: 0B74610C6E59: >> to=, relay=local, delay=0.07, delays=0.04/0/0/0.03, >> dsn=2.0.0, status=sent (delivered to mailbox) >> Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: removed >> >> Die eingegangenen E-Mails unter /var/spool/mail/root und >> /var/spool/mail/klaus sehen so aus: >> ============================================================================================ >> >> >> # cat /var/spool/mail/root /var/spool/mail/klaus >> From sender at loclahost  Tue Jul 30 13:31:48 2019 >> Return-Path: >> X-Original-To: root at localhost >> Delivered-To: root at localhost >> Received: by pml125.home.tachtler.net (Postfix, from userid 0) >>     id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 >> +0200 (CEST) >> Date: Tue, 30 Jul 2019 13:31:48 +0200 >> From: sender at loclahost >> To: root at localhost >> Subject: Test >> Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> >> User-Agent: Heirloom mailx 12.5 7/5/10 >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: quoted-printable >> >> = >> >> From sender at loclahost  Tue Jul 30 13:31:48 2019 >> Return-Path: >> X-Original-To: klaus at localhost >> Delivered-To: klaus at localhost >> Received: by pml125.home.tachtler.net (Postfix, from userid 0) >>     id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 >> +0200 (CEST) >> Date: Tue, 30 Jul 2019 13:31:48 +0200 >> From: sender at loclahost >> To: root at localhost >> Subject: Test >> Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> >> User-Agent: Heirloom mailx 12.5 7/5/10 >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: quoted-printable >> >> = >> >> >> Der Unterschied beider E-Mail sieht wie folgt aus: >> ================================================== >> >> # diff /var/spool/mail/root /var/spool/mail/klaus >> 3,4c3,4 >> < X-Original-To: root at localhost >> < Delivered-To: root at localhost >> --- >>> X-Original-To: klaus at localhost >>> Delivered-To: klaus at localhost >> >> >> Das bedeutet, dass der der (MUA), hier mail(x) im ENVELOP immer RCPT >> TO: verwendet und nur im X-Original-To: zu erkennen ist, wer der >> ursprüngliche Empfänger war. >> >> Voraussetzung: enable_original_recipient = yes > enable_original_recipient haben wir auch auf yes. Was sagt bei dir > message_drop_headers ? > Im Log sieht das bei mir auch so aus, aber nicht im Header. > Postfix Version ist 3.1.0 > Bei mir verweist die virtual auf die lokalen User: > > b at example.com a at example.com > a at example.com myusername > > Daher ist in den beiden Mails delivered-to username at servername und keine > original Mailadresse mehr. > X-Original-To änderte sich erst, nachdem ich bcc aus der Liste für > message_drop_headers entfernt habe. > Ich nehme an bei uns herrscht ein etwas ungünstiges virtual-setup... >> >> Siehe auch: >> http://www.postfix.org/postconf.5.html#enable_original_recipient >> > Hajo -- -------------------------------------------- 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 : From klaus at tachtler.net Tue Jul 30 15:30:13 2019 From: klaus at tachtler.net (Klaus Tachtler) Date: Tue, 30 Jul 2019 15:30:13 +0200 Subject: frage zu bcc und header In-Reply-To: <9f765add-f553-5882-6f67-edb0ff723117@gmx.de> References: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> <20190730134438.Horde.q84fpOg45D2lRdARih5Vfbj@buero.tachtler.net> <9f765add-f553-5882-6f67-edb0ff723117@gmx.de> Message-ID: <20190730153013.Horde.S_sj3iZ_v50WbFpNQl5hYFQ@buero.tachtler.net> Hallo Hajo, ich habe mal die /etc/postfix/virtual gefüllt und noch einmal getestet. In der E-Mail an klaus at localhost wird nun die /etc/postfix/virtual berücksichtigt: X-Original-To: klaus at localhost Delivered-To: fwbuilder at localhost /etc/postfix/main.cf: ===================== # postmulti -i - -x postconf | egrep virtual_alias_maps\.= virtual_alias_maps = hash:/etc/postfix/virtual # postmulti -i - -x postconf | grep message_drop_headers message_drop_headers = bcc, content-length, resent-bcc, return-path # postmulti -i - -x postconf | grep enable_original_recipient enable_original_recipient = yes /etc/postfix/virtual: ==================== klaus at localhost fwbuilder at localhost /var/log/maillog: ================= Jul 30 15:22:51 pml125 postfix/pickup[11869]: 039FF10C6E59: uid=0 from= Jul 30 15:22:51 pml125 postfix/cleanup[11951]: 039FF10C6E59: message-id=<5d4044aa.kFesrPkbn72FT1Hu%sender at localhost> Jul 30 15:22:51 pml125 postfix/qmgr[11870]: 039FF10C6E59: from=, size=431, nrcpt=2 (queue active) Jul 30 15:22:51 pml125 postfix/local[11953]: 039FF10C6E59: to=, orig_to=, relay=local, delay=0.1, delays=0.06/0.01/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox) Jul 30 15:22:51 pml125 postfix/local[11954]: 039FF10C6E59: to=, relay=local, delay=0.11, delays=0.06/0.03/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox) Jul 30 15:22:51 pml125 postfix/qmgr[11870]: 039FF10C6E59: removed /var/spool/mail/root und /var/spool/mail/fwbuilder: =================================================== # cat root fwbuilder From sender at localhost Tue Jul 30 15:22:51 2019 Return-Path: X-Original-To: root at localhost Delivered-To: root at localhost Received: by pml125.home.tachtler.net (Postfix, from userid 0) id 039FF10C6E59; Tue, 30 Jul 2019 15:22:50 +0200 (CEST) Date: Tue, 30 Jul 2019 15:22:50 +0200 From: sender at localhost To: root at localhost Subject: Test Message-ID: <5d4044aa.kFesrPkbn72FT1Hu%sender at localhost> User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable = From sender at localhost Tue Jul 30 15:22:51 2019 Return-Path: X-Original-To: klaus at localhost Delivered-To: fwbuilder at localhost Received: by pml125.home.tachtler.net (Postfix, from userid 0) id 039FF10C6E59; Tue, 30 Jul 2019 15:22:50 +0200 (CEST) Date: Tue, 30 Jul 2019 15:22:50 +0200 From: sender at localhost To: root at localhost Subject: Test Message-ID: <5d4044aa.kFesrPkbn72FT1Hu%sender at localhost> User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable = Grüße Klaus. > Hallo, > > Am 30.07.2019 um 13:44 schrieb Klaus Tachtler: >> Hallo, >> >> Es soll als Beispiel eine E-Mail TO: root at localhost und an BCC: >> klaus at localhost versendet werden: >> >> # mail -s "Test" -r sender at loclahost -b klaus at localhost root at localhost >> . >> EOT >> Null message body; hope that's ok >> >> -s = Subject >> -r from >> -b bcc >> >> Im /var/log/maillog sieht das ganze dann so aus: >> ================================================ >> >> # cat /var/log/maillog | grep 0B74610C6E59 >> Jul 30 13:31:48 pml125 postfix/pickup[4708]: 0B74610C6E59: uid=0 >> from= >> Jul 30 13:31:48 pml125 postfix/cleanup[7084]: 0B74610C6E59: >> message-id=<5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> >> Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: >> from=, size=431, nrcpt=2 (queue active) >> Jul 30 13:31:48 pml125 postfix/local[7085]: 0B74610C6E59: >> to=, relay=local, delay=0.06, delays=0.04/0/0/0.02, >> dsn=2.0.0, status=sent (delivered to mailbox) >> Jul 30 13:31:48 pml125 postfix/local[7268]: 0B74610C6E59: >> to=, relay=local, delay=0.07, delays=0.04/0/0/0.03, >> dsn=2.0.0, status=sent (delivered to mailbox) >> Jul 30 13:31:48 pml125 postfix/qmgr[1586]: 0B74610C6E59: removed >> >> Die eingegangenen E-Mails unter /var/spool/mail/root und >> /var/spool/mail/klaus sehen so aus: >> ============================================================================================ >> >> >> # cat /var/spool/mail/root /var/spool/mail/klaus >> From sender at loclahost  Tue Jul 30 13:31:48 2019 >> Return-Path: >> X-Original-To: root at localhost >> Delivered-To: root at localhost >> Received: by pml125.home.tachtler.net (Postfix, from userid 0) >>     id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 >> +0200 (CEST) >> Date: Tue, 30 Jul 2019 13:31:48 +0200 >> From: sender at loclahost >> To: root at localhost >> Subject: Test >> Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> >> User-Agent: Heirloom mailx 12.5 7/5/10 >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: quoted-printable >> >> = >> >> From sender at loclahost  Tue Jul 30 13:31:48 2019 >> Return-Path: >> X-Original-To: klaus at localhost >> Delivered-To: klaus at localhost >> Received: by pml125.home.tachtler.net (Postfix, from userid 0) >>     id 0B74610C6E59; Tue, 30 Jul 2019 13:31:48 >> +0200 (CEST) >> Date: Tue, 30 Jul 2019 13:31:48 +0200 >> From: sender at loclahost >> To: root at localhost >> Subject: Test >> Message-ID: <5d402aa4.NzO5B78bqjSA/c+a%sender at loclahost> >> User-Agent: Heirloom mailx 12.5 7/5/10 >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: quoted-printable >> >> = >> >> >> Der Unterschied beider E-Mail sieht wie folgt aus: >> ================================================== >> >> # diff /var/spool/mail/root /var/spool/mail/klaus >> 3,4c3,4 >> < X-Original-To: root at localhost >> < Delivered-To: root at localhost >> --- >>> X-Original-To: klaus at localhost >>> Delivered-To: klaus at localhost >> >> >> Das bedeutet, dass der der (MUA), hier mail(x) im ENVELOP immer RCPT >> TO: verwendet und nur im X-Original-To: zu erkennen ist, wer der >> ursprüngliche Empfänger war. >> >> Voraussetzung: enable_original_recipient = yes > enable_original_recipient haben wir auch auf yes. Was sagt bei dir > message_drop_headers ? > Im Log sieht das bei mir auch so aus, aber nicht im Header. > Postfix Version ist 3.1.0 > Bei mir verweist die virtual auf die lokalen User: > > b at example.com a at example.com > a at example.com myusername > > Daher ist in den beiden Mails delivered-to username at servername und keine > original Mailadresse mehr. > X-Original-To änderte sich erst, nachdem ich bcc aus der Liste für > message_drop_headers entfernt habe. > Ich nehme an bei uns herrscht ein etwas ungünstiges virtual-setup... >> >> Siehe auch: >> http://www.postfix.org/postconf.5.html#enable_original_recipient >> > Hajo -- -------------------------------------------- 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 : From Hajo.Locke at gmx.de Tue Jul 30 15:41:24 2019 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Tue, 30 Jul 2019 15:41:24 +0200 Subject: frage zu bcc und header In-Reply-To: <20190730153013.Horde.S_sj3iZ_v50WbFpNQl5hYFQ@buero.tachtler.net> References: <20190730111713.Horde.l2HdKJugO_fsSIQpCQbyS9t@buero.tachtler.net> <20190730134438.Horde.q84fpOg45D2lRdARih5Vfbj@buero.tachtler.net> <9f765add-f553-5882-6f67-edb0ff723117@gmx.de> <20190730153013.Horde.S_sj3iZ_v50WbFpNQl5hYFQ@buero.tachtler.net> Message-ID: <2171e2c1-907e-f598-25b7-32c0686c7de5@gmx.de> Hallo Klaus Am 30.07.2019 um 15:30 schrieb Klaus Tachtler: > Hallo Hajo, > > ich habe mal die /etc/postfix/virtual gefüllt und noch einmal getestet. Danke für deine Mühe und Hilfsbereitschaft, ich werde dann mal bei mir weiter kucken. Danke, Hajo