Date: Tue, 11 Jun 2002 15:20:50 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Paul S. Puth" <pputh@oanet.com> Cc: freebsd-current@freebsd.org Subject: Re: looking for warn quota tools Message-ID: <3D0677C2.ED706536@mindspring.com> References: <5.1.0.14.0.20020611152151.00acbb30@pop.oanet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Paul S. Puth" wrote:
> I am looking for a tool that will email to the user if his/her account
> (more specifically email box) is approaching quota limit. I've searched
> everywhere for such a tool but to no avail.
>
> On Linux, there is a tool called "warnquota" that fits my need but I am
> running FreeBSD 4.5 -RELEASE so I can't utilize that tool. Also, from
> searching on google, I've found a tool called "psntools" that has the
> warnquota feature but it doesn't work on a filesystem that has a mailspool.
>
> Can someone help me?
The "warnquota" program is a program that's based on you using
Cyrus IMAP for you message store.
We are not talking about disk quotas here. In fact, we can't,
since disk quotas appear as write errors for the MDA (the "local"
mailer), not accept errors for the MTA (the SMTP server).
FWIW: It's kind of a dumb idea to send email warning about a
condition which is caused by having too much email. We did
this on the InterJet, and it was actually a pretty dumb thing
to do; you end up with a recursive problem that's unsolvable
-- you basically have to let certain cenders be "priviledged"
for the delivery of the messages, which means hacking both
the MDA ("deliver") and "warnquota".
Another issue is that quota enforcement only occurs *after*
you exceed the quota, not *when* you exceed the quota. This
is because email messages must be treated as atomic units; so
if you are within 3k of a 100k quota, and you get an 80k message,
you can't not accept it.
Further, quota enforcement involves a quota *on the mailbox*;
an interesting side effect of this is that the following happens:
1) You receive a message to the local queue which, if it
were delivered, would push the user over quota (or the
user is already over quota)
2) You attempt to deliver it, and delivery fails because
of the quota
3) You leave the message in the queue, to retry later, in
hopes that the user has reduced the size of their mailbox
So not matter how you look at it, if you deliver it don't deliver
it, it's taking up your disk space, whether you have quotas on
users or have no quotas on users.
The way "HotMail" handles this condition is to drop email that
it has accepted to delivery, if it can't be delivered to the
user because of them being over quota. But since it has
already accepted the email for delivery (by sending "250 OK"
to the remote SMTP client or MTA, it has pledged to deliver
the message, or give failure notification, so the message
contents are not lost), the email is basically lost with no
recourse. The inability to guarantee delivery is the basis
for the liability disclaimer, and the terms of service not
allowing business use of the service (i.e. to prevent legal
liability problems).
You really don't want to bet your business on this level of
(dis)service.
Basically, the only way to really handle this is to refuse
delivery at the SMTP level.
The problem with doing this is that you would have to do
it on a per maildrop (locally hosted email address) basis.
This, in turn, requires that your MTA have promiscuous
knowledge of the quota information in a per maildrop basis.
I.e. you must tightly, rather than loosely, couple the MTA
and the maildrop storage management, not simply hand off the
delivery to a "mailer" after it's been accepted. This means
that you introduce a delivery latency into the "250 OK"
response.
In addition, message bodies are sent via the SMTP protocol
*after* the addresses are accepted/rejected. This basically
means that if the peer machine does not use the "SIZE extension"
to indicate on the "MAIL FROM:" SMTP command the size of the
message that will be sent -- OR it lies about it/gets it wrong
(the SMTP SIZE extenson normally does *NOT* give an absolutely
accurate representation because of transfer encoding and wire
encoding differences, which tend to change the size), then you
are still screwed, by having said that you will accept a message
that you can't deliver.
The only upside in this is that you can ignore the size, and
only reject addresses that are actually *over* quota -- rather
than addresses that would be pushed over quota by the current
message.
That leaves you with the requirement that you allow the mailbox
to go over quota by one message, but that you claim 101% is the
same as 150%. Otherwise, you are stuck with the message in the
local queue, but locally undeliverable for an indefinite period
of time.
The obvious problem with this is that, no matter what your per
account quota is, you can't prevent the delivery of any message
which is less than the maximum size that the server is willing
to accept from a peer via SMTP. So setting a maximum transfer
size of 10M, with accounts with 1M quotas, means that each
account can in fact end up with 10M - 1 byte over quota.
Now... if you are going to go to all this trouble... then the
"over quota" email should actually be metadata about the account;
and then when someone goes to download, there are two bits:
"over quota" and "over quota message sent". The message gets
"sent" by generating it on the message download: in other words,
it's not real. This keeps it from taking up quota space, itself.
Personally, I think that the idea of quotas is pretty lame,
relative to deliverability, unless you rewrite your SMTP
server to tightly couple to the per maildrop message store
(e.g. so you can say "421 Over quota" when they give you a
"RCPT TO:<user.who.is.over.quota@example.com>").
Since one of the fundamental design issues in SMTP servers is
reduced latency, don't expect to be able to do this easily with
sendmail, qmail, postfix, or most other mail servers that you
don't buy from a commercial mail server vendor without quota
enforcement already on their feature list. And if you do buy
a mail server to get the feature, be sure that it handles the
quota enforcement at the "RCPT TO:", rather than after the
"DATA", or you aren't actually saving any disk space by having
the ability to set quotas.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D0677C2.ED706536>