From Hajo.Locke at gmx.de Tue May 3 13:09:53 2016 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Tue, 3 May 2016 13:09:53 +0200 Subject: OT: Spamassassin + Fail2ban Message-ID: <99911f2e-696c-0278-ef81-f76d20ff895b@gmx.de> Hallo Liste, trifft nicht ganz den Postfixkern, ist aber auf jeden Fall verwandt. Ich habe verschiedene Postfix+Spamassassinanbindungen in Betrieb. Bei den einen Varianten wird spamc über procmail bzw. sieve ausgelöst, bei anderen Varianten nutze ich spamass-milter, um spamassassin direkt über die Milterschnittstelle anzusprechen und ist direkt im Postfix eingebunden. Nun würde ich gerne für Fail2ban eine weitere Regel aktivieren, um Sender von Spammails automatisch in meine Blacklist einzutragen. Bei den Milter-Logs klappt das alles gut, da ist alles in einer Zeile vorhanden. Das Problem sind die normalen spamc/spamd Logs. Die Informationen die ich benötige sind über mehrere Zeilen verteilt. So was kann ich mit fail2ban nicht auswerten. Selbst auf der Console sind das mehrere greps von MessageID zu MailID zu SenderIP. Habt Ihr einen Tipp für mich, wie ich diese Logs verwertbar bekomme? An den Spamassassinoptionen find ich nichts mehr und das starten von spamc per procmail/sieve kann ich hier auch nicht ändern. MfG Hajo From stefan1 at hofmeir.de Fri May 6 13:28:17 2016 From: stefan1 at hofmeir.de (Stefan Hofmeir) Date: Fri, 6 May 2016 13:28:17 +0200 Subject: =?iso-8859-15?Q?fehlende_Date-Zeile_erg=E4nzen_=28Datum_fehlt_im_Header=29?= Message-ID: <707297167.20160506132817@hofmeir.de> Hallo, es kommt leider immer wieder vor, dass user per PHP-Scripte Mails generieren, die keine "Date: " Zeile beinhalten. Mit always_add_missing_headers = yes kann man fehlende Headerzeilen ergänzen: http://www.postfix.org/postconf.5.html#always_add_missing_headers > Always add (Resent-) From:, To:, Date: or Message-ID: headers when > not present. Postfix 2.6 and later add these headers only when > clients match the local_header_rewrite_clients parameter setting. Wie kann man erreichen, dass die Regel nur bei fehlender Date-Zeile aktiv wird und sonst keine weiteren Zeilen abändert? -- Viele Grüße Stefan From postfixer99 at gmail.com Tue May 10 11:16:03 2016 From: postfixer99 at gmail.com (Carsten) Date: Tue, 10 May 2016 11:16:03 +0200 Subject: =?UTF-8?Q?Speziellen_DNS-Server_f=c3=bcr_Postfix_definieren?= Message-ID: <5731A6D3.4050104@gmail.com> Hallo zusammen, unsere Linux-Server nutzen die firmeninternen DNS-Server für sämtliche Namensauflösungen. Hier wird Split-DNS betrieben, sodass die öffentliche Zone (Internet) und die interne Zone für den gleichen Namensraum z.T. gewollt unterschiedlich auflöst. Hieraus entstehen jedoch im meinem Fall für den Postfix-Server Probleme, da die internen Definitionen Vorrang haben und in meinem Fall nicht gewünscht sind. Ich möchte gerne, dass das Linux System selbst weiterhin die firmeneigenen internen DNS-Server nutzt (für Datensicherung, Updates, usw.). Der Postfix soll jedoch den öffentlichen Server des Providers oder alternativ die DNS-Root-Server nutzen. Ich finde jedoch keine Option, dem Postfix beizubringen, einen anderen DNS-Server zu nutzen, als den in der /etc/resolv.conf. Gibt es da einen Trick? Gruß Carsten From andre.peters at debinux.de Tue May 10 11:26:08 2016 From: andre.peters at debinux.de (=?utf-8?q?Andr=c3=a9=20Peters?=) Date: Tue, 10 May 2016 09:26:08 +0000 Subject: =?utf-8?q?Re=3a=20Speziellen=20DNS-Server=20f=c3=bcr=20Postfix=20definieren?= In-Reply-To: <5731A6D3.4050104@gmail.com> Message-ID: Hi, Postfix sperrt sich per Standard in einem Jail unter /var/spool/postfix ein (übliche Distros). Du könntest hier einfach die Datei /var/spool/postfix/etc/resolv.conf verändern und vllt. vor Änderung schützen. Aber das ist schon eine ganz dreckige Lösung... Da würde ich lieber einen lokalen DNS Forwarder wie dnsmasq einsetzen und sagen, welchen DNS-Server er für welche Domain nutzen soll. Zum Beispiel mit "server=/interne.domain/192.168.99.99" in der dnsmasq.conf. Dein System würde dann eben den DNS-Server 127.0.0.1 verwenden. Ist generell ganz praktisch, wenn man einen zwischenspeichernden DNS-Server lokal aufsetzt. :-) Beste Grüße André ------ Originalnachricht ------ Von: "Carsten" An: "Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein." Gesendet: 10.05.2016 11:16:03 Betreff: Speziellen DNS-Server für Postfix definieren >Hallo zusammen, > >unsere Linux-Server nutzen die firmeninternen DNS-Server für sämtliche >Namensauflösungen. > >Hier wird Split-DNS betrieben, sodass die öffentliche Zone (Internet) >und die interne Zone für den gleichen Namensraum z.T. gewollt >unterschiedlich auflöst. Hieraus entstehen jedoch im meinem Fall für >den Postfix-Server Probleme, da die internen Definitionen Vorrang haben >und in meinem Fall nicht gewünscht sind. > >Ich möchte gerne, dass das Linux System selbst weiterhin die >firmeneigenen internen DNS-Server nutzt (für Datensicherung, Updates, >usw.). >Der Postfix soll jedoch den öffentlichen Server des Providers oder >alternativ die DNS-Root-Server nutzen. > >Ich finde jedoch keine Option, dem Postfix beizubringen, einen anderen >DNS-Server zu nutzen, als den in der /etc/resolv.conf. > >Gibt es da einen Trick? > >Gruß >Carsten From wn at neessen.net Tue May 10 11:30:14 2016 From: wn at neessen.net (Winfried Neessen) Date: Tue, 10 May 2016 11:30:14 +0200 Subject: =?UTF-8?Q?Re=3A_Speziellen_DNS-Server_f=C3=BCr_Postfix_definiere?= =?UTF-8?Q?n?= In-Reply-To: <5731A6D3.4050104@gmail.com> References: <5731A6D3.4050104@gmail.com> Message-ID: <65d906b08547161afc18d799b16009e8@neessen.net> Hi Carsten, Am 2016-05-10 11:16, schrieb Carsten: > Ich finde jedoch keine Option, dem Postfix beizubringen, einen anderen > DNS-Server zu nutzen, > als den in der /etc/resolv.conf. > Gibt es da einen Trick? > Soweit ich weiss, gibt es ausser smtp_dns_resolver_options, smtp_host_lookup und smtp_dns_support_level keine Postfix Direktiven, die die DNS Aufloesung irgendwie beinflussen. Einen dedizierten DNS kannst Du darueber aber auch nicht angeben. Ein Workaround waere es, den Postfix chrooted laufen zu lassen (kannst Du ueber die master.cf steuern). Da chroot wird i. d. R. in /var/spool/postfix angelegt und setzt dort auch eine dedizierte /etc/resolv.conf voraus. Du koenntest Dir das zu Nutze machen und die resolv.conf im chroot so anpassen, dass sie einen anderen Server fuer die Namensaufloesung nutzt. Sicher nicht die sauberste Loesung aber duerfte funktionieren. Winni From bjoern.meier at gmail.com Tue May 10 11:39:09 2016 From: bjoern.meier at gmail.com (Bjoern Meier) Date: Tue, 10 May 2016 09:39:09 +0000 Subject: =?UTF-8?Q?Re=3A_Speziellen_DNS=2DServer_f=C3=BCr_Postfix_definieren?= In-Reply-To: <65d906b08547161afc18d799b16009e8@neessen.net> References: <5731A6D3.4050104@gmail.com> <65d906b08547161afc18d799b16009e8@neessen.net> Message-ID: hi, Winfried Neessen schrieb am Di., 10. Mai 2016 um 11:30 Uhr: > Soweit ich weiss, gibt es ausser smtp_dns_resolver_options, > smtp_host_lookup und smtp_dns_support_level > keine Postfix Direktiven, die die DNS Aufloesung irgendwie beinflussen. > Einen dedizierten DNS kannst > Du darueber aber auch nicht angeben. Ein Workaround waere es, den > Postfix chrooted laufen zu lassen > (kannst Du ueber die master.cf steuern). Da chroot wird i. d. R. in > /var/spool/postfix angelegt und > setzt dort auch eine dedizierte /etc/resolv.conf voraus. Du koenntest > Dir das zu Nutze machen und die > resolv.conf im chroot so anpassen, dass sie einen anderen Server fuer > die Namensaufloesung nutzt. > > Sicher nicht die sauberste Loesung aber duerfte funktionieren. > hat man dann nicht die Logs voll von Warnungen, dass das File vom "Original" abweicht? Gruß, Björn -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From tech at kdmails.de Tue May 10 11:44:39 2016 From: tech at kdmails.de (Daniel Gompf) Date: Tue, 10 May 2016 11:44:39 +0200 Subject: =?UTF-8?Q?Re:_Speziellen_DNS-Server_f=c3=bcr_Postfix_definieren?= In-Reply-To: <5731A6D3.4050104@gmail.com> References: <5731A6D3.4050104@gmail.com> Message-ID: <5731AD87.20303@kdmails.de> Am 10.05.2016 um 11:16 schrieb Carsten: > Hallo zusammen Hallo Carsten, vielleicht kannst du das Systemseitig lösen, lass den Postfix mit einer eigenen IP-Adresse arbeiten und am DNS-Server erstellst du dann Views. Daniel From tech at kdmails.de Tue May 10 11:58:59 2016 From: tech at kdmails.de (Daniel Gompf) Date: Tue, 10 May 2016 11:58:59 +0200 Subject: =?UTF-8?Q?Re:_Speziellen_DNS-Server_f=c3=bcr_Postfix_definieren?= In-Reply-To: <5731AD87.20303@kdmails.de> References: <5731A6D3.4050104@gmail.com> <5731AD87.20303@kdmails.de> Message-ID: <5731B0E3.5010302@kdmails.de> Am 10.05.2016 um 11:44 schrieb Daniel Gompf: > > > Am 10.05.2016 um 11:16 schrieb Carsten: >> Hallo zusammen > > Hallo Carsten, > > vielleicht kannst du das Systemseitig lösen, lass den Postfix mit einer > eigenen IP-Adresse arbeiten und am DNS-Server erstellst du dann Views. > > Daniel > Das hatte ich vergessen. Wenn du im chroot läufst, sollte es möglich den Daemons eine angepasste resolv.conf zu geben. From postfixer99 at gmail.com Tue May 10 15:42:37 2016 From: postfixer99 at gmail.com (Carsten) Date: Tue, 10 May 2016 15:42:37 +0200 Subject: =?UTF-8?Q?Re:_Speziellen_DNS-Server_f=c3=bcr_Postfix_definieren?= In-Reply-To: <65d906b08547161afc18d799b16009e8@neessen.net> References: <5731A6D3.4050104@gmail.com> <65d906b08547161afc18d799b16009e8@neessen.net> Message-ID: <5731E54D.2090903@gmail.com> Hallo zusammen, vielen Dank für die zahlreichen Vorschläge. Ich habe es mit der chroot-Lösung gemacht, nachdem ich dem SLES 11 erstmal chroot beigebracht habe. Scheint alles zu funktionieren. Die resolv.conf im chroot-Jail hat das immutable-bit bekommen, damit sie nicht vom SLES Update-Skript überschrieben wird. Besten Dank! Carsten From soeren.berger at tik.uni-stuttgart.de Wed May 11 11:40:12 2016 From: soeren.berger at tik.uni-stuttgart.de (=?utf-8?Q?Berger=2C_S=C3=B6ren?=) Date: Wed, 11 May 2016 11:40:12 +0200 Subject: Mailrelayarchitektur mit seperatem Submissionserver Message-ID: Hallo zusammen, ich baue gerade an einem neuen Mailrelaysetup und hätte eine Architekturfrage für meinen Submissionserver. Ich habe inzwischen verschiedene Ansätze (siehe unten) ausprobiert und bin mir nicht sicher welchen ich implementiere bzw. weiter verfolgen soll. Nehmen wir mal folgende Konfiguration an: mx1.example.de 192.168.10.1 mx2.example.de 192.168.10.2 mx3.example.de 192.168.10.3 mailrelay.example.de 192.168.10.1 192.168.10.2 192.168.10.3 smtp.example.de 192.168.10.1 192.168.10.2 192.168.10.3 Die 3 Mailrelays sind für die Spam- und Virenfilterung, Zustellung der Mails in den Mailcluster und Versand ins Internet. smtp.example.de zeigt auf die gleichen Mailrelays. Auf ihnen ist auf Submission konfiguriert. Aus folgenden Gründen würde ich gerne den Submission Server davon trennen: * Mailclients kommen eventuell mit dem DNS Round Robin nicht klar. Das heißt, dass ich die MX nicht einfach neu booten kann. * Eine Trennung der Dienste ist eine klarer strukturierte Architektur * Die Konfiguration wird zwar auf mehr Hosts verteilt, aber dadurch übersichtlicher. Ich habe bis jetzt folgende Ansätze verfolgt: 1.) Getrennter Submission Server Die gesamte Logik der Benutzerautentifizierung liegt dann im Submission Server. Die MX sind nur noch für das Relaying zuständig. Ich habe einfach ein weiteres Mailrelay genommen und auf den alten Mailrelays Submission deaktiviert habe. + Konfiguration getrennt +Komplettes Setup außer Submission Server kann gebootet werden. - Doppelter Datenbestand und Resourcenverbrauch für Spamassassin/Amavis, da auf dem Submissionserver auch ausgehende Mails geprüft werden sollen. Ich würde die Spam gern im SMTP Dialog ablehnen und ungern einen Bounce erzeugen. - Relaykonfiguration wie virtual_mailbox_maps muss geclont werden um Mails im SMTP Dialog abzulehnen, falls sie nicht in den Mailcluster zugestellt werden können. Sonst wird auch hier ein Bounce erzeugt. 2.) Getrennter Submission Server mit Proxy Filter zu den MX Ich habe das so konfiguriert, dass meine master.cf ungefähr so aussieht: submission inet n       -       n       -       -       smtpd   -o smtpd_enforce_tls=yes   -o smtpd_sasl_auth_enable=yes   -o smtpd_client_restrictions=permit_sasl_authenticated,reject   -o smtpd_tls_cert_file=/etc/ssl/certs/smtp.example.de.crt   -o smtpd_tls_key_file=/etc/ssl/private/smtp.example.de.key   -o smtpd_tls_protocols=!SSLv2,!SSLv3   -o smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3   -o smtpd_proxy_filter=mailrelay.example.de:25                        <----- Das ist das wichtige   -o smtpd_proxy_options=speed_adjust   -o syslog_name=postfix/submission + Konfiguration getrennt +Komplettes Setup ausser Submission Server kann gebootet werden. +Kein Amavis (!) auf dem Submission Server +Falls die Mail nicht zugestellt werden kann oder Spam/Viren enthält, kann sie im SMTP Dialog angelehnt werden. + Schlanke Konfiguration Ich habe für diese Idee im Netz absolut nichts gefunden. Ist das vielleicht eine dumme Idee? Wenn ja warum? Für mich sieht sie auf den ersten Blick recht elegant aus. :-) 3.) Konfiguration mit HA Proxy (HA Proxy, nginx?) smtp.example.de auf einen einzelnen Host, der als HA-Proxy für die 3 MX konfiguriert ist. + MX können transparent gebootet werden +kein zusätzlicher Amavis +Falls die Mail nicht zugestellt werden kann oder Spam/Viren enthält, kann sie im SMTP Dialog angelehnt werden, da der Server ja nur ein Proxy ist. - Zusätzliche (aber schlanke) Komponente -+ Konfiguration von Submission und Relay ist auf einem Host Hat jemand von euch Erfahrungen mit einem solchen Setup oder eine Meinung zu meinen 3 Ansätzen? Ich persönlich tendiere zu Version 2. Eine komplett neue/andere Idee ist natürlich auch gerne gesehen. Viele Grüße Sören From tech at kdmails.de Wed May 11 12:15:06 2016 From: tech at kdmails.de (Daniel Gompf) Date: Wed, 11 May 2016 12:15:06 +0200 Subject: Mailrelayarchitektur mit seperatem Submissionserver In-Reply-To: References: Message-ID: <5733062A.50001@kdmails.de> Hallo Sören Am 11.05.2016 um 11:40 schrieb Berger, Sören: > Hallo zusammen, > ich baue gerade an einem neuen Mailrelaysetup und hätte eine Architekturfrage für meinen Submissionserver. Ich habe inzwischen verschiedene Ansätze (siehe unten) ausprobiert und bin mir nicht sicher welchen ich implementiere bzw. weiter verfolgen soll. > > Nehmen wir mal folgende Konfiguration an: > > mx1.example.de 192.168.10.1 > mx2.example.de 192.168.10.2 > mx3.example.de 192.168.10.3 > > mailrelay.example.de 192.168.10.1 192.168.10.2 192.168.10.3 > smtp.example.de 192.168.10.1 192.168.10.2 192.168.10.3 > > Die 3 Mailrelays sind für die Spam- und Virenfilterung, Zustellung der Mails in den Mailcluster und Versand ins Internet. smtp.example.de zeigt auf die gleichen Mailrelays. Auf ihnen ist auf Submission konfiguriert. > > Aus folgenden Gründen würde ich gerne den Submission Server davon trennen: > > * Mailclients kommen eventuell mit dem DNS Round Robin nicht klar. Das heißt, dass ich die MX nicht einfach neu booten kann. Da gibt es keine Probleme > * Eine Trennung der Dienste ist eine klarer strukturierte Architektur Du trennst Sie doch durch Submission und SMTP, evtl. gibst du dem Submission eine weitere IP > * Die Konfiguration wird zwar auf mehr Hosts verteilt, aber dadurch übersichtlicher. Nein, du hast doch auf allen die gleiche die gleiche hast > > Ich habe bis jetzt folgende Ansätze verfolgt: von den dreien würde ich den ersten wählen wenn ich keine weitere Wahl hätte. Hier mal mein Vorschlag. Setzt doch deinen Spam-Scanner ab evtl. sogar als eigenen Server (Redundanz nicht vergessen, wenn du schon 3 Mailserver betreibst), lass dann von allen Mailservern die Mails dort scannen (Milter oder Prequeue). Pass die policy-banks an somit kannst du für deine angemeldeten Nutzer oder die Nutzer der Submission-IP andere Prüfungen setzen. Und für die ganzen Regeln (Weiterleitungen, Umschreibungen, Transport, Nutzer,...) legst du dir eine zentrale Datenbank (SQL, LDAP) an. Hier kann man auch über lokale Replikate nachdenken, Postfix will ja nur lesen. Daniel From ronny at seffner.de Thu May 12 15:15:37 2016 From: ronny at seffner.de (Ronny Seffner) Date: Thu, 12 May 2016 15:15:37 +0200 Subject: Probleme mit der * address verification Message-ID: <000101d1ac50$6138ab40$23aa01c0$@seffner.de> Hallo Liste, ich zitiere mal das Manual (http://www.postfix.org/ADDRESS_VERIFICATION_README.html): "By default, Postfix probe messages have a sender address "double-bounce@$myorigin" (with Postfix versions before 2.5, the default is "postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does not reject mail for this address." Betonung auf "does not reject". Und dann habe ich das hier in meinem Log: "May 11 17:00:16 ns1 postfix/smtpd[9056]: NOQUEUE: reject: RCPT from ns2.seffner-schlesier.de[144.76.78.17]: 550 5.1.0 : Sender address rejected: User unknown in virtual mailbox table; from= to= proto=ESMTP helo=" Das tritt u.a. immer ein, wenn eine Mail für bei mir gehostete Domains auf dem nichtprimären MXer eingeliefert wird und dieser dann eben Sender und Empfänger validieren mag. Das führt dann dazu, dass Kunden sporadisch nicht erreichbar scheinen und deren Kommunikationspartner NDAs bekommen. Verstehe ich das Manual falsch und muss mir die double-bounce Adresse doch anlegen oder kann ich in der Konfiguration was verbogen haben? Mit freundlichen Grüßen / Kind regards      Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny at seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8 From klaus at tachtler.net Fri May 13 05:34:34 2016 From: klaus at tachtler.net (Klaus Tachtler) Date: Fri, 13 May 2016 05:34:34 +0200 Subject: Probleme mit der * address verification In-Reply-To: <000101d1ac50$6138ab40$23aa01c0$@seffner.de> Message-ID: <20160513053434.Horde.PgxD2Up0lKms6gXols59nDQ@buero.tachtler.net> Hallo Ronny, > Hallo Liste, > > ich zitiere mal das Manual > (http://www.postfix.org/ADDRESS_VERIFICATION_README.html): > > "By default, Postfix probe messages have a sender address > "double-bounce@$myorigin" (with Postfix versions before 2.5, the default is > "postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does > not reject mail for this address." > > Betonung auf "does not reject". > > Und dann habe ich das hier in meinem Log: > > "May 11 17:00:16 ns1 postfix/smtpd[9056]: NOQUEUE: reject: RCPT from > ns2.seffner-schlesier.de[144.76.78.17]: 550 5.1.0 > : Sender address rejected: User unknown > in virtual mailbox table; from= > to= proto=ESMTP > helo=" Wie sieht denn Deine postconf -n bzw. postconf -nf aus? > Das tritt u.a. immer ein, wenn eine Mail für bei mir gehostete Domains auf > dem nichtprimären MXer eingeliefert wird und dieser dann eben Sender und > Empfänger validieren mag. Das führt dann dazu, dass Kunden sporadisch nicht > erreichbar scheinen und deren Kommunikationspartner NDAs bekommen. Ist ein "nicht primärer MXer" ein Backup-MX und als solcher definiert, oder nur mit einer anderen Gewichtung versehen 10 mx1.doamin.tld 20 mx2.domain.tld usw.? > Verstehe ich das Manual falsch und muss mir die double-bounce Adresse doch > anlegen oder kann ich in der Konfiguration was verbogen haben? Ich bin auch für einen anderen MXer der "Backup-MX" und nehme für den "primären MX" auch double-bounce an, OHNE dafür ein Postfach angelegt zu haben. > > Mit freundlichen Grüßen / Kind regards >      Ronny Seffner > -- > Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen > www.seffner.de | ronny at seffner.de | +49 35245 72950 > 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8 Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From ronny at seffner.de Fri May 13 12:06:37 2016 From: ronny at seffner.de (Ronny Seffner) Date: Fri, 13 May 2016 12:06:37 +0200 Subject: AW: Probleme mit der * address verification In-Reply-To: <20160513053434.Horde.PgxD2Up0lKms6gXols59nDQ@buero.tachtler.net> References: <000101d1ac50$6138ab40$23aa01c0$@seffner.de> <20160513053434.Horde.PgxD2Up0lKms6gXols59nDQ@buero.tachtler.net> Message-ID: <006201d1acff$243fe460$6cbfad20$@seffner.de> Hallo Klaus, Hallo Liste, >Wie sieht denn Deine postconf -n bzw. postconf -nf aus? > ns1:~# postconf -nf alias_maps = $alias_database allow_min_user = yes append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes config_directory = /etc/postfix content_filter = lmtp-amavis:[127.0.0.1]:10024 default_process_limit = 75 disable_vrfy_command = yes dovecot_destination_concurrency_limit = 1 dovecot_destination_recipient_limit = 1 inet_interfaces = 78.46.92.37 127.0.0.1 [::1] [2a01:4f8:120:6442::2] mail_name = postfix on linux mailbox_command = /usr/lib/dovecot/deliver mailbox_size_limit = 4294967296 message_size_limit = 209715200 mydestination = $myhostname, localhost, localhost.$mydomain mydomain = seffner-schlesier.de myhostname = ns1.seffner-schlesier.de mynetworks = 127.0.0.0/8 78.46.92.37/32 [::1]/128 [fe80::]/64 myorigin = $mydomain non_smtpd_milters = inet:localhost:8891 policy-spf_time_limit = 3600s policy_greylist = check_policy_service inet:127.0.0.1:10023 proxy_read_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf, proxy:mysql:/etc/postfix/mysql-virtual_alias_maps.cf, proxy:mysql:/etc/postfix/mysql-virtual_policy_greylist.cf, proxy:unix:passwd.byname queue_minfree = 1024000000 recipient_bcc_maps = hash:/etc/postfix/recipient-bcc recipient_canonical_maps = hash:/etc/postfix/recipient_canonical recipient_delimiter = + relay_domains = hash:/etc/postfix/relay_domains sender_bcc_maps = hash:/etc/postfix/sender-bcc sender_canonical_maps = hash:/etc/postfix/sender_canonical smtp_bind_address = 78.46.92.37 smtp_bind_address6 = 2a01:4f8:120:6442::2 smtp_tls_CAfile = /etc/postfix/ssl/ca-bundle.pem smtp_tls_exclude_ciphers = aNULL smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_policy_maps = hash:/etc/postfix/tls_policy smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = may smtp_use_tls = yes smtpd_client_restrictions = permit_mynetworks sleep 2 reject_unauth_pipelining smtpd_data_restrictions = reject_multi_recipient_bounce smtpd_delay_reject = no smtpd_helo_required = yes smtpd_milters = inet:localhost:8891 smtpd_recipient_limit = 100 smtpd_recipient_restrictions = reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks check_sender_access hash:/etc/postfix/pre_sasl_senders permit_sasl_authenticated check_recipient_access hash:/etc/postfix/roleaccount_exceptions check_helo_access pcre:/etc/postfix/helo_checks reject_non_fqdn_hostname reject_invalid_hostname check_sender_mx_access cidr:/etc/postfix/bogus_mx check_sender_access hash:/etc/postfix/senders reject_unlisted_sender check_client_access cidr:/etc/postfix/policyd-weight check_policy_service inet:127.0.0.1:60001 check_client_access cidr:/etc/postfix/backup_mx check_recipient_access proxy:mysql:/etc/postfix/mysql-virtual_policy_greylist.cf check_recipient_access hash:/etc/postfix/swag-recipients reject_unauth_destination reject_unverified_recipient check_policy_service unix:private/policy-spf smtpd_relay_restrictions = reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks check_sender_access hash:/etc/postfix/pre_sasl_senders permit_sasl_authenticated check_recipient_access hash:/etc/postfix/roleaccount_exceptions check_helo_access pcre:/etc/postfix/helo_checks reject_non_fqdn_hostname reject_invalid_hostname check_sender_mx_access cidr:/etc/postfix/bogus_mx check_sender_access hash:/etc/postfix/senders reject_unlisted_sender check_client_access cidr:/etc/postfix/policyd-weight check_policy_service inet:127.0.0.1:60001 check_client_access cidr:/etc/postfix/backup_mx check_recipient_access mysql:/etc/postfix/mysql-virtual_policy_greylist.cf check_recipient_access hash:/etc/postfix/swag-recipients reject_unauth_destination reject_unverified_recipient check_policy_service unix:private/policy-spf smtpd_restriction_classes = policy_greylist smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sender_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain smtpd_tls_CAfile = /etc/postfix/ssl/ca-bundle.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/ssl/wildcard_seffner-schlesier_de.2014_2.crt smtpd_tls_ciphers = high smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dh_1024.pem smtpd_tls_eecdh_grade = strong smtpd_tls_exclude_ciphers = aNULL smtpd_tls_key_file = /etc/postfix/ssl/wildcard_seffner-schlesier_de.2014_2.key smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_use_tls = yes spamassassin_destination_recipient_limit = 1 strict_rfc821_envelopes = yes tls_preempt_cipherlist = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unverified_recipient_reject_code = 550 virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_alias_maps.cf virtual_gid_maps = static:2000 virtual_mailbox_base = / virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf virtual_mailbox_limit = 4294967296 virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf virtual_transport = dovecot virtual_uid_maps = static:2000 >Ist ein "nicht primärer MXer" ein Backup-MX und als solcher definiert, >oder nur mit einer anderen Gewichtung versehen 10 mx1.doamin.tld 20 >mx2.domain.tld usw.? > Ja, ich rede hier von dem was ich unter Backup-MX verstehe. Was macht einen Mailserver denn zum Backup-MX? - es gibt im DNS einen MX mit größerer "Gewichtung" - auf dem "Backup-MX" sind die betreffenden Domains in relay_domains gelistet >Ich bin auch für einen anderen MXer der "Backup-MX" und nehme für den >"primären MX" auch double-bounce an, OHNE dafür ein Postfach angelegt >zu haben. > Ja, genau das würde ich laut Manual eben auch erwarten. Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny at seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8 From ronny at seffner.de Fri May 13 12:56:56 2016 From: ronny at seffner.de (Ronny Seffner) Date: Fri, 13 May 2016 12:56:56 +0200 Subject: AW: Probleme mit der * address verification In-Reply-To: <006201d1acff$243fe460$6cbfad20$@seffner.de> References: <000101d1ac50$6138ab40$23aa01c0$@seffner.de> <20160513053434.Horde.PgxD2Up0lKms6gXols59nDQ@buero.tachtler.net> <006201d1acff$243fe460$6cbfad20$@seffner.de> Message-ID: <007601d1ad06$2c40fa80$84c2ef80$@seffner.de> Vermutlich habe ich eine Spur. ns1.seffner-schlesier.de ist der MX, ns2.seffner-schlesier.de der Backup-MX. Der ns2 macht die addess verification nun mit double-bounce at seffner-schlesier.de gegen den ns1, der für diese Domain aber zuständig ist, vielleicht sucht er daher ein passendes Konto. Wenn ich den ns2 die address verification mit double-bounce at example.com durchführen lassen, meckert ns1 nicht und versucht auch seinerseits nicht bei example.com zu verifizieren. Muss nun der ns2 für die Verifizierung "einfach" eine Adresse einer Domain nehmen, für die ns1 NICHT zuständig ist? Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny at seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8 From klaus at tachtler.net Fri May 13 13:18:18 2016 From: klaus at tachtler.net (Klaus Tachtler) Date: Fri, 13 May 2016 13:18:18 +0200 Subject: AW: Probleme mit der * address verification In-Reply-To: <006201d1acff$243fe460$6cbfad20$@seffner.de> References: <000101d1ac50$6138ab40$23aa01c0$@seffner.de> <20160513053434.Horde.PgxD2Up0lKms6gXols59nDQ@buero.tachtler.net> <006201d1acff$243fe460$6cbfad20$@seffner.de> Message-ID: <20160513131818.Horde.Sj7G9w6h1xoxsMa6AQHwzqB@buero.tachtler.net> Hallo Ronny, was mir in Deiner Konfiguration fehlt ist: Das Postfix Buch - Seite 208-214. permit_mx_backup_networks = ... bzw. http://www.postfix.org/postconf.5.html#permit_mx_backup_networks Nur so mal ganz schnell gesehen... Auch in Das Postfix Buch - Seite 185-214. smtpd_recipient_restrictions = ... taucht an geeigneter Stelle/Reihenfolge ein permit_mx_backup, bei mir auf... Grüße Klaus. > Hallo Klaus, Hallo Liste, > >> Wie sieht denn Deine postconf -n bzw. postconf -nf aus? >> > ns1:~# postconf -nf > alias_maps = $alias_database > allow_min_user = yes > append_dot_mydomain = no > biff = no > broken_sasl_auth_clients = yes > config_directory = /etc/postfix > content_filter = lmtp-amavis:[127.0.0.1]:10024 > default_process_limit = 75 > disable_vrfy_command = yes > dovecot_destination_concurrency_limit = 1 > dovecot_destination_recipient_limit = 1 > inet_interfaces = 78.46.92.37 127.0.0.1 [::1] [2a01:4f8:120:6442::2] > mail_name = postfix on linux > mailbox_command = /usr/lib/dovecot/deliver > mailbox_size_limit = 4294967296 > message_size_limit = 209715200 > mydestination = $myhostname, localhost, localhost.$mydomain > mydomain = seffner-schlesier.de > myhostname = ns1.seffner-schlesier.de > mynetworks = 127.0.0.0/8 78.46.92.37/32 [::1]/128 [fe80::]/64 > myorigin = $mydomain > non_smtpd_milters = inet:localhost:8891 > policy-spf_time_limit = 3600s > policy_greylist = check_policy_service inet:127.0.0.1:10023 > proxy_read_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf, > proxy:mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf, > proxy:mysql:/etc/postfix/mysql-virtual_alias_maps.cf, > proxy:mysql:/etc/postfix/mysql-virtual_policy_greylist.cf, > proxy:unix:passwd.byname > queue_minfree = 1024000000 > recipient_bcc_maps = hash:/etc/postfix/recipient-bcc > recipient_canonical_maps = hash:/etc/postfix/recipient_canonical > recipient_delimiter = + > relay_domains = hash:/etc/postfix/relay_domains > sender_bcc_maps = hash:/etc/postfix/sender-bcc > sender_canonical_maps = hash:/etc/postfix/sender_canonical > smtp_bind_address = 78.46.92.37 > smtp_bind_address6 = 2a01:4f8:120:6442::2 > smtp_tls_CAfile = /etc/postfix/ssl/ca-bundle.pem > smtp_tls_exclude_ciphers = aNULL > smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy > smtp_tls_protocols = !SSLv2, !SSLv3 > smtp_tls_security_level = may > smtp_use_tls = yes > smtpd_client_restrictions = permit_mynetworks sleep 2 > reject_unauth_pipelining > smtpd_data_restrictions = reject_multi_recipient_bounce > smtpd_delay_reject = no > smtpd_helo_required = yes > smtpd_milters = inet:localhost:8891 > smtpd_recipient_limit = 100 > smtpd_recipient_restrictions = reject_non_fqdn_recipient > reject_unknown_recipient_domain permit_mynetworks check_sender_access > hash:/etc/postfix/pre_sasl_senders permit_sasl_authenticated > check_recipient_access hash:/etc/postfix/roleaccount_exceptions > check_helo_access pcre:/etc/postfix/helo_checks reject_non_fqdn_hostname > reject_invalid_hostname check_sender_mx_access cidr:/etc/postfix/bogus_mx > check_sender_access hash:/etc/postfix/senders reject_unlisted_sender > check_client_access cidr:/etc/postfix/policyd-weight check_policy_service > inet:127.0.0.1:60001 check_client_access cidr:/etc/postfix/backup_mx > check_recipient_access > proxy:mysql:/etc/postfix/mysql-virtual_policy_greylist.cf > check_recipient_access hash:/etc/postfix/swag-recipients > reject_unauth_destination reject_unverified_recipient > check_policy_service > unix:private/policy-spf > smtpd_relay_restrictions = reject_non_fqdn_recipient > reject_unknown_recipient_domain permit_mynetworks check_sender_access > hash:/etc/postfix/pre_sasl_senders permit_sasl_authenticated > check_recipient_access hash:/etc/postfix/roleaccount_exceptions > check_helo_access pcre:/etc/postfix/helo_checks reject_non_fqdn_hostname > reject_invalid_hostname check_sender_mx_access cidr:/etc/postfix/bogus_mx > check_sender_access hash:/etc/postfix/senders reject_unlisted_sender > check_client_access cidr:/etc/postfix/policyd-weight check_policy_service > inet:127.0.0.1:60001 check_client_access cidr:/etc/postfix/backup_mx > check_recipient_access > mysql:/etc/postfix/mysql-virtual_policy_greylist.cf > check_recipient_access hash:/etc/postfix/swag-recipients > reject_unauth_destination reject_unverified_recipient > check_policy_service > unix:private/policy-spf > smtpd_restriction_classes = policy_greylist > smtpd_sasl_auth_enable = yes > smtpd_sasl_path = private/auth > smtpd_sasl_security_options = noanonymous > smtpd_sasl_type = dovecot > smtpd_sender_restrictions = reject_non_fqdn_sender > reject_unknown_sender_domain > smtpd_tls_CAfile = /etc/postfix/ssl/ca-bundle.pem > smtpd_tls_auth_only = yes > smtpd_tls_cert_file = > /etc/postfix/ssl/wildcard_seffner-schlesier_de.2014_2.crt > smtpd_tls_ciphers = high > smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dh_1024.pem > smtpd_tls_eecdh_grade = strong > smtpd_tls_exclude_ciphers = aNULL > smtpd_tls_key_file = > /etc/postfix/ssl/wildcard_seffner-schlesier_de.2014_2.key > smtpd_tls_mandatory_ciphers = high > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 > smtpd_tls_protocols = !SSLv2, !SSLv3 > smtpd_tls_received_header = yes > smtpd_tls_security_level = may > smtpd_use_tls = yes > spamassassin_destination_recipient_limit = 1 > strict_rfc821_envelopes = yes > tls_preempt_cipherlist = yes > tls_random_source = dev:/dev/urandom > transport_maps = hash:/etc/postfix/transport > unknown_address_reject_code = 554 > unknown_client_reject_code = 554 > unknown_hostname_reject_code = 554 > unverified_recipient_reject_code = 550 > virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_alias_maps.cf > virtual_gid_maps = static:2000 > virtual_mailbox_base = / > virtual_mailbox_domains = > proxy:mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf > virtual_mailbox_limit = 4294967296 > virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf > virtual_transport = dovecot > virtual_uid_maps = static:2000 > >> Ist ein "nicht primärer MXer" ein Backup-MX und als solcher definiert, >> oder nur mit einer anderen Gewichtung versehen 10 mx1.doamin.tld 20 >> mx2.domain.tld usw.? >> > Ja, ich rede hier von dem was ich unter Backup-MX verstehe. Was > macht einen Mailserver denn zum Backup-MX? > - es gibt im DNS einen MX mit größerer "Gewichtung" > - auf dem "Backup-MX" sind die betreffenden Domains in relay_domains gelistet > >> Ich bin auch für einen anderen MXer der "Backup-MX" und nehme für den >> "primären MX" auch double-bounce an, OHNE dafür ein Postfach angelegt >> zu haben. >> > Ja, genau das würde ich laut Manual eben auch erwarten. > > > Mit freundlichen Grüßen / Kind regards > Ronny Seffner > -- > Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen > www.seffner.de | ronny at seffner.de | +49 35245 72950 > 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8 ----- Ende der Nachricht von Ronny Seffner ----- -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From ffiene at veka.com Mon May 16 19:39:30 2016 From: ffiene at veka.com (Frank Fiene) Date: Mon, 16 May 2016 19:39:30 +0200 Subject: SpamAssassin Rules Message-ID: <5836BC43-7211-49C7-A95E-44306F58F08D@veka.com> Moin! Ich habe im Moment Problem mit polnischen Kunden, deren Mails als SPAM abgewiesen werden. Zumeist wegen FSL_HELO_BARE_IP_2=1.498, FSL_HELO_HOME=3.722 und RCVD_NUMERIC_HELO=1.164, der Rest kommt dann schnell mal zusammen. Was ich nicht verstehe: FSL_HELO_BARE_IP_2 soll ja die letzten beiden HELO Commands mit IP-Adressen erkennen. Laut RFC muss ja [] um die IP-Adresse stehen. Tut es aber. RCVD_NUMERIC_HELO sollte dasselbe machen, warum gibt es dann beide Regeln? Was macht FSL_HELO_HOME? Hier mal der Log-Eintrag: May 16 15:15:17 smtp2 amavis[1437]: (01437-19) Blocked SPAM {RejectedInbound}, [212.85.119.9]:60778 [78.10.255.129] -> ,, Message-ID: , mail_id: Kr-19sNdfLDo, Hits: 7.185, size: 3245, Subject: "Fw: zam\303\203\302\263wienie drewnoplast sc (raw: =?iso-8859-2?Q?Fw:_zam=F3wienie_drewnoplast_sc?=)", From: "DrewnoplastSC"_, X-Mailer: Microsoft_Outlook_Express_6.00.2900.5512, helo=cloudserver005851.home.net.pl, Tests: [BAYES_50=0.8,FSL_HELO_BARE_IP_2=1.498,FSL_HELO_HOME=3.722,HTML_MESSAGE=0.001,RCVD_NUMERIC_HELO=1.164], autolearn=no autolearn_force=no, autolearnscore=6.086, 1887 ms Ich vermute einen Fehler in den SA-Regeln. 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 ms at ddnetservice.net Mon May 16 21:10:18 2016 From: ms at ddnetservice.net (Michael Seevogel) Date: Mon, 16 May 2016 21:10:18 +0200 Subject: SpamAssassin Rules In-Reply-To: <5836BC43-7211-49C7-A95E-44306F58F08D@veka.com> References: <5836BC43-7211-49C7-A95E-44306F58F08D@veka.com> Message-ID: <3edb7dec-1670-6178-01c6-da3fb3cb47c9@ddnetservice.net> Am 16.05.2016 um 19:39 schrieb Frank Fiene: > Moin! > > Ich habe im Moment Problem mit polnischen Kunden, deren Mails als SPAM abgewiesen werden. > Zumeist wegen FSL_HELO_BARE_IP_2=1.498, FSL_HELO_HOME=3.722 und RCVD_NUMERIC_HELO=1.164, der Rest kommt dann schnell mal zusammen. > > Was ich nicht verstehe: FSL_HELO_BARE_IP_2 soll ja die letzten beiden HELO Commands mit IP-Adressen erkennen. Laut RFC muss ja [] um die IP-Adresse stehen. > Tut es aber. RCVD_NUMERIC_HELO sollte dasselbe machen, warum gibt es dann beide Regeln? > > Was macht FSL_HELO_HOME? Gemäß der Datei updates_spamassassin_org/72_active.cf macht FSL_HELO_HOME folgendes: header FSL_HELO_HOME X-Spam-Relays-External =~ /\bhelo=\S+\.home\b/i Wenn die Wortkette .home im Helo vorkommt dann wird gematcht. Dass allerdings FSL_HELO_BARE_IP_2 und RCVD_NUMERIC_HELO anschlagen, finde ich allerdings auch etwas merkwürdig, denn der HELO scheint ja laut Amavis Log ja nicht numerisch zu sein. Da wäre vielleicht mal ein SMTP-Dialog interessant um zu sehen was da der andere Server überhaupt überträgt. > > Hier mal der Log-Eintrag: > > May 16 15:15:17 smtp2 amavis[1437]: (01437-19) Blocked SPAM {RejectedInbound}, [212.85.119.9]:60778 [78.10.255.129] -> ,, Message-ID: , mail_id: Kr-19sNdfLDo, Hits: 7.185, size: 3245, Subject: "Fw: zam\303\203\302\263wienie drewnoplast sc (raw: =?iso-8859-2?Q?Fw:_zam=F3wienie_drewnoplast_sc?=)", From: "DrewnoplastSC"_, X-Mailer: Microsoft_Outlook_Express_6.00.2900.5512, helo=cloudserver005851.home.net.pl, Tests: [BAYES_50=0.8,FSL_HELO_BARE_IP_2=1.498,FSL_HELO_HOME=3.722,HTML_MESSAGE=0.001,RCVD_NUMERIC_HELO=1.164], autolearn=no autolearn_force=no, autolearnscore=6.086, 1887 ms > > Ich vermute einen Fehler in den SA-Regeln. > > Diese Rule dürfte wohl schon etwas älter sein, da die ICANN die .home TLD ja zur (Vor-)Registrierung freigegeben hat. Ursprünglich dürfte die Rule dafür gedacht gewesen sein um gekaperte "Heim-Clients" - also solche mit .lan oder .home als TLD - zu erkennen und einen entsprechenden Score zu verpassen. Allerdings muss man als Nachtrag dazu sagen, dass die .TLD hier im vorliegenden Fall gar nicht .home ist, sondern diese .net.pl lautet. Die verursachende Spamassassin Rule ist einfach nur - wie Du auch richtig vermutest - fehlerhaft bzw nicht ganz zu Ende gedacht worden. Daher würde ich an Deiner Stelle die Rule einfach mit einem 0er Score über die local.cf neutralisieren, denn wer weiß wann es mal wieder ein offizielles Spamassassin Rule Update geben wird... Mit freundlichen Grüßen Michael Seevogel From ffiene at veka.com Tue May 17 08:19:44 2016 From: ffiene at veka.com (Frank Fiene) Date: Tue, 17 May 2016 08:19:44 +0200 Subject: SpamAssassin Rules In-Reply-To: <3edb7dec-1670-6178-01c6-da3fb3cb47c9@ddnetservice.net> References: <5836BC43-7211-49C7-A95E-44306F58F08D@veka.com> <3edb7dec-1670-6178-01c6-da3fb3cb47c9@ddnetservice.net> Message-ID: <60CAAB7D-6CAC-4AB8-A9BC-4B0E9B38CE5C@veka.com> Hi, danke für die Antwort! > Am 16.05.2016 um 21:10 schrieb Michael Seevogel : > > > > Am 16.05.2016 um 19:39 schrieb Frank Fiene: >> >> Was macht FSL_HELO_HOME? > > Gemäß der Datei updates_spamassassin_org/72_active.cf macht FSL_HELO_HOME folgendes: > > header FSL_HELO_HOME X-Spam-Relays-External =~ /\bhelo=\S+\.home\b/i > Wenn die Wortkette .home im Helo vorkommt dann wird gemacht. Ja, hatte ich auch so gefunden. > > Dass allerdings FSL_HELO_BARE_IP_2 und RCVD_NUMERIC_HELO anschlagen, finde ich allerdings auch etwas merkwürdig, denn der HELO scheint ja laut Amavis Log ja nicht numerisch zu sein. > Da wäre vielleicht mal ein SMTP-Dialog interessant um zu sehen was da der andere Server überhaupt überträgt. Vor allem ist erst seit ein paar Tagen so. > >> >> Hier mal der Log-Eintrag: >> >> May 16 15:15:17 smtp2 amavis[1437]: (01437-19) Blocked SPAM {RejectedInbound}, [212.85.119.9]:60778 [78.10.255.129] -> ,, Message-ID: , mail_id: Kr-19sNdfLDo, Hits: 7.185, size: 3245, Subject: "Fw: zam\303\203\302\263wienie drewnoplast sc (raw: =?iso-8859-2?Q?Fw:_zam=F3wienie_drewnoplast_sc?=)", From: "DrewnoplastSC"_, X-Mailer: Microsoft_Outlook_Express_6.00.2900.5512, helo=cloudserver005851.home.net.pl, Tests: [BAYES_50=0.8,FSL_HELO_BARE_IP_2=1.498,FSL_HELO_HOME=3.722,HTML_MESSAGE=0.001,RCVD_NUMERIC_HELO=1.164], autolearn=no autolearn_force=no, autolearnscore=6.086, 1887 ms >> >> Ich vermute einen Fehler in den SA-Regeln. >> >> > > > Diese Rule dürfte wohl schon etwas älter sein, da die ICANN die .home TLD ja zur (Vor-)Registrierung freigegeben hat. > Ursprünglich dürfte die Rule dafür gedacht gewesen sein um gekaperte "Heim-Clients" - also solche mit .lan oder .home als TLD - zu erkennen und einen entsprechenden Score zu verpassen. > > Allerdings muss man als Nachtrag dazu sagen, dass die .TLD hier im vorliegenden Fall gar nicht .home ist, sondern diese .net.pl lautet. > Die verursachende Spamassassin Rule ist einfach nur - wie Du auch richtig vermutest - fehlerhaft bzw nicht ganz zu Ende gedacht worden. > > Daher würde ich an Deiner Stelle die Rule einfach mit einem 0er Score über die local.cf neutralisieren, denn wer weiß wann es mal wieder ein offizielles Spamassassin Rule Update geben wird? Das habe ich erstmal so gemacht. > > Mit freundlichen Grüßen > Michael Seevogel > 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 Thu May 19 18:34:10 2016 From: ffiene at veka.com (Frank Fiene) Date: Thu, 19 May 2016 18:34:10 +0200 Subject: FcrDNS Message-ID: <7D36D03A-A662-41C1-B339-59960C7A13AA@veka.com> Normalerweise sind Kunden und Lieferanten immer sehr dankbar, wenn man sie auf eine fehlerhafte Konfiguration hinweist. Meistens ein Problem mit FcrDNS, welches wir verlangen. Hier mal ein Reply von einer ?Mail Maintenance Company? aus UK: > Hi Alex, > > I have forwarded your email to our technical department, who have sent it on to our email/web maintenance company , please see below their reply. > The implication is that an over strict mail rule could well be causing the problem and is interpreting the problem as a DNS resolution issue. I don?t know if you want to take this up with your IT department > Veka are correct in what they say but this isn?t an uncommon setup so it?s surprising they get much mail at all if they enforce this rule for everybody. They wouldn?t get email from me for example as we use Office 365 so our email comes from a Microsoft IP address. The same would apply to anyone using a service like Message Labs to virus scan their email. Die haben gar nicht verstanden, dass das gar nichts damit zu tun hat, dass der Server nicht in der Domain des Absenders liegt. > I suspect it was rejected for another reason (an overly strict spam filter probably) and a cursory look at why has resulted in the wrong reason being communicated back. > Interestingly, if we enforced this rule on our server you wouldn?t receive email from Veka as their mail is sent from an ip address that resolves mail.veka.com not veka.com. Similar but technically different. Hier nochmal. > We could in theory change this on our server but then all our client email would resolve back to industrialworkwear.com so in reality it?s not possible. Ignorant. Ich habe auf den Wikipedia-Eintrag zu FcrDNS verwiesen und RFC 1912: "Make sure your PTR and A records match.? Ich denke, die wissen nicht einmal was ein RFC ist. Da hat wohl der Azubi den Mailserver eingerichtet. Oh Mann ... -- 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 Thu May 19 18:51:26 2016 From: daniel at ist-immer-online.de (Daniel) Date: Thu, 19 May 2016 18:51:26 +0200 Subject: AW: FcrDNS In-Reply-To: <7D36D03A-A662-41C1-B339-59960C7A13AA@veka.com> References: <7D36D03A-A662-41C1-B339-59960C7A13AA@veka.com> Message-ID: <000d01d1b1ee$aef5eb60$0ce1c220$@ist-immer-online.de> Was soll man dazu schon sagen? Firmen wie EA oder Blizzard interessieren sich auch nicht für fehlende Hostnamen, PTR, ect. in der Zone. Die sind Beratungsresistent, egal ob man freundlich, sachlich oder sogar etwas beleidigend schreibt. Genauso wie manche Provider es nicht interessiert wenn Kunden spammen, von wegen die haben keinen Einfluss auf die Server die ein Kunde mietet. Ich muss auch schon EA und Blizzard in Ausnahme setzen, dass alles von deren IP akzeptiert wird, weil sonst wegen hostname ect. reject wird. Und dann warnen die Firmen teils noch vor Spam, und verlangen noch von Kunden man soll die in Whitelist im Adressbuch hinzufügen bei den Mailanbietern, schon klar. Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Frank Fiene Gesendet: Donnerstag, 19. Mai 2016 18:34 An: Diskussionen und Support rund um Postfix Betreff: FcrDNS Normalerweise sind Kunden und Lieferanten immer sehr dankbar, wenn man sie auf eine fehlerhafte Konfiguration hinweist. Meistens ein Problem mit FcrDNS, welches wir verlangen. Hier mal ein Reply von einer ?Mail Maintenance Company? aus UK: > Hi Alex, > > I have forwarded your email to our technical department, who have sent it on to our email/web maintenance company , please see below their reply. > The implication is that an over strict mail rule could well be causing the problem and is interpreting the problem as a DNS resolution issue. I don?t know if you want to take this up with your IT department > Veka are correct in what they say but this isn?t an uncommon setup so it?s surprising they get much mail at all if they enforce this rule for everybody. They wouldn?t get email from me for example as we use Office 365 so our email comes from a Microsoft IP address. The same would apply to anyone using a service like Message Labs to virus scan their email. Die haben gar nicht verstanden, dass das gar nichts damit zu tun hat, dass der Server nicht in der Domain des Absenders liegt. > I suspect it was rejected for another reason (an overly strict spam filter probably) and a cursory look at why has resulted in the wrong reason being communicated back. > Interestingly, if we enforced this rule on our server you wouldn?t receive email from Veka as their mail is sent from an ip address that resolves mail.veka.com not veka.com. Similar but technically different. Hier nochmal. > We could in theory change this on our server but then all our client email would resolve back to industrialworkwear.com so in reality it?s not possible. Ignorant. Ich habe auf den Wikipedia-Eintrag zu FcrDNS verwiesen und RFC 1912: "Make sure your PTR and A records match.? Ich denke, die wissen nicht einmal was ein RFC ist. Da hat wohl der Azubi den Mailserver eingerichtet. Oh Mann ... -- 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 p.heinlein at heinlein-support.de Fri May 20 09:43:29 2016 From: p.heinlein at heinlein-support.de (Peer Heinlein) Date: Fri, 20 May 2016 09:43:29 +0200 Subject: =?UTF-8?Q?OT:_Spezis_f=c3=bcr_SOLR/Lucene_hier=3f?= Message-ID: <573EC021.9000601@heinlein-support.de> Ich kämpfe mit einem unzuverlässigen SOLR-Cluster (Lucene) und xxxxx dieses Javazeugsgeraffel. Das ist einfach nicht meine Welt. Gibt's hier einen SOLR-Profi der mir sagen kann, warum der Cluster ständig irgendwelche Shards down nimmt? Lieben Gruß Peer -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-42 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin From p.heinlein at heinlein-support.de Fri May 20 10:40:41 2016 From: p.heinlein at heinlein-support.de (Peer Heinlein) Date: Fri, 20 May 2016 10:40:41 +0200 Subject: =?UTF-8?Q?BSI_ver=c3=b6ffentlicht_Richtlinie_=22Sicherer_Mailtransp?= =?UTF-8?Q?ort=22?= Message-ID: <573ECD89.8040001@heinlein-support.de> Das BSI hat heute die neue Richtlinie TR-03108 veröffentlicht: https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2016/BSI-TR_03108_20052016.html Wir waren Mitglied der Arbeitsgruppe, mein Hintergrundbericht hier: https://www.heinlein-support.de/blog/news/bsi-richtlinie-sicherer-mailtransport-was-ist-davon-zu-halten/ Schönen Gruß Peer -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-42 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin From gjn at gjn.priv.at Tue May 24 20:02:38 2016 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Tue, 24 May 2016 20:02:38 +0200 Subject: Postscreen whitelist "protection.outlook.com" Message-ID: <15099883.kJE44xONHF@techz> Hallo, Ich suche verzweifelt eine Möglichkeit eine EMail Adrresse freizugeben. Anscheinend gibt es mit dem Anbieter dessen Mailserver Probleme ? xxxxx.pretection.outlook.com Es scheint der einzige zu sein jedenfalls habe ich bis jetzt noch nichts anderes herausgefunden ? Der Hintergrund: Die Mail sollte reinkommen und wird temporär abgelehnt. NOQUEUE: "Service currenly unavailabble" kommt aber anscheinend danach mit einer anderen IP usw., dadurch kommen die Mails Stunden später oder gar nicht ? Habt Ihr dafür einen Lösung ? Außer postcreen abschalten ;-). Danke für eine Antwort ? -- mit freundlichen Grüßen / best regards, Günther J. Niederwimmer From werner at aloah-from-hell.de Tue May 24 20:08:50 2016 From: werner at aloah-from-hell.de (Werner Detter) Date: Tue, 24 May 2016 20:08:50 +0200 Subject: Postscreen whitelist "protection.outlook.com" In-Reply-To: <15099883.kJE44xONHF@techz> References: <15099883.kJE44xONHF@techz> Message-ID: <96b7ca20-fd79-3c5e-b3af-c4997be2cace@aloah-from-hell.de> Moin, z.B. postscreen_access_list mit eine Liste der relevanten IP-Netze[1], etwa: postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr VG, Werner [1] "weiss nicht ob die noch aktuell ist" # outlook.com 23.103.160.0/20 permit 23.103.224.0/19 permit 40.96.0.0/16 permit 40.97.0.0/16 permit 40.98.0.0/16 permit 40.99.0.0/16 permit 40.100.0.0/16 permit 40.101.0.0/16 permit 40.102.0.0/16 permit 40.103.0.0/16 permit 40.104.0.0/16 permit 40.105.0.0/16 permit 65.54.62.0/25 permit 65.55.39.128/25 permit 65.55.78.128/25 permit 65.55.94.0/25 permit 65.55.113.64/26 permit 65.55.126.0/25 permit 65.55.174.0/25 permit 65.55.181.128/25 permit 70.37.151.128/25 permit 94.245.117.128/25 permit 111.221.23.128/25 permit 111.221.66.0/25 permit 111.221.69.128/25 permit 111.221.112.0/21 permit 131.253.33.215 permit 132.245.0.0/16 permit 191.234.192.0/19 permit 157.55.9.128/25 permit 157.55.11.0/25 permit 157.55.47.0/24 permit 157.55.49.0/24 permit 157.55.61.0/24 permit 157.55.157.128/25 permit 157.55.224.128/25 permit 157.55.225.0/25 permit 157.56.0.0/16 permit 191.234.6.152 permit 191.234.140.0/22 permit 191.234.224.0/22 permit 204.79.197.215 permit 206.191.224.0/19 permit 207.46.4.128/25 permit 207.46.58.128/25 permit 207.46.198.0/25 permit 207.46.203.128/26 permit 213.199.174.0/25 permit 213.199.177.0/26 permit 2a01:111:f400::/48 permit Am 24/05/16 um 20:02 schrieb Günther J. Niederwimmer: > Hallo, > > Ich suche verzweifelt eine Möglichkeit eine EMail Adrresse freizugeben. > > Anscheinend gibt es mit dem Anbieter dessen Mailserver Probleme ? > > xxxxx.pretection.outlook.com > > Es scheint der einzige zu sein jedenfalls habe ich bis jetzt noch nichts > anderes herausgefunden ? > > Der Hintergrund: > Die Mail sollte reinkommen und wird temporär abgelehnt. > NOQUEUE: > "Service currenly unavailabble" > > kommt aber anscheinend danach mit einer anderen IP usw., > dadurch kommen die Mails Stunden später oder gar nicht ? > > Habt Ihr dafür einen Lösung ? > > Außer postcreen abschalten ;-). > > Danke für eine Antwort ? > From thomas at antony.eu Tue May 24 20:21:38 2016 From: thomas at antony.eu (Thomas Antony) Date: Tue, 24 May 2016 18:21:38 +0000 Subject: AW: Postscreen whitelist "protection.outlook.com" In-Reply-To: <15099883.kJE44xONHF@techz> References: <15099883.kJE44xONHF@techz> Message-ID: <5bfa8df0e1e14b439d5b22f6bdd1f589@comf-srv16.COMFIDENT.local> Hallo, Ich verwende als Lösung postwhite. https://github.com/stevejenkins/postwhite Grüße Thomas -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Günther J. Niederwimmer Gesendet: Dienstag, 24. Mai 2016 20:03 An: postfixbuch-users at listi.jpberlin.de Betreff: Postscreen whitelist "protection.outlook.com" Hallo, Ich suche verzweifelt eine Möglichkeit eine EMail Adrresse freizugeben. Anscheinend gibt es mit dem Anbieter dessen Mailserver Probleme ? xxxxx.pretection.outlook.com Es scheint der einzige zu sein jedenfalls habe ich bis jetzt noch nichts anderes herausgefunden ? Der Hintergrund: Die Mail sollte reinkommen und wird temporär abgelehnt. NOQUEUE: "Service currenly unavailabble" kommt aber anscheinend danach mit einer anderen IP usw., dadurch kommen die Mails Stunden später oder gar nicht ? Habt Ihr dafür einen Lösung ? Außer postcreen abschalten ;-). Danke für eine Antwort ? -- mit freundlichen Grüßen / best regards, Günther J. Niederwimmer From Zahlenmaler at t-online.de Tue May 24 21:09:43 2016 From: Zahlenmaler at t-online.de (Robert) Date: Tue, 24 May 2016 21:09:43 +0200 Subject: Postscreen whitelist "protection.outlook.com" In-Reply-To: <15099883.kJE44xONHF@techz> References: <15099883.kJE44xONHF@techz> Message-ID: <5744A6F7.6080500@t-online.de> Google macht leider auch sonen mumpitz mit wechselnden IP's failen an einer simplen greylist.... , das sind sie die "big player" :-) postscreen_non_smtp_command_ttl = 30d postscreen_greet_ttl = 30d Die zeitparameter wie lange eine IP "gemerkt" werden soll hoch drehen. Ansonsten das whitelisten laut manpage. Am 24.05.2016 um 20:02 schrieb Günther J. Niederwimmer: > Hallo, > > Ich suche verzweifelt eine Möglichkeit eine EMail Adrresse freizugeben. > > Anscheinend gibt es mit dem Anbieter dessen Mailserver Probleme ? > > xxxxx.pretection.outlook.com > > Es scheint der einzige zu sein jedenfalls habe ich bis jetzt noch nichts > anderes herausgefunden ? > > Der Hintergrund: > Die Mail sollte reinkommen und wird temporär abgelehnt. > NOQUEUE: > "Service currenly unavailabble" > > kommt aber anscheinend danach mit einer anderen IP usw., > dadurch kommen die Mails Stunden später oder gar nicht ? > > Habt Ihr dafür einen Lösung ? > > Außer postcreen abschalten ;-). > > Danke für eine Antwort ? > From sd at schnied.net Wed May 25 08:17:11 2016 From: sd at schnied.net (Stefan Dorn) Date: Wed, 25 May 2016 08:17:11 +0200 Subject: Postscreen whitelist "protection.outlook.com" In-Reply-To: <96b7ca20-fd79-3c5e-b3af-c4997be2cace@aloah-from-hell.de> References: <15099883.kJE44xONHF@techz> <96b7ca20-fd79-3c5e-b3af-c4997be2cace@aloah-from-hell.de> Message-ID: <36838b90-fa0b-4d1b-899e-8c9ef91908a7@schnied.net> Am 24.05.16 um 20:08 schrieb Werner Detter: > > [1] "weiss nicht ob die noch aktuell ist" > # outlook.com > 23.103.160.0/20 permit > 23.103.224.0/19 permit > 40.96.0.0/16 permit > [....] usw. Hallo Werner, woher hast Du denn diese Liste? Selbst gesammelt oder irgendwo gefunden? Ich kenne das: https://mail.live.com/mail/ipspace.aspx Vielleicht hat M$ selbst seine Listen nicht im Griff. Ausschliessen würde ich das nicht. So ist das halt mit manueller Pflege - sie funktioniert einfach nicht. Gruß Stefan From gjn at gjn.priv.at Wed May 25 08:26:39 2016 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Wed, 25 May 2016 08:26:39 +0200 Subject: Postscreen whitelist "protection.outlook.com" In-Reply-To: <96b7ca20-fd79-3c5e-b3af-c4997be2cace@aloah-from-hell.de> References: <15099883.kJE44xONHF@techz> <96b7ca20-fd79-3c5e-b3af-c4997be2cace@aloah-from-hell.de> Message-ID: <25690098.uaMZT0AduZ@techz> Hallo, Am Dienstag, 24. Mai 2016, 20:08:50 CEST schrieb Werner Detter: > Moin, > > z.B. postscreen_access_list mit eine Liste der relevanten IP-Netze[1], etwa: > > postscreen_access_list = permit_mynetworks, > cidr:/etc/postfix/postscreen_access.cidr Das hatte ich auch schon im INet gefunden, ist aber nicht gerade "das gelbe vom Ei" wenn man die Liste pflegen muss :-(. Dachte mir zuerst ich spinne wie ich gehört habe, die Leutchen regen sich darüber auf, wie lange so eine Mail dauert ;-). Bis ich dann die Ursache gefunden hatte ?. gibt es da noch mehr solche Fallen ? > VG, Werner > > [1] "weiss nicht ob die noch aktuell ist" > # outlook.com > 23.103.160.0/20 permit > 23.103.224.0/19 permit > 40.96.0.0/16 permit > 40.97.0.0/16 permit > 40.98.0.0/16 permit > 40.99.0.0/16 permit > 40.100.0.0/16 permit > 40.101.0.0/16 permit > 40.102.0.0/16 permit > 40.103.0.0/16 permit > 40.104.0.0/16 permit > 40.105.0.0/16 permit > 65.54.62.0/25 permit > 65.55.39.128/25 permit > 65.55.78.128/25 permit > 65.55.94.0/25 permit > 65.55.113.64/26 permit > 65.55.126.0/25 permit > 65.55.174.0/25 permit > 65.55.181.128/25 permit > 70.37.151.128/25 permit > 94.245.117.128/25 permit > 111.221.23.128/25 permit > 111.221.66.0/25 permit > 111.221.69.128/25 permit > 111.221.112.0/21 permit > 131.253.33.215 permit > 132.245.0.0/16 permit > 191.234.192.0/19 permit > 157.55.9.128/25 permit > 157.55.11.0/25 permit > 157.55.47.0/24 permit > 157.55.49.0/24 permit > 157.55.61.0/24 permit > 157.55.157.128/25 permit > 157.55.224.128/25 permit > 157.55.225.0/25 permit > 157.56.0.0/16 permit > 191.234.6.152 permit > 191.234.140.0/22 permit > 191.234.224.0/22 permit > 204.79.197.215 permit > 206.191.224.0/19 permit > 207.46.4.128/25 permit > 207.46.58.128/25 permit > 207.46.198.0/25 permit > 207.46.203.128/26 permit > 213.199.174.0/25 permit > 213.199.177.0/26 permit > 2a01:111:f400::/48 permit > > Am 24/05/16 um 20:02 schrieb Günther J. Niederwimmer: > > Hallo, > > > > Ich suche verzweifelt eine Möglichkeit eine EMail Adrresse freizugeben. > > > > Anscheinend gibt es mit dem Anbieter dessen Mailserver Probleme ? > > > > xxxxx.pretection.outlook.com > > > > Es scheint der einzige zu sein jedenfalls habe ich bis jetzt noch nichts > > anderes herausgefunden ? > > > > Der Hintergrund: > > Die Mail sollte reinkommen und wird temporär abgelehnt. > > NOQUEUE: > > "Service currenly unavailabble" > > > > kommt aber anscheinend danach mit einer anderen IP usw., > > dadurch kommen die Mails Stunden später oder gar nicht ? > > > > Habt Ihr dafür einen Lösung ? > > > > Außer postcreen abschalten ;-). > > > > Danke für eine Antwort ? -- mit freundlichen Grüßen / best regards, Günther J. Niederwimmer From gjn at gjn.priv.at Wed May 25 08:53:14 2016 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Wed, 25 May 2016 08:53:14 +0200 Subject: Postscreen whitelist "protection.outlook.com" In-Reply-To: <36838b90-fa0b-4d1b-899e-8c9ef91908a7@schnied.net> References: <15099883.kJE44xONHF@techz> <96b7ca20-fd79-3c5e-b3af-c4997be2cace@aloah-from-hell.de> <36838b90-fa0b-4d1b-899e-8c9ef91908a7@schnied.net> Message-ID: <11441866.85AhOau2Wt@techz> Am Mittwoch, 25. Mai 2016, 08:17:11 CEST schrieb Stefan Dorn: > Am 24.05.16 um 20:08 schrieb Werner Detter: > > [1] "weiss nicht ob die noch aktuell ist" > > # outlook.com > > 23.103.160.0/20 permit > > 23.103.224.0/19 permit > > 40.96.0.0/16 permit > > [....] usw. > > Hallo Werner, > > woher hast Du denn diese Liste? Selbst gesammelt oder irgendwo gefunden? > Ich kenne das: https://mail.live.com/mail/ipspace.aspx Ich habe gestern versucht alle IP aus den SPF records zu finden, ist auch nicht gerade sicher wenn sich das die ganze Zeit ändert? Ich habe z.B. 3 spf Records gefunden spf.protection.outlook.com spfa.protection.outlook.com spfb.protection.outlook.com und dann auch noch von anderen Servern die man zum Schluss gar nicht kennt, was dann ? wenn man das alle 5 Minuten machen muss "Prost Mahlzeit" ? > Vielleicht hat M$ selbst seine Listen nicht im Griff. Ausschliessen > würde ich das nicht. So ist das halt mit manueller Pflege - sie > funktioniert einfach nicht. > > Gruß > Stefan -- mit freundlichen Grüßen / best regards, Günther J. Niederwimmer From jra at byte.cx Wed May 25 08:59:36 2016 From: jra at byte.cx (Jens Adam) Date: Wed, 25 May 2016 08:59:36 +0200 Subject: Postscreen whitelist "protection.outlook.com" In-Reply-To: <15099883.kJE44xONHF@techz> References: <15099883.kJE44xONHF@techz> Message-ID: <20160525085936.13cc4b17.jra@byte.cx> Tue, 24 May 2016 20:02:38 +0200 Günther J. Niederwimmer : > Der Hintergrund: > Die Mail sollte reinkommen und wird temporär abgelehnt. > NOQUEUE: > "Service currenly unavailabble" > > kommt aber anscheinend danach mit einer anderen IP usw., > dadurch kommen die Mails Stunden später oder gar nicht ? > > Habt Ihr dafür einen Lösung ? > > Außer postcreen abschalten ;-). Sicher: postscreen_bare_newline_enable no postscreen_non_smtp_command_enable no postscreen_pipelining_enable no http://www.postfix.org/POSTSCREEN_README.html#after_220 --byte -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 455 bytes Beschreibung: Digitale Signatur von OpenPGP URL : From maegger at ee.ethz.ch Thu May 26 13:07:06 2016 From: maegger at ee.ethz.ch (Matthias Egger) Date: Thu, 26 May 2016 13:07:06 +0200 Subject: Postscreen whitelist "protection.outlook.com" In-Reply-To: <15099883.kJE44xONHF@techz> References: <15099883.kJE44xONHF@techz> Message-ID: <5746D8DA.20706@ee.ethz.ch> Hallo Günther, On 05/24/2016 08:02 PM, Günther J. Niederwimmer wrote: > xxxxx.pretection.outlook.com > > Es scheint der einzige zu sein jedenfalls habe ich bis jetzt noch nichts > anderes herausgefunden ? > > Der Hintergrund: > Die Mail sollte reinkommen und wird temporär abgelehnt. > NOQUEUE: > "Service currenly unavailabble" > > kommt aber anscheinend danach mit einer anderen IP usw., > dadurch kommen die Mails Stunden später oder gar nicht ? > > Habt Ihr dafür einen Lösung ? Die grossen Provider sind in der Regel auf dnswl.org drauf. Seit Postfix 2.11.irgendwas kann man auch negative Werte vergeben, wodurch man faktisch ein Whitelisting macht. Wir haben das Problem mit outlook, google etc. anhand folgender Regel beseitigt: -------------------- postscreen_dnsbl_sites = zen.spamhaus.org*2 [...] list.dnswl.org=127.[0..255].[0..255].0*-2 list.dnswl.org=127.[0..255].[0..255].1*-3 list.dnswl.org=127.[0..255].[0..255].[2..255]*-4 -------------------- Achja, falls postgrey eingesetzt wird sollte man natürlich auch da die Whitelists einrichten, sonst knallt es gleich wieder :-) -------------------- # google.com (big pool) /^mail-[a-z][a-z]0-f[0-9]*\.google\.com$/ # outlook.com uses also a big pool like google. /^.*\.outbound\.protection\.outlook\.com$/ -------------------- Lieber Gruss Matthias -- Matthias Egger ETH Zurich Department of Information Technology maegger at ee.ethz.ch and Electrical Engineering IT Support Group (ISG.EE), ETF/D/102 Phone +41 (0)44 632 03 90 Sternwartstrasse 7, CH-8092 Zurich Fax +41 (0)44 632 11 95 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 4099 bytes Beschreibung: S/MIME Cryptographic Signature URL : From chris at schoeppi.net Mon May 30 15:53:44 2016 From: chris at schoeppi.net (Christian Schoepplein) Date: Mon, 30 May 2016 15:53:44 +0200 Subject: TLS =?iso-8859-15?Q?f=FC?= =?iso-8859-15?Q?r?= ein- und ausgehende Verbindungen Message-ID: <20160530135344.GI24485@v.cs-x.de> Hi, ab und an tauchen Einträge wie dieser hier in den Logs unserer Mailserver auf: May 28 12:46:39 myhostname postfix/smtpd[6602]: connect from researchscan288.eecs.umich.edu[141.212.122.33] May 28 12:46:40 myhostname postfix/smtpd[6602]: Anonymous TLS connection established from researchscan288.eecs.umich.edu[141.212.122.33]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) May 28 12:46:40 myhostname postfix/smtpd[6602]: lost connection after STARTTLS from researchscan288.eecs.umich.edu[141.212.122.33] May 28 12:46:40 myhostname postfix/smtpd[6602]: disconnect from researchscan288.eecs.umich.edu[141.212.122.33] ehlo=1 starttls=1 commands=2 TLS ist wie folgt auf den Servern konfiguriert: # /usr/sbin/postconf -n | grep tls smtp_tls_cert_file = /etc/ssl/private/myhostname.crt smtp_tls_key_file = /etc/ssl/private/myhostname.key smtp_tls_loglevel = 1 smtp_use_tls = yes smtpd_tls_cert_file = /etc/ssl/private/myhostname.crt smtpd_tls_key_file = /etc/ssl/private/myhostname.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_use_tls = yes Postfix-Version ist 3.0.3. Bedeutet der Logeintrag oben, dass der Serverzwar gern eine verschlüsselte Verbindung aufbauen möchte, es aber nicht dazu kommt, da das entsprechende Protokoll von uns nicht angeboten wird? Sind unsere TLS Settings OK oder ggf. zu restriktiv bzw. sollten wir was nachbessern? Ciao und danke, Schöpp -- Christian Schoepplein - - http://schoeppi.net -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 173 bytes Beschreibung: Digital signature URL : From Ralf.Hildebrandt at charite.de Mon May 30 16:00:45 2016 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Mon, 30 May 2016 16:00:45 +0200 Subject: TLS =?utf-8?B?ZsO8?= =?utf-8?Q?r?= ein- und ausgehende Verbindungen In-Reply-To: <20160530135344.GI24485@v.cs-x.de> References: <20160530135344.GI24485@v.cs-x.de> Message-ID: <20160530140045.GF10406@charite.de> * Christian Schoepplein : > Hi, > > ab und an tauchen Einträge wie dieser hier in den Logs unserer > Mailserver auf: > > May 28 12:46:39 myhostname postfix/smtpd[6602]: connect from researchscan288.eecs.umich.edu[141.212.122.33] > May 28 12:46:40 myhostname postfix/smtpd[6602]: Anonymous TLS connection established from researchscan288.eecs.umich.edu[141.212.122.33]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) > May 28 12:46:40 myhostname postfix/smtpd[6602]: lost connection after STARTTLS from researchscan288.eecs.umich.edu[141.212.122.33] > May 28 12:46:40 myhostname postfix/smtpd[6602]: disconnect from researchscan288.eecs.umich.edu[141.212.122.33] ehlo=1 starttls=1 > commands=2 > > TLS ist wie folgt auf den Servern konfiguriert: > > # /usr/sbin/postconf -n | grep tls > smtp_tls_cert_file = > /etc/ssl/private/myhostname.crt > smtp_tls_key_file = /etc/ssl/private/myhostname.key > smtp_tls_loglevel = 1 > smtp_use_tls = yes > smtpd_tls_cert_file = /etc/ssl/private/myhostname.crt > smtpd_tls_key_file = /etc/ssl/private/myhostname.key > smtpd_tls_loglevel = 1 Mal auf 2 hochdrehen > smtpd_tls_received_header = yes > smtpd_use_tls = yes > > Postfix-Version ist 3.0.3. > > Bedeutet der Logeintrag oben, dass der Serverzwar gern eine > verschlüsselte Verbindung aufbauen möchte, es aber nicht dazu kommt, da > das entsprechende Protokoll von uns nicht angeboten wird? Sind unsere > TLS Settings OK oder ggf. zu restriktiv bzw. sollten wir was > nachbessern? Unklar, mehr logging nötig. Man einigt sich auf ein Protokoll, aber dann machts bumm. -- 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 | http://www.charite.de From buettnerp at web.de Mon May 30 16:10:18 2016 From: buettnerp at web.de (Peter Buettner) Date: Mon, 30 May 2016 16:10:18 +0200 Subject: =?UTF-8?Q?Re:_TLS_f=c3=bcr_ein-_und_ausgehende_Verbindungen?= In-Reply-To: <20160530135344.GI24485@v.cs-x.de> References: <20160530135344.GI24485@v.cs-x.de> Message-ID: <574C49CA.4070503@web.de> Moin, ... wieder Name schon sagt: Das sind Portscans von umich.edu. Diese IP's landen bei mir in der fail2ban ip.blackliste und Ruhe ist.. Die TLS Einstellungn sind völlig OK. Gruß Peter Büttner Am 30.05.2016 um 15:53 schrieb Christian Schoepplein: > Hi, > > ab und an tauchen Einträge wie dieser hier in den Logs unserer > Mailserver auf: > > May 28 12:46:39 myhostname postfix/smtpd[6602]: connect from > researchscan288.eecs.umich.edu[141.212.122.33] > May 28 12:46:40 myhostname postfix/smtpd[6602]: Anonymous TLS > connection established from > researchscan288.eecs.umich.edu[141.212.122.33]: TLSv1.2 with cipher > ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) > May 28 12:46:40 myhostname postfix/smtpd[6602]: lost connection after > STARTTLS from researchscan288.eecs.umich.edu[141.212.122.33] > May 28 12:46:40 myhostname postfix/smtpd[6602]: disconnect from > researchscan288.eecs.umich.edu[141.212.122.33] ehlo=1 starttls=1 > commands=2 > > TLS ist wie folgt auf den Servern konfiguriert: > > # /usr/sbin/postconf -n | grep tls > smtp_tls_cert_file = > /etc/ssl/private/myhostname.crt > smtp_tls_key_file = /etc/ssl/private/myhostname.key > smtp_tls_loglevel = 1 > smtp_use_tls = yes > smtpd_tls_cert_file = > /etc/ssl/private/myhostname.crt > smtpd_tls_key_file = > /etc/ssl/private/myhostname.key > smtpd_tls_loglevel = 1 > smtpd_tls_received_header = yes > smtpd_use_tls = yes > > Postfix-Version ist 3.0.3. > > Bedeutet der Logeintrag oben, dass der Serverzwar gern eine > verschlüsselte Verbindung aufbauen möchte, es aber nicht dazu kommt, da > das entsprechende Protokoll von uns nicht angeboten wird? Sind unsere > TLS Settings OK oder ggf. zu restriktiv bzw. sollten wir was > nachbessern? > > Ciao und danke, > > Schöpp > From Ralf.Hildebrandt at charite.de Mon May 30 16:13:39 2016 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Mon, 30 May 2016 16:13:39 +0200 Subject: TLS =?utf-8?B?ZsO8?= =?utf-8?Q?r?= ein- und ausgehende Verbindungen In-Reply-To: <574C49CA.4070503@web.de> References: <20160530135344.GI24485@v.cs-x.de> <574C49CA.4070503@web.de> Message-ID: <20160530141338.GG10406@charite.de> * Peter Buettner : > Moin, > > ... wieder Name schon sagt: Das sind Portscans von umich.edu. > > Diese IP's landen bei mir in der fail2ban ip.blackliste und Ruhe ist.. Ah stimmt, habe nicht auf den Hostnamen geachtet... -- 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 | http://www.charite.de From christian.garling at cg-networks.de Mon May 30 16:11:39 2016 From: christian.garling at cg-networks.de (christian.garling at cg-networks.de) Date: Mon, 30 May 2016 16:11:39 +0200 Subject: =?UTF-8?Q?Postfix_f=C3=BCr_den_Einsatz_von_postscreen_vorbereite?= =?UTF-8?Q?n?= Message-ID: Hallo Liste, ich analysiere gerade einen unserer Mailserver hier in der Firma dessen Konfiguration über die Zeit historisch gewachsen ist. Ich würde gerne neben weiteren Optimierungsschritten auch postscreen einsetzen oder zumindest das System soweit haben, damit postscreen eingesetzt werden könnte. Das Problem daran ist, das Port 25 für die gesamte Mail Kommunikation genutzt wird, also auch für die über Dovecot SASL authentifizierten Benutzer. Durch die weite Streuung der Nutzer die über dieses System versenden ist eine Umstellung auf submission realistisch gesehen unmöglich. Wenn ich mich nicht irre ist eine klare Trennung zwischen "versendenden Benutzern" per submission und "Kommunikation mit dem Rest der Welt" über Port 25 aber für postscreen unerlässlich. Gibt es noch eine andere saubere Möglichkeit postscreen einzusetzen? Mir fällt leider nichts ein wie man das machen könnte. Viele Grüße, Christian Garling From Ralf.Hildebrandt at charite.de Mon May 30 16:24:54 2016 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Mon, 30 May 2016 16:24:54 +0200 Subject: Postfix =?utf-8?B?ZsO8?= =?utf-8?Q?r?= den Einsatz von postscreen vorbereiten In-Reply-To: References: Message-ID: <20160530142454.GH10406@charite.de> * christian.garling at cg-networks.de : > Hallo Liste, > > ich analysiere gerade einen unserer Mailserver hier in der Firma dessen > Konfiguration über die Zeit historisch gewachsen ist. Ich würde gerne neben > weiteren Optimierungsschritten auch postscreen einsetzen oder zumindest das > System soweit haben, damit postscreen eingesetzt werden könnte. Das Problem > daran ist, das Port 25 für die gesamte Mail Kommunikation genutzt wird, also > auch für die über Dovecot SASL authentifizierten Benutzer. Durch die weite > Streuung der Nutzer die über dieses System versenden ist eine Umstellung auf > submission realistisch gesehen unmöglich. Wenn ich mich nicht irre ist eine > klare Trennung zwischen "versendenden Benutzern" per submission und > "Kommunikation mit dem Rest der Welt" über Port 25 aber für postscreen > unerlässlich. Korrekt. > Gibt es noch eine andere saubere Möglichkeit postscreen einzusetzen? Kaum. -- 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 | http://www.charite.de From postfixbuch-users at 0xaffe.de Mon May 30 16:29:01 2016 From: postfixbuch-users at 0xaffe.de (Mathias Jeschke) Date: Mon, 30 May 2016 16:29:01 +0200 Subject: =?UTF-8?Q?Re:_Postfix_f=c3=bcr_den_Einsatz_von_postscreen_vorbereit?= =?UTF-8?Q?en?= In-Reply-To: <20160530142454.GH10406@charite.de> References: <20160530142454.GH10406@charite.de> Message-ID: Hallo Christian, Am 30.05.16 um 16:24 schrieb Ralf Hildebrandt: >> Gibt es noch eine andere saubere Möglichkeit postscreen einzusetzen? > Kaum. Du könntest eine weitere IP-Adresse für den MX-Record etablieren und dann die SMTP-Auth-User gegen Port 25 gegen die aktuelle IP-Adresse/Hostnamen fahren und die eingehenden Mails per MX-Record gegen die neue IP bzw. Hostnamen. Viele Grüße, Mathias. From jost+lists at dimejo.at Mon May 30 16:29:49 2016 From: jost+lists at dimejo.at (Alex JOST) Date: Mon, 30 May 2016 16:29:49 +0200 Subject: =?UTF-8?Q?Re:_Postfix_f=c3=bcr_den_Einsatz_von_postscreen_vorbereit?= =?UTF-8?Q?en?= In-Reply-To: References: Message-ID: Am 30.05.2016 um 16:11 schrieb christian.garling at cg-networks.de: > Hallo Liste, > > ich analysiere gerade einen unserer Mailserver hier in der Firma dessen > Konfiguration über die Zeit historisch gewachsen ist. Ich würde gerne > neben weiteren Optimierungsschritten auch postscreen einsetzen oder > zumindest das System soweit haben, damit postscreen eingesetzt werden > könnte. Das Problem daran ist, das Port 25 für die gesamte Mail > Kommunikation genutzt wird, also auch für die über Dovecot SASL > authentifizierten Benutzer. Durch die weite Streuung der Nutzer die über > dieses System versenden ist eine Umstellung auf submission realistisch > gesehen unmöglich. Wenn ich mich nicht irre ist eine klare Trennung > zwischen "versendenden Benutzern" per submission und "Kommunikation mit > dem Rest der Welt" über Port 25 aber für postscreen unerlässlich. Gibt > es noch eine andere saubere Möglichkeit postscreen einzusetzen? Mir > fällt leider nichts ein wie man das machen könnte. Wenn Dir auf dem Server mehr als 1 IP zur Verfügung steht kannst Du die Dienste darüber trennen? -- Alex JOST