From gregor at aeppelbroe.de Mon Feb 1 16:14:20 2016 From: gregor at aeppelbroe.de (Gregor Burck) Date: Mon, 01 Feb 2016 16:14:20 +0100 Subject: Probleme mit reject_rbl_client Message-ID: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> Moin, ich habe im Moment ein Problem mit meinem smtpd_recipient_restrictions, ein reject_rbl_client bringt mir immer ein: Feb 1 16:02:12 baikonur postfix/smtpd[13578]: connect from mailgw.bund-verlag.de[62.206.247.138] Feb 1 16:02:12 baikonur postfix/smtpd[13578]: Anonymous TLS connection established from mailgw.bund-verlag.de[62.206.247.138]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) Feb 1 16:02:13 baikonur postfix/smtpd[13578]: NOQUEUE: reject: RCPT from mailgw.bund-verlag.de[62.206.247.138]: 554 5.7.1 Service unavailable; Client host [62.206.247.138] blocked using zen.spamhaus.org; from=Gregor.Burck at bund-verlag.de to=gregor at aeppelbroe.de proto=ESMTP helo= Feb 1 16:02:13 baikonur postfix/smtpd[13578]: disconnect from mailgw.bund-verlag.de[62.206.247.138] Mein (privater) Mailer sitzt bei mir Zuhause mit einer dynamischen IP, sollte für den Aufruf von einer Blocklist doch wohl kein Problem sein,... Grüße Gegor PS Hier meine Einstellungen: postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no canonical_maps = hash:/etc/postfix/canonical config_directory = /etc/postfix inet_interfaces = all mailbox_command = /usr/lib/dovecot/deliver mailbox_size_limit = 0 message_size_limit = 152428800 mydestination = baikonur.fritz.box, baikonur, localhost.fritz.box, localhost myhostname = heim.aeppelbroe.de mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.2.0/24 myorigin = $myhostname readme_directory = no recipient_delimiter = + relayhost = mail.ffm-it.de smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_password smtp_sasl_security_options = noanonymous smtp_tls_loglevel = 1 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org, check_policy_service inet:127.0.0.1:10023, reject_unauth_destination, permit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = private/auth smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_CAfile = /etc/postfix/ssl/certs/StartCom-CA.pem smtpd_tls_cert_file = /etc/postfix/ssl/certs/aeppelbroe.de-201610_mitIntermediate.crt smtpd_tls_key_file = /etc/postfix/ssl/private/heim.aeppelbroe.de.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache tls_random_source = dev:/dev/urandom virtual_alias_maps = hash:/etc/postfix/virtual From wn at neessen.net Mon Feb 1 16:21:12 2016 From: wn at neessen.net (Winfried Neessen) Date: Mon, 01 Feb 2016 16:21:12 +0100 Subject: Probleme mit reject_rbl_client In-Reply-To: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> References: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> Message-ID: Hi Gregor, Am 2016-02-01 16:14, schrieb Gregor Burck: > Feb 1 16:02:13 baikonur postfix/smtpd[13578]: NOQUEUE: reject: RCPT > from mailgw.bund-verlag.de[62.206.247.138]: 554 5.7.1 Service > unavailable; Client host [62.206.247.138] blocked using > zen.spamhaus.org; from=Gregor.Burck at bund-verlag.de > to=gregor at aeppelbroe.de proto=ESMTP helo= > Wo ist das Problem? Die IP 62.206.247.138 wurde von Deinem Server geblockt weil Sie bei zen.spamhaus.org gelistet ist/war. Das ist das Prinzip von DNSBL. Oder was uebersehe ich gerade? Winni From gregor at aeppelbroe.de Mon Feb 1 18:57:13 2016 From: gregor at aeppelbroe.de (Gregor Burck) Date: Mon, 01 Feb 2016 18:57:13 +0100 Subject: Probleme mit reject_rbl_client In-Reply-To: References: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> Message-ID: <8408731.4kKgGhlS1k@tschaika> Am Montag, 1. Februar 2016, 16:21:12 schrieb Winfried Neessen: > Wo ist das Problem? Die IP 62.206.247.138 wurde von Deinem Server > geblockt weil Sie bei zen.spamhaus.org > gelistet ist/war. Das ist das Prinzip von DNSBL. Oder was uebersehe ich > gerade? Evtl. war ich nicht ausführlich genug, ich bekomme dann für sämtliche einliefernde IP diese Ausgabe. Wenn ich die IP händisch bei Spamhaus abfrage wird mir ausgegeben, das sie nicht gelistet ist,... Grüße Gregor From shyperchen at icloud.com Mon Feb 1 20:17:38 2016 From: shyperchen at icloud.com (=?utf-8?Q?Nick_Tr=C3=A4ger?=) Date: Mon, 01 Feb 2016 20:17:38 +0100 Subject: Probleme mit reject_rbl_client In-Reply-To: <8408731.4kKgGhlS1k@tschaika> References: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> <8408731.4kKgGhlS1k@tschaika> Message-ID: Hallo, Das Problem hatte ich auch am Wochenende und es lag am fehlerhaften DNS. Evtl. mal den Nameserver umstellen. > Am 01.02.2016 um 18:57 schrieb Gregor Burck : > > Am Montag, 1. Februar 2016, 16:21:12 schrieb Winfried Neessen: >> Wo ist das Problem? Die IP 62.206.247.138 wurde von Deinem Server >> geblockt weil Sie bei zen.spamhaus.org >> gelistet ist/war. Das ist das Prinzip von DNSBL. Oder was uebersehe ich >> gerade? > Evtl. war ich nicht ausführlich genug, ich bekomme dann für sämtliche > einliefernde IP diese Ausgabe. Wenn ich die IP händisch bei Spamhaus abfrage > wird mir ausgegeben, das sie nicht gelistet ist,... > > Grüße > > Gregor From gregor at aeppelbroe.de Tue Feb 2 06:33:36 2016 From: gregor at aeppelbroe.de (Gregor Burck) Date: Tue, 02 Feb 2016 06:33:36 +0100 Subject: Probleme mit reject_rbl_client In-Reply-To: References: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> <8408731.4kKgGhlS1k@tschaika> Message-ID: <1951936.JInnoKOnL5@tschaika> Am Montag, 1. Februar 2016, 20:17:38 schrieb Nick Träger: > Hallo, > Das Problem hatte ich auch am Wochenende und es lag am fehlerhaften DNS. Hmm, ich habe mal auf den DNS Server von google gestellt und auf der Konsole einen nslookup getestet: root at baikonur:/etc/postfix# vi /etc/resolv.conf root at baikonur:/etc/postfix# nslookup 136.112.202.81.zen.spamhaus.org Server: 8.8.8.8 Address: 8.8.8.8#53 ** server can't find 136.112.202.81.zen.spamhaus.org: NXDOMAIN Danach wieder auf meinen eigenen umgestellt: root at baikonur:/etc/postfix# vi /etc/resolv.conf root at baikonur:/etc/postfix# nslookup 136.112.202.81.zen.spamhaus.org Server: 192.168.2.1 Address: 192.168.2.1#53 Non-authoritative answer: Name: 136.112.202.81.zen.spamhaus.org Address: 127.0.0.4 Name: 136.112.202.81.zen.spamhaus.org Address: 127.0.0.11 Das Ergebnis sieht beim Eigenen doch eigentlich korrekt aus? Kann ich durch Fehlerhafte Konfiguration der TLS Einstellungen hier einen Querschläger erzeugt haben? Das war das letzte was ich am Server Eingestellt habe. Grüße Gregor From andreas.schulze at datev.de Tue Feb 2 08:05:21 2016 From: andreas.schulze at datev.de (Andreas Schulze) Date: Tue, 2 Feb 2016 08:05:21 +0100 Subject: Probleme mit reject_rbl_client In-Reply-To: <1951936.JInnoKOnL5@tschaika> References: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> <8408731.4kKgGhlS1k@tschaika> <1951936.JInnoKOnL5@tschaika> Message-ID: <56B05531.9070101@datev.de> Am 02.02.2016 um 06:33 schrieb Gregor Burck: > root at baikonur:/etc/postfix# nslookup 136.112.202.81.zen.spamhaus.org was hat 136.112.202.81.zen.spamhaus.org mit "Client host [62.206.247.138] blocked using zen.spamhaus.org" zu tun? 136.112.202.81.zen.spamhaus.org -> host 81.202.112.136 136.112.202.81.in-addr.arpa domain name pointer 81.202.112.136.dyn.user.ono.com ev. ein tippfehler... aber egal: Generell kann ich nicht empfehlen, 8.8.8.8 als Resolver (auf einem MTA) zu benutzen. nicht nur aus Gründen der Datensparsamkeit sondern auch ganz Praktischen: einige DNSBL Betreiber blocken z.B. explizit zentrale Resolverinstanzen aus verschiedenen Gründen. Wenn man Glück hat, ist das transparent: -> dig AmIblocked.dnswl.org txt +short "no" -> dig AmIblocked.dnswl.org txt +short @8.8.8.8 "Yes" Auf einen MTA, der als MX-Server fungiert gehört aus meiner Sicht ein eigener Resolver ( unbound / bind / ... ) der selber gegen dir Rootzone auflöst. Alles andere generiert solche Anfragen hier auf den Mailing-Listen. Andreas From Dominik.Ziegler at thi.de Tue Feb 2 11:41:48 2016 From: Dominik.Ziegler at thi.de (Ziegler Dominik) Date: Tue, 2 Feb 2016 10:41:48 +0000 Subject: Recipient Verify an Exchange 2013 Datenbankserver Message-ID: <7db3b9a9ad7d4dda8d9a4bb8041fadca@RZ-EX-DB01.rz.fh-ingolstadt.de> Hallo zusammen, wir sind vor kurzem auf Exchange 2013 gewechselt und haben folgendes Problem festgestellt: Der Exchange antwortet leider erst nach dem DATA mit „User Unknown“, anstatt nach RCPT TO. Somit wird unser komplettes System der Adressverifizierung ausgehebelt. Nun gibt es ja divers Anleitungen, wie man mit einem zusätzlichen Connecter am HubTransport-Server diese Funktionalität wiederherstellen kann. Dies haben wir auch gemacht. Nur leider erschließt sich mir nun nicht, wie ich das Ganze im Postfix abbilde. Da ich ja nun explizit den Datenbankserver ansprechen muss und nicht wie zuvor den ClientAccess-Server, muss ich doch einen gesonderten Transport für die Verify-Probes schaffen. Dies habe ich mal mit „address_verify_transport_maps“ und einer gesonderten Datei „verify_transport“ versucht. Leider erzielt das nicht gewünschte Änderung. Ich wollte nun fragen, wie man hier am besten vorgeht. Leider findet man mit simplen „googlen“ nicht viel, wobei ich aber davon ausgehe, dass wir hier nicht die einzigen sind mit diesem Problem. postconf -n: address_verify_map = btree:/var/spool/postfix/data/verify address_verify_negative_expire_time = 3d address_verify_negative_refresh_time = 30m address_verify_transport_maps = hash:/etc/postfix/verify_transport alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no bounce_queue_lifetime = 3d canonical_maps = hash:/etc/postfix/canonical config_directory = /etc/postfix inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mailbox_size_limit = 25000000 maximal_queue_lifetime = 3d message_size_limit = 25000000 mydestination = $myhostname, localhost.$mydomain, mailgate-1.thi.de mydomain = thi.de myhostname = mailgate-1.thi.de mynetworks = 127.0.0.0/8, 194.94.97.0/24, 194.94.240.0/24, 194.95.232.0/24, 194.95.234.0/24, 194.95.238.0/24, 192.168.144.0/24, 192.168.42.0/24, 192.168.155.0/24, 10.50.0.0/16 myorigin = $mydomain readme_directory = no recipient_delimiter = + relay_domains = thi.de, fh-ingolstadt.de, carissma.eu, th-ingolstadt.de, haw-ingolstadt.de, listserv.fh-ingolstadt.de, listserv.haw-ingolstadt.de, listserv2.fh-ingolstadt.de, listserv2.haw-ingolstadt.de, listserv.thi.de, listserv2.thi.de, sp.thi.de relayhost = smtp_tls_CApath = /etc/ssl/certs smtp_tls_cert_file = /etc/postfix/mailgate-1.pem smtp_tls_key_file = /etc/postfix/mailgate-1.key smtp_tls_loglevel = 1 smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_policy_maps = hash:/etc/postfix/tls_policy smtp_tls_security_level = may smtp_tls_session_cache_database = btree:$data_directory/smtp_scache smtpd_banner = $myhostname ESMTP smtpd_recipient_restrictions = permit_mynetworks, check_client_access cidr:/etc/postfix/access-client, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unverified_recipient, smtpd_relay_restrictions = smtpd_tls_CApath = /etc/ssl/certs smtpd_tls_cert_file = /etc/postfix/mailgate-1.pem smtpd_tls_key_file = /etc/postfix/mailgate-1.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:$data_directory/smtpd_scache soft_bounce = no transport_maps = hash:/etc/postfix/transport unverified_recipient_reject_code = 550 virtual_alias_domains = alumni.thi.de virtual_alias_maps = hash:/etc/postfix/virtual_alumni verify_transport: # Receipient Verify am Exchange 2013 Datenbankserver fh-ingolstadt.de smtp:[10.50.1.7:2525] haw-ingolstadt.de smtp:[10.50.1.7:2525] carissma.eu smtp:[10.50.1.7:2525] th-ingolstadt.de smtp:[10.50.1.7:2525] thi.de smtp:[10.50.1.7:2525] # Allgemeine Listenweiterleitung listserv.fh-ingolstadt.de smtp:[194.94.240.234] listserv.haw-ingolstadt.de smtp:[194.94.240.234] listserv.thi.de smtp:[194.94.240.234] # Spezielle Listen studentenzeitung at fh-ingolstadt.de smtp:[194.94.240.158] studentenzeitung at haw-ingolstadt.de smtp:[194.94.240.158] # Weiterleitung an Sharepoint sp.thi.de smtp:[194.94.240.213] Ich hoffe, jemand kann hier weiterhelfen :). Grüße, D.Ziegler --------------------------------------------------------+i Technische Hochschule Ingolstadt Dominik Ziegler Zentraler IT-Service Esplanade 10, D-85049 Ingolstadt Tel +49 (0) 841 / 9348-5580 Fax +49 (0) 841 / 9348-995580 Dominik.Ziegler at thi.de www.thi.de -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 6532 bytes Beschreibung: nicht verfügbar URL : From risse at citkomm.de Tue Feb 2 11:53:49 2016 From: risse at citkomm.de (Marc Risse) Date: Tue, 2 Feb 2016 11:53:49 +0100 Subject: SPF und Masquerading, Envelope oder SRS? Message-ID: <56B08ABD.3090905@citkomm.de> Hallo zusammen, ich habe mit einem Kunden ein Problem: Der Kunde hat zwei Domains (domA.de und domB.de). DomA.de liegt auf meinem Server, domB.de liegt bei einem anderen Provider (kleine Webagentur). Mails an domB.de werden von dieser Webagentur an Postfächer der domA.de weiter geleitet. Diese Weiterleitung ist das Problem: Ich checke bei mir SPF, nun will mir der domB.de-Server eine Mail zustellen, die aber laut Sender von gmx.de kommt. Klar, dass ich diese Mail nicht annehme, gmx.de hat ja entsprechende SPF-Records. Jetzt mein Problem: Ich habe meinem Kunden schon eine kleine Beschreibung gegeben was SPF ist und warum seine Webagentur nicht als "gmx.de" versenden darf. Jetzt scheint diese Agentur etwas überfordert zu sein - mal wieder, denn PTR-Records für IPv6 hatten sie auch mal "vergessen" und erst nach Wochen hatten Sie dann IPv6 wieder abgeschaltet. Was sage ich denen denn jetzt? Können die per Postfix Masquerading das Problem lösen? Oder müssen die das per canonical-Tabelle machen? Sollten die vielleicht per virtual_transport und Script die Mails umschreiben? Hab ich etwas übersehen? SRS ist wohl nicht das korrekte Konzept, oder? Leider habe ich keine Ahnung was die für Softwarekomponenten verwenden und ob die überhaupt Hand an die Konfiguration anlegen können oder dürfen... Ich bin für jede Hilfe dankbar. Marc -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 3429 bytes Beschreibung: S/MIME Cryptographic Signature URL : From wn at neessen.net Tue Feb 2 11:59:51 2016 From: wn at neessen.net (Winfried Neessen) Date: Tue, 02 Feb 2016 11:59:51 +0100 Subject: SPF und Masquerading, Envelope oder SRS? In-Reply-To: <56B08ABD.3090905@citkomm.de> References: <56B08ABD.3090905@citkomm.de> Message-ID: <5ca1eee79642d27f5257dc00eef214f7@neessen.net> Hi Marc, Am 2016-02-02 11:53, schrieb Marc Risse: > Hab ich etwas übersehen? SRS ist wohl nicht das korrekte Konzept, oder? > Doch, SRS waere hier die richtige Loesung: http://www.openspf.org/SRS Winni From daniel at ist-immer-online.de Tue Feb 2 12:02:59 2016 From: daniel at ist-immer-online.de (Daniel) Date: Tue, 2 Feb 2016 12:02:59 +0100 Subject: AW: SPF und Masquerading, Envelope oder SRS? In-Reply-To: <56B08ABD.3090905@citkomm.de> References: <56B08ABD.3090905@citkomm.de> Message-ID: <002f01d15da9$475b0a60$d6111f20$@ist-immer-online.de> Biete das mal anständiges Postfach an mit der Domain die auch verwendet wird. Für ne Werbeagentur nen GMX Freemail Konto würde ich nicht für wirklich Seriös nehmen, und als Hobbywerkstatt ansehen die es privat nebenbei machen. Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Marc Risse Gesendet: Dienstag, 2. Februar 2016 11:54 An: Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein. Betreff: SPF und Masquerading, Envelope oder SRS? Hallo zusammen, ich habe mit einem Kunden ein Problem: Der Kunde hat zwei Domains (domA.de und domB.de). DomA.de liegt auf meinem Server, domB.de liegt bei einem anderen Provider (kleine Webagentur). Mails an domB.de werden von dieser Webagentur an Postfächer der domA.de weiter geleitet. Diese Weiterleitung ist das Problem: Ich checke bei mir SPF, nun will mir der domB.de-Server eine Mail zustellen, die aber laut Sender von gmx.de kommt. Klar, dass ich diese Mail nicht annehme, gmx.de hat ja entsprechende SPF-Records. Jetzt mein Problem: Ich habe meinem Kunden schon eine kleine Beschreibung gegeben was SPF ist und warum seine Webagentur nicht als "gmx.de" versenden darf. Jetzt scheint diese Agentur etwas überfordert zu sein - mal wieder, denn PTR-Records für IPv6 hatten sie auch mal "vergessen" und erst nach Wochen hatten Sie dann IPv6 wieder abgeschaltet. Was sage ich denen denn jetzt? Können die per Postfix Masquerading das Problem lösen? Oder müssen die das per canonical-Tabelle machen? Sollten die vielleicht per virtual_transport und Script die Mails umschreiben? Hab ich etwas übersehen? SRS ist wohl nicht das korrekte Konzept, oder? Leider habe ich keine Ahnung was die für Softwarekomponenten verwenden und ob die überhaupt Hand an die Konfiguration anlegen können oder dürfen... Ich bin für jede Hilfe dankbar. Marc -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 5033 bytes Beschreibung: nicht verfügbar URL : From harald.witt at dpfa.de Tue Feb 2 12:38:15 2016 From: harald.witt at dpfa.de (Harald Witt) Date: Tue, 2 Feb 2016 12:38:15 +0100 Subject: AW: SPF und Masquerading, Envelope oder SRS? In-Reply-To: <56B08ABD.3090905@citkomm.de> References: <56B08ABD.3090905@citkomm.de> Message-ID: <005001d15dae$35298060$9f7c8120$@dpfa.de> Wenn ich das richtig verstanden habe, handelst du also die Mails für DomB. Die Agentur leitet nur weiter? Wenn das so ist, dann vergiss den Umweg. Die sollen den Namen deines Mailservers in den MX-Record für DomB eintragen. Du nimmst auf deinem Server DomB in die virtual_mailbox_domains auf. Fertig. Jetzt kommen alle Mails für DomB direkt zu dir. HTH Harald -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Marc Risse Gesendet: Dienstag, 2. Februar 2016 11:54 An: Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein. Betreff: SPF und Masquerading, Envelope oder SRS? Hallo zusammen, ich habe mit einem Kunden ein Problem: Der Kunde hat zwei Domains (domA.de und domB.de). DomA.de liegt auf meinem Server, domB.de liegt bei einem anderen Provider (kleine Webagentur). Mails an domB.de werden von dieser Webagentur an Postfächer der domA.de weiter geleitet. Diese Weiterleitung ist das Problem: Ich checke bei mir SPF, nun will mir der domB.de-Server eine Mail zustellen, die aber laut Sender von gmx.de kommt. Klar, dass ich diese Mail nicht annehme, gmx.de hat ja entsprechende SPF-Records. Jetzt mein Problem: Ich habe meinem Kunden schon eine kleine Beschreibung gegeben was SPF ist und warum seine Webagentur nicht als "gmx.de" versenden darf. Jetzt scheint diese Agentur etwas überfordert zu sein - mal wieder, denn PTR-Records für IPv6 hatten sie auch mal "vergessen" und erst nach Wochen hatten Sie dann IPv6 wieder abgeschaltet. Was sage ich denen denn jetzt? Können die per Postfix Masquerading das Problem lösen? Oder müssen die das per canonical-Tabelle machen? Sollten die vielleicht per virtual_transport und Script die Mails umschreiben? Hab ich etwas übersehen? SRS ist wohl nicht das korrekte Konzept, oder? Leider habe ich keine Ahnung was die für Softwarekomponenten verwenden und ob die überhaupt Hand an die Konfiguration anlegen können oder dürfen... Ich bin für jede Hilfe dankbar. Marc From igor.sverkos at gmail.com Tue Feb 2 12:47:13 2016 From: igor.sverkos at gmail.com (Igor Sverkos) Date: Tue, 2 Feb 2016 12:47:13 +0100 Subject: Recipient Verify an Exchange 2013 Datenbankserver In-Reply-To: <7db3b9a9ad7d4dda8d9a4bb8041fadca@RZ-EX-DB01.rz.fh-ingolstadt.de> References: <7db3b9a9ad7d4dda8d9a4bb8041fadca@RZ-EX-DB01.rz.fh-ingolstadt.de> Message-ID: Hallo, https://www.heinlein-support.de/blog/mailserver/exchange-2013-dynamische-empfaengerpruefung-fuer-postfix/ bzw. ein anderer Ansatz https://rz.siegnetz.de/postfix/ (gaaaaaanz unten) Hilft dir das weiter? -- Ich Grüße Igor From Dominik.Ziegler at thi.de Tue Feb 2 13:02:22 2016 From: Dominik.Ziegler at thi.de (Ziegler Dominik) Date: Tue, 2 Feb 2016 12:02:22 +0000 Subject: AW: Recipient Verify an Exchange 2013 Datenbankserver In-Reply-To: References: <7db3b9a9ad7d4dda8d9a4bb8041fadca@RZ-EX-DB01.rz.fh-ingolstadt.de> Message-ID: <365c9334362c4ca9b61c9d8694cb30eb@RZ-EX-DB01.rz.fh-ingolstadt.de> Hallo Igor, beide Anleitungen hab ich schon umgesetzt. Nun muss ich ja den Verify-Verkehr zum Mailbox-Server leiten, anstatt zu den Frontend-Servern. Bei dem Punkt scheitere ich leider im Moment, da ich schlicht nicht genau weiß, wie ich das umsetze. Bzw. ob ich mit meiner Überlegung überhaupt auf dem richtigen Weg bin. Grüße, Dominik -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Igor Sverkos Gesendet: Dienstag, 2. Februar 2016 12:47 An: Diskussionen und Support rund um Postfix Betreff: Re: Recipient Verify an Exchange 2013 Datenbankserver Hallo, https://www.heinlein-support.de/blog/mailserver/exchange-2013-dynamische-empfaengerpruefung-fuer-postfix/ bzw. ein anderer Ansatz https://rz.siegnetz.de/postfix/ (gaaaaaanz unten) Hilft dir das weiter? -- Ich Grüße Igor -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 6532 bytes Beschreibung: nicht verfügbar URL : From gregor at aeppelbroe.de Tue Feb 2 16:32:40 2016 From: gregor at aeppelbroe.de (Gregor Burck) Date: Tue, 02 Feb 2016 16:32:40 +0100 Subject: Probleme mit reject_rbl_client In-Reply-To: <1951936.JInnoKOnL5@tschaika> References: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> <8408731.4kKgGhlS1k@tschaika> <1951936.JInnoKOnL5@tschaika> Message-ID: <20160202163240.EGroupware.xKGtcbYoALIESU4BXno8xKG@heim.aeppelbroe.de> >> root at baikonur :/etc/postfix# nslookup 136.112.202.81.zen.spamhaus.org > was hat 136.112.202.81.zen.spamhaus.org mit "Client host > [62.206.247.138] blocked using zen.spamhaus.org" zu tun? Das ist eine Abfrage für eine IP Adresse die auf Spamhaus gelistet ist (81.202.112.136) Korrekter Weise gibt dann Spamhaus entweder eine 127.ger IP zurück, je nach dem auf welcher BL die IP gelistet ist. Jedenfalls wenn ich deren FAQ richtig verstanden habe ;-) > Generell kann ich nicht empfehlen, 8.8.8.8 als Resolver (auf einem > MTA) zu benutzen. Dies war ja auch nur ein test um den nslookup zu verifizieren. > Auf einen MTA, der als MX-Server fungiert gehört aus meiner Sicht > ein eigener Resolver ( unbound / bind / ... ) > der selber gegen dir Rootzone auflöst. Alles andere generiert solche > Anfragen hier auf den Mailing-Listen. Da stimme ich Dir voll und ganz zu. Bei mir ist es ein samba4 DNS, evtl. macht der ja auch Probleme. Ich werde mir das mal näher anschauen. Mal etwas anderes, sowohl von mir daheim, wie auch vom Firmen Netzwerk habe ich bei Spamhaus immer wieder eine 403. Wenn ich z.B. www.spamhaus.org aufrufe, www.spamhaus.org/zen funktioniert plötzlich wieder und wenn ich auf die www.spamhaus.org/lookup gehe habe ich wieder einen 403. Liegen die so unter Beschuss? Gerade bin ich wieder zum lookup gekommen,... Grüße Gregor From daniel at ist-immer-online.de Tue Feb 2 18:10:13 2016 From: daniel at ist-immer-online.de (Daniel) Date: Tue, 2 Feb 2016 18:10:13 +0100 Subject: Probleme mit reject_rbl_client In-Reply-To: <20160202163240.EGroupware.xKGtcbYoALIESU4BXno8xKG@heim.aeppelbroe.de> References: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> <8408731.4kKgGhlS1k@tschaika> <1951936.JInnoKOnL5@tschaika> <20160202163240.EGroupware.xKGtcbYoALIESU4BXno8xKG@heim.aeppelbroe.de> Message-ID: Scheint so als wenn Webseite Probleme hat. Bekomme aus Telekom Netz auch dort 403 oder 404 Fehler. Gruß Daniel > Am 02.02.2016 um 16:32 schrieb Gregor Burck : > > Mal etwas anderes, sowohl von mir daheim, wie auch vom Firmen Netzwerk habe ich bei Spamhaus immer wieder eine 403. > Wenn ich z.B. www.spamhaus.org aufrufe, www.spamhaus.org/zen funktioniert plötzlich wieder und wenn ich auf die www.spamhaus.org/lookup gehe habe ich wieder einen 403. Liegen die so unter Beschuss? > > Gerade bin ich wieder zum lookup gekommen,... > > Grüße > > Gregor > From thomas at antony.eu Tue Feb 2 18:38:45 2016 From: thomas at antony.eu (Thomas Antony) Date: Tue, 2 Feb 2016 17:38:45 +0000 Subject: AW: Recipient Verify an Exchange 2013 Datenbankserver In-Reply-To: <7db3b9a9ad7d4dda8d9a4bb8041fadca@RZ-EX-DB01.rz.fh-ingolstadt.de> References: <7db3b9a9ad7d4dda8d9a4bb8041fadca@RZ-EX-DB01.rz.fh-ingolstadt.de> Message-ID: <1679ef2eede04b3281993d7672294213@comf-srv16.COMFIDENT.local> .... # Receipient Verify am Exchange 2013 Datenbankserver fh-ingolstadt.de smtp:[10.50.1.7:2525] haw-ingolstadt.de smtp:[10.50.1.7:2525] carissma.eu smtp:[10.50.1.7:2525] th-ingolstadt.de smtp:[10.50.1.7:2525] thi.de smtp:[10.50.1.7:2525] .... Hi, Mit der Postfix Transport Map (/etc/postfix/transport) leitest du E-Mails an ein anderes Ziel weiter. http://www.postfix.org/transport.5.html In deinem Fall soll es Postfix -> Exchange werden. Du hast in deiner transport_map beim next-hop den Port in die Klammer gesetzt. Richtig ist Protokoll: [IP oder FQDN]:Port -> fh-ingolstadt.de smtp:[10.50.1.7]:2525 Grüße, Thomas From chris at schoeppi.net Tue Feb 2 19:48:22 2016 From: chris at schoeppi.net (Christian Schoepplein) Date: Tue, 2 Feb 2016 19:48:22 +0100 Subject: OT: Mailloops, vor allem im Zusammenhang mit Exchange Servern :-( Message-ID: <20160202184822.GA31572@v.cs-x.de> Hallo zusammen, wir verschicken über eine Web-Application automatische Benachrichtigungen und stellen damit immer wieder Probleme mit Mailloops fest, vor allem im Zusammenhang mit Exchange Servern :-(. Die Benachrichtigungen enthalten folgende Header, um Mailloops zu vermeiden: X-Loop: yes Auto-Submitted: auto-generated Da ich mich mit Exchange und co überhaupt nicht auskenne meine Frage, ob diese Header eigentlich genügen sollten, oder würdet ihr bei automatisch generierten Mails noch weitere Header einfügen bzw. die vorhandenen ändern? Habt ihr weitere Ideen, was man gegen diese lästigen Mailschleifen tun könnte, außer gleich keine automatisch generierten Mails zu verschicken :-)? Ciao und danke, Schöpp From max.grobecker at ml.grobecker.info Tue Feb 2 22:27:08 2016 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Tue, 2 Feb 2016 22:27:08 +0100 Subject: OT: Mailloops, vor allem im Zusammenhang mit Exchange Servern :-( In-Reply-To: <20160202184822.GA31572@v.cs-x.de> References: <20160202184822.GA31572@v.cs-x.de> Message-ID: <56B11F2C.9000602@ml.grobecker.info> Hallo, Loops werden vor allem dadurch verhindert, dass die Anzahl der "Received"-Header gezählt wird. Postfix hört AFAIK bei 50 Received-Headern auf, die E-Mail zuzustellen. Das kann mittels "hopcount_limit" problemlos an deine Bedürfnisse angepasst werden, es hilft dir aber natürlich nur, wenn es wirklich um Weiterleitungen geht bei denen diese Header erhalten bleiben. Wenn es dir darum geht das automatische Generieren von E-Mails (z.B. Abwesenheitsinfo) zu verhindern, kannst du zusätzlich zu "Auto-Submitted" auch noch "X-Auto-Response-Suppress: OOF, DR, RN, NRN" setzen. Aber: Insbesondere wenn ein Header mit "X-" präfigiert ist, gehört er nicht zum Standard und man sollte sich nicht unbedingt darauf verlassen, dass jeder Mailserver diese Header auswerten kann oder will. Und wenn es sich um Exchange-Server handelt, die nicht unter eurer Kontrolle stehen, lohnt es sich eventuell auch, durch den Postfix den Return-Path überschreiben zu lassen. Dieser wird normalerweise nur von Servern ausgewertet, womit ihr dann ggf. diese E-Mails vorher aussortieren könnt. Viele Grüße aus dem Tal Max -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 819 bytes Beschreibung: OpenPGP digital signature URL : From andreas.schulze at datev.de Wed Feb 3 07:58:25 2016 From: andreas.schulze at datev.de (Andreas Schulze) Date: Wed, 3 Feb 2016 07:58:25 +0100 Subject: Recipient Verify an Exchange 2013 Datenbankserver In-Reply-To: <7db3b9a9ad7d4dda8d9a4bb8041fadca@RZ-EX-DB01.rz.fh-ingolstadt.de> References: <7db3b9a9ad7d4dda8d9a4bb8041fadca@RZ-EX-DB01.rz.fh-ingolstadt.de> Message-ID: <56B1A511.2000902@datev.de> Am 02.02.2016 um 11:41 schrieb Ziegler Dominik: > wir sind vor kurzem auf Exchange 2013 gewechselt und haben folgendes Problem > festgestellt: Der Exchange antwortet leider erst nach dem DATA mit ?User > Unknown?, anstatt nach RCPT TO. http://www.postfix.org/postconf.5.html#smtp_address_verify_target -- A. Schulze DATEV eG From gregor at aeppelbroe.de Wed Feb 10 10:23:34 2016 From: gregor at aeppelbroe.de (Gregor Burck) Date: Wed, 10 Feb 2016 10:23:34 +0100 Subject: =?utf-8?b?W2dlbMO2c3Rd?= Probleme mit reject_rbl_client In-Reply-To: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> References: <20160201161420.EGroupware.qB3cVKxHeT4wzP6AnqOkCne@heim.aeppelbroe.de> Message-ID: <20160210102334.EGroupware.VVjGuDPYQzgEML5TWwQSTXW@heim.aeppelbroe.de> Ich krieche zu Kreuze, es war der Eintrag eines alternativen DNS Servers bei meiner Fritzbox. Umstellung auf default des Providers löste das Problem,... In der FAQ von Spamhaus wird explizit darauf Hingewiesen, das die Rückmeldung einer nicht gelisteten Adresse immer NX Domain sein muss,... Grüße Gregor From ffiene at veka.com Thu Feb 11 14:14:48 2016 From: ffiene at veka.com (Frank Fiene) Date: Thu, 11 Feb 2016 14:14:48 +0100 Subject: Blockieren von Realnamen im From-Feld. Message-ID: Hallo, gibt es eine Möglichkeit, anhand des From-Feldes eine Mail zu blockieren. Hier treffen im Moment Mails ein, deren Absender so aussehen: ?Vorname.Nachname at veka.com? veka at email.com Damit wird ja bei vielen Email-Clients nur der erste Teil angezeigt. Im Moment fällt mir da nur eine SpamAssassin-Regel ein, die so etwas wie ?*@veka.com? erkennt und den Score hoch genug setzt. Viele Grüße! Frank -- Frank Fiene IT-Security Manager VEKA Group Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene at veka.com http://www.veka.com PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 801 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From andre.peters at debinux.de Thu Feb 11 14:20:45 2016 From: andre.peters at debinux.de (=?UTF-8?Q?Andr=c3=a9_Peters?=) Date: Thu, 11 Feb 2016 14:20:45 +0100 Subject: Blockieren von Realnamen im From-Feld. In-Reply-To: References: Message-ID: <56BC8AAD.2090004@debinux.de> Hi, eine Möglichkeit wären header_checks: header_checks = pcre:/etc/postfix/header_checks Datei /etc/postfix/header_checks: /^From:.*veka.com.*/ REJECT Am 11.02.2016 um 14:14 schrieb Frank Fiene: > Hallo, > > gibt es eine Möglichkeit, anhand des From-Feldes eine Mail zu blockieren. > > Hier treffen im Moment Mails ein, deren Absender so aussehen: > > ?Vorname.Nachname at veka.com? veka at email.com > > Damit wird ja bei vielen Email-Clients nur der erste Teil angezeigt. > > Im Moment fällt mir da nur eine SpamAssassin-Regel ein, die so etwas wie ?*@veka.com? erkennt und den Score hoch genug setzt. > > > > Viele Grüße! > Frank > -- > Frank Fiene > IT-Security Manager VEKA Group > > Fon: +49 2526 29-6200 > Fax: +49 2526 29-16-6200 > mailto: ffiene at veka.com > http://www.veka.com > > PGP-ID: 62112A51 > PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 > Threema: VZK5NDWW > > VEKA AG > Dieselstr. 8 > 48324 Sendenhorst > Deutschland/Germany > > Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), > Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, > Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer > HRB 8282 AG Münster/District Court of Münster > -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 5642 bytes Beschreibung: S/MIME Cryptographic Signature URL : From driessen at fblan.de Thu Feb 11 14:43:54 2016 From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=) Date: Thu, 11 Feb 2016 14:43:54 +0100 Subject: AW: Blockieren von Realnamen im From-Feld. In-Reply-To: References: Message-ID: <008101d164d2$3faa7320$beff5960$@fblan.de> Im Auftrag von Frank Fiene > > Hallo, > > gibt es eine Möglichkeit, anhand des From-Feldes eine Mail zu blockieren. > > Hier treffen im Moment Mails ein, deren Absender so aussehen: > > ?Vorname.Nachname at veka.com? veka at email.com Das benutze ich um originale von DHL, paypal usw zu erkennen Ein paar Beispiele kannst du dir dann anpassen if /^From:.*@aol.com/i if /^Subject:$/ /^/ REJECT fuck off, you have no subject are you a subject? endif if /^To:$/ /^/ REJECT i don't know to where you want to send, are you silly? endif endif if /^From:.*DHL.*/i if !/\<.+ at dhl\..+\>$/i /^/ REJECT fuck off, we go on strike and do not provide packages, Your Mailaccount was hacked endif endif if /^From:.*paypal.*/i if !/\<.+@(.\.)paypal\.(de|com)\>$/i /^/ REJECT fuck off, we go on strike and do not provide money, Your Mailaccount was hacked endif endif nicht ganz ernst zu nehmende Meldungen :-)) > > Damit wird ja bei vielen Email-Clients nur der erste Teil angezeigt. > > Im Moment fällt mir da nur eine SpamAssassin-Regel ein, die so etwas wie > ?*@veka.com? erkennt und den Score hoch genug setzt. > > > > Viele Grüße! > Frank Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From jk at jkart.de Thu Feb 11 14:42:24 2016 From: jk at jkart.de (Jamie Katharina Knuth) Date: Thu, 11 Feb 2016 14:42:24 +0100 Subject: Blockieren von Realnamen im From-Feld. In-Reply-To: <56BC8AAD.2090004@debinux.de> References: <56BC8AAD.2090004@debinux.de> Message-ID: <56BC8FC0.9050209@jkart.de> am 11.02.16 14:20 schrieb André Peters : > Hi, > > eine Möglichkeit wären header_checks: > > header_checks = pcre:/etc/postfix/header_checks > > Datei /etc/postfix/header_checks: > /^From:.*veka.com.*/ REJECT > > Am 11.02.2016 um 14:14 schrieb Frank Fiene: >> Hallo, >> >> gibt es eine Möglichkeit, anhand des From-Feldes eine Mail zu >> blockieren. >> >> Hier treffen im Moment Mails ein, deren Absender so aussehen: >> >> ?Vorname.Nachname at veka.com? veka at email.com was aber nur evtl. erfolgreich sein muss, bzw. meist sinnlos ist. Denn From ist sehr oft gefälscht. -- Mit freundlichem Gruß, With kind regard, Jamie Katharina Knuth From ffiene at veka.com Fri Feb 12 09:45:40 2016 From: ffiene at veka.com (Frank Fiene) Date: Fri, 12 Feb 2016 09:45:40 +0100 Subject: Blockieren von Realnamen im From-Feld. In-Reply-To: <56BC8FC0.9050209@jkart.de> References: <56BC8AAD.2090004@debinux.de> <56BC8FC0.9050209@jkart.de> Message-ID: >> [?] >> Am 11.02.2016 um 14:14 schrieb Frank Fiene: >>> Hallo, >>> >>> gibt es eine Möglichkeit, anhand des From-Feldes eine Mail zu >>> blockieren. >>> >>> Hier treffen im Moment Mails ein, deren Absender so aussehen: >>> >>> ?Vorname.Nachname at veka.com? veka at email.com > > > was aber nur evtl. erfolgreich sein muss, bzw. > meist sinnlos ist. > Denn From ist sehr oft gefälscht. Darum genau geht es, es kommen Mails rein, die aussehen als wären sie von uns selber. Das betrifft aber nur den vorderen Teil des From-Feldes, der zwischen den ??, da kann man ja reinschreiben was man will. Wie gesagt, bei einigen Clients wird dann nur das zwischen den ?? angezeigt, weil angenommen wird, dass da der Realname steht. Da auch normale Mails von unserer Domain über diese Relays gehen, ist header_checks zu grob, wenn ich es richtig verstanden habe. Ich kann ja nicht mit permit_mynetworks einige Clients ausnehmen. Ich versuche das mal mit Spamassassin und header VEKA_010_RULE From =~ /.\"*\@veka.com.*\"/i score VEKA_010_RULE 10 in local.cf. Könnte das so gehen? Viele Grüße! Frank -- Frank Fiene IT-Security Manager VEKA Group Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene at veka.com http://www.veka.com PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 801 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From ffiene at veka.com Fri Feb 12 09:48:47 2016 From: ffiene at veka.com (Frank Fiene) Date: Fri, 12 Feb 2016 09:48:47 +0100 Subject: Blockieren von Realnamen im From-Feld. In-Reply-To: References: <56BC8AAD.2090004@debinux.de> <56BC8FC0.9050209@jkart.de> Message-ID: <360B00B3-7AD0-47AC-A6EE-F0A0CF18573E@veka.com> Hab gerade gesehen, es sollte wohl: header VEKA_010_RULE From =~ /\?.*\@veka.com.*\"/i score VEKA_010_RULE 10 lauten. ;-) > Am 12.02.2016 um 09:45 schrieb Frank Fiene : > > header VEKA_010_RULE From =~ /.\"*\@veka.com.*\"/i > score VEKA_010_RULE 10 Viele Grüße! i.A. Frank Fiene -- Frank Fiene IT-Security Manager VEKA Group Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene at veka.com http://www.veka.com PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 801 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From daniel at ist-immer-online.de Fri Feb 12 09:58:28 2016 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 12 Feb 2016 09:58:28 +0100 Subject: AW: Blockieren von Realnamen im From-Feld. In-Reply-To: References: <56BC8AAD.2090004@debinux.de> <56BC8FC0.9050209@jkart.de> Message-ID: <001d01d16573$8a3616a0$9ea243e0$@ist-immer-online.de> Wie wäre es einfach mal im DNS damit anzufangen, dass im SPF nicht alles was nicht berechtigt ist neutral vorgegeben wird. Wenn man schon konkrete IP und MX Angaben macht dann den Rest miit Softfail oder direkt fail. Also statt ?all ein ~all bzw. -all Ganze könnte man auch noch mal verschärfen mit DKIM/DMARC sofern man dort auch reject oder ähnliches vorgibt. So sollte der Kram dann automatisch im Spam landen oder abgewiesen werden jenachdem ob nun ~ oder - anwendest. Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Frank Fiene Gesendet: Freitag, 12. Februar 2016 09:46 An: Diskussionen und Support rund um Postfix Betreff: Re: Blockieren von Realnamen im From-Feld. >> [?] >> Am 11.02.2016 um 14:14 schrieb Frank Fiene: >>> Hallo, >>> >>> gibt es eine Möglichkeit, anhand des From-Feldes eine Mail zu >>> blockieren. >>> >>> Hier treffen im Moment Mails ein, deren Absender so aussehen: >>> >>> ?Vorname.Nachname at veka.com? veka at email.com > > > was aber nur evtl. erfolgreich sein muss, bzw. > meist sinnlos ist. > Denn From ist sehr oft gefälscht. Darum genau geht es, es kommen Mails rein, die aussehen als wären sie von uns selber. Das betrifft aber nur den vorderen Teil des From-Feldes, der zwischen den ??, da kann man ja reinschreiben was man will. Wie gesagt, bei einigen Clients wird dann nur das zwischen den ?? angezeigt, weil angenommen wird, dass da der Realname steht. Da auch normale Mails von unserer Domain über diese Relays gehen, ist header_checks zu grob, wenn ich es richtig verstanden habe. Ich kann ja nicht mit permit_mynetworks einige Clients ausnehmen. Ich versuche das mal mit Spamassassin und header VEKA_010_RULE From =~ /.\"*\@veka.com.*\"/i score VEKA_010_RULE 10 in local.cf. Könnte das so gehen? Viele Grüße! Frank -- Frank Fiene IT-Security Manager VEKA Group Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene at veka.com http://www.veka.com PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster From wn at neessen.net Fri Feb 12 10:01:40 2016 From: wn at neessen.net (Winfried Neessen) Date: Fri, 12 Feb 2016 10:01:40 +0100 Subject: AW: Blockieren von Realnamen im From-Feld. In-Reply-To: <001d01d16573$8a3616a0$9ea243e0$@ist-immer-online.de> References: <56BC8AAD.2090004@debinux.de> <56BC8FC0.9050209@jkart.de> <001d01d16573$8a3616a0$9ea243e0$@ist-immer-online.de> Message-ID: <9377ba0dd3b3d46a6c13a0277534c37e@neessen.net> Hi Daniel, Am 2016-02-12 09:58, schrieb Daniel: >> Hier treffen im Moment Mails ein, deren Absender so aussehen: >> >> ?Vorname.Nachname at veka.com" veka at email.com >> > Wie wäre es einfach mal im DNS damit anzufangen, dass im SPF nicht > alles was nicht > berechtigt ist neutral vorgegeben wird. > SPF wird hier nicht helfen. Wie man ja sehen kann wir die @veka.com Domain nur im Klarnamen-Feld benutzt, aber nicht als eigentliche Mail-Adresse. Hier wird @email.com (keine Ahnung ob das Bsp. wirklich valide ist) benutzt - da kann der SPF Eintrag fuer veka.com nichts dran aendern. Winni From andre.peters at debinux.de Fri Feb 12 10:08:27 2016 From: andre.peters at debinux.de (=?utf-8?Q?Andr=C3=A9_Peters?=) Date: Fri, 12 Feb 2016 10:08:27 +0100 Subject: AW: Blockieren von Realnamen im From-Feld. In-Reply-To: <001d01d16573$8a3616a0$9ea243e0$@ist-immer-online.de> References: <56BC8AAD.2090004@debinux.de> <56BC8FC0.9050209@jkart.de> <001d01d16573$8a3616a0$9ea243e0$@ist-immer-online.de> Message-ID: <09473FB8-52C5-48C9-9C89-24D236D1FF3D@debinux.de> Ich glaube, du hast das mit den SPF Records noch nicht ganz verstanden. :-) Übrigens, zur From-Header Sache: Das war absolut so erwünscht. Schließlich bekommt er die Nachrichten fälschlicherweise mit veka.com im "Header From" und nicht im Envelope. Vermutlich kommen die Mails von einem Freemailer. Das würde erklären, warum der Sender noch nicht auf einer Blacklist steht. Ich würde nach wie vor die Header Checks in Postfix bevorzugen. Aber die SA Lösung ist wohl etwas "sanfter". :-) Zu Daniel nochmal: Sein eigener SPF ist Wurst in diesem Szenario und absolut okay. Abgesehen davon ist Spam von Freemailern oft SPF- und DKIM valid. Von meinem iPhone gesendet > Am 12.02.2016 um 09:58 schrieb Daniel : > > Wie wäre es einfach mal im DNS damit anzufangen, dass im SPF nicht alles was nicht berechtigt ist neutral vorgegeben wird. > > Wenn man schon konkrete IP und MX Angaben macht dann den Rest miit Softfail oder direkt fail. > > Also statt ?all ein ~all bzw. -all > > Ganze könnte man auch noch mal verschärfen mit DKIM/DMARC sofern man dort auch reject oder ähnliches vorgibt. > > So sollte der Kram dann automatisch im Spam landen oder abgewiesen werden jenachdem ob nun ~ oder - anwendest. > > Gruß Daniel > > -----Ursprüngliche Nachricht----- > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Frank Fiene > Gesendet: Freitag, 12. Februar 2016 09:46 > An: Diskussionen und Support rund um Postfix > Betreff: Re: Blockieren von Realnamen im From-Feld. > >>> [?] >>>> Am 11.02.2016 um 14:14 schrieb Frank Fiene: >>>> Hallo, >>>> >>>> gibt es eine Möglichkeit, anhand des From-Feldes eine Mail zu >>>> blockieren. >>>> >>>> Hier treffen im Moment Mails ein, deren Absender so aussehen: >>>> >>>> ?Vorname.Nachname at veka.com? veka at email.com >> >> >> was aber nur evtl. erfolgreich sein muss, bzw. >> meist sinnlos ist. >> Denn From ist sehr oft gefälscht. > > Darum genau geht es, es kommen Mails rein, die aussehen als wären sie von uns selber. > > Das betrifft aber nur den vorderen Teil des From-Feldes, der zwischen den ??, da kann man ja reinschreiben was man will. > Wie gesagt, bei einigen Clients wird dann nur das zwischen den ?? angezeigt, weil angenommen wird, dass da der Realname steht. > > Da auch normale Mails von unserer Domain über diese Relays gehen, ist header_checks zu grob, wenn ich es richtig verstanden habe. > Ich kann ja nicht mit permit_mynetworks einige Clients ausnehmen. > > > Ich versuche das mal mit Spamassassin und > > header VEKA_010_RULE From =~ /.\"*\@veka.com.*\"/i > score VEKA_010_RULE 10 > > in local.cf. > > Könnte das so gehen? > > > Viele Grüße! > Frank > -- > Frank Fiene > IT-Security Manager VEKA Group > > Fon: +49 2526 29-6200 > Fax: +49 2526 29-16-6200 > mailto: ffiene at veka.com > http://www.veka.com > > PGP-ID: 62112A51 > PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 > Threema: VZK5NDWW > > VEKA AG > Dieselstr. 8 > 48324 Sendenhorst > Deutschland/Germany > > Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), > Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, > Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer > HRB 8282 AG Münster/District Court of Münster > > From driessen at fblan.de Fri Feb 12 11:01:33 2016 From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=) Date: Fri, 12 Feb 2016 11:01:33 +0100 Subject: AW: Blockieren von Realnamen im From-Feld. In-Reply-To: References: <56BC8AAD.2090004@debinux.de> <56BC8FC0.9050209@jkart.de> Message-ID: <00ea01d1657c$5c543e70$14fcbb50$@fblan.de> Im Auftrag von Frank Fiene > Da auch normale Mails von unserer Domain über diese Relays gehen, ist > header_checks zu grob, wenn ich es richtig verstanden habe. > Ich kann ja nicht mit permit_mynetworks einige Clients ausnehmen. > > > Ich versuche das mal mit Spamassassin und > > header VEKA_010_RULE From =~ /.\"*\@veka.com.*\"/i > score VEKA_010_RULE 10 Damit bekommen doch alle von @veka.com die 10 Punkte wenn ich mich nicht irre Mach es über Headercheck Beispiel DHL - Fakes (originale DHL gehen durch) if /^From:.*DHL.*/I # ist im From dhl dann überprüfe if !/\<.+ at dhl\..+\>$/I # ist in < > ungleich (!) dann ... /^/ REJECT fuck off, we go on strike and do not provide packages, Your Mailaccount was hacked endif endif für deine Zwecke if /^From:.*vega.*/i if !/\<.+ at veka\.com\>$/i # hast du weitere TLD'd dann ersetze \.com mit \.(de|com|sw|at) was auch immer /^/ REJECT Your Mailaccount was hacked #entschärfte variante endif endif damit fängst du schon mal 99% derer die da mit solchen fakeadressen kommen die in der Anzeige der MUA's nach @vega.com aussehen > > in local.cf. > > Könnte das so gehen? > > > Viele Grüße! > Frank Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From driessen at fblan.de Fri Feb 12 11:14:17 2016 From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=) Date: Fri, 12 Feb 2016 11:14:17 +0100 Subject: AW: Blockieren von Realnamen im From-Feld. In-Reply-To: References: <56BC8AAD.2090004@debinux.de> <56BC8FC0.9050209@jkart.de> Message-ID: <00f101d1657e$21f00dc0$65d02940$@fblan.de> Im Auftrag von Frank Fiene Habe ich vergessen Prüfen kannst du den header_check mit postmap -q "From: my spammer" regexp:/etc/postfix/header_checks > Da auch normale Mails von unserer Domain über diese Relays gehen, ist > header_checks zu grob, wenn ich es richtig verstanden habe. "normale" Mails werden nicht geblockt ! nur die die vorgeben "normal" zu sein Dhl, paypal, visa|mastercard, sparkasse, spardabank, amazon spamwelle / Schadcodes haben mit der Art der Checks keine chance Und das OHNE mails der Originalen Absender geblockt werden!! > Ich kann ja nicht mit permit_mynetworks einige Clients ausnehmen. > > > Ich versuche das mal mit Spamassassin und > > header VEKA_010_RULE From =~ /.\"*\@veka.com.*\"/i > score VEKA_010_RULE 10 Damit bekommen doch alle von @veka.com die 10 Punkte wenn ich mich nicht irre Mach es über Headercheck Beispiel DHL - Fakes (originale DHL gehen durch) if /^From:.*DHL.*/I # ist im From dhl dann überprüfe if !/\<.+ at dhl\..+\>$/I # ist in < > ungleich (!) dann ... /^/ REJECT fuck off, we go on strike and do not provide packages, Your Mailaccount was hacked endif endif für deine Zwecke if /^From:.*vega.*/i if !/\<.+ at veka\.com\>$/i # hast du weitere TLD'd dann ersetze \.com mit \.(de|com|sw|at) was auch immer /^/ REJECT Your Mailaccount was hacked #entschärfte variante endif endif damit fängst du schon mal 99% derer die da mit solchen fakeadressen kommen die in der Anzeige der MUA's nach @vega.com aussehen > > in local.cf. > > Könnte das so gehen? > > > Viele Grüße! > Frank Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From ffiene at veka.com Fri Feb 12 11:57:19 2016 From: ffiene at veka.com (Frank Fiene) Date: Fri, 12 Feb 2016 11:57:19 +0100 Subject: Blockieren von Realnamen im From-Feld. In-Reply-To: <9377ba0dd3b3d46a6c13a0277534c37e@neessen.net> References: <56BC8AAD.2090004@debinux.de> <56BC8FC0.9050209@jkart.de> <001d01d16573$8a3616a0$9ea243e0$@ist-immer-online.de> <9377ba0dd3b3d46a6c13a0277534c37e@neessen.net> Message-ID: > Am 12.02.2016 um 10:01 schrieb Winfried Neessen : > > Hi Daniel, > > Am 2016-02-12 09:58, schrieb Daniel: > >>> Hier treffen im Moment Mails ein, deren Absender so aussehen: >>> ?Vorname.Nachname at veka.com" veka at email.com >> Wie wäre es einfach mal im DNS damit anzufangen, dass im SPF nicht alles was nicht >> berechtigt ist neutral vorgegeben wird. > > SPF wird hier nicht helfen. Wie man ja sehen kann wir die @veka.com Domain nur im > Klarnamen-Feld benutzt, aber nicht als eigentliche Mail-Adresse. Hier wird @email.com > (keine Ahnung ob das Bsp. wirklich valide ist) benutzt - da kann der SPF Eintrag > fuer veka.com nichts dran ändern. Der Meinung bin ich auch, SÜPF nützt ja nichts für das zwischen den ??. Die Mail kam wirklich von veka at email.com natürlich wie schon vermutet über GMX. Viele Grüße! Frank -- Frank Fiene IT-Security Manager VEKA Group Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene at veka.com http://www.veka.com PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 801 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From ffiene at veka.com Fri Feb 12 11:58:22 2016 From: ffiene at veka.com (Frank Fiene) Date: Fri, 12 Feb 2016 11:58:22 +0100 Subject: Blockieren von Realnamen im From-Feld. In-Reply-To: <00ea01d1657c$5c543e70$14fcbb50$@fblan.de> References: <56BC8AAD.2090004@debinux.de> <56BC8FC0.9050209@jkart.de> <00ea01d1657c$5c543e70$14fcbb50$@fblan.de> Message-ID: <491D291F-3D37-4557-869A-69A79B5265E6@veka.com> > Am 12.02.2016 um 11:01 schrieb Uwe Drießen : > >> header VEKA_010_RULE From =~ /.\"*\@veka.com.*\"/i >> score VEKA_010_RULE 10 > > Damit bekommen doch alle von @veka.com die 10 Punkte wenn ich mich nicht irre Ähhh, ich hoffe nicht. Dafür sind ja die beiden \? . Viele Grüße! Frank -- Frank Fiene IT-Security Manager VEKA Group Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene at veka.com http://www.veka.com PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 801 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From Marc.Grooz at regioit.de Fri Feb 12 12:25:21 2016 From: Marc.Grooz at regioit.de (Grooz, Marc (regio iT)) Date: Fri, 12 Feb 2016 11:25:21 +0000 Subject: Bayes Datenbank u. Spamassassin Message-ID: <243016E7989B3045AA79AADDA18308254D886140@srv02029.Admin.local> Hallo Zusammen, Vielleicht könnt Ihr mir weiterhelfen. Seit einer Weile sehe ich das die Bayesfunktion des Spamassassin in meinem Setup oft sehr hoch bewertete Spammails mit einem BAYES_00 -1,9 versieht. Leider aber auch Spammails welche dank des BAYES_00 bei dem Reject Score von 6.31 durchkommen. Ich verwende die aktuelle Amavis- und Spamassassinversionen. sa-update wird auch regelmäßig ausgeführt. Sonst habe ich selber nicht weiter in den Spamassassin eingegriffen. Die Bayesdatenbank wir nur durch das autolearn gefüttert. Hier ein Output der aktuellen Bayeswerte: sa-learn --dump magic 0.000 0 3 0 non-token data: bayes db version 0.000 0 1490 0 non-token data: nspam 0.000 0 100550 0 non-token data: nham 0.000 0 2839359 0 non-token data: ntokens 0.000 0 1455231068 0 non-token data: oldest atime 0.000 0 1455274630 0 non-token data: newest atime 0.000 0 0 0 non-token data: last journal sync atime 0.000 0 1455274271 0 non-token data: last expiry atime 0.000 0 43200 0 non-token data: last expire atime delta 0.000 0 2958 0 non-token data: last expire reduction count Ich hatte auch schon versucht die Bayesfunktion ganz abzuschalten was natürlich dann mehr Spams gefiltert hat da der BAYES_00 nicht mehr greift. Das finde ich aber sehr schade da die Idee ja nicht schlecht ist. Es kommt auch öfters vor das Spammails noch durch keine Blacklist erkannt wird und dann könnte Bayes eine gute Sache sein. Habt Ihr ähnliche Erfahrungen gemacht oder eine Lösung gefunden? Vielen Dank Gruß Marc From Hajo.Locke at gmx.de Mon Feb 22 10:31:59 2016 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Mon, 22 Feb 2016 10:31:59 +0100 Subject: transport in master.cf Message-ID: <56CAD58F.8080201@gmx.de> Hallo Liste, ich spiele etwas an der Postfixkonfiguration herum, weil ich einen eigenen Perl-Daemon testen will. Ich habe einen Standardsmtpd und einen zusätzlichen smtpd auf Port 10026 in der master.cf eingerichtet. Vom Standard smtp schicke ich per transport_maps mit "* smtp:127.0.0.1:10026" alles an den weiteren smtpd. Beim smtpd auf Port 10026 setze ich dann meinen eigenen Perl-Daemon als Policy-Service ein. Im Grunde teste ich nur wie das alles funktioniert und wie man sowas programmiert. Das Problem bei der Sache ist, dass ich den Wildcard transport Eintrag in der master.cf für den weiteren smtpd nicht mehr aufheben kann und der 10026er smtpd auch an sich selbst zustellt. Zumindest hat nichts funktioniert, ist ja auch keine smtpd-Eigenschaft. Ist hier jemandem ein Weg bekannt dies wieder abzuschalten? Brauche ich da eventuell sogar ein Postmulti-Setup? Oder gibt es einen anderen Weg analog zur transport_maps alles an lokalen/nichtlokalen Mails, die auf verschiedenstem Weg ankommen können, an einen anderen smtpd zu leiten? relay_host wäre hier z.b. nicht ausreichend. Ich weiß, dass dies so kein Einsatzszenario ist, aber das Problem an sich konnte ich bisher nicht klären. Danke, Hajo From andre.peters at debinux.de Mon Feb 22 10:45:41 2016 From: andre.peters at debinux.de (=?UTF-8?Q?Andr=c3=a9_Peters?=) Date: Mon, 22 Feb 2016 10:45:41 +0100 Subject: transport in master.cf In-Reply-To: <56CAD58F.8080201@gmx.de> References: <56CAD58F.8080201@gmx.de> Message-ID: <56CAD8C5.8000702@debinux.de> Hi, was du machen möchtest, klingt nach einem "advanced filter". Dazu kannst du in der main.cf (oder wo auch immer) lieber "content_filter = smtp:127.0.0.1:10026" verwenden. (http://www.postfix.org/FILTER_README.html#advanced_filter) Was du gemacht hast, war ein "alles über XY 'relayen'". :-) Das geht auch und wird für "before-queue" Filter gerne verwendet, macht man dann aber als SMTPd Proxy: http://www.postfix.org/SMTPD_PROXY_README.html Hier müsste der Filter/das Perl Script die Mail einfach an irgendeinen weiteren SMTPd Listener zurücksenden. Nur eben nicht an den Listener, der den smtpd_proxy_filter Parameter konfiguriert hat. Nachteil ist, dass du quasi das gesamte Handling an den Proxy weitergibst. Damit fallen die ganzen schönen Vorteile von Postfix als MTA weg. :-) Wenn du nur einen Policyd bauen möchtest, solltest du dir das hier anschauen: http://www.postfix.org/SMTPD_POLICY_README.html - ist wesentlich einfacher zu schreiben als ein Filter. Du musst dich nicht um X Dinge kümmern, die du evtl. gar nicht brauchst. Ich hoffe, ich konnte helfen. Viele Grüße André Am 22.02.2016 um 10:31 schrieb Hajo Locke: > Hallo Liste, > > ich spiele etwas an der Postfixkonfiguration herum, weil ich einen > eigenen Perl-Daemon testen will. > Ich habe einen Standardsmtpd und einen zusätzlichen smtpd auf Port > 10026 in der master.cf eingerichtet. > Vom Standard smtp schicke ich per transport_maps mit "* > smtp:127.0.0.1:10026" alles an den weiteren smtpd. > Beim smtpd auf Port 10026 setze ich dann meinen eigenen Perl-Daemon > als Policy-Service ein. Im Grunde teste ich nur wie das alles > funktioniert und wie man sowas programmiert. > > Das Problem bei der Sache ist, dass ich den Wildcard transport Eintrag > in der master.cf für den weiteren smtpd nicht mehr aufheben kann und > der 10026er smtpd auch an sich selbst zustellt. Zumindest hat nichts > funktioniert, ist ja auch keine smtpd-Eigenschaft. > Ist hier jemandem ein Weg bekannt dies wieder abzuschalten? Brauche > ich da eventuell sogar ein Postmulti-Setup? > Oder gibt es einen anderen Weg analog zur transport_maps alles an > lokalen/nichtlokalen Mails, die auf verschiedenstem Weg ankommen > können, an einen anderen smtpd zu leiten? > relay_host wäre hier z.b. nicht ausreichend. Ich weiß, dass dies so > kein Einsatzszenario ist, aber das Problem an sich konnte ich bisher > nicht klären. > > Danke, > Hajo -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 5642 bytes Beschreibung: S/MIME Cryptographic Signature URL : From Hajo.Locke at gmx.de Mon Feb 22 11:50:16 2016 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Mon, 22 Feb 2016 11:50:16 +0100 Subject: transport in master.cf In-Reply-To: <56CAD8C5.8000702@debinux.de> References: <56CAD58F.8080201@gmx.de> <56CAD8C5.8000702@debinux.de> Message-ID: <56CAE7E8.2000605@gmx.de> Hallo, Am 22.02.2016 um 10:45 schrieb André Peters: > Hi, > > was du machen möchtest, klingt nach einem "advanced filter". Dazu > kannst du in der main.cf (oder wo auch immer) lieber "content_filter = > smtp:127.0.0.1:10026" verwenden. > (http://www.postfix.org/FILTER_README.html#advanced_filter) > > Was du gemacht hast, war ein "alles über XY 'relayen'". :-) Das geht > auch und wird für "before-queue" Filter gerne verwendet, macht man > dann aber als SMTPd Proxy: http://www.postfix.org/SMTPD_PROXY_README.html > Hier müsste der Filter/das Perl Script die Mail einfach an irgendeinen > weiteren SMTPd Listener zurücksenden. Nur eben nicht an den Listener, > der den smtpd_proxy_filter Parameter konfiguriert hat. > Nachteil ist, dass du quasi das gesamte Handling an den Proxy > weitergibst. Damit fallen die ganzen schönen Vorteile von Postfix als > MTA weg. :-) > > Wenn du nur einen Policyd bauen möchtest, solltest du dir das hier > anschauen: http://www.postfix.org/SMTPD_POLICY_README.html - ist > wesentlich einfacher zu schreiben als ein Filter. Du musst dich nicht > um X Dinge kümmern, die du evtl. gar nicht brauchst. Ja, das ist es was ich probiere. Der Policyd funktioniert im Grunde auch. Ich bekomme von postfix die Daten und ich werte aus und geben entsprechende Antwort. Für eine richtige smtp-Engine fehlt mir das Wissen und wäre auch zuviel bei der Sache. Einen richtigen content_filter trau ich mir nicht zu. Den Dienst den ich da mache, setze ich bei dem 10026er smtpd als check_policy_service ein. Tut mir leid, ich hatte mich da nicht klar genug ausgedrückt. Das Problem bei der Sache ist, dass ich eben das gesamte Vorkommen an Mails durch den policyd schicken möchte, um zu sehen was dann auf dem policyd reinkommt und was man damit machen kann. Bei einem Standard smtpd geht das nicht, der greift nicht bei lokalen Mails z.B. per sendmail, daher meine Idee alles per transport_maps an den nächsten smtpd zu senden. Den transport-Eintrag kann ich aber beim 10026er nicht mehr aufheben und damit dann der loop. Ich vermute ich würde ein postmulti setup benötigen. Das ist mir jetzt aber zu viel nur wegen ein paar Tests. Danke für deine Unterstützung. > > Ich hoffe, ich konnte helfen. > > Viele Grüße > André > > Am 22.02.2016 um 10:31 schrieb Hajo Locke: >> Hallo Liste, >> >> ich spiele etwas an der Postfixkonfiguration herum, weil ich einen >> eigenen Perl-Daemon testen will. >> Ich habe einen Standardsmtpd und einen zusätzlichen smtpd auf Port >> 10026 in der master.cf eingerichtet. >> Vom Standard smtp schicke ich per transport_maps mit "* >> smtp:127.0.0.1:10026" alles an den weiteren smtpd. >> Beim smtpd auf Port 10026 setze ich dann meinen eigenen Perl-Daemon >> als Policy-Service ein. Im Grunde teste ich nur wie das alles >> funktioniert und wie man sowas programmiert. >> >> Das Problem bei der Sache ist, dass ich den Wildcard transport >> Eintrag in der master.cf für den weiteren smtpd nicht mehr aufheben >> kann und der 10026er smtpd auch an sich selbst zustellt. Zumindest >> hat nichts funktioniert, ist ja auch keine smtpd-Eigenschaft. >> Ist hier jemandem ein Weg bekannt dies wieder abzuschalten? Brauche >> ich da eventuell sogar ein Postmulti-Setup? >> Oder gibt es einen anderen Weg analog zur transport_maps alles an >> lokalen/nichtlokalen Mails, die auf verschiedenstem Weg ankommen >> können, an einen anderen smtpd zu leiten? >> relay_host wäre hier z.b. nicht ausreichend. Ich weiß, dass dies so >> kein Einsatzszenario ist, aber das Problem an sich konnte ich bisher >> nicht klären. >> >> Danke, >> Hajo > > Danke, Hajo From postfixbuch at cboltz.de Mon Feb 22 20:15:33 2016 From: postfixbuch at cboltz.de (Christian Boltz) Date: Mon, 22 Feb 2016 20:15:33 +0100 Subject: transport in master.cf In-Reply-To: <56CAE7E8.2000605@gmx.de> References: <56CAD58F.8080201@gmx.de> <56CAD8C5.8000702@debinux.de> <56CAE7E8.2000605@gmx.de> Message-ID: <6809002.D2v8rHgh2X@tux.boltz.de.vu> Hallo Hajo, hallo zusammen, Am Montag, 22. Februar 2016, 11:50:16 CET schrieb Hajo Locke: > Am 22.02.2016 um 10:45 schrieb André Peters: > smtpd zu senden. Den transport-Eintrag kann ich aber beim 10026er > nicht mehr aufheben Äh, wieso eigentlich nicht? Probier mal folgenden Eintrag in der master.cf (ggf. anpassen, je nachdem, wie Du den transport-Eintrag festgelegt hast): localhost:10026 inet n - n - - smtpd -o smtpd_proxy_filter= -o transport_maps= -o default_transports=smtp Gruß Christian Boltz -- 404: Blog Ein Haufen Scriptkiddies ist gerade dabei, USENET in bunt neu zu erfinden, und machen derzeit einen Haufen Fehler neu, die schon seit 20 Jahren nicht mehr Gegenstand der Forschung sind. [Kristian Köhntopp] From Hajo.Locke at gmx.de Tue Feb 23 08:43:22 2016 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Tue, 23 Feb 2016 08:43:22 +0100 Subject: transport in master.cf In-Reply-To: <6809002.D2v8rHgh2X@tux.boltz.de.vu> References: <56CAD58F.8080201@gmx.de> <56CAD8C5.8000702@debinux.de> <56CAE7E8.2000605@gmx.de> <6809002.D2v8rHgh2X@tux.boltz.de.vu> Message-ID: <56CC0D9A.9040806@gmx.de> Hallo, Am 22.02.2016 um 20:15 schrieb Christian Boltz: > Hallo Hajo, hallo zusammen, > > Am Montag, 22. Februar 2016, 11:50:16 CET schrieb Hajo Locke: >> Am 22.02.2016 um 10:45 schrieb André Peters: >> smtpd zu senden. Den transport-Eintrag kann ich aber beim 10026er >> nicht mehr aufheben > Äh, wieso eigentlich nicht? > > Probier mal folgenden Eintrag in der master.cf (ggf. anpassen, je > nachdem, wie Du den transport-Eintrag festgelegt hast): > > localhost:10026 inet n - n - - smtpd > -o smtpd_proxy_filter= > -o transport_maps= > -o default_transports=smtp Klappt bei mir nicht, loopt trotzdem. ich hab auch testweise mal in der master.cf einen weiteren smtp-service eingetragen und versucht zu benutzen, klappt aber nicht. Den smtpd interessiert die Einstellung offenbar nicht. Ich hatte gestern doch mal schnell ein Postmulti-Setup aufgebaut und da klappt es, da die smtp- und smtpd-Prozesse strenger getrennt sind. Für paar Tests ist mir das aber zu viel, mit postmulti hab ich bisher noch nichts gemacht. > > Gruß > > Christian Boltz Danke, Hajo From p at sys4.de Tue Feb 23 10:28:09 2016 From: p at sys4.de (Patrick Ben Koetter) Date: Tue, 23 Feb 2016 10:28:09 +0100 Subject: ANN: savacli - Avira SAVAPI command line client Message-ID: <20160223092809.GB4293@sys4.de> Hallo, wir sind schon eine Weile AVIRA Technologie-Partner und setzen unter anderem deren UNIX-Produktlinie fort. Vor Kurzem haben wir für einen dt. Kunden der AVIRA den Kommandozeilen-Client savacli entwickelt. savacli nutzt AVIRAs lizenzpflichtige AV-Engine SAVAPI, um Dateien und Verzeichnisse nach Malware abzusuchen. Es generiert Reports in Plaintext und JSON. Der Kunde möchte nicht genannt werden. Er legt aber grossen Wert darauf, dass savacli als Open Source Software released wird. Diesem Wunsch kommen wir sehr gerne nach. :) Ihr findet Client und Dokumentation unter https://github.com/sys4/savacli. Grüsse p at rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From m.grundmann at wittich-foehren.de Tue Feb 23 18:34:16 2016 From: m.grundmann at wittich-foehren.de (Michael Grundmann) Date: Tue, 23 Feb 2016 18:34:16 +0100 Subject: savacli - Avira SAVAPI command line client In-Reply-To: <20160223092809.GB4293@sys4.de> References: <20160223092809.GB4293@sys4.de> Message-ID: <56CC9818.2090801@wittich-foehren.de> Hi, sage deinem Kunden bitte vielen Dank! Am 23.02.16 um 10:28 schrieb Patrick Ben Koetter: > Hallo, > > wir sind schon eine Weile AVIRA Technologie-Partner und setzen unter anderem > deren UNIX-Produktlinie fort. Vor Kurzem haben wir für einen dt. Kunden der > AVIRA den Kommandozeilen-Client savacli entwickelt. > > savacli nutzt AVIRAs lizenzpflichtige AV-Engine SAVAPI, um Dateien und > Verzeichnisse nach Malware abzusuchen. Es generiert Reports in Plaintext und > JSON. > > Der Kunde möchte nicht genannt werden. Er legt aber grossen Wert darauf, dass > savacli als Open Source Software released wird. Diesem Wunsch kommen wir sehr > gerne nach. :) > > Ihr findet Client und Dokumentation unter https://github.com/sys4/savacli. > > Grüsse > > p at rick > -- Mit freundlichen Grüßen *Verlag + Druck LINUS WITTICH KG* i. A. Michael Grundmann 54343 Föhren Europaallee 2 E-Mail: m.grundmann at wittich-foehren.de Internet: http://www.wittich.de Tel.: +49 6502/9147210 Fax: +49 6502/9147332 Sitz der Gesellschaft: Föhren Geschäftsführer: Dietmar Kaupp Amtsgericht: Wittlich HR 4199 USt ID gemäß §27 a UStG DE 149324406 *Kennen Sie schon localbook? Nein? Hier >>> * From postfixbuch at cboltz.de Thu Feb 25 22:11:52 2016 From: postfixbuch at cboltz.de (Christian Boltz) Date: Thu, 25 Feb 2016 22:11:52 +0100 Subject: pflogsumm.pl - Probleme unter openSUSE Leap Message-ID: <7074662.y1VQLZ550H@tux.boltz.de.vu> Hallo zusammen, ich habe vor kurzem einen Server mit openSUSE Leap 42.1 aufgesetzt und festgestellt, dass pflogsumm.pl die Mails im Logfile nicht mehr erkennt - im "Grand Totals"-Abschnitt stehen 0 received, 0 delivered usw. Immerhin etwas findet pflogsumm - Warnungen für doppelt definierte Parameter, z. B. 1 /etc/postfix/main.cf, line 799: overriding earlier entry: [...] Ich habe gerade das Log mit einem openSUSE 13.1 verglichen - unter Leap sind die Logeinträge in /var/log/mail im Stil von Feb 25 21:24:45 server qmgr[29331]: [...] Feb 25 21:24:45 server smtp[17026]: [...] und unter 13.1 Feb 25 00:18:31 server postfix/qmgr[28225]: [...] Feb 25 00:18:31 server postfix/smtp[16514]: [...] Sprich: Der Prefix "postfix/" fehlt. Ich habe sowohl mit einem älteren pflogsumm.pl (1.1.1) als auch mit dem neuesten (1.1.5 - laut Changelog von Februar 2012) - beide mit dem oben beschriebenen Ergebnis. Ist schon jemand über dieses Problem "gestolpert" und hat eine Lösung parat? Oder muss ich den pflogsumm-Entwickler nerven? Gruß Christian Boltz -- Zeitreisen vermeide ich immer, sollen irgendwie ungesund sein. [Helga Fischer in suse-linux] From andreas.schulze at datev.de Fri Feb 26 08:12:14 2016 From: andreas.schulze at datev.de (Andreas Schulze) Date: Fri, 26 Feb 2016 08:12:14 +0100 Subject: pflogsumm.pl - Probleme unter openSUSE Leap In-Reply-To: <7074662.y1VQLZ550H@tux.boltz.de.vu> References: <7074662.y1VQLZ550H@tux.boltz.de.vu> Message-ID: <56CFFACE.6070409@datev.de> Am 25.02.2016 um 22:11 schrieb Christian Boltz: > Ich habe gerade das Log mit einem openSUSE 13.1 verglichen - unter Leap > sind die Logeinträge in /var/log/mail im Stil von > Feb 25 21:24:45 server qmgr[29331]: [...] > Feb 25 21:24:45 server smtp[17026]: [...] > und unter 13.1 > Feb 25 00:18:31 server postfix/qmgr[28225]: [...] > Feb 25 00:18:31 server postfix/smtp[16514]: [...] > > Sprich: Der Prefix "postfix/" fehlt. ev. hat jemand am Parameter "syslog_name" in der main.cf rumgespielt. normalerweise steht syslog_name auf "postfix" bzw "${multi_instance_name?{$multi_instance_name}:{postfix}" somit sollte in den Einträge eigentlich immer "postfix/irgendwas" auftauchen. siehe http://www.postfix.org/postconf.5.html#syslog_name -- A. Schulze DATEV eG From joerg at backschues.de Fri Feb 26 17:33:45 2016 From: joerg at backschues.de (=?UTF-8?Q?J=c3=b6rg_Backschues?=) Date: Fri, 26 Feb 2016 17:33:45 +0100 Subject: Outlook OLE Package blockieren Message-ID: <56D07E69.5070002@backschues.de> Hallo, sieht jemand eine Change, dieses u.g. OLE Package mit Postfix / AMaViS zu blockieren: Eine entsprechende Beispieldatei befindet sich am Ende der Web-Seite. Selbst bei Virustotal werden keine Auffäligkeiten festgestellt: Das könnte eine neue "Locky" Verbreitungsmethode werden. -- Gruß Jörg Backschues From andreas.schulze at datev.de Fri Feb 26 19:09:38 2016 From: andreas.schulze at datev.de (Andreas Schulze) Date: Fri, 26 Feb 2016 19:09:38 +0100 Subject: Outlook OLE Package blockieren In-Reply-To: <56D07E69.5070002@backschues.de> References: <56D07E69.5070002@backschues.de> Message-ID: <56D094E2.1030409@datev.de> Am 26.02.2016 um 17:33 schrieb Jörg Backschues: > Hallo, > > sieht jemand eine Change, dieses u.g. OLE Package mit Postfix / AMaViS > zu blockieren: > > > > > Eine entsprechende Beispieldatei befindet sich am Ende der Web-Seite. > > Selbst bei Virustotal werden keine Auffäligkeiten festgestellt: > > > > > Das könnte eine neue "Locky" Verbreitungsmethode werden. > ich vermute mal, dass eine soche E-Mail als winmail.dat bzw. Content-Type ms/t-net transportiert wird. Dieses Format (auch als Exchange Rich Text) ist Outlook propriätär. Mit gutem Willen kann man an seinem MX eine Policy durchsetzen, sowas einfach zu blocken. Andreas From driessen at fblan.de Sat Feb 27 07:21:39 2016 From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=) Date: Sat, 27 Feb 2016 07:21:39 +0100 Subject: AW: Outlook OLE Package blockieren In-Reply-To: <56D07E69.5070002@backschues.de> References: <56D07E69.5070002@backschues.de> Message-ID: <003201d17127$1f0b1be0$5d2153a0$@fblan.de> Im Auftrag von Jörg Backschues > > > > Das könnte eine neue "Locky" Verbreitungsmethode werden. Wegen locky sind zur Zeit folgende Einträge bei mir in Amavis im Einsatz #Sperre wegen Lockyvirus qr'\.[^./]*\.(doc|dot|docx|docm|dotx|dotm|docb|xls|xlt|xlm|xlsb|xla|xlam|xll|xlw|ppt|pot|pps|pptx|pptm|potx|potm|ppam|ppsx|ppsm|sldx|sldm|pub|msg)\.?$'i, qr'^application/msword,application/vnd.openxmlformats-officedocument.wordprocessingml.document$'i, qr'^application/vnd.openxmlformats-officedocument.wordprocessingml.template$'i, qr'^application/vnd.ms-word.document.macroEnabled.12$'i, qr'^application/vnd.ms-word.template.macroEnabled.12$'i, qr'^application/vnd.ms-excel$'i, qr'^application/vnd.openxmlformats-officedocument.spreadsheetml.sheet$'i, qr'^application/vnd.openxmlformats-officedocument.spreadsheetml.template$'i, qr'^application/vnd.ms-excel.sheet.macroEnabled.12$'i, qr'^application/vnd.ms-excel.template.macroEnabled.12$'i, qr'^application/vnd.ms-excel.addin.macroEnabled.12$'i, qr'^application/vnd.ms-excel.sheet.binary.macroEnabled.12$'i, #Sperre wegen Lockyvirus ende Das msg habe ich dann gerade noch hinzugefügt > > -- > Gruß > Jörg Backschues Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From Hullen at t-online.de Sat Feb 27 12:06:00 2016 From: Hullen at t-online.de (Helmut Hullen) Date: Sat, 27 Feb 2016 12:06:00 +0100 Subject: Outlook OLE Package blockieren In-Reply-To: <003201d17127$1f0b1be0$5d2153a0$@fblan.de> Message-ID: Hallo, Uwe, Du meintest am 27.02.16: >> Das könnte eine neue "Locky" Verbreitungsmethode werden. > Wegen locky sind zur Zeit folgende Einträge bei mir in Amavis im > Einsatz > #Sperre wegen Lockyvirus > qr'\.[^./]*\.(doc|dot|docx|docm|dotx|dotm|docb|xls|xlt|xlm|xlsb|xla > |xlam|xll|xlw|ppt|pot|pps|pptx|pptm|potx|potm|ppam|ppsx|ppsm|sldx|sld > m|pub|msg)\.?$'i, Zu ergänzen u.a. durch "rar". hier: xyz.png.exe gepackt in xyz.png.rar Als Nachricht eines Scanners getarnt. Viele Gruesse! Helmut From driessen at fblan.de Sat Feb 27 13:03:04 2016 From: driessen at fblan.de (=?iso-8859-1?Q?Uwe_Drie=DFen?=) Date: Sat, 27 Feb 2016 13:03:04 +0100 Subject: AW: Outlook OLE Package blockieren In-Reply-To: References: <003201d17127$1f0b1be0$5d2153a0$@fblan.de> Message-ID: <004601d17156$d0ac3d50$7204b7f0$@fblan.de> Im Auftrag von Helmut Hullen Hallo Helmut > Zu ergänzen u.a. durch "rar". Rar,zip,7zip usw. werden alle zuerst entpackt und dann gescannt :-)) Exe,com,bat,pif ... usw. wird schon standardmäßig nicht durchgelassen > > hier: xyz.png.exe gepackt in xyz.png.rar > > Als Nachricht eines Scanners getarnt. > > Viele Gruesse! > Helmut Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From philipp at phflesch.de Sat Feb 27 16:12:37 2016 From: philipp at phflesch.de (Philipp Flesch) Date: Sat, 27 Feb 2016 16:12:37 +0100 Subject: Outlook OLE Package blockieren In-Reply-To: References: Message-ID: <56D1BCE5.5020905@phflesch.de> Ohne mir jetzt Eure Listen angeschaut zu haben - ich kann nur https://www.mailsupport.dfn.de/dokumentation/checks/anhaenge/ empfehlen :-) Am 27.02.2016 um 12:06 schrieb Helmut Hullen: > Hallo, Uwe, > > Du meintest am 27.02.16: > >>> Das könnte eine neue "Locky" Verbreitungsmethode werden. >> Wegen locky sind zur Zeit folgende Einträge bei mir in Amavis im >> Einsatz >> #Sperre wegen Lockyvirus >> qr'\.[^./]*\.(doc|dot|docx|docm|dotx|dotm|docb|xls|xlt|xlm|xlsb|xla >> |xlam|xll|xlw|ppt|pot|pps|pptx|pptm|potx|potm|ppam|ppsx|ppsm|sldx|sld >> m|pub|msg)\.?$'i, > Zu ergänzen u.a. durch "rar". > > hier: xyz.png.exe gepackt in xyz.png.rar > > Als Nachricht eines Scanners getarnt. > > Viele Gruesse! > Helmut >