January 2015 - postfix-users

helpful_warnings=no schaltet nicht "override earlier entry" Warnings aus
by Axel Beckert 10 Mar '15

10 Mar '15

Hallo, wir verteilen unsere main.cf auf Server und Workstations per Konfigurationsmanagement. Es gibt eine Default-main.cf, die meistens ausreicht. Braucht es Abweichungen, so werden diese durch ein beim Deployment angehängtes per-host-Konfigurationsschnipsel gelöst. In diesem sind ggf. Einstellungen drin, die in der Default-Datei bereits mit anderen Wertten drin sind, um diese zu überschreiben. Mit Debian 7 Wheezy und Postfix 2.9.6 funktioniert dies wunderbar, aber seit Debian 8 Jessie und Postfix 2.11.3 jammert Postfix in verschiedensten Situationen über diese "Überschreib"-Methoden: # postconf > /dev/null postconf: warning: /etc/postfix/main.cf, line 29: overriding earlier entry: mydestination= postconf: warning: /etc/postfix/main.cf, line 30: overriding earlier entry: relayhost=smtp.phys.ethz.ch postconf: warning: /etc/postfix/main.cf, line 31: overriding earlier entry: inet_interfaces=loopback-only # Die dazugehörige main.cf sieht wie folgt aus: ---8<--- # Note: file generated by dphys-config DO NOT EDIT IN /etc/postfix/main.cf # Default settings (hostname has been inserted by the configuration # deployment tool) myhostname = silberspitz.ethz.ch smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU Linux) biff = no append_dot_mydomain = no alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname relayhost = smtp.phys.ethz.ch mynetworks = 127.0.0.0/8, [::1]/128 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = loopback-only sender_canonical_maps = pcre:/etc/postfix/sender_canonical mydestination = # Per-host settings mydestination = silberspitz.ethz.ch silberspitz localhost bb.phys.ethz.ch hobbit.phys.ethz.ch xymon.phys.ethz.ch relayhost = inet_interfaces = all --->8--- (Grundidee bei diesem Beispiel: Alle Standard-Server sollen Mails via Mailserver verschicken, nicht aber der Monitoring-Server von dem o.g. Beispiel stammt. Der soll auch noch Mails an das SMS-Gateway verschicken können, wenn der Mailserver down ist.) Um o.g. Warnungen zu unterdrücken habe ich dann noch ein helpful_warnings = no ganz vorne in der main.cf hinzugefügt. Gemäss man page unterdrückt dies "warnings about problematic configuration settings, and helpful suggestions." -- Klang für mich nach genau der richtigen Einstellung, hat aber leider keinen Unterschied gemacht. Deswegen meine Frage: Wie bekomme ich Postfix dazu, diese Warnungen nicht mehr auszugeben? Sie verursachen diverse Mails von Cron-Jobs, weil Output (auf STDERR) kommt, z.B. von popularity-contest: ---8<--- Subject: Cron <root@silberspitz> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) /etc/cron.daily/popularity-contest: sendmail: warning: /etc/postfix/main.cf, line 28: overriding earlier entry: mydestination= sendmail: warning: /etc/postfix/main.cf, line 29: overriding earlier entry: relayhost=smtp.phys.ethz.ch sendmail: warning: /etc/postfix/main.cf, line 30: overriding earlier entry: inet_interfaces=loopback-only postdrop: warning: /etc/postfix/main.cf, line 28: overriding earlier entry: mydestination= postdrop: warning: /etc/postfix/main.cf, line 29: overriding earlier entry: relayhost=smtp.phys.ethz.ch postdrop: warning: /etc/postfix/main.cf, line 30: overriding earlier entry: inet_interfaces=loopback-only --->8--- Und nein, ich will nicht pauschal allen Output nach STDERR unterdrücken, da könnte ja durchaus mal ein relevanter Fehler drin sein. :-) (Mal ganz davon abgesehen, dass ich das nicht in jedem Skript machen will, welches irgendwann mal "sendmail" aufruft.) Im Changelog habe ich diesen Eintrag gefunden: 20130404 Human factors: warning when a main.cf parameter has multiple entries with different values. File: util/dict.c. Aber das ist doch gar kein Bug, das ist ein Feature! ;-) Code-Stelle dazu ist recht sicher dies hier: 459 if ((old = dict->lookup(dict, member)) != 0 460 && strcmp(old, val) != 0) 461 msg_warn("%s, line %d: overriding earlier entry: %s=%s", 462 VSTREAM_PATH(fp), lineno, member, old); Bei Weiterverfolgen, ob das Log-Level irgendwo ausgewertet wird und beeinflusst werden kann, bin ich bis zur Funktion msg_text am Ende von util/msg_output.c gekommen, aber da haben mich meine C-Kenntnisse dann irgendwann verlassen... Mit freundlichem Gruss, Axel Beckert -- Axel Beckert <beckert(a)phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT H 6 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/

2 2

TLSA: DNS ttl und revoced certs
by django＠nausch.org 05 Feb '15

05 Feb '15

HI! Zwei kurze Fragen: Welche Erfahrungswerte könnt Ihr mir denn TTL von TLSA-Records nennen? Was macht man bei einem zurückgerufenen Zertifikat? Reicht es den TLSA-Record zu klöschen, oder gibt es da ähnlich wie bei DKIM 'nen besonderen Eintrag zum Kennzeichnen, das das Zertifikat/Schlüssel revoced wurde? ttyl Django

6 12

CA certificate verification failed for *: num=7:certificate signature failure
by Marc Patermann 28 Jan '15

28 Jan '15

Hallo, ich schicke Mails an einen externen Exchange-Server. Die TLS-Verbindung wird teilweise "Trusted" aufgebaut, teilweise mit "A certificate verification failed for exchange[10.17.101.63]:25: num=7:certificate signature failure" aufgebaut. Wie kann das sein? Die CA Cert-Chain habe ich auf dem Server in /etc/ssl/certs abgelegt. Vorher war die TLS-Verbindung immer untrusted. Hier mal Auszüge aus dem Log: Jan 28 10:59:58 exts098 postfix/smtp[19043]: setting up TLS connection to exchange[10.17.101.63]:25 Jan 28 10:59:58 exts098 postfix/smtp[19043]: Trusted TLS connection established to exchange[10.17.101.63]:25: TLSv1 with cipher RC4-MD5 (128/128 bits) -- Jan 28 11:06:53 exts098 postfix/smtp[17667]: setting up TLS connection to exchange[10.17.101.63]:25 Jan 28 11:06:53 exts098 postfix/smtp[17667]: CA certificate verification failed for exchange[10.17.101.63]:25: num=7:certificate signature failure -- Jan 28 11:08:23 exts098 postfix/smtp[17667]: setting up TLS connection to exchange[10.17.101.63]:25 Jan 28 11:08:23 exts098 postfix/smtp[17667]: Trusted TLS connection established to exchange[10.17.101.63]:25: TLSv1 with cipher RC4-MD5 (128/128 bits) Marc

3 2

Postfix ist nicht von GHOST betroffen
by Patrick Ben Koetter 28 Jan '15

28 Jan '15

Wer ein wenig mehr Hintergrund möchte: https://sys4.de/de/blog/2015/01/28/entwarnung-fur-postfix-und-cve-2015-0235… p@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

2 1

Re: Mails einzelner Domains über Relay ausliefern
by Michael Reincke 21 Jan '15

21 Jan '15

Hallo, die Lösung sind sender_dependent_relayhost_maps http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps Gruß Michael Am 20. Januar 2015 19:01:20 MEZ, schrieb Michael Reincke <michael.reincke(a)famre.de>: >Hallo, > >Am 20. Januar 2015 18:25:53 MEZ, schrieb "Markus Schönhaber" ><postfix-users-de(a)list-post.mks-mail.de>: >>Am 20.01.2015 um 18:09 schrieb frank(a)belau.de: >> >>> ich bräuchte mal euer Wissen. Ich habe ein Webserver auf dem als >>> lokaler MTA ein Postfox läuft. Auf diesem System werden Webseiten >für >> >>> mehrere Domains gehostet. Bisher werden alle Mails direkt >>ausgeliefert. >>> (Der MX läuft auf anderen Systemen). Jetzt habe ich eine >Anforderung, >> >>> daß Mails von 2 Webseiten (jeweils eine andere Domain) über jeweils >>> einen eigenen Relayhost ausgeliefert werden sollen. >>> >>> Wie bekommt man das hin? >>> >>> >>> *(a)domain_a.de -> direkt ausliefern >>> ... >>> *(a)domain_f.de -> direkt ausliefern >>> *(a)domain_x.de -> über Relayhost X ausliefern >>> *(a)domain_y.de -> über Relayhost Y ausliefern >> >>http://www.postfix.org/postconf.5.html#transport_maps >> >>-- >>Gruß >> mks > >Wird so leider nicht funktionieren. >Die transport map ist nur für das Routing bzgl. Empfänger zuständig. > >Gruß > >Michael > >-- >Michael Reincke

3 2

Mails einzelner Domains über Relay ausliefern
by frank＠belau.de 20 Jan '15

20 Jan '15

Hallo zusammen, ich bräuchte mal euer Wissen. Ich habe ein Webserver auf dem als lokaler MTA ein Postfox läuft. Auf diesem System werden Webseiten für mehrere Domains gehostet. Bisher werden alle Mails direkt ausgeliefert. (Der MX läuft auf anderen Systemen). Jetzt habe ich eine Anforderung, daß Mails von 2 Webseiten (jeweils eine andere Domain) über jeweils einen eigenen Relayhost ausgeliefert werden sollen. Wie bekommt man das hin? *(a)domain_a.de -> direkt ausliefern ... *(a)domain_f.de -> direkt ausliefern *(a)domain_x.de -> über Relayhost X ausliefern *(a)domain_y.de -> über Relayhost Y ausliefern MfG Frank.

2 1

Problem mit cleanup nach content filter
by Jakob-Matthias Böttger 16 Jan '15

16 Jan '15

Hallo zusammen, ich habe folgendes Problem. Die Faktura Software eines Kunden verschickt Mails ohne Date Header. (Ich weiss das ist das Eigentliche Problem...) Der Mailserver nimmt auf 587 entgegen und schickt die Mail durch einen pre queue Contentfilter, in diesem Fall Amavis. Amavis registriert den fehlenden Header und Kreidet dies an. Die Mail wird jetzt auch ausgeliefert leider aber ohne den Date Header. Eigentlich müsste doch der Cleanup diesen jetzt nach dem content filter hinzufügen. Habt ihr eine Idee woran das liegt?

1 0

OT: DNS Provider gesucht
by lst_hoe02＠kwsoft.de 15 Jan '15

15 Jan '15

Hallo, ich bin auf der Suche nach einem DNS Provider, bevorzugt Deutschland mit der Möglichkeit DNSSEC gesicherte Domains zu verwalten, schön wäre auch Sachen wie SRV und TLSA Records. Das ganze darf auch etwas kosten sollte aber für den Privatgebrauch bezahlbar bleiben (~50 Euro / Jahr und Domain). Bin für jeden Hinweis dankbar, bei den "großen" sieht es leider bei DNSSEC traurig aus und auch SRV Records sind selten, TLSA gibt es wohl nirgends. Danke Andreas

8 14

ANN: dane-users@sys4.de Mailingliste und https://dane.sys4.de DANE SMTP Validator
by Patrick Ben Koetter 15 Jan '15

15 Jan '15

Nahezu 3% der DANE SMTP aktivierten Domains validieren nicht richtig oder sie veröffentlichen unbrauchbare TLSA Ressource Records[1]. Der Anteil wäre größer, hätten wir in der Vergangenheit nicht schon problematische Sites auf deren DANE Probleme aufmerksam gemacht. Eine Fehlerrate von 3% ist definitiv zu hoch. Der DANE Validator <https://dane.sys4.de> soll Konfigurationsfehler identifizieren. Er soll Administratoren unterstützen, funktionierende DANE SMTP Konfigurationen zu erstellen. Mit dem heutigen Release stellen wir die erste öffentliche Beta online. Die Version 1 soll bald folgen. Zeitgleich haben wir die englischsprachige Mailingliste "DANE users" <dane-users(a)sys4.de> ins Leben gerufen. Die Liste dient der Diskussion praktischer Fragestellungen aus dem DANE-Alltag. Sie ist nicht auf ein konkretes Produkt festgelegt. Interessierte abonnieren die Liste auf https://mail.sys4.de/cgi-bin/mailman/listinfo/dane-users. p@rick [1] Basierend auf einer DANE-Einführungsstudie von Viktor Dukhovni. -- [*] 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

2 3

SASL- und IMAP-Authentifizierungsmechanismen von Dovecot/Postfix
by Michael Köhler 12 Jan '15

12 Jan '15

Hallo, ich denke schon die ganze Zeit darüber nach, ob der Authentifizierungsmechanismus „plain“ ein Sicherheitsrisiko ist, welchen ich in Postfix mit „smtpd_sasl_security_options“ bzw. „smtpd_sasl_tls_security_options“ und in Dovecot unter „auth_mechanisms“ angeben kann?! Ich bin geneigt dazu das Tor so weit wie möglich zu schliessen und nur die höchste und "verschlüsselste" Authentifizierungsmethode zuzulassen - aber ist das sinnvoll? Je nach Client kann es da zu Problemen führen, weil nicht alle Clients alle Möglichkeiten durchprobieren und deswegen der Erklärungsaufwand höher ist. Wenn ich die diversen Dokus/Bücher richtig verstanden habe, dann wird bei IMAP logischerweise (wenn ich Dovecot als IMAP-Server einsetze) Dovecot als Authentifizierungsinstanz genutzt. Wenn ich jetzt auth_mechanisms = plain, login, ... setze - wie wird dann eine Anmeldung per IMAPS vorgenommen? Wird die Authentifizierung verschlüsselt ablaufen? Und stellt Plaintext in dem Falle ein Sicherheitsrisiko dar? Und wie ist das bei Postfix? Ich kann mit smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = $smtpd_sasl_security_options festlegen, dass bei einer unverschlüsselten SMTP-Session sowohl keine anonyme Authentifizierung als auch keine im Plaintext stattfinden darf. Um es komfortabler zu machen, kann ich aber auch smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous festlegen. Damit kann ich TLS-verschlüsselt auch wieder Plaintext verwenden. Würde denn auch smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_tls_auth_only = yes zu dem gleichen Ergebnis führen, wenn ich nur verschlüsselte Authentifizierung erlauben will? Denn dann würde ja smtpd_sasl_security_options gar nicht zum Zuge kommen, oder? Was ist nun eine sichere und zugleich komfortable Konfiguration, damit sich am besten alle möglichen Clients einfach per IMAPS/SMTPS authentifizieren können? Viele Grüße, Michael

6 14