> 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.

> 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)

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

> 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

> * 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

> 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:

> > 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

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

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

Bei wem läufts denn und mit welchen auth Backend?

Hier auf dem Testsystem aktuell nur PAM.