At 08:50 AM 4/19/2002 +0200, Mark wrote: >But I am even far less a fan of limiting the frequency with which users >check their mail. It sounds great, at first glance, but is a System >Administrator's nightmare in the making. Steve, if you are worried about >customers calling in, wait until you start refusing connections as a >"throttle" measure. And they would actually be right, too; from the client >end, your server would simply appear broken -- that is, unless they check >for return codes, which you know they will not do. Their client software >may, or may not, show a legible reason for why mail cannot be retrieved, but >that is not for qpopper to assume that it will -- nor even for us to assume >that the user will then know how to interpret it. I would even go as far as >to say that the user will likely NOT no what to do, and will wind up writing >me, ten times a day, telling me the server is broken, and would I please fix >it.
Yes, whatever action is taken it should not appear as an error on the POP server. But, a 10 minute delay in receiving a message would, for many of our users, be seen as an error. Of course, being a university, our services are "free" to our users, at least in the sense that they are not sent an itemized bill. As such, the performance demands are often unreasonable. >As has been pointed out, UID's are cached. What one COULD do, for a client >who connects too soon after his last check, is to simply reply that he has >no new mail. You see, that is something that I could support (not that I >have a say in it, really, but just the thought.) From the server end, >qpopper would simply forego checking the mail for real, but in its >functionality towards the connecting client be fully transparent. To the >client it would just appear as not having new mail yet; no disconnect, no >firewall-like stumbling blocks; just qpopper reporting he has no new mail >yet. And the implementation thereof would be real simple too. Just one >per-UID ticker, which you reset at each connection; and you only really >check for mail when it has been, say, 5 mins after his latest check. I've considered this, and the .cache files makes it easy. Better, as some have pointed out, is having some graduated mechanism, perhaps based on mailbox size. If you keep an empty mailbox, you can check once a minute--no big deal. If you never delete mail, then you can check once an hour unless the load is high. At one time I ran a script which checked the log file for pops, and enforced an average checking time. Say, 12/hour. If you used those 12 in 12 minutes you needed to wait until your average was back below threshold. In practice, this worked nicely since a reasonable user could hit "check mail" a bunch of times when expecting a new message. But, lets consider what the real problem is. The real problem is a protocol and program which make checking large mailboxes frequently an expensive operation. There is no reason for this. The .cache file has made the checks less expensive, and the only problem now is that large mailboxes are still too expensive. I've already suggested extending the cache mechanism to reduce the cost of a large mailbox. Another idea is to amortize the cost, by incurring it during delivery. Consider, is there ever a good reason to parse the mbox? Is there ever a good reason to re-write the mbox, except when messages are deleted? What if the cache file where considered an index into the mbox, and the local mail delivery program updated the cashe file when new messages are delivered? Now, even a big mailbox with a new message is cheap, except for disk space and a longer seek time. (Yes, this is a the DB index into mail solution discussed recently, with the cache file serving as the DB.) The problem is not users who check mail every minute---they are simply using the tools available. The problem is that the tools do not take into consideration the stress placed on the back-end system. That system was designed when email was small and infrequent. Now it is large and frequent. Guess what, the Internet has been successful---more and more people are using it for more and more things. At one time, that was the goal! Well, be careful what you wish for, it may come true. (Or course, better yet would be charging by the message, since users can then decide if the cost is worth it, and administrators would have an incentive to sell more, and larger messages. Alas, for some reason in the hyper-libertarian world that is the Internet, this option is rarely mentioned, and less frequently taken seriously :-) Mike P.S. Believe me, this is on my list. But, my list is very long and more pressing "free" services need my immediate attention. -- Michael Sofka [EMAIL PROTECTED] CCT Sr. Systems Programmer email, webmail, listproc, TeX, epistemology. Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
