I implemented a VMware version of iRedMail to sign newsletter emails using DKIM. I used Ubuntu 9 server version(optimized for VMware version) to build appliance.

1. The server works as a mail proxy in front of the SMTP server we use exclusively for the newsletter. It signs and relays the email to the existing SMTP server. I kept the existing SMTP server so that I could continue to use my existing procedures for parsing the log files to identify old/obsolete mailboxes.
2. I created iRedMail users in LDAP to relay local users to mailboxes on Exchange.
3. My primary bottleneck is still my mail transmission to the Internet speed, 2 per second. I can create newsletter emails at about 8 per second.
4. On an old Proliant DL350 G4 iRedMail consumes about 40% of the dual CPU computer for four hours.

Since I had experience installing iRedMail it went quickly. The biggest bug I had to fix was the AWStats/permissions problem on the mail.log file.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

1. Use a static IP to send out the newsletter.  One of the first SPAM checks email providers use is to see whether the  IP you are using to send out the newsletter is coming from your domain.  This means that you need to set up a sub-domain(e.g. mailserver.mycompany.com) and a PTR record for the sub-domain.
   1. Set up a sub-domain for the static IP. Since our web server is hosted we had to ask our host provider to set up the sub-domain.
   2. Set up a PTR record for reverse DNS lookup. I asked the folks who provided us our static IP to set up the PTR record to the sub-domain.
   3. If everything is set up correctly you should be able to pass the reverse DNS lookup test. This is the site, Forward Confirmed Reverse DNS Lookup Test, I used to confirm it was working properly.
2. Set up feedback loops if you can. Feedback loops are pretty dumb idea that email providers like. I dislike them since I have only feedback loop that is useful. I am grateful that AOL has made it reasonably easy for me to remove people who do not want to be on our mailing list. I was able to quickly modify our existing newsletter template to embed an unsubscribe link that would make it through the feedback loop processing. On the other hand I found I wasted a huge amount of time trying to set up a feedback loop with  Yahoo and Hotmail. Both Yahoo and Gmail  want you to sign your emails with DKIM or they will not talk to you. DKIM was supposed to reduce SPAM but I have not seen any reports showing it reducing SPAM. Implementing DKIM will require me to set up a new email server for the newsletter so it is pretty far down my priority list. So far I have been able to ignore this issue. Hotmail wanted me to get a letter from our local internet provider saying we were the only folks using the static IP. Our local internet provider, RoadRunner, told me several times that no customer had ever requested a letter like that and they were not going to provide it. I set up a feedback loop with Comcast but after a couple of months they increased the amount of information they redacted from the email and broke the unsubscribe loop in the feedback loop message. 
3. Embed an unsubscribe link in your newsletter template that will unsubscribe the user but does not require the email address.  Since most feedback loops redact the email address, this will allow you click on the link in the Feedback loop message to unsubscribe the user.
4. Go through the error log on your email server and look for the messages that indicate that email address is inactive or no longer used. Unfortunately there is a multitude of messages that are used to describe unknown users(5.1.1, 5.5.1, unknown user, alias not found).  This is one area that begs for a standard. This is where the feedback loop should have been.
5. Manually go through your newsletter inbox and look for:
   1. Earthlink, PeoplePC, Zonealert, and other verification replies
   2. Unknown user messages.
   3. Feedback loop messages
   4. Changed addresses and unsubscribe messages.
   5. Other replies.
      1. Mailbox full, Out of office replies
      2. Customer service requests. About once a week we get a reply to the newsletter that asks a question about a product.
      3. Miscellaneous SMTP problems(e.g. DNS and email forwarding problems)

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.