'block_bad_helo' benötigt 'delay_checks' oder auch nicht

Neulich kam vom Kunden die Frage, ob 'block_bad_helo' vielleicht nicht so ganz richtig funktioniert. Seit Sendmail 8.14.0 blockt das Feature Zustellversuche von Gegenstellen, die im HELO "unseren" oder unqualifizierte Namen angeben.

Der Kunde hatte 'block_bad_helo' in der sendmail.mc aktiviert

FEATURE(`block_bad_helo')dnl

 und erhielt auch entsprechende Logzeilen,

Sep 5 19:37:51 mailin sendmail[10839]: s85HbhIZ010834: ruleset=check_rcpt, arg1=<user@domain.com>;, relay=out.domain.com [xxx], reject=550 5.7.1 <user@domain.com>;... bogus HELO name used: 127.0.0.1

vermutete aber bald, dass Sendmail das Feature recht launenhaft verwendet. Mittels Telnet bestätigte sich der Verdacht, die Testmail wurde trotz Bad Helo akzeptiert:

ray:~ $ telnet mailin 25
Trying 192.168.30.10...
Connected to mailin.
Escape character is '^]'.
220 mailin ESMTP Sendmail 8.14.4/8.14.4; Thu, 6 Sep 2014 10:48:08 +0200
helo test
250 mailin Hello ray [192.168.200.11], pleased to meet you
mail from:<>
250 2.1.0 <>... Sender ok
rcpt to:<user@sendmaid.org>;
250 2.1.5 <user@sendmaid.org>;... Recipient ok

Die kurze Antwort (siehe auch Sendmail-Doku ab Version 8.14.1): 'block_bad_helo' benötigt zusätzlich das Feature 'delay_checks'.

Weiterlesen: 'block_bad_helo' benötigt 'delay_checks' oder auch nicht


Sendmail 8.14.9 veröffentlicht

Am 21. Mai 2014 wurde Sendmail 8.14.9 als Maintanance Release veröffentlicht.

Wichtigste Änderung ist ein Securtiy Fix gegen einen in CVE-2014-3956 beschriebenen Bug. In den Sendmail-Versionen vor 8.14.9 besteht ein Fehler (die Argumente sind vertauscht) in der Funktion sm_close_on_exec in der Datei conf.h, aufgrund dessen offene File Deskriptoren nicht geschlossen werden und nachgelagert ausgeführte Prozesse auf die offen gebliebenen Files zugreifen können. Evtl. auf einem Sendmail-Server befindliche lokale Benutzer könnten diesen Fehler für sich nutzen, sofern sie innerhalb der Mailzustellung selbst Programme (z. B. via procmail oder über den Mailer prog) ausführen dürften. Dieses ist eher in kleineren Installationen der Fall, in denen die Benutzer zugleich ihre Postfächer auf dem MTA haben. Sie wären dann in der Lage, allerhand Unsinn mit den von Sendmail für sie offen gelassenen Files (inkl. der SMTP-Verbindung) zu treiben.

Reine MTAs - ohne die beschriebenen lokalen Benutzer mit der Möglichkeit, eigene Programme ausführen zu dürfen - sind von dem Fehler nicht betroffen.

Referenzen:

1. http://www.sendmail.com/sm/open_source/download/8.14.9/?show_rs=1#RS

2. http://www.cvedetails.com/cve/CVE-2014-3956/


Perdition spricht ManageSieve

Ende 2013 veröffentlicht, gefällt die 2.x Version des Perdition Proxy vor allem durch die Unterstützung von ManageSieve (eingeführt in 1.19-rc1). Sieve ist eine Sprache zur Filterung von E-Mails, die insbesondere auf weit verbreiteten IMAP-Servern (wie Cyrus oder Dovecot) implementiert ist. ManageSieve ist ein Protokoll zur Verwaltung der Sieve Skripte auf Remote Servern sowohl durch die Benutzer selbst als auch durch Administratoren.

Dass dies nun auch über einen Proxy Server möglich ist, erleichtert verteilten Umgebungen den Umgang mit Sieve-Skripten. So können sich sieve-fähige Webmail-Server, die i. d. R. ohne genaue Ortskenntnisse agieren, schlicht mit dem Sieve Port des Proxies verbinden, er wird ihre Anweisungen dem richtigen Server übermitteln. Dies gilt natürlich auch für native Clients mit Sieve-Unterstützung wie z. B. Thunderbird mit entsprechendem Plugin.

Referenzen:

1. http://horms.net/projects/perdition/

2. http://tools.ietf.org/html/rfc5804