SMTP Mail Server (SMTP-AUTH, TLS, tarpitting, RBL) http://www.tnpi.biz/internet/mail/toaster/patches/ Virtual Domain Hosting w/delegated administration Virtual Domain Users Mailing List (Ezmlm) AutoResponder Web Based E-Mail (Sqwebmail, Squirrelmail, V-Webmail) Web Based Domain Administration Mail Filtering (rblsmtpd, SpamAssassin, Qmail-Scanner) Virus Scanning (ClamAV, F-Prot, Uvscan) SMTP roaming via SMTP-AUTH, POP-AUTH, & IMAP-AUTH POP3, POP3-SSL IMAP, IMAP-SSL (Courier IMAP) CGI frontend to mail features Log processing and pretty graphs (via RRDutil) Auto-Installs of MySQL, Apache, phpMyAdmin, and more Centralized configuration files Support for clusters of qmail servers Builds self-signed SSL certs for Apache (HTTPS), Qmail (SMTP TLS), & Courier (IMAPS/POP3S)
All of the following *can* be installed but you have control via toaster-watcher.conf over many of the optional installs. You also have control over many of the popular options for building certain programs like MySQL, Apache, Vpopmail, etc.
Qmail : Secure, fast, and reliable MTA MySQL (3,4) : Database engine ucspi-tcp : Inetd replacement daemontools : Tools for managing daemons ezmlm-idx : Mailing list management Apache (1,2) : Secure HTTP server Apache mods : mod_php, mod_ssl, mod_perl OpenLDAP : LDAP client vpopmail : Virtual Domain module qmailadmin : Vpopmail domain administration vqadmin : Vpopmai system admin panel autorespond : Auto Responder & vacation gdbm : Database routines ispell : Spell checking for web mail qmailadmin : Web Control Panel Interface sqwebmail : Web based email squirrelmail : Web based email courier-IMAP : IMAP & POP3 servers maildrop : procmail like mail deliver agent spamassassin : spam filtering program clamAV : Virus scanning software qmailscanner : content scanner for qmail maillogs : mail log processor rrdutil : MRTG like graphs Mail::Toaster: Perl modules for mail systems MATT::Bundle : Perl modules for unix systems razor : Spam signatures database pyzor : Python spam signatures database dcc : Spam fighting tool procmail : mail delivery agent maildrop : Procmail like mail delivery agent socklog : pipe qmail logs to another host cronolog : automatic log rotater qmailanalog : useful for summarizing qmail logs isoqlog : qmail log processor, pretty HTML gnupg : GNU version of PGP automake : GNU automake autoconf : GNU autoconf gmake : GNU make Perl modules:
Compress::Zlib, HTML::Template, Crypt::PasswdMD5, Net::DNS, Crypt-OpenSSL-DSA, Crypt-OpenSSL-RSA, DBI, DBD::mysql, TimeDate
pop3://mail.example.com imap://mail.example.com pop3s://mail.example.com imaps://mail.example.com http://mail.example.com/cgi-bin/sqwebmail https://mail.example.com/cgi-bin/sqwebmail http://mail.example.com/squirrelmail https://mail.example.com/squirrelmail
Mail::Toaster::CGI showcases the toasters functionality. See it live at: http://mail.cadillac.net/
Point a web broswer at https://mail.example.com/cgi-bin/qmailadmin
This is now part of Mail::Toaster and has been renamed mailadmin. If you have installed Mail::Toaster recently, you'll find the latest copy in /usr/local/sbin/mailadmin.
mailadmin perl script - Front end to nearly everything you can do with the vpopmail programs and a bunch of handy fixup utilities for qmail systems. http://www.tnpi.biz/internet/mail/toaster/maildomain/maildomain.pl
tai64nlocal < logfile > qmaillog.tmp
1. qmail queue | more 2. qqtool -a list 3. rrdutil 4. isoqlog 5. Manually feed qmail-send output through matchup and pipe the results through a processor (all one one line): /usr/local/qmailanalog/bin/matchup < /var/log/mail/send/current | /usr/local/qmailanalog/bin/z* where z* is one of the following: zddist, zdeferrals, zfailures, zoverall, zrecipients, zrhosts, zrxdelay, zsenders, zsuccesses, zsuids
echo "local" > /usr/local/share/sqwebmail/calendarmode
The scripts are extensible in anticipation of using them on platforms other than FreeBSD where they were developed. My next "supported" OS is Mac OS X and much support is already included for it. Linux may follow but Linux fans might want to check out Bill Shupp's toaster pages. Here's a couple URLs for you: http://www.shupp.org/toaster/ and http://qmailtoaster.clikka.com/.
Contents of ~vpopmail/etc/tcp.smtp (fix wrapped lines):
127.:allow,RELAYCLIENT="" 209.218.8.2:allow =:allow :allow,RBLSMTPD="Blocked - Reverse DNS queries for your IP fail. You cannot send me mail." #:allow,RBLSMTPD="-Blocked - Reverse DNS queries for your IP fail. You cannot send me mail." line 1. Obvious, allows localhost to relay. line 2. Allows traffic from the inter7 email list line 3. Matches any mail message with reverse dns.
line 4. Matches what's left (no reverse DNS). By setting the RBLSMTPD environment variable, we actually get to pass a message back to the mail server we're blocking telling them why. That gives them a chance to fix it before the messages bounces.
They'll get a message like this in their mail logs:
Mar 27 08:40:43 seattle qmail: 1048783243.397888 info msg 6469: bytes 258 from qp 13226 uid 0 Mar 27 08:40:43 seattle qmail: 1048783243.438981 starting delivery 533: msg 6469 to remote matt@simerson.net Mar 27 08:40:43 seattle qmail: 1048783243.979048 delivery 533: deferral: 207.89.154.94_does_not_like_recipient./ Remote_host_said:_451_Blocked_ Reverse_DNS_queries_for_your_IP_failed. You_cannot_send_me_mail. Giving_up_on_207.89.154.94./
line 5. If you want to be a little more aggressive about it, use the 5th line instead of the fourth. Notice the '-' character in there. That tells rblsmtpd to return a permanent error (ie, don't try again!)
Mar 27 08:42:40 seattle qmail: 1048783360.776812 info msg 6475: bytes 250 from qp 13464 uid 0 Mar 27 08:42:40 seattle qmail: 1048783360.805534 starting delivery 534: msg 6475 to remote matt@simerson.net Mar 27 08:42:41 seattle qmail: 1048783361.259737 delivery 534: failure: 207.89.154.94_does_not_like_recipient. Remote_host_said:_553_Blocked_-_Reverse_DNS_queries_for_your_IP_fail. You_cannot_send_me_mail. Giving_up_on_207.89.154.94./ Mar 27 08:42:41 seattle qmail: 1048783361.269637 bounce msg 6475 qp 13467 Mar 27 08:42:41 seattle qmail: 1048783361.270564 end msg 6475
Notice that in the second case, the message bounces immediately. It's your mail server, you have to decide what policy you think is best. Bouncing messages seems to get more attention, and gets it faster than deferring connections.
That's all there is to it. Of course, that assumes you are running rblsmtpd as part of your smtp invocation.
See the Filtering section at http://www.tnpi.biz/internet/mail/toaster/filter.shtml
Use qqtool: http://www.tnpi.biz/internet/mail/qqtool/
See this post to the mailing list for a possible explanation: http://matt.simerson.net/cgi-bin/ezmlm.cgi?mss:2006:pnonldigcpgkfpehlcgo
toaster_watcher.pl now includes this functionality. Simply enable it within toaster-watcher.conf and it will do the job for you.
http://www.tnpi.biz/internet/mail/toaster/patches/tcpserver-mysql.shtml
The patch adds MySQL query support to tcpserver. The patch will allow tcpserver to query a Mysql server for each new connection and set RELAYCLIENT based on the presence of the remote IP in the table. This is a very useful and popular patch.
The html temples live in /usr/local/share/sqwebmail/html/
The html templates live in /usr/local/share/qmailadmin/html/
See contrib/httpd.conf-2.0.diff in the Mail::Toaster distribution.
There are several anti-spam mechanisms in place. The first is RBLs.
Layer 1: RBLs
RBL's that deny SMTP connections to your server have no concept of email addresses. They only know whether the remote address is a blacklisted or not. So, if someone is blacklisted, you only have two choices:
a) use the blacklist and deny connections b) use the blacklist and whitelist specific IP's c) don't use the blacklist
I choose b. I strongly desire to block volumes of crap before my SMTP server has to deal with it. In the few cases where a remote server is misconfigured and gets blacklisted, I have no problems being one of many servers they can't send mail to until they get it fixed. This is a form of policing the Internet and making careless or just plain naughty mail server owners become good netizens.
If a RBL is unjustly blocking too much for your organizations policies, you'll want to disable it.
Layer #2: Patches to qmail-smtpd.
We block invalid users (based on qmail-chk-usr patch, and have the badmailfrom, badrcptto, and other patches which you'll need to read up on to understand how to use. However, there isn't (as far as I know) any whitelisting. Even if there was, I wouldn't consider it beneficial.
Layer #3: Qmail-scanner.
If you've chosen to use it. It can filter based on external programs (ClamAV, SpamAssassin, etc) as well as things like attachment extensions, keywords, etc. It's very powerful, but has substantial resource requirements so use it with care.
The aforementioned layers are at the system level and settings there apply to your entire mail server. If you must employ different policies for different users, then you must do one of the following:
a) run multiple SMTP servers (on unique IPs) with different policies b) choose a "lowest common denominator" policy
The final layer of protection is at the mailbox level. This is where the user gets to opt into using SpamAssassin, and routing suspected spam into a .Spam folder. If there is to be user selectable preferences, this is where they belong, and eventually I'll work in some Squirrelmail -> SpamAssassin integration so users can tweak their preferences.
There are other mechanisms available for fighting spam but none that are easily implemented or that don't have other nasty side affects.
Layer 4: Maildrop
Maildrop is much like procmail and is used for the same reasons. After the message has passed through all the checks above, we can do some very sophisticated processing of the message. For example, the default mailfilter I wrote and include with the toaster does the following:
1. process messages < 256k through SpamAssassin 2. Process any user specific rules 3. verify users mail quotas 4. delete any message with a spam score > 12 5. Deliver spam message to Spam folder 6. bounce message if Mailbox is over quota
You have some very powerful tools included with the Mail::Toaster that will let you deal with each message in any fashion that you'd like. The only limits are your knowledge of the available tools and you are encouraged to learn them.
Simple answer: No.
Long answer. I never recommend portupgrade -a on a production server. There are a variety of reasons for this:
Broken Binaries
Read the portupgrade man page for details.
Overwrites custom binaries
The toaster setup installs some customized binaries such as the heavily modified qmail package. If you let portupgrade "update" qmail, then the special anti-spam features go away. Ouch.
Does not honor make options
You'll note that toaster-watcher.conf has lots of options for configuration how certain toaster components are installed. We'll take MySQL for example. You might want it installed with ssl or linuxthreads. The toaster setup script honors those settings, but after portupgrade "updates" your MySQL, those special features are gone.
Because of the aforementioned reasons, many folks end up breaking their mail systems after running portupgrade. The best advise is have a development server to test on first. If it doesn't break your dev server, then it'll probably work find on your production one. Be very careful updating any programs installed via toaster_setup.pl. If you do upgrade something and break your toaster, run through the setup again, and it should repair the damage.
First, you need to understand what a "normal" processing time is. On my server, I do DCC, Pyzor, Razor2, and the rest of the "normal" checks. If I have RBL checking on, then processing a message takes a couple seconds. If I disable RBL checks, messages processing drops to less than a second. This is on a pretty old server (Dual PIII 650) with 1GB of RAM.
If your processing time is extraordinarily different, That could be one of several reasons:
DNS timeouts
By default, SpamAssassin does RBL lookups against several blacklists. Make sure your DNS works well. If you are doing RBL checks via SMTP, then you may want to disable the RBL lookups in SpamAssassin. You can do that by adding "skip_rbl_checks 1" to /usr/local/etc/mail/spamassassin/local.cf.
If a RBL that SA is trying to contact is down, it may also introduce an extended timeout. Disabling the RBL checks is a good way to diagnose this. I run all the RBL checks at the SMTP level so I can deny the messages and thus avoid having to process them. As such, it makes little sense to have SA also running RBL checks.
Firewall blocking
SpamAssassin can use DCC, Razor2, and Pyzor. Those modules require contacting network servers. If your firewall rules are blocking those connections, this will introduce a timeout that hangs SA for 5 seconds per check. So, if your message processing time takes 11 seconds and it should be taking about 1, then you are likely blocking a couple checks. I added the following rules to my IPFW firewall:
# Allow DCC (6277) & Pyzor (24441) ${fwcmd} add allow udp from ${oip} to any 6277,24441 ${fwcmd} add allow udp from any 6277,24441 to ${oip} 1024-65535
I did it as follows:
Create the MySQL database
http://eu.spamassassin.org/full/2.6x/dist/sql/README
I named my database "spamassassin" and the table "userpref" as shown in the SA docs. The table name isn't significant, just make sure you are consistent in how you configure SA and sasql's access to it.
Create a MySQL user and password for access to the spamassassin database. I did so with a grant such as: GRANT ALL PRIVILEGES ON spamassassin.* TO spamassassin@'locahost' IDENTIFIED BY 'secretword';
Install SASQL
http://www.squirrelmail.org/plugin_view.php?id=167
Install it as you would any other squirrelmail plugin. Edit sasql_conf.php and set the DSN.
Install WebUserPrefs
http://www.pipegrep.net/webuserprefs/
cd /usr/local/www/mail fetch http://... tar -xzf webuserprefs-0.5.tar.gz mv webuserprefs-0.5 webuserprefs cd webuserprefs vi config.php
Edit the prefs_source to "db", authorization to "squirrelmail" and set the database info. Point your browser at http://mail.example.com/webuserprefs/ and volia. The catch is that you must be logged in via squirrelmail in order to use it. The alternate solution is to use IMAP or POP3 but then you have to recompile PHP with IMAP support.
Install Pear-DB
You'll find it in /usr/ports/databases/pear-DB.
I had mod_php4 installed before and this silly port was convinced it needed the lang/php4 port installed. Since I had another need for the PHP cli, I honored it's insistence by deinstalling www/mod_php4.
Modify spamd's flags. The best way is to modify /etc/rc.conf and add the following lines:
spamd_enable="YES" spamd_flags="-a -d -v -q -x -r /var/run/spamd.pid"
Here's the relevant portions of mine:
enable_quotas="YES" check_quotas="YES" clamav_clamd_enable="YES" spamd_enable="YES" spamd_flags="-a -d -v -q -x -r /var/run/spamd.pid" ntpdate="YES" xntpd_enable="YES" xntpd_flags="-p /var/run/ntpd.pid" sendmail_enable="NONE" snmpd_enable="YES"
Grab a cut of coffee, it's SMTP lesson time.
The type of statistics you'll see in your logs regarding SMTP blocks will reflect several things of interest (that are related to your question). The first, and most obvious is how you are using the RBLs.
The most important setting in that regard is rbl_enable_soft_failure in your toaster-watcher.conf file. If you have soft failure enabled, then when you deny a mail agent access, you are doing so with a temporary failure, which amounts to saying "try again later". The idea behind that is that if it's a legit mail server, it gives them a chance to fix their problem and then try sending again.
I'm not in that camp. My email addresses have been plastered on web pages for years and years, on mailing lists, usenet forums, etc. Thus, my address(es) are included in many of the spammers databases so I'm going to be a target regardless. I want to stop them dead so I set rbl_enable_soft_failure to 0, which chooses a 553 error "sorry go away, permanent error, you spammer pig" style. This tells the remote server, don't even bother trying again, it won't work.
Obviously with the latter arrangement, you'll see a lot fewer (than if using the former) RBL blocks. Many of the spammers don't honor the 553 error and try again anyhow but that's quite OK. The majority of mail servers (themselves victims of naughty people) will get the 553 and bounce the message, no longer trying to contact me. All is well. This is the very same reason why it's better to use a SMTP 553 error instead of simply packet filtering their IP. Sure, they're blackholed, but they'll get a SMTP unreachable error and just keep trying. I want the spam traffic destined to my server to go away, not add to the cost of my system (via connectivity). When your server has thousands of mailboxes on it, these policy decisions make very real and measurable differences.
Doing a RBL lookup on a message at SMTP invocation time is cheap. Extremely cheap. It's a simple DNS query so it's very very very lightweight. I may even have it cached from the last time the spammer tried. It costs almost nothing. If I can deny a spam message there, before having to pass it to qmail-scanner (medium cost), through the virus scanner (medium to expensive), bayesian filtering (low cost), spamassassin network tests: blacklists, DCC, pyzor, razor (low - medium), and then maildrop filtering, then you it's worth it to me.
So, reason #1: It costs me less to use RBLs.
The next reason for RBL usage is more political. The spammers revenue (that they charge advertisers) is based on message deliveries. They maintain databases of email accounts that they can deliver to. They have developed very sophisticated ways of determining if a message got delivered (well beyond "did the SMTP server accept it") and further, if it landed in a real persons mailbox. These include delivery notifications, embedded HTML (the web server logs then reflect success), and other clever mechanisms.
Very few Mail User Agents are very clever about dealing with spam messages. Unfortunately, the ones that are (like Mail.app) are not the most popular. A lions share of users use that icky software from Redmond which is a spammers dream come true. Even if I tag and bag the spam to a special folder, they end user may peruse through it, opening the message to verify and thus letting the spammer know the message was delivered successfully. Yay, spam 'em again!
So, if I can block the message entirely (not just from my mailbox, but from every landing on my server) then the spammer will never get back any indication of success. This increases the likelihood of being removed from the naughty miscreants list and thus reduces the likelihood of getting spammed from him again in the future.
Sounds great in theory right? So how does it play out in real life? I have quite a few "case studies" we'll call them, ranging from my own personal mail servers to mail systems with tens of thousands of mailboxes on them. In general, the spam to ham ratio of messages on the internet is rising, but in every case my mail servers (with RBLs), the number of RBL blocks I see is gradually decreasing. This suggests that either RBLs are becoming less effective or some other unknown factor(s) are at work.
So, let's look at my mail server as a case study. Over time my message volume on my server has continued to rise, so we should expect the level of spam messages as well as ham messages to be steadily increasing (or the number of RBL blocks to increase). The effectiveness of my spam filters has been fairly constant (>98%) for the past six months yet the number of spam messages being delivered on my mail server has steadily dropped. What accounts for the difference?
Reason #2: Keeping spam messages way from end users
About a year ago I was watching my mail server logs and noticed that quite a few of my mail users (of whom I know personally) were getting extraordinarily high levels of spam being delivered to them. I then decreased my spam tolerance by blocking mail servers without DNS (which required whitelisting a fair number of mail servers), increasing my RBL usage. Immediately after that the number of RBL hits spiked and then began a gradual decline ever since. This reduction of traffic is due almost entirely to the RBL usage as I tested the reverse DNS blocking at various times and ultimately removed it.
Approximately six months later I did another round of decreased spam tolerance and enabling the spam filtering for these users, all of whom are not very sophisticated mail users. They don't know or care about mail servers, filtering, etc. They just want their email to work. Overnight the levels of spam in their inboxes dropped to almost nothing (a condition I'm accustomed to living with). This, of course made them all very happy. It also gave me a way to track the effectiveness of the RBLs, as I had a very accurate indicator of their effectiveness. RBLs only caught about 50% of the spam, but that's still a remarkably good achievement for something that costs so little to employ.
So, RBLs aren't a "one stop shopping" spam solution, but they are a very effective tool.
Reason #3: Spammers hate RBLs
There is good reason why RBL operators are targets of DoS attacks. These days running a RBL means making sure you and your upstream provider are prepared to deal with massive DoS attacks, sometimes lasting over a week. These DoS attacks can cost many thousands of dollars in excess bandwidth fees, lost revenues, and related costs. This is the reason for several of the RBL operators decisions to step out of the game, including osirusoft which was one of, if not the most effective free RBL. If RBLs weren't effective, they wouldn't be targets.
Unfortunately, the spammers have millions of advertising dollars at stake. When a RBL is as effective as Osirusoft, it measurably effects their bottom line, and thus becomes a target. If I can hurt the spammers where it counts (in their wallet), then in my book, that's A Very Good Thing.
Matt
Easy way:
Upgrade to Mail::Toaster 3.37 or higher. rm -rf /usr/local/www/data/qss toaster_setup.pl -s qss
The long way:
cd /usr/local/www/data mkdir qss; cd qss download tar archive from: http://sourceforge.net/projects/qss/ tar -xzf qss-2.0.2.tar.gz vi config.php
Change the start date to the earliest date shown in your log file (head /var/spool/qmailscan/quarantine.log). Change the logFile variable to point to "/var/spool/qmailscan/quarantine.log". Then open up the permissions a bit on the quarantine so qmail-scanner stats can read it:
chmod o+x /var/spool/qmailscan chmod o+r /var/spool/qmailscan/quarantine.log
Qmail-Scanner changed the logging date format at version 1.20 but qmailscanner stats doesn't have a fix for it yet. If you log files with dates in this format: 23-09-2003 then it'll work great. If you are using a newer version of qmail-scanner, you'll notice that your log entries are not showing up. I have both (before/after upgrade) so I fixed qmailscanner stats it by editing the index.php as follows (The if..else block is my addition):
vi index.php if ( eregi("(^[0-9]+)", $val[0]) ) { # Calc the date timestamp $date = explode("/",$val[0]); $dateT = $date[0]; $date[0] = $date[1]; $date[1] = $dateT; $date = strtotime(implode("/",$date)); } else { $date = strtotime ($val[0]); };
Point your browser at http://mail.example.com/qss/ and voila! A working example is provided here: https://mail.cadillac.net/qss/
You have a couple options:
1. Remove the offending RBL from toaster-watcher.conf 2. set RBLSMTPD="" for the IP(s) in tcp.smtp
The latter is the better approach.
Grab the spam, including all headers, and paste it into a telnet session as described on Matt's "mail forge" page.
http://www.tnpi.biz/internet/mail/forge.shtml
% telnet mail.domain.com smtp Trying 64.224.19.12... Connected to mail.zone.com. Escape character is '^]'. 220 mail.zone.net ESMTP ehlo 250-mail.zone.net 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-PIPELINING 250-STARTTLS 250 8BITMIME mail from: <user@domain.com> 250 ok rcpt to: <user@domain.com> 250 ok data 354 go ahead PASTE SPAM HERE . 250 ok 1016471746 qp 9246
This command is run automatically by the vpopmail install section of toaster_setup. If if fails (because it can't connect to the database, mysql isn't running, etc) it prints out this message with the values filled in place of the variables show below.
CREATE DATABASE vpopmail; GRANT ALL PRIVILEGES ON $db.* TO $user@"$host" IDENTIFIED BY '$pass'; use vpopmail; CREATE TABLE relay ( ip_addr char(18) NOT NULL default '', timestamp char(12) default NULL, name char(64) default NULL, PRIMARY KEY (ip_addr) ) TYPE=ISAM PACK_KEYS=1; quit;
The values are filled in from your settings in toaster-watcher.conf.
Well, if you can get FreeBSD installed without the install CD melting, then you've gotten a step further than we have in our test labs.
I have used this procedure on many, many production systems without incident. These instructions are what works for me. YMMV. Use at your own risk. There is a strong possibility that you will hose your system during this upgrade so try it on a test server! If you don't have a test server, hire someone that's done it before. Preferably someone whose done it many times before! Like me, who has screwed up this process on my own systems in every conceivable way, thus learning how to avoid messing up yours.
1. Insert the new hot-swap SCSI disk in your server 2. Use camcontrol rescan to tell FreeBSD to detect it. 3. Use sysinstall to configure and partition it.
I mount the new partitions on /mnt: /mnt/root, /mnt/usr, etc. Once the new partitions are mounted, I use pax (pax -rwpeX) to copy all the files from the old to the new partition (while the server is still online).
cd / pax -rwpeX . /mnt/root/ cd /usr pax -rwpeX . /mnt/usr/ cd /var pax -rwpeX . /mnt/var/
Once that's done, I have a 10 minute old copy of the active (old) drive on the new one. A few files won't copy properly (they'll be in use), etc but I'll have 99% of the file system copied with negligible system impact and no down time. Now it's time to drop to single user mode and use rsync to sync up the disks.
shutdown now rsync -avxW --delete / /mnt/root rsync -avxW --delete /usr /mnt/usr rsync -avxW --delete /var /mnt/var shutdown -h now
You're ready to boot off the new disk. Turn off the power, remove the old SCSI disk, insert the new one in it's hot-swap bay (so it get's the same SCSI device ID), and turn your server back on. Voila, you just upgraded your disk with only 2 minutes of down time.
The easiest way is to simply remove the hot swap SCSI drive from the old server and stick it in the new one. If you are using RAID, move the RAID card too, along with all the drives. Grin, and pat yourself on the back for thinking so far ahead and buying good equipment. :)
Assuming you can't use the above instructions for whatever reasons, the following info might prove helpful. Your users account information is stored in several places, all of which need to be moved to the new server. Here are the critical directories:
/var/qmail/control /var/qmail/users /usr/local/vpopmail /var/db/mysql
A thorough checklist would look something like this:
1. Upgrade exiting Mail::Toaster to latest version 2. Wait a day or two (make sure nothing broke) 3. Build the new Mail::Toaster 4. Stop all the services on both systems. 5. Copy the directories above from old to new server 6. Start up the new system
If there is mail on the old systems queue, give it a new IP and leave it online until it's finished emptying it's queue (up to a week).
This assumes the new server will inherit the IP and hostname from the old one. If that's not the case, then you have DNS entries to update, config files to alter, etc.
When you enable spam filtering in qmailadmin, what you actually do is change the way qmail delivers the mail to the user's inbox. SpamAssassin isn't concerned with this seemmingly magic button.
With the spam filtering box unchecked in qmailadmin, the mail is placed directly in the user's maildir. Whatever SpamAssassin did to it does not matter. It's the user's job to handle it from here.
When you tick the spam filter box, a file named /usr/local/vpopmail/domains/example.com/username/.qmail is generated. This file gives instructions to the program delivering mail (vdelivermail) to the user. In (at least) the 3.3x toasters, the mail is fed through a program called maildrop. Maildrop takes *its* instructions from a script-ish file named /usr/local/etc/mail/mailfilter.
The current mailfilter file looks at the mail headers added by SpamAssassin to see if it's a spam or not (false positives notwithstanding), placing it in a folder called "/usr/local/vpopmail/domains/example.com/username/.Spam" if it is. If the spam folder doesn't exist, maildrop creates it and subscribes the user to the folder so he/she can see it and manipulate it.
The mailfilter also checks quotas and some other stuff.
The Spam folder is only available from an IMAP client. Squirrelmail is an IMAP client.
It get's automatically created when the first spam message arrives. It is automatically subscribed to your IMAP folders.
A: If your ISP's mailserver is mail.someisp.net, add
:mail.someisp.net
to the bottom of /var/qmail/control/smtproutes. This will only work if your ISP allows relaying from its entire dynamic IP range. This is usually the case. -- Tor Willy Austeratt
To install Mail::Toaster, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Mail::Toaster
CPAN shell
perl -MCPAN -e shell install Mail::Toaster
For more information on module installation, please visit the detailed CPAN module installation guide.