My experience with quotas is quite limited, but... Björn Puttmann wrote: > 1) most importantly this could end up in emails bouncing back and forth > from one mail account to another if both accounts create a bounce message.
If your recipe is generating these mails, it should add a header which it can check for, eg. "X-Loop-Prevention" or something. In the worst case scenario, you send an "over quota" message, the other side returns one to you, then you stop when you see your own header. > 2) the return code of 75 is (as far as i know) not really specific. It > only refers > to a temporary failure while trying to deliver the mail locally. Consider instead that is *is* a temporary failure. The user can't accept mail right now, but they will later when/if they clean out their inbox. I know this isn't a solution, but it's worth considering why this is a temporary failure instead of a permanent one. Returning an message to the sender like this is like a bounce, is there a way to tell `deliver` to treat it like one and give a better return code? > Is there any way to prevent postfix from calling mailbox_transport > for an account that is over quota and instead produce a bounce message > notifying the sender of the fact that the mail could not be deliverd? My knowledge is shaky here, but this would require the delivery agent passing a message back to postfix to tell it it's no-good. I assume this isn't an issue for postfix's inbuilt local delivery agent, as it just tries to write files and will know immediately if there's a problem. There's no way to know that delivery will fail unless you try, and postfix doesn't know about quotas.
signature.asc
Description: OpenPGP digital signature
