#!/bin/blog

September 27, 2012

Postfix: Rewrite the sender address of all mail

Filed under: Internet, UNIX/Linux/BSD — Tags: — martin @ 12:17 pm

OMG, I used to do mail for kings and queens. With properly crafted mail setups, meticulously built from the finest bits and bytes you can imagine.

But things have gone somewhat downhill from there. Now that I play the most general UNIX dude, I get this request far too often (talk about once every few weeks), and I’m not sure whether I have a proper solution for it or not. It goes like this:

“I have applications on the system, and I don’t know how, but they send mail, and I want all mail to be rewritten to a single from address. And please don’t try to tell me what you think good design looks like, but just get the damn job done.

So, the first approach was to add a pcre map in sender_canonical_maps with something like this, that matches every sender, as requested:

/.*/ godknowswhat@example.com

Directly from there, we tried to optimize away the sender_canonical file and its regex and came to this in main.cf:

sender_canonical_maps = static:godknowswhat@example.com

This actually leads to the same behaviour as it replaces any given sender with godknowswhat@example.com. Which, after a while, brought us to our first mail loop when Postfix had delivery problems and rewrote the empty bounce sender address (<>).

So now we are back to our pcre map for good, interestingly with just a single byte changed:

/.+/ godknowswhat@example.com

This rewrites all sender addresses to godknowswhat@example.com, but if a bounce appears, the sender address is not rewritten and the bounce can be delivered or at least double-bounce if it runs into additional failure.

September 2, 2010

Getting the Postfix MTA onto IPv6

Filed under: Internet — Tags: , — martin @ 6:45 am

This is simple. Postfix native IPv6 support was introduced in Version 2.2, which was released around the year 2005. So unless you are running an extremely outdated operating system, your Postfix MTA will be ready for IPv6. (Original Postfix IPv6 docs are here.)

The changes required to the Postfix main.cf are extremely basic:

# Tell Postfix to use IPv6:
inet_protocols = ipv4,ipv6
# Add the equivalents to your existing IPv4 setup to mynetworks
mynetworks = 127.0.0.1/32 1.2.3.0/24 [::1]/128 [2001:db8:dead:beef::]/64
# This will be required if you need to override an autoconfed address
# (for outbound connections):
smtp_bind_address6=2001:db8:dead:beef::deca:fbad

After this, stop and start Postfix. A postfix reload alone will not bind to the new IPv6 interface.

After local testing, set up an additional AAAA record for your mailexchanger:

   MX 10 mx.example.com.
mx A 1.2.3.2
; The new record:
mx AAAA 2001:db8:dead:beef::deca:fbad

Don’t forget that you must, as always, set up proper forward and reverse DNS for your MX. Implement this at the same risk as if you were moving to a new IPv4 address.

Not long after the AAAA record is in place, you should see the spambots trying to deliver mail via IPv6, and Postfix will start to use IPv6 for outbound e-mail automatically if it can find a remote IPv6 MX. Which will be the case rather sooner than later.

See? You may still be an early adopter now, but you surely aren’t a pioneer living on the most remote corner of the net. I, for one, now have customers who use proper IPv6 e-mail without even knowing. ­čÖé

May 16, 2009

Debian VMware woes

Filed under: UNIX & Linux — Tags: , , , , — martin @ 8:28 am

Had some trouble with Debian in VMware Server 2.0: I/O was horribly slow, 100% IOwait when doing the simplest things, hdparm showing 11MB/s throughput.

This was fixed by shutting down the VM, changing the SCSI adapter from Buslogic to LSI logic and booting up again. hdparm is at 63MB/s now. The machine, which will be an SMTP mail exchanger, now scans 8 mails per second (Postfix before-queue filter via amavisd-new+ClamAV) in 10 concurrent sessions. Not bad at all.

Debian is by far the simplest choice for an SMTP content filter because it’s not neccessary to bring in any dependencies by hand. Cool. ­čÖé

February 10, 2008

“Attempted master login with no master passdbs”

Filed under: UNIX & Linux — Tags: , , , , — martin @ 7:31 am

If you get this under some conditions while using dovecot for SASL authentication from the Postfix MTA, you’re using an outdated pre-release version of dovecot, like e.g. 1.0.rc15. This specific version is still included not only in CentOS and RHEL 5 but also in Debian 4.0 (etch). The error is caused by a bug that was already fixed in later pre-release versions.

I replaced the stock rpm from CentOS 5 with the current released dovecot 1.0.10 rpm from atrpms.net, which instantly fixed the problem.

Packages of dovecot 1.0.10 for Debian are available from backports.org.

January 25, 2008

Postfix 2.5.0

Filed under: Security — Tags: , , , — martin @ 7:22 am

Seit heute ist die Version 2.5.0 des Postfix-MTA verf├╝gbar. Das Feature, das mich am meisten interessiert, ist die M├Âglichkeit der Validierung von Serverzertifikaten anhand des Fingerprint.

Aus dem Changelog:

TLS (SSL) support was streamlined further, and provides a new
security level based on certificate fingerprints instead of CA
signatures.

Wo man vorher bei der Mailauslieferung ├╝ber Eintr├Ąge in tls_policy_maps gepr├╝ft hat, ob das gegnerische Zertifikat von einer bekannten CA signiert ist und auf einen Common Name aus einer bestimmten Domain ausgestellt ist:

example.com secure match=example.net

kann man nun auch selbstsignierte Zertifikate verwenden (oder Zertifikate, die von einer CA ausgestellt sind, mit deren Zertifizierungspolicy man nicht einverstanden ist) und den Fingerprint pr├╝fen:

example.com fingerprint
  match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1

Alle anderen Attribute des Zertifikats (insbesondere das Ablaufdatum) werden damit ignoriert.

Aus der Doku:

If certificate fingerprints are exchanged securely, this is the strongest, and least scalable security level. […] This may be feasible for an SMTP “VPN” connecting a small number of branch offices over the Internet, or for secure connections to a central mail hub. It works poorly if the remote SMTP server is managed by a third party, and its public certificate changes periodically without prior coordination with the verifying site.

Ich finde es wirklich ulkig, da├č hier von einem SMTP-VPN die Rede ist. Genau diesen treffenden Vergleich hat n├Ąmlich auch mal ein Kunde konstruiert, der im gro├čen Ma├čstab Secure Channel TLS einsetzt, um den Internet-Mailtraffic mit seinen Partnern abzusichern.

F├╝r die Verwendung im “Enterprise-Bereich” sollte die Pr├╝fung von Fingerprints aber in der Tat trotz des objektiv zu gewinnenden Sicherheitsvorteils genau auf den Pr├╝fstand gestellt werden. Schlampig arbeitende Gegenstellen mit Snake-Oil-Zertifikaten werden damit n├Ąmlich m├Âglicherweise erst recht zu weiterhin schlampiger Arbeit angehalten.

March 10, 2007

Postfix 2.3: Abgehend Server-Zertifikate pr├╝fen

Filed under: Internet — Tags: , , , , — martin @ 10:59 pm

Ausgangslage: Ein Internet-Mailgateway unter Postfix 2.3 soll ganz normal Mail an beliebige Gegenstellen im Internet ausliefern. F├╝r bestimmte Zieldomains soll sichergestellt werden, da├č Mails dorthin ausschlie├člich TLS-verschl├╝sselt ├╝bertragen werden.

Hier die Basiskonfiguration f├╝r TLS, ein Auszug aus der main.cf:
# TLS grunds├Ątzlich deaktivieren, Aktivierung erfolgt dann fallweise.
smtp_tls_security_level = none
# Auch wenn wir selbst kein TLS machen, wollen wir loggen, wenn
# Gegenstellen TLS anbieten.
smtp_tls_note_starttls_offer = yes
# Apropos Log; standardm├Ą├čig loggt Postfix ├╝berhaupt keine Infos zu
# TLS-Transaktionen.
smtp_tls_loglevel = 1
# In dieser Map tragen wir die Gegenstellen ein, mit denen wir nur per
# TLS kommunizieren wollen.
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# Und in diesem Verzeichnis sind die Zertifikate enthalten, von denen
# die Zertifikate der Gegenstellen signiert sein m├╝ssen, um als akzeptabel
# zu gelten.
smtp_tls_CApath = /etc/postfix/tls/cacerts.d

Zu beachten ist, da├č die im smtp_tls_CApath hinterlegten Zertifikate vor Verwendung gehasht werden m├╝ssen. Daf├╝r wird das Perl-Script c_rehash aus der OpenSSL-Distribution verwendet.

c_rehash `postconf -h smtp_tls_CApath`

(Falls der smtp-Client im chroot l├Ąuft, m├╝ssen die Zertifikate und die Links mit den Hashwerten dort ebenfalls vorhanden sein. Man kann das z.B. erreichen, indem man die Zertifikate in /var/spool/postfix/etc/postfix/tls/cacerts.d/ ablegt und das Verzeichnis dann per Symlink aus /etc/postfix/tls/ erreichbar macht. Oder man legt einen entsprechenden Kopierjob an. Der Fantasie des Lesers sind keine Grenzen gesetzt.)

Wie intensiv die Zertifikate bei abgehenden Verbindungen gepr├╝ft werden sollen, wird mittels smtp_tls_security_level festgelegt. Dar├╝berhinaus k├Ânnen in der ├╝ber smtp_tls_policy_maps referenzierten Datei /etc/postfix/tls_policy pro Zieldomain abweichende Policies definiert werden. Es lassen sich eine ganze Menge “Sicherheitsstufen” einstellen:

  • none: Es wird generell nicht verschl├╝sselt. Wenn der gegnerische Mailserver seine Verschl├╝sselungsbereitschaft anzeigt (STARTTLS im ESMTP-Greeting), wird dies ignoriert.
  • may: Wenn der gegenerische Mailserver STARTTLS anbietet, wird verschl├╝sselt, wenn nicht, dann nicht.
  • encrypt: Die Mail wird nur ├╝bertragen, wenn der gegnerische Mailserver STARTTLS anbietet und eine Verschl├╝sselung aufgebaut werden kann. Eine Pr├╝fung des Server-Zertifikats findet nicht statt. Selbstsignierte Zertifikate werden akzeptiert.
  • verify: Die Mail wird nur ├╝bertragen, wenn der gegnerische Server ein Zertifikat benutzt, das von einer CA ausgestellt wurde, deren Zertifikat im mit smtp_tls_CApath angegebenen Pfad enthalten ist.
  • secure: Die Mail wird nur ├╝bertragen, wenn der gegnerische Server ein Zertifikat benutzt, das von einer CA ausgestellt wurde, deren Zertifikat im mit smtp_tls_CApath angegebenen Pfad enthalten ist und bei dem der im Zertifikat eingetragene Common Name mit der Zieldomain ├╝bereinstimmt.

Als Default-Policy (smtp_tls_security_level) eignen sich ausschlie├člich “none” und “may”, denn mit “encrypt” und aufw├Ąrts wird man ein Gateway, das Mail ins Internet senden soll, nicht betreiben k├Ânnen. Ich habe mich im vorliegenden Fall f├╝r “none” entschieden, da ich in der von “may” gebotenen opportunistischen Verschl├╝sselung keinen Nutzen erkenne. Im Gegenteil: Opportunistische Verschl├╝sselung kostet mich nicht nur Rechenzeit, sondern es besteht potentiell die Gefahr, da├č Probleme bei der Kommunikation mit MTAs auftreten, bei denen TLS fehlerhaft konfiguriert und/oder implementiert ist.

Nun zu den Zielen, mit denen wir verschl├╝sselt kommunizieren wollen. Wenn man davon ausgeht, da├č keine Verschl├╝sselung besser ist als schlechte Verschl├╝sselung, kann man die Optionen “may” und “encrypt” in diesem Zusammenhang direkt vergessen:

  • Die opportunistische Verschl├╝sselung “may” bringt keinerlei Sicherheitsgewinn.
  • Kaum etwas anderes gilt f├╝r “encrypt”: F├╝r eine Gegenstelle Verschl├╝sselung zu erzwingen und dann jedes Zertifikat, egal ob abgelaufen oder selbstsigniert, zu akzeptieren, ist nur die Illusion von Sicherheit, gerade so, als w├╝rde man das routinem├Ą├čige Abklicken von SSL-Warnungen im WWW-Browser zum Standard erheben.

├ťbrig bleiben also “verify” und “secure”, von denen die letztere nat├╝rlich ganz besonders verlockend klingt und es auch ist:

  • Mit “verify” wird erzwungen, da├č Mail an eine Gegenstelle nur dann ausgeliefert wird, wenn deren Zertifikat von einer bekannten CA signiert wurde.
  • Mit “secure” wird nicht nur, wie bei “verify”, das Zertifikat ├╝berpr├╝ft, sondern es wird auch noch verlangt, da├č der Common Name des gegnerischen Zertifikats der Zieldomain entspricht. Alternativ kann auch eine Liste von Host- und Domainnamen angegeben werden, die als Common Names f├╝r die Zieldomain akzeptabel sind.

Hier also ein paar Beispiele f├╝r Eintr├Ąge in der tls_policy.

  • F├╝r die Domain binblog.de soll uns eine einfache ├ťberpr├╝fung des Zertifikats reichen:
    binblog.de verify

  • Die Mailexchanger der Domain example.com liegen alle in example.com (mx1.example.com und mx2.example.com), und wir wollen nur Zertifikate akzeptieren, die auf einen Hostnamen (Common Name) unter example.com ausgestellt sind:
    example.com secure

  • Der Mailexchanger der Domain scsy.de hat den Namen vortex.f00.net. In diesem Fall m├╝ssen wir, wenn wir den Common Name ├╝berpr├╝fen wollen, extra dazusagen, in welcher Domain er liegen bzw. welchen Namen er haben soll:
    scsy.de secure match=vortex.f00.net

Mit der in den letzten beiden Beispielen genannten “sicheren” ├ťberpr├╝fung von Zertifikaten stellen wir so weit wie m├Âglich sicher, da├č wir gegen DNS-Angriffe gesch├╝tzt sind: Wird uns ein gef├Ąlschter MX-Record untergeschoben, weigert sich Postfix, Mail an diesen auszuliefern. Wechselt die Domain den Besitzer und bekommt neue Mailexchanger, weigert sich Postfix ebenfalls, Mail dorthin auszuliefern, solange nicht entsprechende Konfigurations├Ąnderungen in der TLS Policy vorgenommen werden.

Wenn Postfix aufgrund einer Umstellung auf einer der Gegenseiten keine Mail ausliefern kann, werden die Mails ├╝brigens nicht gebounced, sondern im Rahmen der normalen Timeouts in der Queue behalten. Es bleibt also gen├╝gend Gelegenheit, auf ├ťberwachungen oder Useranrufe zu reagieren.

Diese gesamte Konfigurationsmethodik wurde von Postfix 2.2 zu Postfix 2.3 komplett ausgetauscht. Leider ist 2.3 bisher nur zu den wenigsten Distributionen durchgedrungen. Die Implementation in 2.3 ist aber so gelungen ausgefallen, da├č ich jedem, der sich auf diese Ebene begeben will, nur zum Upgrade raten kann.

Wer das alles viel zu ├╝berkandidelt findet: Die ├╝bern├Ąchste Postfix-Version, 2.5, wird voraussichtlich sogar die M├Âglichkeit haben, gezielt die Fingerprints von Zertifikaten pro Zieldomain anzugeben. Damit d├╝rfte dann wirklich das allerletzte DNS-Schlupfloch gestopft sein, und gleichzeitig k├Ânnen selbstsignierte Zertifikate verwendet werden.

Update am 21.3.: Hoffentlich werden hier jetzt keine Unwahrheiten mehr verbreitet. ­čśë

June 30, 2005

Schmalspuradmins wie wir

Filed under: Internet — Tags: , — martin @ 10:03 pm

Nachdem ich dieses Highlight jetzt zum x-ten mal in meinen Mails gesucht habe, hier jetzt ein f├╝r alle mal die kleine Entscheidungshilfe, die ein Kollege aus der PUG beim Googeln aufgetan hat, als er sich ├╝ber Alternativen zu Sendmail informieren wollte:

Wenn du Disco-Software haben willst, die sich irgendwelchen Modewellen unterwirft und auf Zuruf ├╝berfl├╝ssigen Bullshit implementiert, dann bist du bei postfix besser aufgehoben. Fragt sich
allerdings, wieso du dann nicht gleich Exchange einsetzt. Da kriegst du auch eine toll bunte Management Konsole mit Maus-Konfiguration. Genau richtig f├╝r Schmalspur-Admins deines Kalibers.

(Newsgroup-Posting, allerdings schon aus 2001)

Find ich immer noch super.

Create a free website or blog at WordPress.com.