[Postfixbuch-users] Postfix / Cyrus / OverQuota im SMTP Dialog

[inetsolutions.de [Support-Team]]

Hallo Peer, 

danke für die Antworten.

> Meine grundsätzlicher Ansatz wäre:
> 
> Ein separates Script (außerhalb Dovecot/Cyrus) prüft die Quotas.  Ein "du"
> auf das Maildir muß reichen, 100%ig genau muß es nicht sein. Dieses
> Script muß die Mailadressen in einer DB (wie auch immer)
> vermerken/sperren.
> 
> Diese DB wird dann von Postfix als check_recipient_access ausgewertet und
> wirft dann für die betroffenen Nutzer temporäre oder fatale Fehler aus.


Ja das habe ich auch schon versucht. check_recipient_access
hash:/etc/postfix/over_quota
Problem dabei ist, dass Emailadressen ja in Postfächer gehen.

virtual_alias_maps =    hash:/etc/postfix/vusers
#vusers:
meine at email.de postfach1

Ich müsste nun auswerten:

#/etc/postfix/over_quota 
postfach1 REJECT over_quota_text

Aber der check_recipient_access nimmt ja nur Emailadressen.
Im SMTP Dialog kenne ich zu meine at email.de ja das Postfach noch nicht.

Ich könnte nun natürlich /etc/postfix/vusers nehmen und überall wo postfach1
stehe die Emailadresse in die /etc/postfix/over_quota kopieren.
Problem: die vusers ändert sich sehr oft.
Nächste Problem: Das "du" über alle Mailboxen dauert ca. 2 Stunden.


> Alternativ ein Policy-Dämon, aber eine einfache access-Map würde ja
> reichen.
> 

Hab ich versucht. Kam da nicht weiter. 

#main.cf
check_policy_service unix:private/check_script
#master.cf
check_script   unix    -       n       n       -       -       spawn
    user=nobody argv=/check.sh

#/check.sh


Wie sage ich /check.sh nun, was der Absender und der Empfänger der Email
ist?
Zudem weiß check.sh ja nicht an welches Postfach die Mail dann schließlich
soll. So weit check.sh auch nicht, welches Postfach es auf überfüllung
prüfen muss.


> Eine andere Crash-Idee kam mir allerdings noch soeben. Ist ungetestet,
> müßte aber gehen wenn LMTP etc. zum Einsatz kommt. Man nutzt Adress
> Verification und setzt die Cache-Zeiten sehr gering -- beispielsweise 30
> Minuten oder so. Oder man läßt die DB weg, dann wird ja gar nicht gecacht
> sondern alles in Echtzeit verifiziert.
> 
> Dann "lernt" Postfix einen 4xx Overquota-Reject von Cyrus umgehend und
> reicht das nach draußen weiter.
> 
> Die zusätzliche Last dürfte in vielen Fällen zu verschmerzen sein und
> damit könnte man das wahlweise als "quick & dirty" oder eben auch
> als "quick und very eleganter Trick" ansehen.  :-)

Die Idee ist gar nicht so dumm.
Du meinst

reject_unverified_recipient

Klingt ganz gut, muss ich mir grad noch überlegen, welche Folgen das für
Weiterleitungen an externe Mailadressen (alias / Nebenempfänger) haben
könnte. Hast du dazu eine Idee?

Und wie würde das bei REJECTs durch SIEVE aussehen? Dürfte ja kein Problem
sein.


Problem: Meine OverQuota werden deferred obwohl ich in imapd.conf
lmtp_overquota_perm_failure: yes stehen habe.
Aber das dürfte ja egal sein oder?

Ein Test hat ergeben, dass die Address verification recht lange dauert. Für
Over_Quota Postfächer manchmal ca 30 Sekunden.
=> Recipient address rejected: unverified address: Address verification in
progress
Ist ja aber nicht so schlimm, der Sender sollte es in wenigen Minuten ja
dann nochmal versuchen.


> Peer
> 
> 
> 
> 
> --
> Heinlein Professional Linux Support GmbH
> Linux: Akademie - Support - Hosting
> 
> http://www.heinlein-support.de
> 
> Zwangsangaben lt. §35a GmbHG:
> HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
> Geschäftsführer: Peer Heinlein  -- Sitz: Berlin
> --
> _______________________________________________
> Postfixbuch-users -- http://www.postfixbuch.de
> Heinlein Professional Linux Support GmbH
> 
> Postfixbuch-users at listen.jpberlin.de
> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users