More specifically, create the Postfix multi-instance.

If you want the Postfix instance to listen on a TCP port, make sure the master_service_disable variable is unset (as below) and that the inet_interfaces variable is set to the IPs that you want the instance to listen on. Also, after copying over your main.cf and master.cf files, you will lose the Postfix multi settings. Just make sure the following settings are in the instance specific main.cf.

If you are editing the files by hand, make sure you don’t lose the main Postfix instance multi-instances settings (I know that was a mouthful):

Then you can fire up the instance by executing the following command:

From there on in, you can control all instances, a specific instance or even group the instances. Its about time complex setups got easy.

Related posts:

1. Setting Up DKIM and Postfix on CentOS 5.2
2. What About An External Multi-Touch Trackpad For a Mac

The other item that should be noted is that some ISPs don’t have a feedback loop and just respond to the abuse@ or postmaster@ email addresses for a domain. In addition to the feedback loop setup, ensure you have those addresses as valid addresses for your domain.

For more information on Feedback loops and how they help your deliverability, see the Wikipedia entry on Feedback Loops.

• Abuse.net – Not technically a feedback loop, but your domain(s) should be listed.
• AOL
• Bluetie – Handles Excite
• Comcast
• Earthlink – Just an email address. Good luck hearing back from them.
• Cox
• Outblaze – Just an email address, but were pretty responsive.
• MSN/Hotmail
• Road Runner
• United Online – Juno, NetZero and BlueLight Internet
• USA.net
• Yahoo!
• MailTrust/Rackspace
• Tucows/Hosted Email

Related posts:

1. Redacted On A Feedback Loop
2. Counting Email Addresses By Domain in MySQL
3. Email::Find

First thing that you’ll need to do is grab yourself a copy of Larch. I did this simply by typing and it installed everything nicely, but click the link to the repository on Github if it doesn’t work for you.

Immediately I dove in and ran it. And immediately I hit my first problem:

The fix for this issue is that SSL needs to be available (or installed as a library) to Ruby. Since I have Ruby built from source, it was just as easy as what’s below. I have removed the output for readability.

Now that we have SSL installed, let’s try it again.

Whoops, another stopping point. If you are receiving the above error, then you need to make sure that your dovecot installation is set up for maildir. What this error is saying is that your installation doesn’t support folder that are folders and mailboxes at the same time. If your current dovecot installation is setup for mbox, you will need to convert it. That is beyond the scope of this post, but add the code below in the /etc/dovecot.conf if it’s not already there.

I have been happily and successfully running Larch ever since.

Related posts:

1. Backing Up Gmail/Google Apps to a Dovecot Server
2. Mail::IMAPClient
3. Email::Find

1. Create 2 accounts in Apple Mail: Gmail and the Dovecot account
2. Sync the Gmail account to your local computer
3. Copy everything to the Dovecot server

This works, but I have to use a slow connection (my home connection) and I have a lot of accounts to do this for, so I would much prefer to script this. The problem is that I have been trying to get this to work with either imapsync or imapcopy. Neither seem to work properly.

According to the documentation, I have the proper version and it should work with GMail. I tried all the supported –authmech1 possibilities. I found an article saying that Google doesn’t accept the word AUTHENTICATE when authenticating, but then imapsync wouldn’t work and it claims it does. So, when trying imapsync, this is what it looked like (some of the security issues have been blocked to protect the innocent):

My attempt at imapcopy was closer to successful, but still not what I needed. I ran into some Dovecot errors (at least I think that’s what it is) that I am not sure what to do with.

So if you have any idea what to do here in a more intelligent manner than I am stuck with, please let me know in the comments. Thanks.

Related posts:

1. Transferring Email From Gmail/Google Apps to Dovecot With Larch
2. Mail::IMAPClient
3. Creating a Slave DNS Server on Bind9

I’m not sure who thinks its a good idea to replace all instances of an email addresses in a feedback loop with [redacted]@feedbackloopcompany.com, but it is of no help to anyone. An argument can be made for protecting the identity of the recipient, but that argument holds little weight because there is little the sender can do about it.

If a sender needs to go through the authorization process of a larger recipient domain (like AOL, Yahoo!, or Excite for example) where their IP reputation is checked and their history is checked, etc. then why should there still be restrictions placed on the information going between the two domains (you as the sender and them as the recipient domains). I am aware that the draft specification allow the operating domain for the feedback loop to keep the identity private of the user clicking the “Report SPAM” button, but that forces the sending domains to use tactics to circumvent this to keep their reputation up.

Therefore I believe that if a sending company has verified their feedback loop address, they should be able to see which recipient reported their email as “Junk”. Get rid of the redacted and leave the email address intact.

Related posts:

1. List of Feedback Loops
2. Mail::Sender
3. Yahoo and Goodmail Cut the Cord (Temporarily)

I previously posted about a program that parses your amavisd-new SPAM log file called amavisd-logwatch. Now I am going to give you some tutorials of how to make efficient use of the results. I am assuming that you have access your SpamAssassin scoring config files. I am also assuming that you have access to the log parsing results. I have mine sent via email daily.

One item I would like to mention is that when making changes to SPAMAssassin, ensure that you make them in a separate file from the default configuration files. I use /etc/spamassassin/local_tests.cf. I strongly recommend this setup as this makes it easier to segment your configuration files by type when your rule sets and modifications start to get larger and larger.

Section: Bayes Probability
First things first, skip the majority of the summary sections and go right down to the section on Bayes probability:

Bayes Probability Information

You’ll notice that of the 14,627 times that the Bayesian filter was run on messages, that it came up with BAYES_99 11,825 of those times (or 80.85%) . You’ll also notice that all the subsequent BAYES_XX probability tests were extremely low (2nd and 3rd place being 5.4% and 4.5% respectively).

Conclusion: Assuming that you are relatively happy with your current level of SPAM filtering, that would mean that your Bayes filter is doing fairly well (in general). You may not need to tweak it. If you are feeling frisky though, to tweak the impact that the BAYES_99. To change this, open up your local_test.cf and add the line:

This increases your BAYES_99 score by 1.25 points from its base. It doesn’t have to be 1.25 points, start small to see what you are comfortable with and slowly work your way up. Be careful as too high a jump will cause false positives which makes for angry users.

Section: SPAM Score Frequency
The SPAM score frequency refers to how often a piece of email scores within a given range.

SPAM Score Frequency

Conclusion: Taking note of the fact that nearly 60% of the emails scored a 30 or higher, and assuming again that you are comfortable with your SPAM filter, you can adjust the SPAM kill score threshold in amavisd-new accordingly. I trust my SPAM filter, but I have written many rules and made many tweaks to it. So I have set my SPAM kill threshold low enough (15.8 to be exact). As you can see, this is pretty close to the middle of the set of numbers (also known as the median). This eliminates the delivery of the vast majority of the obvious SPAM.

Stay tuned for the next part in the series where we will tweak the individual scores based on the results report.

Related posts:

1. Deploying Amavisd-logwatch
2. Setting Up DKIM and Postfix on CentOS 5.2
3. Parsing Ini Files With Ruby

On his web site, it says he doesn’t like waiting for package maintainers, so its just a tarball. Since my installs are Debian based, I created a deb for it. My .deb creating skills are not perfect, but it works. The deb was built on sid and is available here.

Download the Debian package and install it:

Leaving the defaults are safe in the config file. The one thing that does need to be changed is the additional cron script that I added to the installer. It will email the output of the script when cron.daily runs. If you do not want this to happen, then just delete the file /etc/cron.daily/amavis-logwatch. To have the script run, you have to edit it and change the defaults to reasonable defaults (like proper From, To, and CC email addresses). Also make sure to change the /var/log/mail.log file if that isn’t the location of your mail log.

Once you have made those changes, you will receive a nightly report with your amavisd-new log information.

Related posts:

1. More Efficient SPAM Fighting with Amavisd-logwatch
2. List of Feedback Loops
3. Creating Dummy Packages On Debian

Why, when sending emails to certain domains, do I get the error: 451 Could not load DRD for domain

Because I deal with fairly large mailing lists, I see odd errors a lot. Most of them I can disregard. In any case in which I see an error over 1,000 times, I make it a policy to deal with it. I have seen one close to 9 million.

It appears to be an error from a Symantec appliance, but people write about it coming from Exchange servers as well.

If anyone has any idea what this, please email me, leave a comment, or post a link to somewhere.

Related posts:

1. Mail::IMAPClient
2. MySQL Proxy Query Profiling
3. IO::Socket::INET

My setup is that I have a mail spooler and multiple mail senders. This is to say that the emails are created on spooler.domain.com and sent via sender1.domain.com and sender2.domain.com. I will walk through how to setup DKIM on the sender machines so that all mail spooled from the spooler still gets signed.

First start out by installing DKIM. At the time the HOWTO was published, I downloaded the RPM from Topdog.

Once you have installed DKIM you have to create the public and private keys. Do this using the dkim-genkey.sh shell script.

By running this script, 2 files will be generated; default.txt: the public key which gets published via DNS; default.private: private key used for signing the emails.

Move the private key to the dkim directory and secure it.

Now create the DNS entries. The p= section is the public key created using the dkim-genkey.sh script. Don’t forget to increment the SOA and reload DNS.

The reason for this peer_list file is so that the senders know that its ok for them to sign emails relayed via the spooler.

Onto the configuring of the system. It should look something like the following. I chose to have the port be a local port, but it could be done via a network connection as well. Ensure you change the SIGNING_DOMAIN variable and be sure to note the EXTRA_ARGS variable and where PEER_LIST is used.

Let’s start up dkim. Since it is a daemon running separately from Postfix, running it and restarting it won’t affect mail (yet).

And it’s finally time for Postfix. You need to add 2 simple lines to your Postfix main.cf. These 2 lines should match the PORT variable in the dkim-milter.conf sysconfig file.

Now you’re asking yourself, how do I test this? The easy answer is to use a Gmail account. When you receive an email, click on the show details link on the right hand side of the screen (to the left of the time). If you have performed this sequence correctly, you will see a line that says:

Another way to test the success of this is to view the source of the email. You should have some lines that look similar to this:

Congratulations, you have a working DKIM installation.

Related posts:

1. A Few Words About Setting Up Postfix Multi Instance
2. Deploying Amavisd-logwatch