Posts Tagged ‘postfix’

Mittwoch, 6. September 2023

Postfix: Wartende ausgehende Emails löschen

Link zu diesem Artikel

Gestern habe ich auf einem Linux-System durch einen dummen Programmierfehler einen endlosen For Loop generiert, welcher tausende Emails mit dem selben Inhalt an meine persönliche Email-Adresse absetzte.

Zum Glück habe ich den lokalen Postfix so konfiguriert, dass er die Emails in für meinen Hoster in homöopatischen Dosen rauslässt (main.cf):

...
# Rate Limiting / Throttling
# default_destination_rate_delay = seconds between two emails
initial_destination_concurrency = 1
default_destination_concurrency_limit = 1
default_destination_rate_delay = 20
default_destination_recipient_limit = 2
default_process_limit = 1

Während also alle paar Sekunden die Unfall-Mails in der INBOX aufpoppten, entschied ich mich, auf den Heimserver einzuloggen und kurzerhand die ganze Postfix-Queue zu löschen.

Das ist ganz einfach:

# postsuper -d ALL

Quelle: How to Flush the Mail Queue in Postfix

Bei der Aktion wurden über 4000 auf den Versand wartende Emails gelöscht …

Tags: , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 1. März 2020

Unter macOS High Sierra mit MacPorts, postfix und s-nail E-Mails versenden

Link zu diesem Artikel

Emails von der Kommandozeile versenden — was man bei Linux im Handumdrehen hinkriegt, erforderte bei mir unter macOS stundenlange Handstände.

MacPorts postfix anstelle macOS postfix

Doch jetzt habe ich den Kniff raus: Die von macOS mitgelieferte postfix-Installation habe ich schlussendlich ignoriert und auf das MacPorts postfix-Paket gesetzt.

MacPorts Variants nicht vergessen

Der erste Fallstrick lauert schon hier: Um heutzutage über einen Hoster E-Mails zu versenden, benötigt man zwingend SASL und TLS. Diese Features müssen als sog. MacPorts Variants explizit mitinstalliert werden, sonst landen sie nicht auf dem Mac:

# port install postfix +sasl +tls

Ansonsten meldet postfix:

...
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: smtp_sasl_auth_enable is true, but SASL support is not compiled in
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: TLS has been selected, but TLS support is not compiled in
...

Verzeichnisse und Pfade zur Sicherheit hardkodieren

Eine funktionierende postfix-Konfiguration mitsamt Installationsscript habe ich von meinen Linux-Servern herüberkopiert (diese Anleitung alleine würde das Format dieses Blog-Artikels sprengen). Die Konfiguration habe ich aber mit den MacPorts-Einstellungen ergänzt. Denke daran: Bei Linux liegen die Konfiguration sowie die Arbeitsverzeichnisse allesamt am erwarteten Ort (bspw. /etc/postfix/main.cf). Da wir unter macOS auf MacPorts setzen, liegt dieselbe Datei hier unter /opt/local/etc/postfix/main.cf. Deshalb habe ich zur Sicherheit in main.cf folgende von MacPorts vorgeschlagene Ergänzungen (siehe /opt/local/etc/postfix/main.cf.sample) hinzugefügt:

$ cat /opt/local/etc/postfix/main.cf
# Directories
queue_directory = /opt/local/var/spool/postfix
command_directory = /opt/local/sbin
daemon_directory = /opt/local/libexec/postfix
data_directory = /opt/local/var/lib/postfix
meta_directory = /opt/local/etc/postfix
manpage_directory = /opt/local/share/man
sample_directory = /opt/local/share/postfix/sample
readme_directory = /opt/local/share/postfix/readme
shlib_directory = no
html_directory = no

# Paths
sendmail_path = /opt/local/sbin/sendmail
newaliases_path = /opt/local/bin/newaliases
mailq_path = /opt/local/bin/mailq

# Log
maillog_file_prefixes = /var, /var/log/macports/postfix
maillog_file = /var/log/macports/postfix/postfix.log

# Other stuff ...
mail_owner = _postfix
setgid_group = _postdrop
default_privs = nobody
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
...

Logs in eine Datei schreiben

Weiter hatte ich während dem Debuggen so meine liebe Mühe, die Logging-Informationen zu finden, da diese an syslog gesendet werden und bei macOS dann in der Console.app landen. Deshalb habe ich im Gegensatz zu meinen Linux-Installationen auch noch die Konfigurationsdatei /opt/local/etc/postfix/master.cf anpassen müssen. Essentiell war es, die folgende Zeile einzufügen:

...
postlog   unix-dgram n  -       n       -       1       postlogd
...

Quelle: Postfix logging to file or stdout

Verhindern, dass fälschlicherweise die macOS postfix-Konfiguration geladen wird

Damit mir die Parallelinstallation von Postfix nicht in die Quere kommt und ich mir sicher war, dass die MacPorts-Installation von postfix tatsächlich die Konfiguration unter /opt frisst, habe ich kurzerhand den macOS postfix-Ordner verschoben:

# mv /etc/postfix /etc/postfix.bkp

Ob das wirklich nötig gewesen wäre sei dahingestellt; Vorsicht, wer das auf seinem System macht: Ich garantiere für nichts.

Postfix starten und stoppen

Die Postfix-Installation lädt man folgendermassen:

# port load postfix
# launchctl unload /Library/LaunchDaemons/org.macports.postfix.plist
# launchctl load -w /Library/LaunchDaemons/org.macports.postfix.plist

Die plist-Datei zeigt als symbolischer Link nach /opt/local/etc/LaunchDaemons/org.macports.postfix/org.macports.postfix.plist. In dieser Datei habe ich folgendes angepasst/ergänzt — das ist nicht zwingend nötig, sollte aber dazu führen, dass Postfix bei jedem Neustart automatisch gestartet wird. Ausserdem sollten im Fall von Start-Problemen Fehlermeldungen in eine Log-Datei geschrieben werden:

...
        <string>--pid=none</string>
    </array>
    <key>Disabled</key>
    <false/>
    <key>KeepAlive</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/var/log/launchd.macports.postfix.standard.log</string>
    <key>StandardErrorPath</key>
    <string>/var/log/launchd.macports.postfix.error.log</string>
</dict>
</plist>

s-nail verwendet standardmässig die macOS mail-Executables

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. MacPorts bietet hierzu s-nail an (Homepage des Entwicklers).

# port install s-nail

Als ich mit s-nail ein Test-Mail versenden wollte folgte eine weitere Hiobs-Botschaft:

$ echo "Test email" | mail user@domain.tld
unknown: fatal: open /etc/postfix/main.cf: No such file or directory
/Users/user/dead.letter 7/135
mail: ... message not sent

Ich übertreibe nicht, wenn ich sage, dass ich Stunden mit Debugging verbracht habe. Bis ich plötzlich realisierte, dass s-nail die offiziellen Mail-Executables mail, mailx und/oder sendmail unter /usr/bin verwendet. Der Lackmus-Test: Wenn ich diese Mail-Executables manuell aufrief, erschien ein- und dieselbe Fehlermeldung.

Dies obwohl meine Bash PATH-Variable /opt/local/bin und /opt/local/sbin vor /usr/bin und /usr/sbin nennt, verwendete s-nail aus irgendeinem Grund standardmässig die letztgenannten Pfade.

Wie sage ich s-nail aber, dass es stattdessen die MacPorts mail-Befehle verwenden soll? Folgende Anpassung in /opt/local/etc/mail.rc war nötig:

...
set mta=/opt/local/sbin/sendmail

Absender (From:) der E-Mails selber festlegen

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. Ich verwende in Bash-Scripts sehr oft folgendes Konstrukt, und ich wollte sicherstellen, dass die Scripts sowohl unter Debian GNU/Linux als auch macOS laufen (Argument -a):

$ echo -e "Test" | $(which mail) -a "From: DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Ich habe leider eine schlechte, aber auch eine gute Nachricht. Die gute: Man kann auch unter macOS den Absender setzen. Leider aber nicht mit demselben Befehl wie unter Debian GNU/Linux.

Bei s-nail muss ich leider ein anderes Argument verwenden:

$ echo -e "Test" | $(which mail) -r "DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Postfix hat Probleme mit selber gesetzter Absenderadresse und SPF Records

Doch nun trat bereits das nächste Problem auf, wie ein Blick in die leere INBOX und in /var/log/macports/postfix.log zeigte:

...
Mar 01 15:43:59 imac postfix/smtp[81049]: 4D0E3FBBE221: to=<user@domain.tld>, relay=s000.cyon.net[149.126.4.000]:25, delay=20, delays=0.03/20/0.03/0.04, dsn=5.0.0, status=bounced (host s000.cyon.net[149.126.4.000] said: 550 SPF: 1.2.3.4 is not allowed to send mail from emeidi.com (in reply to RCPT TO command))
...

Faszinierend. Unter Linux hatte ich eine solche Fehlermeldung noch nie gesehen. Ich verwende für den Versand „offizieller“ E-Mails jeweils emeidi.com als Absenderadresse.

Schlussendlich blieb nur die Holzhammer-Methode. Ich verschob alle Konfigurationsdateien, welche auf meinen Linux-Installationen nicht existierten, von /opt/local/etc/postfix in den Unterordner _old. Schlussendlich sah das Verzeichnis so aus:

$ find /opt/local/etc/postfix/opt/local/etc/postfix
/opt/local/etc/postfix/_old
/opt/local/etc/postfix/_old/access
/opt/local/etc/postfix/_old/access.sample
/opt/local/etc/postfix/_old/aliases
/opt/local/etc/postfix/_old/aliases.sample
/opt/local/etc/postfix/_old/bounce.cf.default
/opt/local/etc/postfix/_old/canonical
/opt/local/etc/postfix/_old/canonical.sample
/opt/local/etc/postfix/_old/generic
/opt/local/etc/postfix/_old/generic.sample
/opt/local/etc/postfix/_old/header_checks.sample
/opt/local/etc/postfix/_old/LICENSE
/opt/local/etc/postfix/_old/main.cf.default
/opt/local/etc/postfix/_old/main.cf.proto
/opt/local/etc/postfix/_old/main.cf.sample
/opt/local/etc/postfix/_old/master.cf.proto
/opt/local/etc/postfix/_old/master.cf.sample
/opt/local/etc/postfix/_old/relocated
/opt/local/etc/postfix/_old/relocated.sample
/opt/local/etc/postfix/_old/TLS_LICENSE
/opt/local/etc/postfix/_old/transport
/opt/local/etc/postfix/_old/transport.sample
/opt/local/etc/postfix/_old/virtual
/opt/local/etc/postfix/_old/virtual.sample
/opt/local/etc/postfix/header_checks
/opt/local/etc/postfix/main.cf
/opt/local/etc/postfix/makedefs.out
/opt/local/etc/postfix/master.cf
/opt/local/etc/postfix/postfix-files
/opt/local/etc/postfix/sasl
/opt/local/etc/postfix/sasl/outgoing
/opt/local/etc/postfix/sasl/outgoing.db

In sasl/outgoing entfernte ich zudem den TCP-Port nach der Server-Adresse, und master.cf ergänzte ich mit Zeilen, die bisher nur unter Linux existierten.

Heureka

Und jetzt endlich kann ich mir von der Kommandozeile aus E-Mails senden. Hat nur geschlagene sechs Stunden gedauert.

Tags: , , , , , , , , , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 29. Juli 2017

postfix ausgehende E-Mails mit einem bestimmten Betreff automatisch verwerfen lassen

Link zu diesem Artikel

arpwatch und Apple-Geräte wie Apple TV und Time Capsules sind keine guten Freunde.

Überwacht man das lokale Netzwerk mit arpwatch und hat im selben Netzwerk einen Apple TV sowie mindestens eine Time Capsule stehen, wird man damit konfrontiert, dass die IP des Apple TVs (scheinbar, aus Sicht von arpwatch) konstant die MAC-Adresse wechselt.

Ich vermute Folgendes hinter diesem komischen Sympton: Geht der Apple TV schlafen, simuliert die Time Capsule den Apple TV und seine Funktionen irgendwie im Netzwerk — wahrscheinlich, damit man auf iOS-Geräten den Apple TV weiterhin „sieht“ und als AirPlay-Ziel anwählen kann. Erfolgt dann tatsächlich eine solche Anfrage, erweckt die Time Capsule den Apple TV irgendwie aus den Schlaf und das iOS-Device kann dann auf den Fernseher streamen. Man möge mich korrigieren, wenn ich (völlig) falsch liege.

Leider hat dieses Verhalten den unerwünschten Nebeneffekt, dass arpwatch konstant meine INBOX vollballert mit Meldungen zur Apple TV IP, welche ständig die MAC-Adresse zu wechseln scheint.

Da ich kein Netzwerkprofi bin und nicht C programmieren kann, verwehrt sich mir der Weg, arpwatch mit einer Funktion auszustatten, MAC-Wechsel von Apple-Geräten zu ignorieren.

Ich setze deshalb später in der Verarbeitungskette an und verwende einen Filter in postfix, um Mails mit einem bestimmten Betreff nicht mehr an mein Mailkonto weiterzuleiten. Dies ist ganz simpel, sofern man bereits eine funktionierende postfix-Installation am Laufen hat:

/etc/postfix/header_checks

/^Subject:.*flip flop \(apple-tv.domain.local\).*/ DISCARD

/etc/postfix/main.cf

...
header_checks = regexp:/etc/postfix/header_checks

Und Ruhe ist. Wenn man sich nicht sicher ist, ob postfix überhaupt etwas blockt, oder wenn man befürchtet, dass postfix zu viele Mails verwirft, hilft /var/log/postfix.log weiter:

$ cat /var/log/postfix.log | grep discard
...
Jul 27 22:41:23 SERVER postfix/cleanup[8564]: A8BCB1560312: discard: header Subject: flip flop (apple-tv.domain.local) from local; from=<root@SERVER>

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Februar 2017

ELK: Race Condition mit resolv.conf und WiFi

Link zu diesem Artikel

Seit einer Woche läuft auf einem Laptop bei mir zu Hause der ELK-Stack und sammelt per Syslog die Logs aller meiner Devices an drei Standorten. In unregelmässigen Abständen werde ich hier über Erkenntnisse berichten, die ich dank der zentralisierten Analyse der Logs gemacht habe.

Dank ELK fand ich auf Grund von postfix Log-Meldungen bald einmal heraus, dass mein Raspberry Pi 3, welcher ein Dashboard in unserer Wohnung antreibt, keine E-Mails versenden kann. postfix konnte den Hostnamen meines Mail-Providers nicht auflösen:

DASHBOARD postfix/error[1234]: ABCDEF: to=<log@domain.tld>, orig_to=<root@dashboard>, relay=none, delay=40662, delays=40584/78/0/0.27, dsn=4.4.3, status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=server41.cyon.ch type=A: Host not found, try again)

Nach einer längeren Debugging-Session dann die Erkenntnis:

The problem is that Postfix checks /etc/resolv.conf before the WiFi is connected. Therefore, /var/spool/etc/postfix/resolv.conf stays empty after the boot and mails cannot be sent.

Quelle: Postfix error: Host or domain name not found

Genau das war das Problem. Während der Kommentator auf Superuser empfiehlt, postfix erst nach der erfolgreichen WiFi-Verbindung zu starten, löste ich das Problem anderweitig, indem ich einen Cron-Job einrichtete:

...
*/1 * * * *	root	cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf
...

Sicherlich nicht sexy, aber es löst das Problem (und schafft eventuell einige andere).

Tags: , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. Juni 2013

Mit postfix über cyons SMTP E-Mails versenden

Link zu diesem Artikel

Wer wie ich zu Hause einen Linux-Server betreibt, benötigt manchmal auch die Möglichkeit, E-Mails zu versenden.

Mit folgenden Einstellungen versende ich mit Linux E-Mails über meinen schweizerischen Qualitätshoster cyon:

/etc/postfix/main.cf

...
relayhost = [server00.cyon.ch]
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = login
smtp_sasl_password_maps = hash:/etc/postfix/sasl/outgoing
smtp_sasl_security_options = noanonymous

Damit der Versand aber effektiv klappt, muss ich wie im Attribut smtp_sasl_password_maps angegeben noch die Zugangsdaten eines cyon-Mail-Kontos hinterlegen:

/etc/postfix/sasl/outgoing

[server00.cyon.ch] user@domain.tld:password

Bevor postfix zum ersten Mal gestartet wird, muss diese Datei gehasht werden:

# postmap /etc/postfix/sasl/outgoing

Damit wird eine neue Datei unter /etc/postfix/sasl/outgoing.db angelegt, welche von postfix beim nächsten Start eingelesen wird.

Test

Zu Testzwecken versende ich nun per Kommandozeile eine E-Mail:

$ echo "Bla" | mail -s "Test" user@domain.tld

WICHTIG: Es empfiehlt sich, im cyon-Control Panel eine dediziertes E-Mail-Konto anzulegen, welches nur dem E-Mail-Versand dient. Sollte der Server gehackt werden, kann sich der Angreifer so nicht im privaten E-Mail-Verkehr herumtummeln.

Die beiden Dateien /etc/postfix/sasl/outgoing und /etc/postfix/sasl/outgoing.db sollten zudem nur für den Besitzer lesbar gemacht werden:

# chmod 600 /etc/postfix/sasl/outgoing /etc/postfix/sasl/outgoing.db

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen