Postfix 2.0 bis 2.4: Was ist passiert? - Heinlein Support...Linux höchstpersönlich. Postfix 2.3/2.4 – 3. Mailserver Konferenz 2007 – Peer Heinlein SMTP und LMTP: Es wächst zusammen,

Linux höchstpersönlich.

Postfix 2.3/2.4 – 3. MailserverKonferenz 2007 – Peer Heinlein

Postfix 2.0 bis 2.4:Was ist passiert?

► Postfix wurde in den letzten Jahren fast täglich weiterentwickelt

► Gerade für den Spam und Virenschutz kamen viele schöne Funktionen dazu

► Trotzdem: Langsam kann Postfix alles, was man haben will... 2.0.0 2.1.0 2.2.0 2.3.0 2.4.00

25000

50000

75000

100000

125000

150000

175000

200000

225000

Postfix: Lines of Code

Version

Line

s of

cod

e



Postfix 2.2, 2.3, 2.4 und die Zukunft:Was kommt nun?

► Wietse Venema über den status quo von Postfix:

► In 2006, Postfix 2.3 was mostly complete. This was the result of a heroic effort to add enhanced status codes, DSN, and to make Postfix extensible with other SASL implementations, and last but not least extensible with Milters.

► In 2007, Postfix 2.4 added a few missing pieces to Milter support, and a few performance improvements that help highvolume sites.



Tausend tolle Sachen...Die vielen kleinen Änderungen



SMTP und LMTP: Es wächst zusammen, was zusammen gehört► LMTP wurde in das Modul „smtp“ integriert

► Das Modul ist in /usr/lib/postfix doppelt vorhanden.

► Fast alle smtp_*Parameter gibt es nun auch als lmtp_*Parameter► Viele neue Features für LMTP gratis dazu :):

SSL/TLS für LMTPShared Connection Caching für LMTP

► fallback_relay wurde zur Klarheit in smtp_fallback_relay umbenannt► Der alte Namen geht natürlich weiterhin.



Sender Dependend Relayhosts► Bislang gab es nur relayhost= und fallback_relay=

(bzw. smtp_relayhost= und smtp_fallback_relay=)► Problem 1: Manche Mailserver/Freemailer erlauben nicht die Einlieferung

fremder Absenderdomains.► Problem 2: Findet man SPF toll, ist OutboundRouting nötig.► [Man merke: SPF ist nicht toll. Aber das ist ein anderes Thema.]

► Nun ein neues Kommando für die main.cf:► sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay

► Die relayhost_maps ist eine klassische LookupTable: ► Erste Spalte: Absender Zweite Spalte: Relayhost

[email protected] [email protected] smtp.freeaildomain.local

mailto:[email protected]:[email protected]



Sender Dependent SASLAuthentication

► Sender Dependent Relayhosts erfordern ggf. auch unterschiedliche SASLLogindaten für jeden Nutzer► smtp_sender_dependent_authentication=yes aktiviert das Feature

► Postfix fragt die smtp_sasl_password_maps dann zuerst nach der SenderMailadresse ab, dann wie bisher nach Zielhost/Domain.

► Sender Dependend Authentication deaktiviert Connection Caching für diesen Zielhost

► Macht nix, große Freemailer haben unterschiedliche Hosts für UserSMTP und MXInbound



Pimp my Mailversand (1)

► Verbindungsauf und abbau kostet Kraft & Zeit:► TCP/IPHandhshake► DNSLookups► HELOKommando► (Wechsel zu SSL/TLS)

► ConnectionCaching nutzt vorhandene Verbindungen► max_conn_use=

► Neues Logfileformat:

Jun 16 18:48:40 ilpostino postfix/smtp[12532]: 6CC688C222: to=, relay=mxha01.web.de[217.72.192.149]:25, conn_use=2, delay=21, delays=0.85/19/0.02/0.6, dsn=2.0.0, status=sent (250 OK id=1HzbS30001sV00)►Jun 16 18:48:40 ilpostino postfix/smtp[12532]: 6CC688C222: to=, relay=mxha01.web.de[217.72.192.149]:25, conn_use=3, delay=21, delays=0.85/20/0.02/0.65, dsn=2.0.0, status=sent (250 OK id=1HzbS40001sV00)




► Alle smtpClientProzesse benutzen ein gemeinsames (shared) ConnectionCaching:► Nach Verbindungsende übergibt smtp die Verbindung an scache.► Sinnvoll: Der smtp gibt Verbindungen zu scache nur für Server, die noch viele

Mails in der Queue haben: smtp_connection_cache_on_demand = yes► Alternativ: smtp_connection_cache_destinations listet manuell zu cachende

Verbindungen. Syntax wie $mydestination: Direkte Liste oder lookupTable► scache hält die Verbindung maximal smtp_connection_cache_time_limit = 2s!► (Sendmail und Exim können kein shared caching...)

► Das neue scacheModul ist in der master.cf definiert:► scache unix n 1 scache




► (Shared) Connection Caching geht nicht bei SSL/TLSVerbindungen

► Alle connection_cache_status_update_time loggt scache seine Statistik:

► Domain lookup: Caching anhand RecipientDomain► Address Lookup: Caching über die IP des MXServers

Jun 16 13:56:08 ilpostino postfix/scache[4610]: statistics: start interval Jun 16 13:47:36Jun 16 13:56:08 ilpostino postfix/scache[4610]: statistics: domain lookup hits=6 miss=29 success=17%Jun 16 13:56:08 ilpostino postfix/scache[4610]: statistics: address lookup hits=0 miss=155 success=0%Jun 16 13:56:08 ilpostino postfix/scache[4610]: statistics: max simultaneous domains=13 addresses=13 connection=13



Analyse my Mailversand

► Postfix loggt einen neuen „delay“Wert: delays=a/b/c/d

► So kann genauer der Flaschenhals analysiert werden:► a=Zeit bis die Mail in der Queue war (d.h. inkl. Empfangszeit)► b=Zeit, die die Mail in der Queue war► c=Zeit für den Verbindungsaufbau (DNS, HELO und TLS)► d=Übertragungszeit für den Versand► a+b+c+d = delay

► Alle Angaben in Sekunden

Jun 16 18:48:40 ilpostino postfix/smtp[12532]: 6CC688C222: to=, relay=mxha01.web.de[217.72.192.149]:25, conn_use=2, delay=21, delays=0.85/19/0.02/0.6, dsn=2.0.0, status=sent (250 OK id=1HzbS30001sV00)



Was nicht passend ist, wird passend gemacht► Endlich wurden ein paar verwirrende Optionen der

Restrictions umbenannt:► reject_unknown_client => reject_unknown_client_hostname► reject_unknown_hostname => reject_unknown_helo_hostname► reject_invalid_hostname => reject_invalid_helo_hostname► reject_non_fqdn_hostname => reject_non_fqdn_helo_hostname

► Danke!

► Die alten Namen funktionieren weiterhin.



Die neue MilterSchnittstelle:Sendmail muß nicht immer schlecht sein...► Milter ist die Schnittstelle für FilterPlugins unter Sendmail

► milter ist ein prequeueFilter

► Postfix hat diese Implementiert => MilterPakete sind nun nutzbar

► Vorsicht: Postfix 2.3 ändert darum seine QueueStruktur!

► Update ist kein Problem

► Wenn Wechsel von >= 2.3 zurück (!) zu



Individuelle BounceTemplates

► Früher: Neukompilieren!

► Jetzt im Stile von HEREDokumenten gelöst:► bounce_template_file verweist

aus main.cf auf Vorlage► /etc/postfix/bounce.cf.default

dient als Beispiel

► Englische Fassung nicht vergessen!

► Deutsche Templates:► http://postfix.stateof

mind.de/bouncetemplates/

failure_template =



Und viele andere Kleinigkeiten

► RateLimiting für SSL_/TLSClients möglich► smtpd_client_new_tls_session_rate_limit

► Authentifzierungsbibliotheken per Plugin unterstützt► Neben CyrusSASL jetzt auch DovecotSASL & CO

► Postfix behält Groß/Kleinschreibungen in den verschiedenen LookupTables bei► canonical, virtual, relocated und generische LookupTables achten drauf► Weiterleitungen an [email protected] sind möglich

► Keine rekursiven Ersetzungen mehr per pcre/regexpTables!

► Grundlegende Überarbeitung/Erweiterung von SSL/TLS► Neue Sicherheitsstufen möglich; SSL/TLS ohne feste Zertifikate möglich

mailto:[email protected]



Enhanced Status Codes und

Delivery Status Notications im Detail



Enhanced Status Codes (ESN)

► Normale Fehlermeldungen können zu wenig Informationen über den Grund des Fehlers geben.

► Insb. automatische Auswertung der Bounces sind unmöglich

► DSN liefert ein großes Set definierter möglicher Fehler

► Auch Benachrichtigungen über erfolgreiche Zustellungen sind möglich.

X.2.0 Other or undefined mailbox statusX.2.1 Mailbox disabled, not accepting messagesX.2.2 Mailbox fullX.2.3 Message length exceeds administrative limit.

X.5.0 Other or undefined protocol statusX.5.1 Invalid commandaX.5.2 Syntax errorX.5.3 Too many recipientsX.5.4 Invalid command argumentsX.5.5 Wrong protocol version

X.7.0 Other or undefined security statusX.7.1 Delivery not authorized, message refusedX.7.2 Mailing list expansion prohibitedX.7.3 Security conversion required but not possibleX.7.4 Security features not supportedX.7.5 Cryptographic failureX.7.6 Cryptographic algorithm not supportedX.7.7 Message integrity failurec



Enhanced Status Codes (ESN):Warumwiesoweshalb?► SMTPCodes waren nicht eindeutig genug; genaue Codes sind

aber für Delivery Status Notifications (DSN) erwünscht► Aus alt...: 550 User unknown

Mach neu: 550 5.7.0 User unknown

► Diese können, müssen aber nicht ausgewertet werden; der SMTPCode klärt bereits die Fakten auf Zustellebene:► 2xx: Status Okay► 4xx temporärer Fehler► 5xx fataler / dauerhafter Fehler

► ESN sind derzeit eher auf inhaltlicher Ebene interessant, d.h. warum/wo/wie etwas nicht zugestellt wurde etc.



Enhanced Status Codes (ESN):Hier sind sie definiert!

► Der StatusCode hat drei Teile: classe . subject . detail► 2.x.x = Erfolg► 4.x.x = temporärer Fehler► 5.x.x = fataler Fehler

► Enhanced Status Codes stammen aus RFC 3463:http://www.faqs.org/rfcs/rfc3463.html



Enhanced Status Codes (ESN): So werden Sie benutzt.

► Die Codes können in access_maps, header/body_checks etc. benutzt werden:► [email protected] REJECT 5.7.1 You're not authorized to send this email

► soft_bounce=yes paßt auch die Enhanced Status Codes an► Aus 5.x.x wird 4.x.x

► Postfix korrigiert auch sender/recipientcodes:► Wird eine access_map für sender und recipientlookups gleichzeitig genutzt,

wird aus einem 5.1.4 (Bad destination mailbox address syntax) ggf. ein 5.1.7 (Bad sender's mailbox address syntax)

mailto:[email protected]



Delivery Status Notifications (DSN):Warumwiesoweshalb?► DSN machen die ESN für uns nutzbar

► Insgesamt vier Kategorien: success, failure, delay oder none► Default: delay, failure (also wie immer!)

► Absender kann angeben, über was er informiert werden will► Über eine Erweiterung des ESMTPBefehlssatzes► Über neue Parameter für /usr/bin/sendmail:

sendmail N success,delay,failure [...]

► DSN können auch vorgeben, welche Teile der Mail bei einem Bounce zurückgeschickt werden sollen► header oder body`



Delivery Status Notifications (DSN):Die EnvelopeID taggt Mails

► DSN implementiert auch eine EnvelopeID, die von Server zu Server weitergereicht und beim Bouncen zurückgeschickt wird

► So können unzustellbare Nachrichten beim Massenversand identifiziert werden

► Ersetzt alte VERPMechanismen – nicht verwechseln► Angabe wieder über erweiterten ESMTPBefehlssatz► Oder über neuen Parameter:

sendmail V [...]► Die EnvelopeID ist nicht identisch mit der MessageID!



Delivery Status Notifications (DSN):Die ESMTPErweiterungen► MAIL FROM und RCPT TO wurden optional erweitert:

► MAIL FROM: RET=[FULL|HDRS]Bei einem Bounce wird [alles|nur der Header] zurückgeschickt

► MAIL FROM: ENVID=“textid“Legt die EnvelopeID fest, die beim Bounce zur Identifizierung zurückgeschickt werden soll.

► RCPT TO: NOTIFY=[NEVER|SUCCESS,FAILURE,DELAY]Der Absender fordert DSN für (k)eine dieser Kategorien an

► RCPT TO: ORCPT=rfc2822;[email protected] den ursprünglichen Empfänger an, von dem aus weitergeleitet wurde („virtual“maps).

mailto:[email protected]:[email protected]:[email protected]:[email protected]



Delivery Status Notifications (DSN):So outet sich der Server► Die Fähigkeit zu DSN wird per ESMTP bekannt gegeben:

► Unter Umständen nerven DSNs jedoch oder sind unerwünschte Serverbelastung.

► Erfolgreiche Zustellbestätigungen ein Sicherheitsproblem sein!

220 peer.post.fix ESMTP PostfixEHLO mail.domain.local250peer.post.fix250PIPELINING250SIZE 10240000250VRFY250ETRN250ENHANCEDSTATUSCODES2508BITMIME250 DSN



Delivery Status Notifications (DSN):Selektiv an/abschalten► Einzelne DSNFeatures kann man nicht ausblenden.

► Also: Ganz oder gar nicht!► DSN sind nur möglich, wenn sich der Server nach EHLO outet!

► Global in /etc/postfix/main.cf: ► smtpd_discard_ehlo_keywords = silentdiscard, dsn

► Oder selektiv je nach Client:► smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_access

legt fest, für welche Netze kein DSN announct wird:

► Das Keywort „silentdiscard“ verhindert entsprechende Logmeldungen

/etc/postfix/esmtp_access:# DSN für 192.168.0.0/16 erlauben192.168.0.0/16 silentdiscard0.0.0.0/0 silentdiscard, dsn::/0 silentdiscard, dsn



Delivery Status Notifications (DSN):Das passiert, wenn sie geblockt werden

► Am ersten NichtDSNHost endet die Verfolgung.

► Nimmt man kein DSN am MXGateway an, wird der einliefernde Mailserver jedoch noch das erfolgreiche weiterrelayen zurückmelden.

► Dagegen ist sicherheitstechnisch aber nichts einzuwenden.

► Für den Absender ist i.d.R. aber ausreichend zu wissen, daß die Zustellung an das MXRelay erfolgreich war.

► Wann/wo/wie MXRelay in das Zielpostfach geschrieben hat, muß Absender nicht wissen.



Ja...und nun?► Update aufgrund verschiedener Performancezuwächse

durchaus erstrebenswert.

► Gerade auch die ESN/DSNUnterstützung sollte in unser aller Interesse sein.

► Postfix 2.4.x dürfte eine Basis sein, auf der man sich lange ausruhen kann. Ein Update jetzt macht auch für konservative UpdatePolitik Sinn.

► Aber grundsätzlich gilt natürlich: Wer keine Schmerzen hat, muß auch nicht krampfhaft neues ausprobieren.

► Grundsätzlich ist ein Update kein wirkliches Problem. Doch der Teufel steckt im Detail.

► Ihr wißt ja: Never change a running system



Für die, die nicht genug kriegen können

► Das PostfixBuch von mir bei Open Source Presshttp://www.postfixbuch.de

► Übrigens: Komplett überarbeitete 3. Auflage im späten Herbst.

► Hat dann alles, was man braucht und wissen muß:► Die ganzen neuen Features und Änderungen► Mehr LDAP► Richtig schön amavisdnew / SpamAssassin► Noch mehr Tipps und Best Practice mit vielen Empfehlungen aus der Praxis

► Die PostfixbuchMailingliste:http://listi.jpberlin.de/mailman/listinfo/postfixbuchusers



Für die, die konkrete Hilfe brauchen

► Wir sind die MailserverSchmiede:► Troubleshooting im Notfall► Consulting & Installation, auch ClusterInstallationen mit > 250.000 Nutzern► HA AntiSpam/VirenRelays► GroupwareLösungen und Migrationsstrategien

► 24/7 CompetenceCall mit LPIC2Admins: 030/40 505 110

► PostfixKurse an unserer Akademie oder inhouse bei Ihnen

► MailOutsourcing in unser Rechenzentrum



Was ich noch zu sagen hätte...

► Bei Fragen: Fragen!

► Und ansonsten: Danke für Eure Aufmerksamkeit und noch eine schöne weitere Konferenz!

Documents

Postfix 2.0 bis 2.4: Was ist passiert? - Heinlein Support...Linux höchstpersönlich. Postfix 2.3/2.4 – 3. Mailserver Konferenz 2007 – Peer Heinlein SMTP und LMTP: Es wächst zusammen,