Dovecot Quota via policy service abfragen
Mit Dovecot-2.2 (und wohl auch backported nach 2.1 – so hatte ich das
verstanden) kann man nun aus Postfix heraus den Füllstand einer Mailbox
auf einem Dovecot-Server abfragen. Somit kommt man nicht mehr in
Verlegenheit, Mails für „volle“ Mailboxen anzunehmen und diese deshlab
später bouncen zu müssen (Backscatter):
http://sys4.de/de/blog/2013/04/05/dovecot-quota-mit-postfix-abfragen/
Zu erwähnen ist dabei noch, daß Timo das Quota-Verhalten von Dovecot
leicht geändert hat:
Früher konnte man die Quota in keinem Fall überschreiten. Das hat zur
unschönen Situation geführt, daß man bei 99% Füllstand immer wieder
sporadisch (kleine) Mails bekommen hat — und sich in Sicherheit wog. Die
wichtigen (großen) Mails mit Anhang kamen nicht durch. Aber da man ja
immer wieder Mails bekommen ist das nicht aufgefallen!
Jetzt kann man die Quota um quota_grace (default: 10%) überschreiten, und
somit eine fast 110%-ige Füllung erreichen – und dieser Zustand führt
dazu, daß nach dieser letzten, ultimativ quota-sprengenden Mail gar keine
Mail mehr durchkommt. Bis der User aufräumt.
Und sowas fällt dann den Benutzern doch auf, denn Quota-Warnmails
liest eh keiner…
—
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich
-
6. April 2013
-
Ralf Hildebrandt
-
17 Antworten
Ralf Hildebrandt schrieb:
> Jetzt kann man die Quota um quota_grace (default: 10%) überschreiten, und
> somit eine fast 110%-ige Füllung erreichen – und dieser Zustand führt
> dazu, daß nach dieser letzten, ultimativ quota-sprengenden Mail gar keine
> Mail mehr durchkommt. Bis der User aufräumt.
Ist es nicht bei 109% dasselbe mit den kleinen Mails?
Patrick
* Patrick Westenberg :
> Ralf Hildebrandt schrieb:
>
> >Jetzt kann man die Quota um quota_grace (default: 10%) überschreiten, und
> >somit eine fast 110%-ige Füllung erreichen – und dieser Zustand führt
> >dazu, daß nach dieser letzten, ultimativ quota-sprengenden Mail gar keine
> >Mail mehr durchkommt. Bis der User aufräumt.
>
> Ist es nicht bei 109% dasselbe mit den kleinen Mails?
Nein. Man kommt mir irgendeiner Mail über die 100%, danach ist Schluss.
Vorher hat man die 100% de-facto nie erreicht (die meisten User lesen
dann doch kleine Mails und löschen die, so ala „Kommst Du mit zum
Essen“ – sodaß immer bissel Platz bleibt).
—
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité – Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hildebrandt@charite.de | http://www.charite.de
Hallo!
Ralf Hildebrandt wrote:
> Mit Dovecot-2.2 (und wohl auch backported nach 2.1 – so hatte ich das
> verstanden) kann man nun aus Postfix heraus den Füllstand einer Mailbox
> auf einem Dovecot-Server abfragen. Somit kommt man nicht mehr in
> Verlegenheit, Mails für „volle“ Mailboxen anzunehmen und diese deshlab
> später bouncen zu müssen (Backscatter):
>
> http://sys4.de/de/blog/2013/04/05/dovecot-quota-mit-postfix-abfragen/
Hat jemand mal versucht, den quota-status mit postfix abzufragen?
Ich habe das nach Ralf’s Anleitung versucht umzusetzen, erhalte aber
nur
Apr 7 14:07:52 delta postfix/qmgr[19078]: 1D8921B31260: from=, size=1492149, nrcpt=1 (queue active)
Apr 7 14:07:53 delta postfix/pipe[19091]: 1D8921B31260: to=, relay=dovecot, delay=2542, delays=2542/0.01/0/0.29, dsn=4.3.0, status=deferred (temporary failure)
plugin {
quota = maildir:User quota
quota_grace = 10%%
quota_rule = *:storage=500MB
quota_rule2 = Trash:storage=+10%%
quota_status_success = DUNNO
quota_status_nouser = DUNNO
quota_status_overquota = 552 5.2.2 Mailbox is full / Mailbox ist voll
autocreate = Trash
autocreate2 = Drafts
autocreate3 = Sent
autosubscribe = Trash
autosubscribe2 = Drafts
autosubscribe3 = Sent
}
service quota-status {
executable = quota-status -p postfix
inet_listener {
port = 12340
}
client_limit = 1
}
und in der main.cf
warn_if_reject check_policy_service inet:127.0.0.1:12340
als letzte smtpd_recipient_restriction und 127.0.0.1 damit kein
port in der firewall geöffnet werden muss.
# netstat -pantu |grep 12340
tcp 0 0 0.0.0.0:12340 0.0.0.0:* LISTEN 19150/dovecot
tcp 0 0 :::12340 :::* LISTEN 19150/dovecot
Im dovecot.log erhalte ich dann nur:
Apr 07 14:07:52 lda(miles@anup.de): Error: sieve: msgid=: failed to store into mailbox ‚INBOX‘: Quota exceeded (mailbox for user is full)
Apr 07 14:07:52 lda(miles@anup.de): Error: sieve: script /var/spool/vhosts/anup.de/miles/.dovecot.sieve failed with unsuccessful implicit keep (user logfile /var/spool/vhosts/anup.de/miles/.dov
ecot.sieve.log may reveal additional details)
Also ich vermisse das reject-warning von postfix und es hat auch nicht den
Anschein, dass postfix den Status der Quota bei dovecot über port 12340
abfrägt.
BTW kann man dem inet_listener außer dem port auch den hostnamen mitgeben?
Schönen Sonntag!
Andreas
Am 07.04.2013 14:22, schrieb Andreas Meyer:
> Hat jemand mal versucht, den quota-status mit postfix abzufragen?
yupp
> service quota-status {
> executable = quota-status -p postfix
> inet_listener {
> port = 12340
> }
> client_limit = 1
> }
> BTW kann man dem inet_listener außer dem port auch den hostnamen mitgeben?
Deine Konfiguration würde dann erweitert so aussehen:
…
service quota-status {
executable = quota-status -p postfix
inet_listener {
address = 127.0.0.1
port = 12340
}
client_limit = 1
}
…
Läuft hier auf der Testbox auch noch nicht da der Policy Service an den
Postfix Müll zurück liefert…
Ein schneller Test per Telnet auf den Policy Service, es wird eine leere
Antwort
„action= “
als Antwort generiert.
Auf alles, was der Policy Server nicht versteht, liefert er ein
sinnvolles „DUNNO“ zurück, so bald die notwendigen Parameter im Request
vorhanden sind um eine sinnvolle Antwort zu gewährleisten, wird nur eine
leere „action= “ generiert…
Ich teste weiter.
Alexander Stoll wrote:
> Am 07.04.2013 14:22, schrieb Andreas Meyer:
>
> > Hat jemand mal versucht, den quota-status mit postfix abzufragen?
>
> yupp
>
> > service quota-status {
> > executable = quota-status -p postfix
> > inet_listener {
> > port = 12340
> > }
> > client_limit = 1
> > }
>
> > BTW kann man dem inet_listener außer dem port auch den hostnamen mitgeben?
>
> Deine Konfiguration würde dann erweitert so aussehen:
>
> …
> service quota-status {
> executable = quota-status -p postfix
> inet_listener {
> address = 127.0.0.1
> port = 12340
> }
> client_limit = 1
> }
danke!
> …
>
> Läuft hier auf der Testbox auch noch nicht da der Policy Service an den
> Postfix Müll zurück liefert…
> Ein schneller Test per Telnet auf den Policy Service, es wird eine leere
> Antwort
>
> „action= “
>
> als Antwort generiert.
Ich halte bei einem telnet auf localhost 12340
~> telnet localhost 12340
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‚^]‘.
und wenn ich die Returntaste drücke
action=DUNNO
action=DUNNO
Also nach der dovecot.conf würde der DUNNO bei quota_status_success
und quota_status_nouser zurückliefern.
> Auf alles, was der Policy Server nicht versteht, liefert er ein
> sinnvolles „DUNNO“ zurück, so bald die notwendigen Parameter im Request
> vorhanden sind um eine sinnvolle Antwort zu gewährleisten, wird nur eine
> leere „action= “ generiert…
Verrätst Du uns, welche Parameter Du im Request noch mitgeben kannst?
> Ich teste weiter.
Ich habe die Abfrage auch schon mittels unix_listener probiert, aber
dazu muss man wohl in der master.cf von Postfix einen service quota-status
definieren und dazu fehlen mir die notwendigen Parameter und Kenntnisse.
Andreas
Andreas Meyer wrote:
> Alexander Stoll wrote:
> > Läuft hier auf der Testbox auch noch nicht da der Policy Service an den
> > Postfix Müll zurück liefert…
> > Ein schneller Test per Telnet auf den Policy Service, es wird eine leere
> > Antwort
> >
> > „action= “
> >
> > als Antwort generiert.
>
> Ich halte bei einem telnet auf localhost 12340
>
> ~> telnet localhost 12340
> Trying 127.0.0.1…
> Connected to localhost.
> Escape character is ‚^]‘.
>
> und wenn ich die Returntaste drücke
>
> action=DUNNO
>
>
> action=DUNNO
>
> Also nach der dovecot.conf würde der DUNNO bei quota_status_success
> und quota_status_nouser zurückliefern.
>
> > Auf alles, was der Policy Server nicht versteht, liefert er ein
> > sinnvolles „DUNNO“ zurück, so bald die notwendigen Parameter im Request
> > vorhanden sind um eine sinnvolle Antwort zu gewährleisten, wird nur eine
> > leere „action= “ generiert…
Finde gerade folgendes im log von postfix:
Apr 7 15:38:11 delta postfix/smtpd[19878]: warning: access table inet:127.0.0.1:12340 entry has empty value
Kann ich nicht so recht einordnen. Warum eine access table? Postfix sollte
eigentlich auf den inet_listener zugreifen.
Andreas
Am 07.04.2013 15:47, schrieb Andreas Meyer:
> Finde gerade folgendes im log von postfix:
>
> Apr 7 15:38:11 delta postfix/smtpd[19878]: warning: access table inet:127.0.0.1:12340 entry has empty value
Das bezieht sich auf die „leere Antwort“ des Policy Service, selbes
Problem wie bei mir…
> Kann ich nicht so recht einordnen. Warum eine access table? Postfix sollte
> eigentlich auf den inet_listener zugreifen.
Macht es
So bald die Parameter für eine sinnvolle Abfrage mitgeliefert werden, siehe
http://www.postfix.org/SMTPD_POLICY_README.html#protocol
Wirklich einfaches Protokol; habs getestet mit vollem Parametersatz
(Attribute) und so bald „size“ und „recipient“ (für eine sinnvolle
Abfrage notwendig) mitgegeben werden kommt eine leere „action“ zurück.
Dovecot scheint also die Abfrage zu bearbeiten aber der Response Code
wird falsch zurückgeliefert, dürfte eigentlich nur die Varianten wie in
quota_status_success
quota_status_nouser
quota_status_overquota
definiert enthalten. Da fehlt offensichtlich noch etwas Robustheit 😉
Weitere Tests: Die Angabe eines nicht vorhandenen Users führt zum
Segfault des Policy Service…
Bei wem läufts denn und mit welchen auth Backend?
Hier auf dem Testsystem aktuell nur PAM.
* Alexander Stoll :
> Läuft hier auf der Testbox auch noch nicht da der Policy Service an
> den Postfix Müll zurück liefert…
> Ein schneller Test per Telnet auf den Policy Service, es wird eine
> leere Antwort
>
> „action= “
>
> als Antwort generiert.
Ja, das passiert wenn man den statustext ändert. Default nehmen, geht.
—
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité – Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hildebrandt@charite.de | http://www.charite.de
Am 07.04.2013 19:29, schrieb Ralf Hildebrandt:
> * Alexander Stoll :
>> „action=“
>> als Antwort generiert.
>
> Ja, das passiert wenn man den statustext ändert. Default nehmen, geht.
Hat mal jemand statt
quota_status_overquota = 552 5.2.2 Mailbox is full / Mailbox ist voll
folgendes ausprobiert?
quota_status_overquota = „552 5.2.2 Mailbox is full / Mailbox ist voll“
Manchmal sollen Anführnugszeichen ja Wunder wirken.
Beste Grüße,
Jan
am 07.04.13 14:51 schrieb Alexander Stoll :
> Am 07.04.2013 14:22, schrieb Andreas Meyer:
>
>> Hat jemand mal versucht, den quota-status mit postfix abzufragen?
>
> yupp
>
>> service quota-status {
>> executable = quota-status -p postfix
>> inet_listener {
>> port = 12340
>> }
>> client_limit = 1
>> }
>
>> BTW kann man dem inet_listener außer dem port auch den hostnamen
>> mitgeben?
>
> Deine Konfiguration würde dann erweitert so aussehen:
>
> …
> service quota-status {
> executable = quota-status -p postfix
> inet_listener {
> address = 127.0.0.1
> port = 12340
> }
> client_limit = 1
> }
> …
>
> Läuft hier auf der Testbox auch noch nicht da der Policy Service an
> den Postfix Müll zurück liefert…
> Ein schneller Test per Telnet auf den Policy Service, es wird eine
> leere Antwort
>
> „action= “
>
> als Antwort generiert.
>
> Auf alles, was der Policy Server nicht versteht, liefert er ein
> sinnvolles „DUNNO“ zurück, so bald die notwendigen Parameter im
> Request vorhanden sind um eine sinnvolle Antwort zu gewährleisten,
> wird nur eine leere „action= “ generiert…
>
> Ich teste weiter.
und wie ist deine Erkenntnis bei den weiteren Tests?
—
Mit freundlichen Grüßen,
with kind regards,
Jim Knuth
———
Geld, hatte sich herausgestellt, war genau wie Sex.
Du hast an nichts anderes gedacht, wenn du’s nicht
gehabt hast, und du hast an andere Dinge gedacht,
wenn du es hattest.(James Baldwin)
Am 15.04.2013 14:37, schrieb Jim Knuth:
> und wie ist deine Erkenntnis bei den weiteren Tests?
Im Moment ist mir das, wie der Policy Service in 2.1.16 / 2.2 (Open
Source) implementiert ist, nicht robust genug um auf den Gedanken zu
kommen diesen Stand produktiv ausrollen zu wollen.
Kann sein, die Enterprise Versionen oder sonstige Daily funktionieren,
hier auf meiner Testbox tut es der OS Release nicht…
Da das Feature zwar hochinteressant ist, bei mir aber kein Leidensdruck
herrscht mehr Zeit dafür zu opfern und ggf. sogar noch in den Sourcen zu
stochern, warte ich auf neue Versionen und/oder eine vernünftige Doku dazu.
Wer positives Feedback hat, ich höre gerne Details.
* Andreas Meyer :
> Hallo!
>
> Ralf Hildebrandt wrote:
>
> > Mit Dovecot-2.2 (und wohl auch backported nach 2.1 – so hatte ich das
> > verstanden) kann man nun aus Postfix heraus den Füllstand einer Mailbox
> > auf einem Dovecot-Server abfragen. Somit kommt man nicht mehr in
> > Verlegenheit, Mails für „volle“ Mailboxen anzunehmen und diese deshlab
> > später bouncen zu müssen (Backscatter):
> >
> > http://sys4.de/de/blog/2013/04/05/dovecot-quota-mit-postfix-abfragen/
>
> Hat jemand mal versucht, den quota-status mit postfix abzufragen?
Jo klar, ich.
> Ich habe das nach Ralf’s Anleitung versucht umzusetzen, erhalte aber
> nur
>
> Apr 7 14:07:52 delta postfix/qmgr[19078]: 1D8921B31260: from=, size=1492149, nrcpt=1 (queue active)
> Apr 7 14:07:53 delta postfix/pipe[19091]: 1D8921B31260: to=, relay=dovecot, delay=2542, delays=2542/0.01/0/0.29, dsn=4.3.0, status=deferred (temporary failure)
Ich sehe hier nur einen Fehler vom transport „dovecot“.
> plugin {
> quota = maildir:User quota
> quota_grace = 10%%
> quota_rule = *:storage=500MB
> quota_rule2 = Trash:storage=+10%%
>
> quota_status_success = DUNNO
> quota_status_nouser = DUNNO
> quota_status_overquota = 552 5.2.2 Mailbox is full / Mailbox ist voll
Lass mal das quota_status_overquota feld weg.
> Also ich vermisse das reject-warning von postfix und es hat auch nicht den
> Anschein, dass postfix den Status der Quota bei dovecot über port 12340
> abfrägt.
Naja, vielleicht steht es an der falschen Stelle in den Restrictions!
Das muss passieren BEVOR irgendwas ein OK zurückgibt.
—
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité – Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hildebrandt@charite.de | http://www.charite.de
Hallo Waffenmeister!
Ralf Hildebrandt wrote:
> > Apr 7 14:07:52 delta postfix/qmgr[19078]: 1D8921B31260: from=, size=1492149, nrcpt=1 (queue active)
> > Apr 7 14:07:53 delta postfix/pipe[19091]: 1D8921B31260: to=, relay=dovecot, delay=2542, delays=2542/0.01/0/0.29, dsn=4.3.0, status=deferred (temporary failure)
>
> Ich sehe hier nur einen Fehler vom transport „dovecot“.
>
> > plugin {
> > quota = maildir:User quota
> > quota_grace = 10%%
> > quota_rule = *:storage=500MB
> > quota_rule2 = Trash:storage=+10%%
> >
> > quota_status_success = DUNNO
> > quota_status_nouser = DUNNO
> > quota_status_overquota = 552 5.2.2 Mailbox is full / Mailbox ist voll
>
> Lass mal das quota_status_overquota feld weg.
Habe ich jetzt neben quota_grace = 10%% auch rausgenommen.
Apr 7 19:38:35 delta postfix/smtpd[23037]: connect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
Apr 7 19:38:36 delta postfix/smtpd[23037]: setting up TLS connection from p54B32BC9.dip.t-dialin.net[84.179.43.201]
Apr 7 19:38:36 delta postfix/smtpd[23037]: TLS connection established from p54B32BC9.dip.t-dialin.net[84.179.43.201]: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
Apr 7 19:38:37 delta postfix/smtpd[23037]: NOQUEUE: client=p54B32BC9.dip.t-dialin.net[84.179.43.201], sasl_method=CRAM-MD5, sasl_username=anmeyer@anup.de
Apr 7 19:39:01 delta postfix/smtpd[23139]: connect from localhost[127.0.0.1]
Apr 7 19:39:01 delta postfix/smtpd[23139]: 9C1BA1B30FB0: client=localhost[127.0.0.1]
Apr 7 19:39:01 delta postfix/cleanup[23142]: 9C1BA1B30FB0: message-id=
Apr 7 19:39:01 delta postfix/qmgr[22234]: 9C1BA1B30FB0: from=, size=1492149, nrcpt=1 (queue active)
Apr 7 19:39:01 delta postfix/smtpd[23139]: disconnect from localhost[127.0.0.1]
Apr 7 19:39:02 delta postfix/smtpd[23037]: disconnect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
Apr 7 19:39:02 delta postfix/pipe[23143]: 9C1BA1B30FB0: to=, relay=dovecot, delay=0.56, delays=0.33/0/0/0.23, dsn=4.3.0, status=deferred (temporary failure)
> > Also ich vermisse das reject-warning von postfix und es hat auch nicht den
> > Anschein, dass postfix den Status der Quota bei dovecot über port 12340
> > abfrägt.
>
> Naja, vielleicht steht es an der falschen Stelle in den Restrictions!
> Das muss passieren BEVOR irgendwas ein OK zurückgibt.
Ich habe warn_if_reject check_policy_service inet:127.0.0.1:12340
ziemlich am Anfang der recipient_restrictions gesetzt nachdem ich
den check am Ende hatte noch nach postgrey.
smtpd_recipient_restrictions =
check_sender_access hash:/etc/postfix/access_sender,
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_helo_hostname,
reject_unlisted_recipient,
warn_if_reject check_policy_service inet:127.0.0.1:12340
reject_unknown_sender_domain,
check_sender_access pcre:/etc/postfix/umlaute.pcre,
check_recipient_access pcre:/etc/postfix/umlaute.pcre,
reject_unauth_destination,
reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org,
check_client_access cidr:/etc/postfix/client.cidr,
check_policy_service inet:127.0.0.1:10023
Andreas
* Andreas Meyer :
> Habe ich jetzt neben quota_grace = 10%% auch rausgenommen.
Gut.
> Apr 7 19:38:35 delta postfix/smtpd[23037]: connect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
> Apr 7 19:38:36 delta postfix/smtpd[23037]: setting up TLS connection from p54B32BC9.dip.t-dialin.net[84.179.43.201]
> Apr 7 19:38:36 delta postfix/smtpd[23037]: TLS connection established from p54B32BC9.dip.t-dialin.net[84.179.43.201]: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
> Apr 7 19:38:37 delta postfix/smtpd[23037]: NOQUEUE: client=p54B32BC9.dip.t-dialin.net[84.179.43.201], sasl_method=CRAM-MD5, sasl_username=anmeyer@anup.de
> Apr 7 19:39:01 delta postfix/smtpd[23139]: connect from localhost[127.0.0.1]
> Apr 7 19:39:01 delta postfix/smtpd[23139]: 9C1BA1B30FB0: client=localhost[127.0.0.1]
> Apr 7 19:39:01 delta postfix/cleanup[23142]: 9C1BA1B30FB0: message-id=
> Apr 7 19:39:01 delta postfix/qmgr[22234]: 9C1BA1B30FB0: from=, size=1492149, nrcpt=1 (queue active)
> Apr 7 19:39:01 delta postfix/smtpd[23139]: disconnect from localhost[127.0.0.1]
> Apr 7 19:39:02 delta postfix/smtpd[23037]: disconnect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
> Apr 7 19:39:02 delta postfix/pipe[23143]: 9C1BA1B30FB0: to=, relay=dovecot, delay=0.56, delays=0.33/0/0/0.23, dsn=4.3.0, status=deferred (temporary failure)
Na dann sind deine Restrictions falsch und die Mail wird „OK“‚ed bevor
der Policy Server gefragt wird.
> Ich habe warn_if_reject check_policy_service inet:127.0.0.1:12340
> ziemlich am Anfang der recipient_restrictions gesetzt nachdem ich
> den check am Ende hatte noch nach postgrey.
>
> smtpd_recipient_restrictions =
—> hier einbauen check_sender_access hash:/etc/postfix/access_sender,
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_invalid_helo_hostname,
> reject_unlisted_recipient,
> warn_if_reject check_policy_service inet:127.0.0.1:12340
> reject_unknown_sender_domain,
> check_sender_access pcre:/etc/postfix/umlaute.pcre,
> check_recipient_access pcre:/etc/postfix/umlaute.pcre,
> reject_unauth_destination,
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client zen.spamhaus.org,
> check_client_access cidr:/etc/postfix/client.cidr,
> check_policy_service inet:127.0.0.1:10023
>
> Andreas
> _______________________________________________
> Dovecot Mailingliste
> JPBerlin – Politischer Provider
> Dovecot@listen.jpberlin.de
> https://listen.jpberlin.de/mailman/listinfo/dovecot
—
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité – Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hildebrandt@charite.de | http://www.charite.de
Ralf Hildebrandt wrote:
> * Andreas Meyer :
>
> > Habe ich jetzt neben quota_grace = 10%% auch rausgenommen.
>
> Gut.
>
> > Apr 7 19:38:35 delta postfix/smtpd[23037]: connect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
> > Apr 7 19:38:36 delta postfix/smtpd[23037]: setting up TLS connection from p54B32BC9.dip.t-dialin.net[84.179.43.201]
> > Apr 7 19:38:36 delta postfix/smtpd[23037]: TLS connection established from p54B32BC9.dip.t-dialin.net[84.179.43.201]: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
> > Apr 7 19:38:37 delta postfix/smtpd[23037]: NOQUEUE: client=p54B32BC9.dip.t-dialin.net[84.179.43.201], sasl_method=CRAM-MD5, sasl_username=anmeyer@anup.de
> > Apr 7 19:39:01 delta postfix/smtpd[23139]: connect from localhost[127.0.0.1]
> > Apr 7 19:39:01 delta postfix/smtpd[23139]: 9C1BA1B30FB0: client=localhost[127.0.0.1]
> > Apr 7 19:39:01 delta postfix/cleanup[23142]: 9C1BA1B30FB0: message-id=
> > Apr 7 19:39:01 delta postfix/qmgr[22234]: 9C1BA1B30FB0: from=, size=1492149, nrcpt=1 (queue active)
> > Apr 7 19:39:01 delta postfix/smtpd[23139]: disconnect from localhost[127.0.0.1]
> > Apr 7 19:39:02 delta postfix/smtpd[23037]: disconnect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
> > Apr 7 19:39:02 delta postfix/pipe[23143]: 9C1BA1B30FB0: to=, relay=dovecot, delay=0.56, delays=0.33/0/0/0.23, dsn=4.3.0, status=deferred (temporary failure)
>
> Na dann sind deine Restrictions falsch und die Mail wird „OK“‚ed bevor
> der Policy Server gefragt wird.
>
> > Ich habe warn_if_reject check_policy_service inet:127.0.0.1:12340
> > ziemlich am Anfang der recipient_restrictions gesetzt nachdem ich
> > den check am Ende hatte noch nach postgrey.
> >
> > smtpd_recipient_restrictions =
>
> —> hier einbauen ist ja nur zum Test
>
> > check_sender_access hash:/etc/postfix/access_sender,
> > permit_mynetworks,
> > permit_sasl_authenticated,
> > reject_invalid_helo_hostname,
> > reject_unlisted_recipient,
> > warn_if_reject check_policy_service inet:127.0.0.1:12340
> > reject_unknown_sender_domain,
> > check_sender_access pcre:/etc/postfix/umlaute.pcre,
> > check_recipient_access pcre:/etc/postfix/umlaute.pcre,
> > reject_unauth_destination,
> > reject_rbl_client bl.spamcop.net,
> > reject_rbl_client zen.spamhaus.org,
> > check_client_access cidr:/etc/postfix/client.cidr,
> > check_policy_service inet:127.0.0.1:10023
That did the trick! The order of the recipient_restricitons was wrong.
Apr 7 20:24:55 delta postfix/smtpd[23806]: connect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
Apr 7 20:24:55 delta postfix/smtpd[23806]: setting up TLS connection from p54B32BC9.dip.t-dialin.net[84.179.43.201]
Apr 7 20:24:56 delta postfix/smtpd[23806]: TLS connection established from p54B32BC9.dip.t-dialin.net[84.179.43.201]: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
Apr 7 20:24:56 delta postfix/smtpd[23806]: NOQUEUE: reject: RCPT from p54B32BC9.dip.t-dialin.net[84.179.43.201]: 552 5.2.2 : Recipient address rejected: Quota exceeded (mailbox for user is full); from= to= proto=ESMTP helo=
Apr 7 20:24:56 delta postfix/smtpd[23806]: lost connection after RCPT from p54B32BC9.dip.t-dialin.net[84.179.43.201]
Apr 7 20:24:56 delta postfix/smtpd[23806]: disconnect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
The MUA does not get rid of the mail, when it would exceed the quota.
But now the next problem. I cannot send this mail and get the following
with
smtpd_recipient_restrictions =
check_policy_service inet:127.0.0.1:12340
check_sender_access hash:/etc/postfix/access_sender,
permit_mynetworks,
permit_sasl_authenticated,
….
Apr 7 20:31:43 delta postfix/smtpd[23820]: connect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
Apr 7 20:31:44 delta postfix/smtpd[23820]: setting up TLS connection from p54B32BC9.dip.t-dialin.net[84.179.43.201]
Apr 7 20:31:45 delta postfix/smtpd[23820]: TLS connection established from p54B32BC9.dip.t-dialin.net[84.179.43.201]: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
Apr 7 20:31:46 delta postfix/smtpd[23820]: warning: problem talking to server 127.0.0.1:12340: Success
Apr 7 20:31:46 delta postfix/smtpd[23820]: NOQUEUE: reject: RCPT from p54B32BC9.dip.t-dialin.net[84.179.43.201]: 451 4.3.5 Server configuration problem; from= to= proto=ESMTP helo=
Apr 7 20:31:46 delta postfix/smtpd[23820]: lost connection after RCPT from p54B32BC9.dip.t-dialin.net[84.179.43.201]
Apr 7 20:31:46 delta postfix/smtpd[23820]: disconnect from p54B32BC9.dip.t-dialin.net[84.179.43.201]
the mail is not sent out. I deactivated the check to get sent
mail sent.
Andreas
Am 07.04.2013 15:22, schrieb Andreas Meyer:
> Hat jemand mal versucht, den quota-status mit postfix abzufragen?
> Ich habe das nach Ralf’s Anleitung versucht umzusetzen, erhalte aber
Ich hab das mal mit einer recht gruseligen SQL Abfrage (postfixadmin
Datenbank und SQL als dict backend for dovecot 2.0 und Ubuntu 12.04)
gebastelt.
Der Postfix Teil:
Erstmal rausdröseln, in welchem Postfach die Mail wirklich abgeliefert
werden soll, und dann sehen ob Mailbox voll oder nicht. Die Verrenkung
mit (-quota2.bytes – quota) is nötig, da sonst User ohne Quota limit
immer über dem Quota sind.
table = quota2
query = ( SELECT IF( (- quota2.bytes – quota) >1, ‚552 5.2.2 Quota
exceeded (mailbox for user is full)‘, ‚OK‘ ) AS available FROM mailbox
JOIN quota2 ON mailbox.username = quota2.username WHERE ( SELECT goto
FROM alias WHERE ( address = ‚%u@%d‘ OR address = CONCAT( ‚%u@‘, (
SELECT target_domain FROM alias_domain WHERE alias_domain = ‚%d‘ LIMIT 1
)))) REGEXP mailbox.username ) ORDER BY available LIMIT 1
check_recipient_access mysql:/etc/postfix/sql/virtual_over_quota.cf, usw…
Vielleicht kanns ja jemand brauchen, der nicht updaten kann, will darf.
Oder das bekommt jemand schöner….
Andreas