Vipre Email Security Blocking Quickbooks Invoices

Some background...I use an Exchange 2007 server to provide Exchange hosting for a number of small clients. Until recently, my office manager took care of the billing through a variety of faxing, emailing, and snail mailing. I made the decision to move towards sending all (or as much as possible) documents using electronic methods. Specifically, I started leveraging more of the QuickBooks merchant solutions.

The problem...All of our Exchange 2007 customers found that our invoices went to quarantine. I found it a bit embarrassing explaining to clients that even though the email says it's from me, it actually comes from "sdm.ctcfe.quickbooks.com" and our Vipre Email Security Default Antispam Policy does not like that.

The fix...I created a rule to allow all traffic *@quickbooks.com but it did not resolve the problem. In the end, the issue took a call to tech support @ 877-673-1153. The person I spoke with had me send the header info, the Snapshot log, etc. She noticed that we could probably solve the problem by allowing anything with quickbooks in the header. Under whatever antispam policy is blocking the QuickBooks email, you have to create a custom rule. To do this, select add under the rules tab of the antispam policy. Give the rule a name, select "custom," then next. Scroll down and select "headers,"  leave the search type to Contains, and type quickbooks as the value. Select next, and then finish. Hit the apply button at the top of the page and you should be good to go.

I may tighten this up later as anything with Quickbooks in the header gets to jump on through the email security.

Cox Email

A customer experienced a problem with using a combination of email accounts in Outlook. Specifically, he used a Cox residential account with two other business email accounts. The host for the business email recommended using whatever SMTP server the Internet provider had at the office. This is a little problematical with laptops as many times the user will be at a hotel or home.

I sometimes get around the issue by allowing the customer to authenticate to our server using an alternate port number for sending email. I provided the ability whether or not the customer had an account on our email server. I've done it with other customer devices which needed SMTP services but never really liked using our server just for SMTP access.

This time around I decided to see if the customers current email provider would allow sending using an alternate port. I used the customer's Cox information, username without @cox.net, and the password in the SMTP authentication area for each business account. Using a search, I could not easily find an alternate port for Cox, so I just guessed using the standard 587. All the accounts tested fine at the office, but not at the customer's home.

I dug around using Google and found that Cox allows SMTP SSL on port 465. The port listing was buried in the instructions for configuring Outlook Express. After reconfiguring the authentication to use 465 for SMTP traffic, the mail seemed to flow for every account. The customer is testing next week to make sure the fix works at other locations.