Shortie

Auch ich sehe hier keine wirklichen Nutzen. Wenn ich als Firma den Zugriff auf die eigenen IP-Bereiche auf dem System einschränken will, dann direkt über Configfiles und nicht über die Datenbank. Weiter kommt da hinzu, dass in Zeiten von Homeoffice das ganze schnell ausarten könnte und eher eine über GeoIP Datenbanken gesteuerte Einschränkung Sinn machen würde. Davon abgesehen mag das mit IPv4 ja noch machbar sein, aber mit IPv6 ist der Normaluser doch (noch) überfordert. Solche Restiktionen sind meines Erachtens ein Relikt aus der Anfangszeit des Internets, als der Traffic zwischen den Providern noch Unsummen gekostet hat und man seine Kunden am besten über die eigene Einwahlstruktur und Netze gezwungen hat, um die diese Kosten niedrig zu halten und die Kunden bei der Einwahl abrechnen zu können.

Sollte auch passen. Dann fällt mir grad auch nichts mehr ein, außer das Logging zu aktivieren / erhöhen und dort suchen.

ich meinte von /usr/local/bin/quota-warning-de.sh - gehört die vmail?

nein, leider nicht und im Vergleich mit meiner Datei finde ich nur dass bei mir quota_warning2 nicht auskommentiert ist. Wie sehen der Eigentümer der Datei aus? Also User und Group

Abgelehnt werden die E-Mails und der Sender bekommt auch eine E-Mail mit "Quota exceeded (mailbox for user is full)" - richtig oder? Die quota-warning-de.sh (bei mir ist es chmod 700 - chown vmail :vmail) informiert ja nur den Mailboxeigentümer - eher nice to have statt wirklich notwendig plugin { quota_warning = storage=95%% quota-warning 95 %u } hast du das mindestens auch drin?

Als Anregung was bei mir relevantes drin ist und es ist schon lange her, dass ich es eingerichtet habe: plugin { quota_warning = storage=95%% quota-warning 95 %u quota_warning2 = storage=80%% quota-warning 80 %u } service quota-warning { executable = script /usr/local/bin/quota-warning-de.sh user = vmail unix_listener quota-warning { user = vmail } } plugin { quota = maildir:User quota } und wegen der Vollständigkeit noch um die Mailboxuser zu informieren /usr/local/sbin/quota-warning-de.sh: #!/bin/sh PERCENT=$1 USER=$2 cat << EOF | /usr/lib/dovecot/dovecot-lda -d $USER -o "plugin/quota=maildir:User quota:noenforcing" From: support@domain.de To: $USER Cc: support@domain.de Date: `date +"%a, %d %b %Y %H:%M:%S %z"` Subject: Quota-Warnung! Sehr geehrter Benutzer, das Postfach $USER ist zu $PERCENT% ausgelastet! Viele Grüße Ihr Support

Nun der Kunde hat bspw. 5GB Speicherplatz - wie er die aber nutzt und sich aufteilt gebe ich ihm nicht vor. Daher kann ich da im nachhinein nichts einschränken. Einer der "Maximalkunden" nutzt da nur eine Webvisitenkarte und den Rest für 5 oder 6 E-Mail-Adressen und dort haben die Mailuser unterschiedliche Auslastungen, die ich ohne genauere Kenntnis eben nicht einschätzen kann - außer dass einer alleine immer wieder über die 5GB rausknallt (wohl ein Objektleiter). Würde ich den festsetzen auf die maximalen 5GB wären ja immer noch die anderen Mailnutzer die das Gesamtpaket überschreiten.

Genau an dieser Umsetzung hänge ich auch aktuell mal wieder bei Bestandskunden. Wenn ich nun im Nachhinein eine Gesamtquota vergebe, aber der Kunde die Mailboxquota nicht setzt (und somit auf 0 bleibt) geht technisch nichts. E-Mails werden trotzdem zugestellt. Auch wenn er auf E-Mails (automatische "Speicherplatz voll" oder auch direkte Ansprache) nicht reagiert, kann / darf / sollte ich ihm ja nicht seine Verteilung vorgeben. Wenn die jeweiligen Mailbox-Quotas definiert sind, funktioniert die Ablehnung bei Mailbox full. Oder habe ich noch irgendwo eine Einstellung übersehen, die nur das Gesamtquota für E-mails berücksichtigt?

Ist RR Prinzip. Was heißt denn deutlich schwächer und wieviele Domains soll der verwalten? DNS ist nicht so resourcenintensiv. Einer meiner DNS läuft seit mehr als 6 Jahren mit derselben Hardware und macht sonst nur Backupserver noch.

Die Config ist kein Hexenwerk und rsync usw. brauchst du nicht. Lediglich ein Script auf dem Slave was dir die Domain / Zone (siehe mein Post weiter oben) in die named.conf.slave (oder wie du die immer nennen magst) einträgt und bind neu startet. Dann holt der Slave sich die Zone automatisch über AXFR vom Master. Mein DNS läuft unabhängig von Froxlor und sieht grob ausgedrückt so aus: Auf dem Master habe ich ein Script was mir die Domain in named.conf.master einträgt und die Zonendatei aus einem Template erstellt (sed für das Datum in der Seriennummer usw.), dann den bind neustartet und über ssh gleich noch das Script auf den Slave mit zwei Parametern (Domainname und IP des Masters) aufruft.

Dann ist es klar, dass ihr nichts tun müsst. Vermutlich wird beim anmelden oder registrieren der Domain gleich automatisch der Slave bereitgestellt.

ich muß doch dem Slave eine Konfiguration mitgeben, dass dieser weiß dass er für eine Domain zuständig ist: # Slave zone statement for forward DNS lookup zone "domain.com" IN { type slave; file "domain.com"; masters { 192.168.2.5; }; }; und diese Konfiguration geht meines Wissens nicht automatisch aus bind, sondern nur über externe Scripte oder dein Registrar wenn dort der Slave läuft (bspw. bei Schlundtech oder InternetX möglich).

Wie sagst du einem Slave automatisch dass er für eine Domain / Zone zuständig ist? AXFR macht doch nur Zonen-Updates oder hab ich was übersehen?

Wird mit Froxlor generierten Zonen und Configs wahrscheinlich nicht gehen, aber generell geht das. BIND 9 kann das in Abhängigkeit des Clients - also woher die Abfrage kommt. Das bedeutet Du musst ACLs und Views einführen. Schau dir Example 2 in folgendem Link an: https://kb.isc.org/docs/aa-00851

Kleiner Hinweis: Offene DNS Resolver sind nicht so gerne gesehen und unter Umständen ein Sicherheitsproblem. Daher sollten deine Nameserver nur für bestimmte IP-Adressen oder Netze rekursive Resolverdienste anbieten. Schwierig wird's also die ACL entsprechend aktuell zu halten, wenn deine Clients hinter einer dynamischen IP-Adresse sitzen.