John Morrissey wrote: > > On Tue, Sep 09, 2003 at 09:02:28PM +0200, Andre Oppermann wrote: > > In our opinion Trash should not be counted but periodically emptied > > with a cron job and find -delete. > > This is going to be difficult for large sites to swallow. We have about > 2.4TB of disk in use for user mail (and growing), so find(1)ing over the > Trash folder in all of those Maildirs quickly becomes prohibitive in cycle > time (time it takes the job to finish and start scanning from the beginning) > as well as disk I/O operations.
I see. > Plus, it keeps our users honest by counting what's in their trash. That way > they can't hide large messages there (or forget about them) and suck disk > space between cron job runs. Also, Courier-IMAP has a compile-time option to > count Trashed messages toward the quota. I know about that Courier-IMAP feature. Will discuss this with Claudio again. Maybe we will make it a compile time option. BTW: We are very much looking to move away from recommending courier- imap. Mr. Sams coding style isn't very good and his world order of running the stuff is not our cup of tea either. We'll announce when we've decided for someone else. > > I don't think the moreipme patch is the right way to solve the looping > > problem. I'd say qmail-remote should detect 'itself' by some cookie in the > > smtp greeting. All smtp accepting and speaking hosts would have a common > > random cookie string they will check for. SMTP server is saying "220 > > blabla cookie123" and qmail-remote will check for that. > > Transparent layer 4 switching still presents a problem that way. We've had > spammers set up MX records destined for our external cluster address before > spamming us. Bastards! :-( > Checking for a local token in the SMTP banner only prevents mail from > looping back to the same host - it can still go out through the switch, get > load balanced coming back in, hit another machine in the cluster, and > oscillate back and forth, creating another huge mail loop. Nope, see below. > I'm not sure how to prevent this cleanly using token detection unless the > token is hardcoded across all machines in the cluster. Using the machine's > domain name for the token presents problems because some sites may have > split clusters in the same domain, or may use an smtproute to dump mail to a > temporary machine in that domain during an emergency situation. The cookie is supposed to be the same for all smtp listeners and senders who are not supposed to talk to each other. I've already coded that two hours ago. In ~control/smtpclustercookie you define your cookie. Any two hosts with the same cookie will refuse smtp connections from each other. And hard bounce right away. > > If it finds it boom. Other than that you can reject messages from the same > > cluster via smtp tcpserver. Put the ip addresses of local sender there. > > Those messages will still sit in the local queue forever[1], though. If > qmail-remote rejects the message immediately, it bounces and is gone from > the queue immediately. Hmmm... Will code a qmail-smtpd environment variable that allows to reject a connection with a 550 in the greeting. Set that env var in tcpserver and 550 goodbye. > [1] Until they've finally reached queuelifetime and bounce. > > > > * IP-based POP3 virtual hosts > > > qmail-ldap-virtualpop3-20020901.patch > > > > We don't think one should have one ip address per domain. However > > everyone is free to apply this patch themselfes. > > Don't consider all IP-based hosting "evil." We use it to host three large I don't consider it evil as such. I just afraid that some smartie is going to get an ip for every of his howmanyever domains to avoid uid name clashes. > (several hundred thousand mailboxes/each) domains on a single mail cluster. > The users are treated identically (except for the domain name), and it > simplifies management for us to have a single cluster that handles all of > them. The only thing ip based pop3 solves is the uid name space collision problem. We'll think about that too... No promisis though. > With IP based virtual hosting, we can do this. Without it, we'd have to > spend hundreds of thousands of dollars in labor to contact our entire > customer base to update their settings. In return for a /27, we save > $x00,000. ARIN hasn't batted an eyelash at our justification for this. I agree that for mergers this makes a lot of sense. > If it helps, think of IP based virtual hosting as a tire iron. I can use it > to swap the snows onto my car in the fall, or I can use it to kneecap the > guy who keeps tossing his empty beer bottles onto my front lawn. Just > because it has the potential for causing harm doesn't mean there aren't > legitimate uses for it. I'm not saying it is bad or evil. Just that is has to be used with due care. It should not be too easy to go that way. Some sort of justification should be required. > > > * Add a Status: header to messages retrieved via POP. I don't know who > > > wrote this, but googling for it will probably turn it up. If not, I > > > can always post a copy. > > > qmail-pop3d-status.patch > > > > What is the advantage of this? > > Our users can retrieve their mail via POP3 or via a webmail interface. If > they read a message in the webmail interface, this patch will add a Status: > header to the message when it's fetched via POP3. Some (most?) MUAs will > honor this header when displaying message status, so the message will also > appear as read in their MUA. Can you give some specific example how such an Status line looks like? Is there a specification somewhere? I'm unable to find that patch with google. > > > * Sync file metadata along with the file itself (by syncing the > > > directory). I believe this is required when running qmail on Linux due > > > to differing file semantics as compared to the *BSDs. > > > http://www.emptybox.org/collections/daemons/qmail/qmail-link-sync.patch > > > > Depends on the filesystem. We don't add that because it's Linux and > > mostly ext2 specific. > > AFAICT, all Linux filesystems exhibit this behavior unless you have a recent > kernel and use the 'nodirasync' mount option. Why not offer Linux safety by > using a build-time option for this (like DASH_EXT et al already have)? Used > when it's needed, not used when it isn't. Lame answer: We're running *BSD here. Actually we haven't met many (any?) Linux user who actually did care at all. When presented the option all have chosen super fast async ext2/ext3 over slow reliable queueing. For power outages they've got the UPS. So no problem and no "risk". Yea, sure... -- Andre
