From owner-freebsd-current Tue Jun 11 15:21:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 1794A37B407 for ; Tue, 11 Jun 2002 15:21:36 -0700 (PDT) Received: from pool0186.cvx40-bradley.dialup.earthlink.net ([216.244.42.186] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Hu13-0005AB-00; Tue, 11 Jun 2002 15:21:30 -0700 Message-ID: <3D0677C2.ED706536@mindspring.com> Date: Tue, 11 Jun 2002 15:20:50 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Paul S. Puth" Cc: freebsd-current@freebsd.org Subject: Re: looking for warn quota tools References: <5.1.0.14.0.20020611152151.00acbb30@pop.oanet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "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:"). 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