about Postfix, lmtp and quotas...

[deepblue]

Hi everybody,

We are running an Zimbra system with ~10.000 Accounts.
Always some accounts are over quota.

Up to zimbra 4.5.x the lmtp process always rejected mails to over quota accounts with a 5.x.x error.
So it was up to postfix to generate a bounce to the sender.

This behavior changed in 5.x.x. The lmtp process rejected the mails with a 4.x.x (non permanent failure).
So these mails where hold in postfix deferred queue until ether the user
removed some mails from is account or the mail was bounced
to the sender after some days.

Since ZCS 5.0.6 you can configure the LMTP behavior with
zimbraLmtpPermanentFailureWhenOverQuota. The value of "TRUE" will issue a 5.x.x error while "FALSE"
will generate a 4.x.x. This new setting gives me to option to revert to the
former (ZCS 4.5.x) method to not accept mails for over quota
mailboxes.

But I still see a problem here. We could end up in the follwing situation:

Lets assume that user foo@bar.com is over quota.

1. Mail to foo@bar.com is sent to the zimbra system from an external account
2. zimbras postfix will accept the mail, scan for virus and spam
3. postfix forwards the mail to the lmtp process
4. lmtp checks for over quota and returns the mail to postfix with 5.x.x error
5. postfix has to generate a bounce to the sender
6. the sender is forged....

And now the zimbra system is becoming a huge backscatter source...

What I am looking for, is a good way to tell postfix not even to accept mails for "over quota accounts".
In that case the bounce/DSN had to be generated by the remote mailserver.
I consider this to be important as backscatter is becoming more and more of a plague.
We had several threads in the zimbra forum from people searching for help against backscatter targeted to one of their users...

Is there a way to introduce some kind of over quota check inside smtpd_recipient_restrictions?

Regards
Thomas

[fvargas]

Hi,

We have the same problem.

We have the release 5.0.7_GA_2450.SuSEES10_20080630182541 SuSEES10 NETWORK edition and all the mails that exceed their quotas are put in the deferred queue.

We reduce the queue time to 1 day, but some users are asking for a response immediatly.

How can we control this behavior. The mails over quoted must be rejected with a 5.x.x code error.

Thanks for your help.

Regards.

FV

[mmorse]

Easier method available in 5.0.6+:
su - zimbra
zmprov mcf zimbraLmtpPermanentFailureWhenOverQuota TRUE

FALSE = temporary 452
TRUE = permanent 552

Bug 27838 - Configurable treatment for inbound over quota mail

[mmorse]

That was in response to fvargas - instead of reducing the time/custom bounce just use zimbraLmtpPermanentFailureWhenOverQuota mentioned by deepblue.

Deepblue is asking for the ability to put the check before it's even accepted for delivery - suppose you could script a periodic poll for the over quota accounts & put it into a hash that is set to reject in smtpd_recipient_restrictions.

Awe Bill yours still had good links - didn't have to go and hard delete your post!

We reduce the queue time to 1 day, but some users are asking for a response immediatly.

If you mean they want a notification then it can be set to any length you like.

How can we control this behavior. The mails over quoted must be rejected with a 5.x.x code error.

If this question is related to the one above, you can use the postfix maximal_queue_lifetime to set the bounce 'time'.

Postfix Configuration Parameters (Postfix Configuration Parameters)
How To Configure Custom Postfix Bounce Messages | HowtoForge - Linux Howtos and Tutorials (How To Configure Custom Postfix Bounce Messages | HowtoForge - Linux Howtos and Tutorials)

[deepblue]

Deepblue is asking for the ability to put the check before it's even accepted for delivery - suppose you could script a periodic poll for the over quota accounts & put it into a hash that is set to reject in smtpd_recipient_restrictions.

Yepp... check the quota before accepting the mail is the "right thing (©)" :-)

I will try to create a hash with quota exceeded accounts and put this into smtpd_recipient_restrictions.
But if you want to do it the right way, you have to check the size of the new message against the actual mailboxsize and quota just in time.

And even that could lead to race conditions with not yet delivered messages queued by postfix,
currently processed by amavis or not yet stored by lmtpd... But I think this is acceptable....

Regards
Thomas

[fvargas]

Easier method available in 5.0.6+:
su - zimbra
zmprov mcf zimbraLmtpPermanentFailureWhenOverQuota TRUE

FALSE = temporary 452
TRUE = permanent 552

Hi,

We applied this zmprov mcf zimbraLmtpPermanentFailureWhenOverQuota TRUE and now everything is Ok.

This is the rejected message:

Action: failed
Status: 5.2.2
Remote-MTA: dns; mail.genesistelecom.net.ve
Diagnostic-Code: smtp; 552 5.2.2 Over quota

Thanks for your help.

Regards.

FV

[shabbir mansuri]

What is the prucedure for 7.0

Please help..











We applied this zmprov mcf zimbraLmtpPermanentFailureWhenOverQuota TRUE and now everything is Ok.

This is the rejected message:

Action: failed
Status: 5.2.2
Remote-MTA: dns; mail.genesistelecom.net.ve
Diagnostic-Code: smtp; 552 5.2.2 Over quota

Thanks for your help.

Regards.

FV[/QUOTE]