Sendmail

Die wichtigste Komponente im modernen Mailsystem ist der Message Transfer Agent oder Mail Transfer Agent, kurz MTA. Verrichtete er früher, wenn ausreichend performant, eher unauffällig seine Arbeit als Routing-Instanz mit vorgeschalteter Relay-Kontrolle, besteht seine Hauptaufgabe am Gateway heute in der Spam-Abwehr. Sein Ziel dabei ist, die Zustellung unerwünschter E-Mails bereits am Eingang abzulehnen.

Damit befinden wir uns mitten im Spezialgebiet von Sendmail. Die Sendmail-eigenen Rulesets bieten umfangreiche Konfigurationsmöglichkeiten weit über Sendmails und die Standard-Features anderer MTAs hinaus. Die Checks können alle Informationen rund um Client, Absender und Empfänger sowie Header-Zeilen bewerten. Sie arbeiten damit ebenso flexibel wie ressourcenschonend. Für die Inhaltsfilterung können externe Programme (z. B. SpamAssassin oder diverse Virenscanner) über die Milter-Schnittstelle eingebunden werden.

Sendmail Standard-Features

Die normale Funktionalität (Routing und Relay-Kontrolle) eines MTAs inkl. erster einfacher aber wirkungsvoller AntiSpam-Maßnahmen kann in Sendmail einfach konfguriert werden, u.a.

  • Mailrouting (via MX oder Smart Host, statisch per Domain mittels Mailertable, nach LDAP etc.)
  • Relay-Kontrolle (Access-DB)
  • AntiSpam-Maßnahmen wie die FEATUREs 'require_rdns', 'badmx' oder 'block_bad_helo'
  • > die Einbindung von Real Time Blacklists (RBLs)
  • die Konfiguration von TLS/SSL und STARTTLS
  • > die Authentifizierung über SMTP AUTH (mittels SASL)

Individuelle Rulesets

Die große Stärke von Sendmail sind die sog. Rulesets. Jede FEATURE-Anweisung in der M4-Datei von Sendmail ergänzt die resultierende sendmail.cf um "ihre" Regeln. Zudem ist es möglich, der Konfiguration eigene Rulesets hinzuzufügen. Dafür bietet Sendmail sog. Hooks in fast jedes bestehende Ruleset an, z. B. für

  • > das Routing von E-Mails über einen Spamfilter nur für best. Domains oder Empfänger
  • den Einsatz von speziellen AntiSpam-Maßnahmen in Abhängigkeit von Authentifizierung, Absender, Empfänger, Client-IP oder bestimmter Header-Zeilen
    •  
      Beispiel: RBLs auf Empfänger-Basis 
      Der Einsatz von zumeist DNS-basierten Real Time Blacklists (RBLs) ist heute eine gängige Methode, Spamschleudern zu identifizieren und deren Zustellversuche abzuwehren.

      Pro Blacklist kommt eine Zeile in die Sendmail-Konfiguration:

      FEATURE(enhdnsbl, `ubl.rbleins.de', `"554 Mail from " $&{client_addr} " rejected"',,`127.0.0.5.')dnl
      FEATURE(enhdnsbl, `dip.rblzwei.de', `"554 Mail from " $&{client_addr} " rejected"',,`127.0.0.10.')dnl

      Fertig. Mails von Servern auf der Blacklist von ubl.rbleins.de (Return Code 127.0.0.5) oder der Blacklist von dip.rblzwei.de (Return Code 127.0.0.10) werden abgelehnt.

      Doch obwohl es sehr zuverlässige RBLs gibt, besteht immer die Möglichkeit der fehlerhaften Kategorisierung einzelner Server. Für einzelne Ihrer Empfänger können sie leicht Ausnahmen von der RBL-Prüfung in der Access-DB von Sendmail vornehmen.

      Dazu das Feature 'delay_checks' in der Sendmail-Konfiguration aktivieren (bitte die Nebenwirkungen von 'delay_checks' beachten, es verändert die Reihenfolge der Sendmail Checks):

      FEATURE(`access_db')dnl
      FEATURE(`delay_checks',`friend')dnl

      Damit können Sie Ausnahmen in die Access-DB schreiben:

      Spam:user1@sendmaid.org	FRIEND
      Spam:user3@sendmaid.org	FRIEND

      Wenn nun aber einige Ihrer Kunden einzelne der von Ihnen eingebundenen RBLs akzeptieren und andere nicht? Oder Sie Mails nur dann ablehnen wollen, wenn ein Client auf bspw. 2 von 4 verwendeten RBLs steht? Mithilfe von eigenen Sendmail-Rulesets können Sie Ihre Konfiguration noch flexibler gestalten. Speichern Sie die Entscheidungen Ihrer Benutzer in einer Datenbank, können sie von Sendmail jeweils aktuell abgefragt und verarbeitet werden.

      Das folgende Beispiel zeigt Sendmail-Regeln für die individuelle Verwendung von RBLs.

      Die Konfiguration hierfür erfolgt in der Access-DB. Pro RBL ist eine Zeile für den Empfänger einzutragen:

      UBL:user2@sendmaid.org SPAM
      DIP:user2@sendmaid.org SPAM
      DIP:user4@sendmaid.org SPAM

      Empfänger user4@sendmaid.org möchte ausschließlich die dynamischen IPs von dip.rblzwei.de blocken, während für user2@sendmaid.org beide RBLs konfiguriert sind.

      Die folgenden Sendmail-Regeln liefern das gewünschte Ergebnis:

      LOCAL_CONFIG
      Kput macro
      Kednsbl dns -R A -T<TMP> -r2

      LOCAL_RULESETS
      Local_check_relay
      R$* $: $(put {rbls} $@ $) $1
      # ubl.rbleins.de
      R$-.$-.$-.$- $: <$(ednsbl $4.$3.$2.$1.ubl.rbleins.de. $: OK $)> $1.$2.$3.$4
      R<127.0.0.5.> $+ $: $(put {rbls} $@ _UBL_ $) $1
      R<$+> $+ $: $2
      # dip.rblzwei.de
      R$-.$-.$-.$- $: <$(ednsbl $4.$3.$2.$1.dip.rblzwei.de. $: OK $)> $1.$2.$3.$4
      R<127.0.0.10.> $+ $: $(put {rbls} $@ $&{rbls}_DIP_ $) $1
      R<$+> $+ $@ OK

      Local_check_rcpt
      R$* $: < $&{rbls} > $1
      R<$* _UBL_ $*> $* $: $>E <$3> <?> <! UBL> <$3>
      R<SPAM> $* $#error $@ 5.7.1 $: "554 Mail from " $&{client_addr} " rejected"
      R<$+><$*> $: < $&{rbls} > $1
      R<$* _DIP_ $*> $* $: $>E <$3> <?> <! DIP> <$3>
      R<SPAM> $* $#error $@ 5.7.1 $: "554 Mail from " $&{client_addr} " rejected"
      R<$+><$*> $@ OK

      In 'Local_check_relay' wird beim Connect zunächst ermittelt, ob der Client auf den verwendeten Blacklists steht. Jeder Treffer wird mit "seinem" Schlüsselwort (im fiktiven Beispiel UBL oder DIP) in dem Macro $&{rbls} gespeichert. Auf dieses Macro wird in 'Local_check_rcpt' zurückgegriffen. Steht der Client auf einer der RBLs, wird hier für jeden Empfänger (RCPT TO: im SMTP-Protokoll) geprüft, ob die Mail für ihn abgelehnt werden soll oder nicht.

      Selbstverständlich können die Regeln weiter verfeinert werden, z.B. Domains oder immer gültige RBLs berücksichtigen. 

Milter-Schnittstelle

Die Sendmail Rulesets können eine Mail bis maximal auf Header-Ebene prüfen. Besonders geeignet sind sie für die Bewertung von Absender, Empfänger und Gegenstelle. Seit 2001 beinhaltet Sendmail die sog. Milter-Schnittstelle, über die externe Programme eingebunden werden können. Diese Programme können zusätzlich auf den Inhalt der Mail zugreifen und ihn, wie die gesamte Mail, auch verändern. Die Schnittstelle wird genutzt für

  • Checks, die eine Datenbank benötigen, z. B.
  • Inhaltsfilterung durch
  • Signierung und Verifizierung durch DKIM, DomainKeys, SPF

Mit den Sendmail-eigenen Rulesets und der integrierten Milter-Schnittstelle sind die Möglichkeiten von Sendmail nahezu unerschöpflich - zumindest im E-Mail-Bereich.