March 2015 - postfix-users

Server timing out when sending larger messages
by Catscrash 27 Mar '15

27 Mar '15

Hi, Ich hab einen neuen VPS-Server, der mir einige Probleme mit Timeouts gibt, die ich so noch nie hatte. Die Probleme tauchen bei manchen Providern bei allen Mails auf, bei anderen nur bei größeren (~800k = größer) Das sieht dann in etwa so aus: Mar 24 18:02:08 __HOST__ postfix/smtp[27831]: Anonymous TLS connection established to mail.XXX.org[XX.XX.XX.XX]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Mar 24 18:08:06 __HOST__ postfix/smtp[27831]: 7F4D8D486F7: to=<xx(a)xx.xx>, relay=mail.XXX.org[xx.xx.xx.xx]:25, delay=19438, delays=18916/0.03/169/353, dsn=4.4.2, status=deferred (conversation with mail.XXX.org[xx.xx.xx.xx] timed out while sending message body) Passiert mit gmail, t-online, etc. aber auch mit einem anderen meiner Server, der normalerweise keinerlei Probleme macht, sodass ich da auch mal die Gegenseite sehen kann: Mar 24 18:02:08 root postfix/smtpd[28051]: Anonymous TLS connection established from __HOSTNAME__[yy.yy.yy.yy]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) Mar 24 18:02:19 root postfix/policyd-weight[12338]: decided action=PREPEND X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 (only DNSBL check requested); <client=__HOSTNAME__[yy.yy.yy.yy]> <helo=__HOSTNAME__> <from=ZZZ@__HOSTNAME__> <to=xx(a)yy.zz>; delay: 1s Mar 24 18:02:19 root postgrey[18205]: action=pass, reason=recipient whitelist, client_name=__HOSTNAME__, client_address=yy.yy.yy.yy, sender=ZZZ@__HOSTNAME__, recipient=xx(a)yy.org Mar 24 18:02:19 root postfix/smtpd[28051]: 73104482C241: client=__HOSTNAME__[yy.yyy.yyy.yy] Mar 24 18:02:40 root postfix/cleanup[28654]: 73104482C241: message-id=<> Mar 24 18:03:56 root postfix/smtpd[28683]: initializing the server-side TLS engine Mar 24 18:17:27 root postfix/smtpd[28051]: timeout after DATA (16309 bytes) from __HOSTNAME__[yy.yyy.yyy.yy] postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_at_myorigin = yes append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes config_directory = /etc/postfix dovecot_destination_recipient_limit = 1 imscp-arpl_destination_recipient_limit = 1 inet_interfaces = all inet_protocols = ipv4 local_destination_recipient_limit = 1 local_recipient_maps = unix:passwd.byname $alias_database local_transport = local mail_spool_directory = /var/mail mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 message_size_limit = 0 mydestination = $mydomain mydomain = __HOSTNAME__.local myhostname = __HOSTNAME__ mynetworks_style = host myorigin = $myhostname recipient_delimiter = + relay_domains = hash:/etc/postfix/imscp/relay_domains smtp_bind_address = yy.yyy.yyy.yyy smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtp_tls_loglevel = 1 smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = may smtpd_banner = $myhostname smtpd_data_restrictions = reject_multi_recipient_bounce, reject_unauth_pipelining smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unlisted_recipient, permit smtpd_relay_restrictions = smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = smtpd smtpd_sasl_security_options = noanonymous smtpd_sasl_type = cyrus smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, permit_mynetworks, permit_sasl_authenticated smtpd_tls_CAfile = /etc/ssl/private/ca-bundle.crt smtpd_tls_auth_only = no smtpd_tls_cert_file = /etc/ssl/private/xxxxxx.pem smtpd_tls_key_file = /etc/ssl/private/xxxxxx..key smtpd_tls_loglevel = 1 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_received_header = yes smtpd_tls_security_level = may transport_maps = hash:/etc/postfix/imscp/transport virtual_alias_maps = hash:/etc/postfix/imscp/aliases virtual_gid_maps = static:8 virtual_mailbox_base = /var/mail/virtual virtual_mailbox_domains = hash:/etc/postfix/imscp/domains virtual_mailbox_limit = 0 virtual_mailbox_maps = hash:/etc/postfix/imscp/mailboxes virtual_minimum_uid = 999 virtual_transport = dovecot virtual_uid_maps = static:999 Eigentlich ist der VPS recht flott und reagiert schnell, ping zeiten sind sehr gut und ich habe ansonsten noch nichts bemerkt was langsam erscheint, aber aus irgendeinem Grund scheint das bei SMTP nicht der Fall zu sein. Ich hab sicherheitsalber iptables geflushed, falls da irgendwas blockendes drin ist, hat aber nichts geholfen. Habt ihr eine Idee? Danke!

2 2

komisches neues Verhalten bei Postfix 3.0.0
by Christian Bricart 26 Mar '15

26 Mar '15

Tach zusammen, ich hab' grade mal in einem Anflug von Wahnsinn mich an das Upgrade von Postfix auf 3.0.0 gemacht ;-) hat prinzipiell gar nicht weh getan, weil die neuen Defaults aus der COMPATIBILITY_README eh schon meine Defaults waren - also ging das Aktivieren von > compatibility_level = 2 direkt und ohne Schmerzen ;) Aber *ein* neues Verhalten wurmt mich: warum fummelt die Version beim Starten in/an meiner main.cf rum und appended einfach jedesmal sinnlose Defaults: > queue_directory = /var/spool/postfix > meta_directory = /etc/postfix > command_directory = /usr/sbin > sample_directory = /etc/postfix > newaliases_path = /usr/bin/newaliases > mailq_path = /usr/bin/mailq > readme_directory = no > sendmail_path = /usr/sbin/sendmail > daemon_directory = /usr/libexec/postfix > manpage_directory = /usr/local/man > html_directory = no > data_directory = /var/lib/postfix > shlib_directory = /usr/lib64/postfix/${mail_version} zusätzlich gibt es ja wohl neuerdings(?) eine Datei ${meta_directory}/postfix-files welches mir beim Starten immer dem Symlink meiner main.cf folgt und sie dann statt dem Link da hinkopiert.. dort drin steht zumindest was von "f" für die main.cf - allerdings für die master.cf auch und die lässt er in Ruhe.. Wo finde ich denn Doku wie man das "The-Postfix-Way" macht..? Weil ausser "Do not edit this file." finde ich nix ;-) Danke Christian

1 0

bcc_senders
by Joachim Fahrner 22 Mar '15

22 Mar '15

Hallo, ich bin auf einen anderen Server umgezogen, habe alle Konfigfiles kopiert, und jetzt geht was nicht mehr auf dem neuen Server :-( Ich nutze bcc_senders um mir per plus-adressierung eine Kopie in den Sent-Ordner zu legen. Beispiel: jf(a)fahrner.name jf+sent(a)fahrner.name sendet eine Kopie an mich selbst. Im Dovecot habe ich eine Sieve-Regel für das Feld "delivered-to", wenn da "jf+sent(a)fahrner.name" drin steht verschiebe ich es in den Sent-Ordner. Das klappt jetzt nicht mehr. Ich kriege zwar die Kopie, aber in "delivered-to" fehlt das "+sent". Ich hab grad gar keine Idee wo ich nach dem Fehler suchen könnte. -- Mit besten Grüßen Joachim Fahrner

2 4

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

PGP-Schlüssel einfach und sicher verteilen
by Robert Schetterer 06 Mar '15

06 Mar '15

Hi @ll, weil es grade durch die Medien getrieben wird https://sys4.de/de/blog/2015/02/26/pgp-schluessel-einfach-und-sicher-vertei… Best Regards MfG Robert Schetterer -- [*] sys4 AG http://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

10 35

Re: GPG-Verschlüsselung auf dem Server für ausgehende Mail
by Matthias Schmidt 05 Mar '15

05 Mar '15

> Am 25 Feb 2015 um 00:52 schrieb Matthias-Christian Ott <ott(a)mirix.org>: > > On 2015-02-24 13:07, Matthias Schmidt wrote: >> >>> Am 22 Feb 2015 um 03:52 schrieb Matthias-Christian Ott <ott(a)mirix.org>: >>> >>> On 2015-02-21 13:19, Ralph J.Mayer wrote: >>>> ich würde gerne jede meiner ausgehenden Mails automatisch verschlüsseln >>>> lassen, sofern ein Schlüssel vorliegt. >>>> Das ganze soll auf meinem Server passieren, weil ich z.B. auf dem iPhone >>>> kein PGP habe. >> >> es gibt für das iPhone mehrere Anwendungen: >> - iPGMail >> - oPenGP >> >> ich würd auch immer nur Verschlüsseln, wenn’s sein muss. > > Damit es dann möglichst auffällig ist, dass die verschlüsselten E-Mails > wichtige Informationen beinhalten. Das hilft doch nur einer > Metadatenauswertung. > Käse, die Header werden ja eh nicht verschlüsselt und das ist das was da ausgewertet wird. Dass die Verschlüsselung die Auswertung von Metadaten erschweren würde ist ein Märchen. Bei der Verschlüsselung geht es allein darum den Inhalt vor unberechtigten Mitlesern zu schützen und das ist in diesem Fall meist nicht irgendein staatl. Dienst. Wenn die nämlich so interessiert an Dir sind, dass sie Deine Mails lesen wollen, greifen die die schon ab, währen Du die schreibst. Außerdem hast Du dann ein ziemliches Problem am Hals ;-) Gruss Matthias

2 1

Postfix/Cyrus auf Emailrechner / Anbindung per shell oder mySQL an Rechner wo Daten gepflegt werden
by Thomas 05 Mar '15

05 Mar '15

Hallo, ich habe auf meinen master Rechner Apache, mySQL usw. und verwalte dort meine Benutzer mit user, password, Emailadresse. Dann habe ich einen zweiten Email-Rechner mit Postfix, Cyrus, IMAP usw. auf den ich ein- und ausgehende Emails verwalte/versende. Heute pflege ich das per Hand. Ich möchte aber das wenn man auf dem master Rechner Benutzer anlegt/ändert dieses gleich auf meinen Email-Rechner aktualisiert wird. Frage, soll ich noch per Script die SASL Datenbank auf dem Emailrechner pflegen und die postfix conf file pflegen/rüberkopieren oder das ganze so machen das der Emailrechner per Tunnel auf die mySQL Datenbank des Masterrechners zugreift. Was aber wenn der Tunnel mal kaputt ist, mySQL mit Replikation ist mir dafür zu aufwändig und das dann keine Emails angenommen werden können möchte ich auch nicht. Oder was wäre eine gescheite Lösung und gibt es evtl. schon shell Scriptfiles im Netz die das rüberkopieren oder den shell Zugriff umgesetzt haben und genau das machen. danke Gruss Thomas

4 5