[Mimedefang] Where is my "quota exceeded" message?

Jan Pieter Cornet johnpc at xs4all.nl
Mon Mar 13 17:46:10 EST 2006


On Mon, Mar 13, 2006 at 04:34:53PM -0300, Roberto Machado wrote:
> I'm trying to implement disk quotas in my system, and I'm having a few 
> difficulties:
> 
> 1) first I configured quotas in my filesystem, and I'm  using 
> procmail, so everything should be straightforward. And actually works, 
> but when I get bounces, sendmail returns simply:
> 
>    ----- The following addresses had permanent fatal errors -----
> <user at domain.com>
>     (reason: Can't create output)
> 
>    ----- Transcript of session follows -----
> 550 5.0.0 <user at domain.com>... Can't create output
> 
> The "quota exceeded" is apparently default, but I can't see it in my 
> system. Now, the reason for my post: could Mimedefang be interfering 
> with it? Procmail, when ran manually, gives me the correct output:

It's unlikely Mimedefang interferes here. Sendmail reports the exit code
from the local delivery agent (see /usr/include/sysexits.h), and "quota
exceeded" is not a possible return value, so procmail returns something
else. Apparenly it returns EX_CANTCREAT. However, sendmail should
normally also include STDERR of the delivery agent, which should include
the message you saw. I don't know why that is missing.

> 2) Particularly, I would like to implement quotas solely within 
> Mimedefang, but from what I rad, Mimedefang won't allow me to do it 
> ellegantly. filter_recipient passes the first envelope recipient and 
> rejects the whole message, while MILTER provides the proper hook to 
> simply reject a single "rcpt to". It is true that I am a few versions 
> behind on Mimedefang. Has it been changed? You folks have some idea on 
> how to implement quotas through Mimedefang, doing the right thing 
> (i.e,, rejecting the bad recipient in the smtp recipient envelope 
> message)?

That is exactly what we do now, and it works fine, except for one minor
buglet that I consider a feature ;)

For all practical purposes, you can trust the SIZE= parameter from the
MAIL TO command. It isn't there all the time, but in that case just
assume the mail is 1 disk block (usually 4k).

What we do is check if the user's disk quota is completely maxed out,
or if the incoming mail is bigger than the user's mailbox size. If
that is the case, we return a "552 5.2.2 quota exceeded" permanent error.
However, if there still is room in the users mailbox, but usage + msg_size
exceeds disk quota, then we give a 452 4.2.2 quota exceeded temporary
failure.

Note that it is perfectly acceptable to reject such mails on a per-RCPT
basis, without failing the entire email, and it has always been like
that in Mimedefang as far as I knew, so you might have misread the
documentation. Also, be aware that you need to explicitly pass the
msg_size sendmail macro to mimedefang, or parse the SIZE= parameter
on the MAIL From: line yourself (the parameters are passed as one
of the arguments of the filter_sender call, on more recent versions
of MIMEDefang).

Also, on our OS (FreeBSD), the defang user is able to see quotas of
other users, but, as Jim also mentioned, if that isn't the case, then
you need to use some sort of trick. Running mimedefang as root is likely
a bad idea, but you might be able to hack together a quick "quotad" that
gives out quota information over a unix domain socket only readable by
the defang user.

Now the only gotcha is this: if the user setup a .forward (usually
with a "copy to self" \username entry too), then mail will start
bouncing once his mailbox fills up, as users are likely to do
when they forget about the "copy to self" feature. This is sometimes
surprising, and this has happened several times, but I've never heard
any complaints :)

Using this method we reject about 5 emails per second, on average, that
would otherwise have bounced back to a (possibly forged) sender.

Our current code is pretty heavily tailered for our specific
configuration, so it'd be useless to share. Hm.. I do recall posting
this to the list earlier, you might find my previous posting in the
archive, I think I posted some skeleton code that time.

All the best,

-- 
Jan-Pieter Cornet <johnpc at xs4all.nl>
!! Disc lamer: The addressee of this email is not the intended recipient. !!
!! This is only a test of the echelon and data retention systems. Please  !!
!! archive this message indefinately to allow verification of the logs.   !!



More information about the MIMEDefang mailing list