On Tue, Sep 09, 2003 at 09:02:28PM +0200, Andre Oppermann wrote: > > * Count messages in the Trash toward quota (compile-time option) > > qmail-quota-include-trash.patch > > 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. 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. > > * Latest moreipme patch - almost a requirement for operating behind a > > layer 4 switch. > > http://www.suspectclass.com/~sgifford/qmail/ [snip] > 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. 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. 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. > 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. [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 (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. 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. 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. > > * 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. > > * 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. john -- John Morrissey _o /\ ---- __o [EMAIL PROTECTED] _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
