After careful examination of false positives and scoring weights by SpamAssassin, all e-mail, by default, that (a) is marked as spam and (b) scores above a 10 will be deleted.  The threshold is considered if and only if the message is marked as spam.  To remove this feature just delete the section of code starting from the if … line down to the final closing brace (}) from /etc/maildroprc.  If you had made changes between today and when the global filter files were rolled out, then it was skipped over.  This accounted for quite literally only a handful of accounts, which gives a good indication of how many people actually read this blog.  Pat yourself on the back, good job!

Rationale: the majority of false positives score below an 8.  Generally for a message to score above a 10 would require multiple rules to be triggered, such as an invalid SPF record and listing in a real-time blacklist, both of which are blocked prior to the message being handed off to SpamAssassin.  Messages with invalid SPF information already pick up ~2.1 - 2.7 points depending upon the type of failure (soft, neutral, fail) and provided they make it that far, messages listed in SpamHaus rack up another ~2.8 points bringing the total score, before any further scoring attributes are evaluated, to 4.9– right below the spam threshold.  RBL and SPF mismatches are the major constituents of spam scoring, so really anything above a 10 on the server today would have likely scored a 15 or above prior to this week.

Given the marked rise in spam over the past few months, it’s time to reneg on a long-standing decision to defer RBL filtering to SpamAssassin.  Effective immediately if a sender’s IP address is listed in SpamHaus, then it will be rejected by the MTA.

The only change now is that SpamAssassin won’t be performing SpamHaus lookups, but rather Postfix will.  This should help cut down on spam that slips through due to poor bayes scoring.

Keeping up with the great shake-up as of late, there are some more internal changes going on with the servers.

1. maildrop no longer falls back to a getpwnam() lookup if lookup fails in the PostgreSQL database.  What was happening here is that Postfix handed the message off to maildrop for delivery and it checked against the PostgreSQL database for delivery locations (this is what “Manage Mailboxes” does).  Ideally, if an account were disabled (gray + italicized), then lookup would fail and delivery would cease.  Unfortunately what ended up happening is that maildrop fell back to getpwnam() on the full e-mail address, which incidentally is how users are managed on the server.  Although a user may have gone over quota and was then disabled to prevent further mail from piling up, in actuality it still found the user and hopelessly tried to deliver the message.
2. maildrop’s permissions have also been relaxed.  Many users were editing the .mailfilter files and uploading with the default 644 permissions.  maildrop is rather finnicky and requires 600 in order to be read for security reasons.
3. A global filter file has been added to all sites, named /etc/maildroprc.  This filter is executed prior to individual filters in $HOME/.mailfilter. Because we will invariably have a conflict between the new global filtering definition in /etc/maildroprc and individual SpamAssassin calls (xfilter “spamc -u $USER@$HOSTNAME”) , SpamAssassin filtering will be deferred to the global filtering file leaving local filters in $HOME/.mailfilter to handle the post-processing.  This shouldn’t pose a significant change for anyone.  A global filter allows for easy filtering across all users — something I’ve seen constantly requested.
4. File descriptors on Apache have been increased from 1,024 to 4,096 in response to the new bandwidth logs.
5. The maximum number of concurrent clients on Apache has also increased from 256 to 384 following an isolated occurrence on Image late last week.
6. FTP bandwidth data was garbage and has been purged.  Likely it’ll be necessary to parse the xferlog for transfer stats.

Filtering rules will take effect tonight between the hours of 12 AM - 2 AM EDT (-0400 GMT).  Your old filter file will be renamed to .mailfilter-apis.  The only change is that everything between “#BEGIN SA_CONFIG” and “#END SA_CONFIG” will be stripped from the filter file, leaving most folks with an empty filter.

If you have any other usage questions, head over to the Resource Center.

New esprit update introduces the rudimentary bandwidth tracking.

• Added: bandwidth cleanup script
• Fixed: unnecessary to complain about missing Urchin profiles if none were setup
• Changed: reordered dashboard pages, Site Maintenance -> Reports -> User Management -> Tools

Currently all HTTP, HTTPS, body, and header traffic is lumped into one category.  Whether this will change or not is contingent upon mod_logio.  Since tracking is tied directly to mod_logio, there won’t be any issues with incorrect figures.

Mandatory SPF checks will be implemented on the servers starting tomorrow afternoon.  This will hopefully combat the deluge of spam customers have been receiving lately.

If you are receiving Undelivered/Undeliverable messages,  then make sure you visit the “SPF Wizard” within the control panel to add an SPF record for your domain.  If you are using Apis to send e-mail — which should look configured as such — then the default settings should help limit the amount of backscatter you are currently receiving.

Failing that, there is one more idea with maildrop presets, but let’s see what happens.

12:49 PM EDT — SPF checks are now implemented on all of the servers.  You should begin seeing a reduction in spam.  Also, make sure the SPF record is a strict fail (-all) instead of a softfail (~all).  You may edit the TXT record via DNS Manager if it is a softfail.

Good news for me, bad news for everyone else, I have an amicable solution for handling bandwidth tracking on the new servers.  Instead of going the cumbersome method of writing an Apache module to track bandwidth, I will be taking a page from cPanel’s book and just writing traffic to a flat file.  Every night at approximately 3 AM a script will reconcile the bandwidth logs and dump it into the database.  There is a marginal hit on filesystem performance, but again this is a far better solution than Ensim’s cumbersome configuration file parsing, plus we will still be able to retain the rapid Web server restarts that we have all grown to appreciate and love.

Currently, the script to parse and dump the logs into the database is being written and should be live no later than Saturday morning.

IMAP/POP3 and SSH traffic are negligible.  Dedicated port traffic will be next on the list of problems to solve… possibly with some iptables packet counting.

- Matt

New version of esprit is live on the servers at this time…

• Added: WebDAV support
• Fixed: Inherit uid from directory in  File_Module::fix_apache_perms_backend
• Fixed: sub-delegated hostnames are skipped in DNS Manager (NS RR type)
• Fixed: rewrote how DNS records are added; since nsupdate won’t give us the nameserver’s error message, first add the record, check for existence, then if the change did not go through run the modified zone configuration through named-checkzone

Disk quotas have finally been doubled from their initial figures as promised “back in the day”.  The first step was a 50% increase from 350 MB to 525 MB and the second step doubled the initial disk quota to 700 MB.

All sites should have these changes available at this time.  Packages have been updated to reflect the new disk space allocations.  Next step is to once again count apache-owned files towards the quota.  Once completed, disk space upgrades will be taken care of for some time to come.

Due to popular demand, and a stable release, RoundCube support has been added to all accounts, accessible via http://roundcube.<your domain>/

Have fun with the snazzy, new webmail client.

The kernel on Aleph will be upgraded to 2.6.25 on May 3rd at 1 AM EST (-0500 GMT).  There will be a brief 3 - 5 minute period of service interruption as the server is rebooted.  We will be performing the kernel upgrade to assess the changes in the sky2 network driver used on the servers.  Currently with 2.6.24 we still see intermittent timeouts once every several days lasting 20 seconds when the network card “hangs” and is restarted.  While these are rare, ensuring optimal stability around the clock is important.  If the sky2 driver fixes eliminate the hangs, then 2.6.25 will be rolled out on all the servers in 10 - 14 days.
Update: the new kernel will also include offline support for the second processor to reduce power consumption during non-peak hours.  This feature will be demoed on Saturday night as well between 2 AM - 9 AM EST.