IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Postfix (Seite 4 von 5)

Outlook Autodiscover für IMAP/SMTP: Wie die automatische Kontoeinrichtung funktioniert

Benutzer wollen ihr E-Mail-Postfach einrichten. Sie geben E-Mail-Adresse und Passwort ein — den Rest soll der Client erledigen. Bei Exchange mit Active Directory funktioniert das seit Jahren automatisch. Aber was, wenn der Mailserver Postfix und Dovecot heißt und kein Exchange in Sicht ist?

Microsoft Outlook unterstützt auch für IMAP und SMTP die automatische Konfiguration per Autodiscover. Man muss nur wissen, wo Outlook nachschaut — und dort die richtigen Antworten bereithalten.

Outlook Autodiscover für IMAP und SMTP – automatische Mailkonto-Konfiguration über DNS, HTTPS und XML

Wo Outlook nach der Konfiguration sucht

Outlook arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig. Schlägt ein Schritt fehl, geht es zum nächsten:

1. Active Directory (SCP) — Ist der Rechner Domänenmitglied, fragt Outlook per LDAP nach einem Service Connection Point. Dort steht normalerweise die URL des Exchange-Servers. Für reine IMAP-Setups irrelevant.

2. HTTPS auf der E-Mail-Domain — Outlook versucht https://example.org/autodiscover/autodiscover.xml. Funktioniert nur, wenn der Webserver der Domain den Pfad bedient.

3. HTTPS auf autodiscover.<domain> — Outlook versucht https://autodiscover.example.org/autodiscover/autodiscover.xml. Das ist der Weg, den wir nutzen. Ein Webserver unter diesem Hostnamen mit gültigem TLS-Zertifikat — mehr braucht es nicht.

4. HTTP-Redirect — Outlook versucht http://autodiscover.example.org/autodiscover/autodiscover.xml und folgt einem 301/302-Redirect. Weniger sicher, aber ein Fallback.

5. DNS SRV-Record — Outlook fragt _autodiscover._tcp.example.org und folgt dem SRV-Eintrag. Bei einem SRV-Verweis auf eine andere Domain zeigt Outlook eine Sicherheitsabfrage: „Konfiguration von dieser Webseite zulassen?“ Einmalig bestätigen, danach läuft es.

6. Lokale XML-Datei — Outlook sucht auf dem Rechner nach einer vorinstallierten Konfigurationsdatei. Für Firmenumgebungen mit Software-Verteilung relevant.

7. Manueller Assistent — Wenn nichts funktioniert hat, öffnet Outlook den Konfigurationsassistenten. Genau das wollen wir vermeiden.

Was Outlook per POST schickt und erwartet

Outlook macht einen HTTP-POST auf /autodiscover/autodiscover.xml und schickt im Body ein XML mit der E-Mail-Adresse des Benutzers:

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
  <Request>
    <EMailAddress>benutzer@example.org</EMailAddress>
    <AcceptableResponseSchema>
      http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a
    </AcceptableResponseSchema>
  </Request>
</Autodiscover>

Die Antwort enthält IMAP- und SMTP-Einstellungen. Der Clou: Weil Outlook die E-Mail-Adresse im POST mitschickt, kann ein PHP-Script sie auslesen und als <LoginName> in die Antwort einsetzen. Ohne diesen Trick würde Outlook nur den Teil vor dem @ als Benutzernamen verwenden — bei Mailservern, die die volle E-Mail-Adresse als Login erwarten, ein Problem.

Multi-Domain per DNS SRV-Record

Ein Autodiscover-Webserver reicht für beliebig viele Maildomains. Jede zusätzliche Domain braucht nur einen SRV-Record im DNS:

_autodiscover._tcp.example.org.  IN SRV 0 0 443 autodiscover.kernel-error.de.

Outlook folgt dem SRV-Record, zeigt einmalig die Sicherheitsabfrage, und hat danach die komplette Konfiguration. Das PHP-Script auf dem Zielserver beantwortet Anfragen für alle Domains — die E-Mail-Adresse kommt ja im POST mit.

Umsetzung und aktuelle Konfiguration

Die konkrete Einrichtung — nginx-Konfiguration, PHP-Script und DNS — beschreibe ich im Nachfolgebeitrag: Outlook Autodiscover für IMAP und SMTP konfigurieren. Dort steht auch das Update von 2026 mit den Korrekturen am PHP-Script (GET-Absicherung, XSS-Schutz) und der Zusammenlegung mit Thunderbird Autoconfig.

Wer seine Konfiguration testen will: Microsoft bietet unter testconnectivity.microsoft.com den „Microsoft Remote Connectivity Analyzer“ an. Dort den Autodiscover-Test auswählen und die eigene E-Mail-Adresse eingeben.

Fragen? Gerne per Kontaktformular.

Postfix nach hause telefonieren

Ich war mal wieder auf so einem lustigen Postfixvortrag… Die verschiedenen Möglichkeiten der Spamabwehr waren natürlich wieder Thema. Der Vortragende ist dabei tierisch auf sender adress verification abgegangen. Er hat es quasie als Lösung aller Probleme verkauft. Puhh, ich habe mich bald an der Mate verschluckt. Ich mein… OK in ganz besonderen Fällen kann es möglicherweise helfen (mir fallen zwar gerade keine ein aber…) und früher ging da vielleicht mal was. Im Grunde macht diese Art der „Spamabwehr“ nur Stress.

Sender adress verification / callback verification / callout verification???

Versucht jemand eine E-Mail einzuliefern, versucht Postfix vor der Annahme der E-Mails zuerst selbst eine E-Mail an den Absender zuzustellen. Klappt dieses nimmt er die E-Mail an und wenn es nicht geht, dann nicht. Kommt also eine E-Mail vom Absender: spam@spamgott.net versucht Postfix diesem Absender eine E-Mail zuzustellen. Es wird also geprüft ob es die Domain überhaupt gibt, dann wird geschaut ob es einen MX-RECORD gibt, dann wird versucht eine Verbindung zu diesem Server aufzubauen. Ist es nicht möglich würde Postfix die jeweilige Meldung an den einliefernden „durchreichen“. Damit würden E-Mails nicht abgewiesen nur weil der Maileingangsserver des vermeintlichen Absenders gerade Stress hat oder dort Greylisting aktiviert ist. Wäre es möglich eine E-Mail einzuliefern wird die E-Mail erst überhaupt angekommen und die Absenderadresse in folgender Datei abgelegt:

/var/lib/postfix/verify_cache.db

Aktiviert wird der ganze Foo in der Postfix Konfigurationsdatei /etc/postfix/main.cf:

smtpd_recipient_restrictions =
….........,
reject_unverified_sender,
….........,

Klingt alles erst einmal ganz gut, oder? Ne überhaupt nicht…. Die Idee ist nett aber wenn man sich nun mal vorstellt eine Domain wird zum versenden von Spam missbraucht, dann schlagen bei diesem Server nicht nur die ganzen Bounce E-Mails auf, sondern zusätzlich noch der ganze Verification Krims. Es soll auch Absender geben die man wirklich nicht erreichen kann (sinnfrei, ist mir auch klar). Diese E-Mails kommen natürlich nicht an…. Versucht immer mal wieder jemand E-Mails an Empfänger zuzustellen, welche es nicht gibt, machen Mailserver gerne mal für eine gewisse Zeit dicht. Was ebenfalls nicht gut ist.

Und mal im Ernst, niemand will wirklich Strom, Traffic und Hardwareleistung bezahlen für den Mist. Wenn man sich einfach nur unnötige Last auf sein System ziehen will, wäre SETI@home mein Tipp! Mit etwas Hirnschmalz in seine Konfiguration gibt es deutlich bessere und effektivere Möglichkeiten. Dieser Weg ist einfach mal wieder der Versuch die Arbeit anderen aufzuhalsen.

Siehe auch: SPF-Record einrichten

Fragen? Einfach melden.

Postfix und AMaViS: content_filter oder smtpd_proxy_filter?

AMaViS ist eine bewährte Lösung, um eingehende E-Mails nach Viren und Spam zu filtern. Was viele nicht wissen: Es gibt zwei grundverschiedene Wege, AMaViS an Postfix anzubinden. Die meisten HowTos beschreiben content_filter. Es gibt aber auch smtpd_proxy_filter, und der ist mein persönlicher Favorit.

content_filter: Erst annehmen, dann filtern

Postfix nimmt die Verbindung vom einliefernden Mailserver an und empfängt die komplette E-Mail. Der einliefernde Server bekommt ein „OK, E-Mail erhalten“ und baut die Verbindung ab. Postfix speichert die Nachricht zwischen und schiebt sie an AMaViS weiter. Hat AMaViS gerade alle Hände voll zu tun, versucht Postfix es einfach immer wieder.

Erkennt AMaViS die E-Mail als Spam oder Virus, passiert je nach Konfiguration: Info an Absender/Empfänger, Quarantäne, Tagging, oder die Nachricht verschwindet einfach. In jedem Fall hat Postfix die Nachricht zu diesem Zeitpunkt bereits angenommen und die Verantwortung übernommen.

smtpd_proxy_filter: Filtern vor der Annahme

Hier leitet Postfix die E-Mail während der SMTP-Session direkt durch AMaViS. Der einliefernde Server bekommt nicht einfach ein „OK“, sondern die durchgereichte Antwort von AMaViS: „Nein, das ist Spam“ oder „Virus im Anhang, abgelehnt“. Unser Mailsystem nimmt die E-Mail nur an, wenn AMaViS nichts dagegen hat.

Das bringt uns rechtlich auf eine andere Seite. Man kann uns nicht nachsagen, dass wir eine anvertraute Nachricht unterdrückt oder vorenthalten hätten. Wir haben die Nachricht nie angenommen.

Die Nachteile

AMaViS braucht zur Bewertung Zeit. Genau diese Zeit halten wir den einliefernden Mailserver fest und die Verbindung offen. Das kostet Ressourcen. Über diesen Weg können weniger E-Mails gleichzeitig angenommen werden als wenn Postfix sie erst zwischenspeichert. Mehr Leistung bedeutet mehr parallele AMaViS-Prozesse.

Ist gerade kein AMaViS-Prozess frei, wird die E-Mail nicht abgewiesen. Postfix liefert einen temporären Fehler (4xx), und der einliefernde Server probiert es später noch einmal. Das ist normales SMTP-Verhalten.

Konfiguration

In /etc/postfix/master.cf die Anbindung über smtpd_proxy_filter statt content_filter einrichten:

smtp inet n - - - 100 smtpd
    -o smtpd_proxy_filter=127.0.0.1:10024

amavis unix - - n - 6 smtp
    -o smtp_data_done_timeout=1800
    -o smtp_send_xforward_command=yes
    -o disable_mime_output_conversion=yes
    -o disable_dns_lookups=yes

127.0.0.1:10025 inet n - - - - smtpd
    -o content_filter=
    -o smtpd_proxy_filter=
    -o local_recipient_maps=
    -o smtpd_authorized_xforward_hosts=127.0.0.0/8
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_data_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks

In /etc/postfix/main.cf die alte content_filter-Anbindung auskommentieren:

#content_filter = smtp-amavis:[127.0.0.1]:10024
#receive_override_options = no_address_mappings

Stolperfalle: receive_override_options

Wichtig: Auch receive_override_options = no_address_mappings muss auskommentiert werden. Sonst schaut Dovecot bei der lokalen Zustellung nicht nach virtuellen Alias-Einträgen. Die E-Mails werden dann mit „user unknown“ zurückgewiesen:

postfix/pipe[18488]: 5FC6EE20C1:
  to=<kernel-error@kernel-error.com>, relay=dovecot,
  dsn=5.1.1, status=bounced (user unknown)

Dovecot findet den User nicht in der SQL-Tabelle, weil Postfix die Alias-Auflösung übersprungen hat. Ohne no_address_mappings löst Postfix den virtuellen Alias zuerst auf, und Dovecot bekommt den richtigen Usernamen.

Wer inzwischen auf rspamd umgestiegen ist: rspamd arbeitet standardmäßig als Milter, was die Proxy-vs-Content-Filter-Frage komplett eliminiert. Als Milter prüft rspamd die E-Mail während der SMTP-Session, genau wie smtpd_proxy_filter, aber ohne den Umweg über einen zweiten SMTP-Dienst.

Fragen? Einfach melden.

Die vergessenen abuse und postmaster Adressen

Für jede Domain, die E-Mail empfängt, muss es eine postmaster@ und eine abuse@ Adresse geben. E-Mails an diese Adressen müssen angenommen werden, und jemand sollte sie auch lesen. Geregelt ist das in RFC 5321 und RFC 2142.

Wofür die Adressen da sind

postmaster@domain.tld ist für technische Fragen zum Mailsystem. Wenn jemand Probleme hat, E-Mails an eine Domain zu schicken, wendet er sich an den Postmaster. Im schlechtesten Fall sitzt dort ein Mensch, der die Nachricht an den richtigen Admin weiterleiten kann.

abuse@domain.tld ist für Missbrauchsmeldungen. Wird die Domain zum Spam-Versand missbraucht, schreibt man an abuse. Eine Abuse-Adresse findet sich auch im WHOIS der meisten IP-Netze.

Warum das in der Praxis scheitert

Immer wieder kommen Beschwerden bei mir an, weil E-Mails an gehostete Domains abgewiesen werden. Also sucht man den Grund, findet ihn im Reject (Blockliste, fehlender Reverse-DNS, dynamische IP) und schreibt dem Postmaster der Absenderdomain. Vier Sekunden später kommt die Antwort: „Postfach nicht gefunden“ oder „Mailbox voll“.

Die Adressen existieren nicht, oder niemand liest sie. Das ist nicht nur ein Verstoß gegen die RFCs. Es macht die Fehlersuche für alle Beteiligten unmöglich.

Das eigentliche Problem: Filter

Selbst wenn die Adressen existieren, reicht das nicht. Wenn jemand Probleme hat, E-Mails an unsere Domain zu schicken, versucht er es über postmaster@. Wird diese E-Mail ebenfalls gefiltert, hat der Absender verloren. Ein Hinweis auf ein echtes Problem mit dem Mailsystem erreicht uns nicht.

Die Lösung: postmaster@ und abuse@ müssen an allen Filtern vorbei. Sowohl in Postfix als auch im Content-Filter.

Postfix: Empfänger whitelisten

In /etc/postfix/recipient-access die beiden Adressen mit OK eintragen:

# /etc/postfix/recipient-access
postmaster@kernel-error.de    OK
abuse@kernel-error.de         OK

Danach die Hash-Datei erzeugen:

postmap /etc/postfix/recipient-access

In /etc/postfix/main.cf muss check_recipient_access vor den Restrictions stehen. Die Reihenfolge ist entscheidend: Postfix arbeitet die Regeln von oben nach unten ab, die erste passende greift.

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_recipient_access hash:/etc/postfix/recipient-access,
        reject_rbl_client zen.spamhaus.org,
        ...

Alle nachfolgenden HELO-Checks und RBL-Prüfungen greifen jetzt nicht mehr auf E-Mails an postmaster@ und abuse@.

Wo im SMTP-Dialog prüfen?

Postfix bietet mehrere Stellen für Restrictions:

smtpd_client_restrictions — nach connect
smtpd_helo_restrictions — nach HELO/EHLO
smtpd_sender_restrictions — nach MAIL FROM
smtpd_recipient_restrictions — nach RCPT TO
smtpd_data_restrictions — nach DATA
smtpd_end_of_data_restrictions — nach der Übertragung

Je früher man ablehnt, desto weniger Ressourcen verbraucht man. Wer im HELO prüft, nimmt erst gar keinen Empfänger entgegen. Wer erst nach DATA prüft, hat die komplette E-Mail schon angenommen. Für die meisten Setups ist smtpd_recipient_restrictions der sinnvolle Kompromiss.

Content-Filter: Spam durchlassen

Postfix lässt die E-Mails an postmaster@ und abuse@ jetzt durch. Aber der Content-Filter dahinter wird sie trotzdem filtern, wenn man ihm nicht sagt, dass er sie in Ruhe lassen soll.

In rspamd geht das über eine settings.conf Regel, die bestimmte Empfänger vom Spam-Filtering ausnimmt. In AMaViS (falls noch im Einsatz) über @spam_lovers_maps in /etc/amavis/conf.d/50-user:

# AMaViS: /etc/amavis/conf.d/50-user
@spam_lovers_maps = (
  [
    "postmaster\@kernel-error.de",
    "abuse\@kernel-error.de",
  ]
);

Das bedeutet nicht, dass die E-Mail nicht geprüft wird. AMaViS testet weiterhin, lässt die Nachricht aber durch. Viren und verdächtige Anhänge filtere ich an dieser Stelle weiterhin. Nur Spam darf passieren. Denn wenn mir jemand über eine dynamische IP per Telnet eine Nachricht an postmaster@ schickt, soll sie ankommen.

Wer sich grundsätzlich gegen Spoofing absichern will: SPF hilft dabei, festzulegen, welche Server für eine Domain senden dürfen.

Fragen? Einfach melden.

Postfix für sichere E-Mail-Auslieferung: Nur noch per TLS konfigurieren

Verschlüsselte E-Mail-Übertragungen sind meist ganz gut. Zumindest hält sie einem lästige Lauscher vom Hals. Besonders wichtig ist dabei der verschlüsselte Austausch zwischen Mail-Server und Mail-Client. Denn die User sitzen mit ihren Mail-Clients sehr schnell in einem „unsicheren“ Netzwerk. Daher wird inzwischen sehr oft und gut darauf geachtet diese Verbindungen zu sichern.

Die Verbindungen zwischen den Servern werden oft als nicht SO wichtig empfunden. Denn die Kisten stehen ja meist in gesicherten Bereichen (Serverraum, DMZ, Rechenzentrum) und dort zu lauschen ist schon aufwendiger – nicht unmöglich.
Es macht also Sinn seinem Postfix zu ermöglichen seine Server zu Server Verbindungen kryptisch zu gestalten.

Mit folgender Änderung sagt man seinem Postfix dass bei ausgehenden Verbindungen TLS benutzt werden kann, wenn möglich.

$ postconf -e smtp_tls_security_level=may

Wird Postfix nun ein Zertifikat gereicht, welches von Postfix mangels der Root-Zertifikate nicht geprüft werden kann… Ja, dann ist hier schon wieder Ende.

Sep 25 10:38:07 rootserver postfix/qmgr[2069]: D69471A2026: from=<kernel-error@kernel-error.com>;, size=38273, nrcpt=1 (queue active)
Sep 25 10:38:07 rootserver postfix/smtp[9454]: certificate verification failed for gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Auf Debian Systemen finden sich eine recht gepflegte Ansammlung im Paket: ca-certificates. Nachdem dieses installiert ist:

$ apt-get install ca-certificates

Sagt man Postfix noch wie er es findet:

$ postconf -e smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Schon sollte Postfix in der Lage sein, ausgehende Serververbindungen zu prüfen und zu verschlüsseln.

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

Postfix

Zu beginn habe ich diese Seite nur mit dem Text: „Zeugs zu Postfix“ gefüllt!

Dieses erfüllt auch jetzt noch fast alles was es als Beschreibung zu sagen gibt. Aber auch nur fast! Postfix ist einer der besten und flexiebelsten MTAs die ich kenne. Hier werfe ich nun immer mal wieder Zeugs hin, welches vielleicht hilfreich sein könnte.

 

 

Fragen? Einfach melden.

AMaViS Performance-Tuning

Ich beobachte in der letzten Zeit immer mal wieder dass E-Mails im AMaViS lange hängen bleiben…. Viel Zeit scheint dabei für die Festplatte bzw. die Schreib-/Lesezugriffe drauf zu gehen. Die E-Mail wird von AMaViS angenommen, in dessen tmp Verzeichnis geschrieben. Dann noch ein paar mal gelesen um alle Tests zu machen, ausgepackt usw. usw… Um dieses etwas einzugrenzen habe ich mich gedacht, warum nicht eine RAM Disk für AMaViS oder besser für dessen Temp?

Auf einer gängigen Debian Kiste findet sich dieses Verzeichnis hier:

/var/lib/amavis/tmp

 Damit dieses Verzeichnis nicht mehr auf der Festplatte herum-gewürfelt wird, sondern sich nur noch im Arbeitsspeicher des Servers befinden (der ist ja viel schneller als so ne olle HDD) trägt man folgendes in seine /etc/fstab ein:

/dev/shm    /var/lib/amavis/tmp    tmpfs    defaults,size=256m,mode=750,uid=109,gid=113    0 0

 Man sollte nur darauf achten, dass uid und gid die des lokalen amavis sind. Sonst darf am Ende AMaViS nicht mehr in ein eigenes Temp schreiben. Es soll bessere Wege die ID zu finden, ich mache es schnell und einfach mit:

$ cat /etc/passwd|grep amavis
amavis:x:109:113:AMaViS system user,,,:/var/lib/amavis:/bin/sh

109 ist dabei die User-ID
113 ist die Group-ID

 Das neue AMaViS-tmp ist damit 256MB gross. Für die Grösse gibt es eine „Faustformel“… Diese macht nicht für jeden Sinn! Man würde mit dieser Formel zwar _fast_ nie in die Gefahr eines zu kleinen AMaViS-temps laufen, nur verbrennt man so seinen RAM. Try and Error ist hier eher mein Vorschlag. Denn sollte AMaViS wirklich mal keinen Platz mehr haben, wird die E-Mail mit einem temporären Fehler abgewiesen. Der einliefernde Mailserver wird daher versuchen die E-Mail ein paar Minuten später noch einmal zuzustellen. Damit sollte keine E-Mail verloren gehen. Als Admin behält man nach so einer Änderung einfach seinen Server im Auge und erhöht bzw. reduziert den Wert/die Grösse… Fertig.

Die RAM-Disk gibt AMaViS einen extremen Boost und steigert so dessen Performance enorm. Ich finde es kommt selten vor dass man so einfach ein so krasses Performance-Tuning hin bekommt. Nun laufen die E-Mails also schneller durch AMaViS und mein Postfix muss nicht mehr so lange auf die Filterung warten. WOOOOHOOOOO

Siehe auch: rspamd mit IMAPSieve

Fragen? Einfach melden.

Telekommailserver verschärfte Bedingungen der Mailannahme

Na also, nun hat die Telekom die Sicherheitsrichtlinien ihrer E-Mail Server so angepasst dass helo, hostname und R-DNS zusammenpassen müssen. Sonst gibt es diese Meldung:

A problem occurred. (Ask your postmaster for help or to contact tosa@rx.t-online.de to clarify.)

So gefällt mir das! Meine Kiste macht dieses ja schon länger so und ich bekomme immer mal wieder die Info, man könne mir keine E-Mail schicken. Mein Mailserver sei wohl kaputt, er sage immer:

550 5.7.1 Client host rejected: cannot find your hostname….

Wenn ich dann erkläre um was es geht bekomme ich immer mal wieder den Vorwurf da zu –genau- zu sein. Da jetzt noch ein weiteres großes Unternehmen genau so verfährt werden sich wohl noch mehr Mailserver „Administratoren“ um dieses Problem kümmern müssen. Lustig finde ich ja dass die Telekom direkt eine E-Mail Adresse angegeben hat tosa@rx.t-online.de, was da wohl abgehen muss.

 

http://www.kernel-error.de/postfix-spam-und-virenabwehr-durch-helo

 

 

 

Siehe auch: SPF-Record einrichten

Fragen? Einfach melden.

Spec-Files und Extra-Repositorys: Paketverwaltung unter Solaris optimieren

Veraltet: OpenIndiana und Solaris werden kaum noch produktiv eingesetzt. Die hier beschriebene Paketverwaltung mit IPS und Spec-Files ist Solaris-spezifisch.

Es gibt eine ganze Hand breit Software, welche man gerne auf seinem Solaris System hätte. Nicht alle sind in den Basis Repositorys dabei

Daher gibt es das Spec Files Extra Projekt. Das OpenIndiana Projekt hat eines in ihrem Spec Files Extra Repository untergebracht. So lassen sich schnell und einfach über den Paketmanager Dinge installieren wie: Python3, PostgreSQL, Postfix, LaTeX, ffmpeg, vlc, wine……

Gut beschrieben inkl. ggf. nötiger „Workarounds“ findet man im Openindiana Wiki.

Es gibt zwei verschiedene SFE Repositorys. Eines mit Paketen bei denen die Lizenzbedingungen ein problemloses Nutzen zulässt und eines bei dem es ggf. zu Problemen kommen kann.

Wobei man hier beim in den meisten europäischen Ländern kein Problem mit den Lizenzen bekommen sollte. Jeder sollte es aber für sich selbst prüfen.

Eingerichtet ist beides wie folgt:

# pkg set-publisher -p http://pkg.openindiana.org/sfe
# pkg set-publisher -p http://pkg.openindiana.org/sfe-encumbered

Nach diesem Zweizeiler hat man nun schon die Möglichkeit die Pakete bequem per Paketmanager zu installieren.

Dovecot Quota einrichten: Postfachgröße begrenzen mit Warnungen und SQL

Ohne Quota wachsen IMAP-Postfächer bis die Platte voll ist. Dovecot bringt ein Quota-Plugin mit, das die Postfachgröße begrenzt und den Benutzer warnt bevor es eng wird. Bei vollem Postfach kann Dovecot eingehende Mails mit einem temporären Fehler abweisen, statt sie sofort zu bouncen. So hat der Benutzer Zeit aufzuräumen.

Plugin aktivieren

In conf.d/20-imap.conf und conf.d/20-lmtp.conf (oder 15-lda.conf) das Quota-Plugin laden:

# 20-imap.conf
protocol imap {
  mail_plugins = $mail_plugins quota imap_quota
}

# 20-lmtp.conf
protocol lmtp {
  mail_plugins = $mail_plugins quota
}

imap_quota sorgt dafür dass Mailclients die Quota-Information per IMAP abfragen können (GETQUOTA/GETQUOTAROOT). Die meisten Clients zeigen dann einen Fortschrittsbalken.

Quota-Backend und Standardgröße

In conf.d/90-quota.conf:

plugin {
  quota = count:User quota
  quota_vsizes = yes
  quota_rule = *:storage=512M
}

count ist das empfohlene Backend ab Dovecot 2.2+. Es speichert die Quotadaten in der Index-Datei und muss nicht jedes Mal alle Mails auf der Platte zählen. Das alte dirsize-Backend funktioniert zwar noch, wird aber bei großen Postfächern langsam. quota_rule = *:storage=512M setzt die Standardgröße für alle Postfächer auf 512 MB.

Quota Warnings

Dovecot kann bei bestimmten Schwellenwerten ein Script aufrufen, das eine Warnung verschickt:

plugin {
  quota_warning = storage=80%% quota-warning 80 %u
  quota_warning2 = storage=95%% quota-warning 95 %u
}

service quota-warning {
  executable = script /usr/local/bin/quota-warning.sh
  user = vmail
  unix_listener quota-warning {
    user = vmail
  }
}

Die doppelten Prozentzeichen (%%) sind nötig weil Dovecot % als Variablen-Prefix interpretiert. Das Script /usr/local/bin/quota-warning.sh bekommt den Schwellenwert und die E-Mail-Adresse als Parameter:

#!/bin/sh
PERCENT=$1
USER=$2
echo "Ihr Postfach $USER ist zu $PERCENT% belegt.
Bitte loeschen oder archivieren Sie aeltere E-Mails." | \
  mail -s "Postfach $USER: $PERCENT% belegt" "$USER"

Individuelle Quotas per SQL

Wenn nicht jeder Benutzer die gleiche Postfachgröße bekommen soll, lässt sich die Quota per SQL-Abfrage pro Benutzer setzen. In der dovecot-sql.conf.ext:

user_query = SELECT \
  home, uid, gid, \
  CONCAT('*:storage=', quota_mb, 'M') AS quota_rule \
  FROM virtual_users \
  WHERE email = '%u'

Die Tabelle virtual_users braucht dafür ein Feld quota_mb. Dovecot übernimmt den Wert aus dem SQL-Ergebnis und überschreibt damit die Standardregel aus der Config. Benutzer ohne Eintrag bekommen weiterhin die 512 MB aus quota_rule.

Verhalten bei vollem Postfach

Standardmäßig gibt Dovecot bei vollem Postfach einen permanenten Fehler zurück und Postfix bounced die Mail. Mit der folgenden Einstellung wird stattdessen ein temporärer Fehler gesendet (4xx), damit Postfix die Mail in der Queue behält und es später nochmal versucht:

plugin {
  quota_exceeded_message = Quota exceeded, please try again later.
}

# In der LDA/LMTP Config:
quota_full_tempfail = yes

So hat der Empfänger Zeit sein Postfach aufzuräumen, ohne dass Mails verloren gehen. Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑