Sendmail

Aus Knowledgebase
Version vom 13. Dezember 2010, 12:20 Uhr von PoC (Diskussion | Beiträge) (→‎Siehe auch: Redundanter Link weg)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Sendmail ist ein noch immer oft benutzter Mail Transfer Agent. Der folgende Artikel soll einen Überblick über die Konfiguration und Debugging von Sendmail ermöglichen. Der Schwerpunkt liegt hierbei auf dem vom Autor erstellten Debian-Package, die Konfiguration anderer Pakete unterscheidet sich teilweise in Automatismen und Betriebsart von Sendmail.

Grundlegendes

Sendmail kennt zwei Betriebsarten:

  • Standalone, Sendmail lauscht auf Port 25 (und ggfs. weiteren) und behandelt über Forks aus- und eingehende Mails, von der Annahme per SMTP bis zur Übergabe an den LDA (wie z. B. Procmail),
    • Vorteile: Sehr einfache und übersichtliche Konfiguration, keine nennenswerte Verzögerung in der Mailzustellung wegen separatem Queuerunner.
  • Secure, damit werden bestimmte Konfigurationsdaten doppelt vorgehalten. Der SMTP-Dienst läuft unter einem nichtprivilegierten Benutzer und legt eingehende Mails in der Queue ab, während ein Queuerunner diese Queue regelmäßig abarbeitet. Dieser Runner läuft als root, damit er lokale Postfächer bedienen kann.
    • Vorteile: Von Ferne ausnutzbare Sicherheitslücken beschränken sich auf den Benutzer, unter dem der SMTP-Dienst läuft (sicherer).

In der weiteren Betrachungsweise wird nur der erste Modus behandelt.

Arbeitsweise

Sendmail nimmt per SMTP oder per lokalem Aufruf Mails entgegen und erzeugt für diesen Vorgang einen Kindprozess. In dieser Phase wird bereits anhand verschiedener Parameter entschieden, ob die Mail überhaupt angenommen wird (dargestellte Reihenfolge willkürlich):

  • ist der eigene Host überhaupt als MX im DNS gelistet (relay_based_on_MX),
  • hat die per SMTP verbundene Gegenseite eine saubere DNS-Konfiguration (require_rdns),
  • ist die Domain des Absenders in irgend einer Form auflösbar via A oder MX-Records,
  • hat der Absender eine Domain angegeben oder nur den Namen (links vom @),
  • ist für die Empfängerdomain lokale Zustellung bzw. Relaying erlaubt (local-host-names, access_db),
  • ist für den lokalen Empfänger (links vom @) Zustellung erlaubt, bzw. existiert der Benutzer oder ein Alias in irgend einer Form (blacklist_recipients)
  • Der Load der Maschine liegt unter einem festgelegten Schwellwert (Default: 12), siehe auch confQUEUE_LA und confREFUSE_LA.
  • Ggfs. weitere Checks, falls angegeben (Ratelimiting, Plattenplatz, DNSBL, Milter für Antispam und Antivirus), …

Sind alle Checks abgearbeitet, wird die Mail angenommen und in der Queue /var/spool/mqueue abgelegt, gesplittet in eine Steuerdatei (Qf…) und die Datendatei (df…). In der Queue liegende Mails können einfach mit mailq eingesehen werden. Falls Sendmail ausserhalb des festgelegten Intervalls nochmals die Queue abarbeiten soll, kann das mit sendmail -q forciert werden.

In beim Start angegebenen Intervallen (/etc/default/sendmail, z. B. -q10m alle 10 Minuten) wird die Queue abgearbeitet und versucht, in der Queue liegende Mails zuzustellen. Relevante Konfigurationsdateien sind hier /etc/passwd (lokale Benutzer), /etc/mail/mailertable, /etc/mail/virtusertable, /etc/mail/aliases sowie /etc/mail/local-host-names.

Debugging

Für jede Transaktion, wird eine Zeile an Syslog übergeben. Eine Transaktion kann sein:

  • das Annehmen oder Ablehnen von Mails,
  • Zustellung einer Mail aus der Queue an das festgelegte Ziel.

In Syslog sieht das dann so aus:

Dec 11 16:06:00 leela sendmail[13290]: oBBF5xLw013290: from=<apps+kr4mnrqaykyn@facebookappmail.com>,
   size=4726, class=0, nrcpts=1, msgid=<c1e8a8595c9196993fa2ce92fef0ca1c@api.facebook.com>, proto=ESMTP,
   daemon=MTA, relay=outmail003.snc4.facebook.com [66.220.144.135]
Dec 11 16:06:09 leela sendmail[13450]: oBBF5xLw013290: to=localuser2, delay=00:00:10, xdelay=00:00:00,
   mailer=local, pri=35226, dsn=2.0.0, stat=Sent

Mit dem Aufruf sendmail -bv mail@address.com kann festgestellt werden, über welche Wege Sendmail eine Mailzustellung vornehmen würde. Zwischenschritte wie Aliasauflösung usw. werden standardmäßig nicht dargestellt.

server ~ # sendmail -bv root
poc... deliverable: mailer local, user poc
server ~ # sendmail -bv info@leitwerk.de
info@leitwerk.de... deliverable: mailer relay, host [exchange.app.leitwerk.de], user info@leitwerk.de
server ~ # sendmail -bv testuser@googlemail.de
testuser@googlemail.de... deliverable: mailer esmtp, host googlemail.de, user testuser@googlemail.de

Diese Tests können auch in die Irre führen: Wenn eine Konfigurationsänderung vorgenommen wurde, Sendmail aber zwischenzeitlich nicht neu gestartet wurde (sofern notwendig), funktioniert der manuelle Aufruf, eine versandte Testmail triggert Fehler.

Konfiguration

Die Konfiguration von Sendmail erfolgt grundlegend in /etc/mail/, in mehreren Konfigurationsdateien. Die Konfiguration ist in mehreren Arten von Dateien abgelegt, nämlich in

  • Hashtabellen, die bei jeder Transaktion gelesen werden und bei Änderungen daher keinen Neustart von Sendmail bedingen. Dafür müssen diese Dateien aus einer Textdatei nach Änderungen der Textdatei mit dem makemap-Kommando neu erzeugt werden. Beispiele: access, mailertable.
  • Normalen Konfigurationsdateien, die nur bei einem Sendmail-Neustart eingelesen werden und dann im Speicher vorgehalten werden. Beispiele: local-host-names, trusted-users.
  • Der eigentlichen Sendmail-Konfigurationsdatei sendmail.cf. Sie referenziert alle anderen Konfigurationsdateien und ist nicht dafür gedacht, von Menschen gelesen und bearbeitet zu werden.[1] Das ist auch gar nicht notwendig: Bearbeitet wird die Vorlagendatei sendmail.mc, aus dieser wird über einen komplexen Mechanismus aus Includes und Makros (m4) die eigentliche Konfigurationsdatei erzeugt.

Dadurch, dass die Konfigurationsdateien aus der sendmail.cf direkt referenziert werden, können diese in aller Regel nicht als existent vorausgesetzt werden. Selbst die Namensgebung muss nicht mit dem, was man so kennt übereinstimmen. Zudem bedeutet die bloße Existenz einer dieser Dateien nicht, dass sie von der sendmail.cf auch referenziert wird. Hier ist Sauberkeit und Vorsicht geboten, um später nicht über scheinbar obskure Fehler zu stolpern.

Sendmail.mc

Diese Datei ist in mehrere Abschnitte gegliedert:

  • Ostype,
  • Domain,
  • Feature(s),
  • Mailer definitionen.

Je nach dem, welche Optionen hier aufgenommen werden, werden weitere externe Dateien referenziert oder bestimmte Verhaltensweisen von Sendmail aktiviert. Eine Beispieldatei sieht so aus:

include(`/usr/share/sendmail/m4/cf.m4')dnl
OSTYPE(`linux')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA, Family=inet6, M=E')dnl
DAEMON_OPTIONS(`Port=submission, Name=MSA, Family=inet6, M=Ea')dnl
CLIENT_OPTIONS(`Family=inet6, Addr=2001:6f8:1296:1:210:18ff:fe06:7c06')dnl
DOMAIN(`generic')dnl
FEATURE(`no_default_msa',`dnl')dnl
FEATURE(`always_add_domain')dnl
FEATURE(`access_db')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`mailertable')dnl
FEATURE(`virtusertable')dnl
FEATURE(`relay_based_on_MX')dnl
FEATURE(`use_ct_file', `/etc/mail/trusted-users')dnl
FEATURE(`dnsbl',`ix.dnsbl.manitu.net',`"554 Rejected " $&{client_addr} " found in ix.dnsbl.manitu.net"')dnl
FEATURE(`delay_checks')dnl
HACK(`require_rdns')dnl
INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass/spamass.sock, F=T,T=S:4m;R:4m;E:10m')dnl
include(`m4/clamav-milter.m4')dnl
define(`confMILTER_MACROS_ENVRCPT',`r, v, Z, b')dnl
define(`confMILTER_MACROS_EOM', `{msg_id}, {mail_addr}, {rcpt_addr}, i')dnl
define(`confTO_QUEUEWARN', `1d')dnl
define(`UUCP_MAILER_MAX', `0')dnl
define(`confPRIVACY_FLAGS', `goaway')dnl
define(`confAUTH_OPTIONS', `A')dnl
TRUST_AUTH_MECH(`GSSAPI PLAIN LOGIN')dnl
define(`confAUTH_MECHANISMS', `GSSAPI PLAIN LOGIN')dnl
define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile')dnl
define(`CERT_DIR', `/etc/ssl')dnl
define(`confCACERT_PATH', `CERT_DIR/certs')dnl
define(`confCACERT', `CERT_DIR/certs/ca-certificates.crt')dnl
define(`confSERVER_CERT', `CERT_DIR/certs/leelaCert.pem')dnl
define(`confSERVER_KEY', `CERT_DIR/private/leelaKey.pem')dnl
define(`confCLIENT_CERT', `CERT_DIR/certs/leelaCert.pem')dnl
define(`confCLIENT_KEY', `CERT_DIR/private/leelaKey.pem')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl
MAILER(`uucp')dnl
  • Über die erste Zeile include wird der komplette Makrozweig geladen, diese Zeile ist beim genannten Paket unabdingbar wichtig.
  • Über die Daemon-Options wird Sendmail IPv6-fit gemacht.
  • Die Client-Option dient dazu, Sendmail zu zwingen, mit einer bestimmten Absenderadresse zu versenden.
  • Die Bedeutung der übrigen Statements kann in der oben genannten README-Datei nachgelesen werden.

Diese Konfiguration erlaubt grundlegend kein Relaying, es sei denn, im DNS ist der eigene Hostname als MX hinterlegt. Das erspart dem Administator, hier extra noch im Mailsystem herumzukonfigurieren (relay_based_on_MX). Ausnahmen können über die access_db definiert werden.

Bedeutung der Konfigurationsdateien

access_db
/etc/mail/access, Hashtabelle zur generellen Zugriffssteuerung, vergleichbar zu den Qmail-Konfigurationsdateien relaydomains, tcprules.d/qmail-smtpd und teilweise smtproutes (SMTP-Auth für den SMTP-Client).
ct_file
/etc/mail/trusted-users, Textdatei, in welcher lokale Benutzer referenziert werden, die sich als andere Benutzer ausgeben dürfen, ohne dass eine entsprechende Warnung in die Mailkopfzeilen eingebaut wird. Z. B. für Mailinglistensoftware oder Webmailsoftware notwendig.
mailertable
/etc/mail/mailertable, Hashtabelle zur Verteilung Mails über die definierten Mailer, sofern der Default (MX-Lookup) nicht erwünscht ist. Für SMTP-Zielhosts, die nicht in eckigen Klammern stehen, wird trotzdem ein MX-Lookup vorgenommen und das Ergebnis zur Zustellung benutzt! Vergleichbar zur Qmail-Konfigurationsdatei smtproutes.
virtusertable
/etc/mail/virtusertable, Hashtabelle zur Verteilung von Mailadressen an lokale Benutzer. Damit kann info@domain1.de an z. B. infobla1 zugestellt werden, während info@domain2.de an infobla2 zugestellt wird. In den aliases oder als Benutzer selbst darf info nicht angelegt sein, weil diese Mechanismen Vorrang haben. Vergleichbar zur Qmail-Konfigurationsdatei virtualdomains.

In der Konfiguration implizit enthalten sind:

aliases
/etc/mail/aliases, Hashtabelle zur Verteilung von Mails an einen anderen oder mehrere Empfänger. Kann als einzige Tabelle einfach mit newaliases neu aufgebaut werden. Vergleichbar zu /var/qmail/aliases/.
local-host-names
/etc/mail/local-host-names, zusätzlich zu dem eigenen Hostnamen als lokal (für die eigenen Benutzer) anzusehenden Domains. Vergleichbar zur Qmail-Konfigurationsdatei locals.
service.switch
Konfigurationsdatei zum von Sendmail benutzten Name Service, unabhängig von der vom Betriebssystem vorhandenen Einstellung in /etc/nsswitch.conf.

Details zur Konfiguration können in /usr/share/sendmail/README nachgelesen werden.

Milter

Milter sind Programme, die als Mail Filter fungieren und üblicherweise über Unix Domain Sockets an Sendmail andocken. Siehe oben als Beispiel die Einbindung von Spamassassin über spamass-milter, während Clamav über die vorgefertigte /etc/mail/m4/clamav-milter.m4 eingebunden wird:

INPUT_MAIL_FILTER(`clamav', `S=local:/var/run/clamav/clamav-milter.ctl, F=, T=S:4m;R:4m')dnl

Details zur Einbindung sind in der jeweiligen Dokumentation der Milter nachzulesen, ob weitere Parameter notwendig sind, wie z. B. confMILTER-Parameter.

Fußnoten

  1. Auch wenn die sendmail-Literatur das immer wieder suggeriert.

Siehe auch

Weblinks