E-mail NDR: #5.1.1 SMTP; 550 Rejecting for Sender Policy Framework (SPF too many lookups)

One of our clients was having issues sending an e-mail to one of our regional ISP’s e-mail servers.

• Remote Server returned ‘<inbound.server.com #5.1.1 SMTP; 550 Rejecting for Sender Policy Framework>’
• SPF too many lookups

There was no further information. The specifics came from a very helpful mail technician at the ISP.

So, we started to dig around and came up with the following:

• Sender Policy Framework Site: OpenSPF.org
• Kitterman Technical Services’ excellent SPF Tool

A ticket went through Third Tier’s Help Desk this week that was based on this problem with Dave Shakelford pointing to the following blog post:

• JangoMail Help Center: SPF ‘too many lookups” Error

So, what does all of this mean?

It means that we need to make sure all of our clients that send mail via an ISP SMTP server, third party sanitation and continuity service, or mail hosting service need to have a correct SPF record in place.

As the JangoMail blog post makes clear, we may have to jump through a few hoops to get it right, but get it right we must as our client’s mail is critical to their business.

Philip Elder
Microsoft Cluster MVP
MPECS Inc.
Co-Author: SBS 2008 Blueprint Book

Project Honey Pot – 1 Billionth Spam Message

Have a moment for a really good read?

Project Honey Pot has had their 1 Billionth Spam Message.

From the above linked blog post:

Every time Project Honey Pot receives a message we estimate that another 125,000 are sent to real victims. Our billionth message represents approximately 125 trillion spam messages that have been sent since Project Honey Pot started in 2004.

At this milestone, we wanted to take a second to report some of our findings. Our goal is not to rehash the same old insights but instead to give a new picture that only looking at five years and a billion data points can produce

Their findings are quite interesting with regards to the sources of spam, harvesting, and more.

It is well worth the read.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer

Rogue Infection: WARNING! YOUR’RE IN DANGER!

One of our clients received a link via an e-mail from a friend saying that they needed to purchase, download, and install a product to help keep their system running great!

• Rogue AntiSpyware blog: Registry Defender

Now, the machine is virtually unusable due to constant battering by pop ups from a product called System Security 2009 (also a Rogue AntiSpyware blog link). The rogue also prevents any .EXE from running on the system except an IE window that takes us to the “online activation system”.

We are going to flatten this system, extract their data from an earlier ShadowProtect image, and start fresh.

Since much of the infections legitimately found on the system are Trojan related, there can be no guarantees that removing them does not leave a backdoor of some sort into the system.

The desktop as it is now:

And:

Our client new something was well out of sorts due to the misspelling of “YOUR’RE” when the background started showing up.

Note the constant fight between the malware and AVG Free.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*All Mac on SBS posts will not be written on a Mac until we replace our now missing iMac! (previous blog post)

Windows Live Writer

SBS - Client e-mail needs an SPF for SMTP outbound

Whenever we setup a new client, whether they run with a Reputation Services Provider or not, we always have the client's ISP or DNS hosting company setup an SPF record for their e-mail domain or domains.

What is an SPF Record you may ask?

It stands for Sender Policy Framework. It allows e-mail to be transmitted with a different return e-mail address stamp than the network it is being transmitted from.

For example, our @mpecsinc.ca domain has an SPF in place to allow our domain @mpecsinc.ca e-mail to be transmitted from either Nucleus or Interbaun's networks since our e-mail servers reside on both ISP's networks.

Without an SPF in place, some spam filters out there will drop e-mail with a return e-mail address that is not associated with the network it is transmitted from. In many cases, the e-mail servers or reputation services providers will not provide an NDR either. This means that the e-mail will essentially disappear.

Microsoft actually has a wizard for you to use to generate the correct SPF to give to the Internet DNS hosting provider:

Microsoft SPF Wizard

Punch in our own domain mpecsinc.ca and we get:

MPECSInc.ca Domain SPF

Note that our Internet DNS already has the SPF records in place. Continue on in the wizard and we will be asked questions to make changes to the above SPF settings. The final step is the SPF generation itself which will coincide with our current setup.

Once you have those settings in hand, an e-mail to the Internet DNS host will get that record in place.

The link: Microsoft SPF Tool.

This is one more little way we need to be aware of the way e-mail is handled. Being aware of the need for an SPF record is one less thing to look for when troubleshooting e-mail transmission problems.

Need a quick way to test your client's DNS setup? Check this tool out: Men&Mice DoDig. You need to know the ISP's DNS server, the domain name you are researching, and select the ANY option to get the full DNS setup report. This tool is very handy when in a pinch and trying to diagnose Internet facing DNS issues.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

SBS 2008 Lab Test - Spam Filtering

The primary purpose of this post is to present our SBS 2008 lab users' e-mail addresses to the world as a spam trap.

Let's see just how good the Forefront and LiveOneCare for Server setup is.

• Norm Hasborn
• Barry McKechnie
• Melinda Overlaking
• Linda Briggs
• Bob Bountiful
• Tom Benkert
• Norm Hasborn Jr.
• David Lalberson
• Elvis Haskins
• Bob Easter

Just in case you are wondering, the above users are setup in the SPRINGERS SBS domain as part of the book I am co-authoring with Harry Brelsford of SMB Nation fame tentatively called the SBS 2008 Blueprint.

Once we get things rolling along pretty good, we might even setup a couple "Out of Office" replies just to spice things up a bit! :)

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

SBS 2008 - WSUS Synchronizations and Exchange

Have a look at this:

Exchange BL and Spam Updates

The list of updates released in one day makes it pretty clear that our WSUS synchronization schedule needs to be set to more than once a day.

By default, we are setting all of our WSUS setups to sync 8 times a day or once every three hours.

That should be enough to catch most everything!

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

Trend Email Hosted Reputation Services now InterScan Messaging Hosted Security

While we have been implementing Trend Micro's AntiVirus solution at our client sites, a few of them have also expressed an interest in the spam filtering offered by Trend.

Our first client was setup using the Email Hosted Reputation Services (EHRS). The service did help to reduce spam over the Exchange IMF setup.

Recently, Trend went through an update of their antivirus products and the hosted spam filtering. The new filtering is called InterScan Messaging Hosted Security (IMHS).

We switched one of our existing clients over to the new IMHS service and unfortunately have been having nothing but grief since. Spam that was not coming through before is now coming through in spades.

We waited the obligatory 48-72 hours to make sure the MX record changes had taken, and still things have not improved.

The straw that broke the camel's back: A bounce message forwarded by one of their clients saying that the attachment size was too large ... at 4MB ... with Trend's server name listed as the culprit.

Since this client is one of our key clients, we are not about to go any further with the service.

Since the previous EHRS services will no longer be in effect, we will default back to the Exchange IMF for now.

For the most part, things were working fine before EHRS, worked a bit better with EHRS, but have taken a big step back with IMHS.

While we are relatively happy with Trend's A/V, we will no longer be selling what is now the Worry-Free Business Security Advanced which includes IMHS. We will stick with the Worry-Free Business Security product for now.

The other side to this pickle: With the advent of SBS 2008, which will include ForeFront and Windows Live OneCare 120 day trials out of the box, if we choose to install them, we may look at going Microsoft on the entire platform. This reduces our install and configuration time too.

Since we are selling 100% Open Value Agreements to all of our clients, and have been for quite a while now, adding ForeFront and OneCare to our client's Open Value Agreements when it comes time to upgrade their refreshed hardware will be a small step.

We shall see ...

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

Payment for services - Honour and our Word

A while back we were brought in to help a fellow IT company owner by one of our local suppliers that we have been dealing with for years.

The IT shop had an older SBS setup that had a choked SMTP queue.

As we do with all drop-in situations, we outlined our hourly charges, resolution or not, and made sure that the business owner agreed to them ... which he did. We also have the local admin person create a user and password with domain admin privileges as a precautionary measure. That way they can delete that user when the job was finished.

Well, it is now almost four months later, and they are refusing to pay us for our time.

The SBS box was not setup properly. The wizards were not used and the Exchange box was an open relay. While we worked hard to get things right, the plugged queue just kept growing ... so the suggestion was made to swing to new hardware ... to which the business owner indicated they wanted things worked out instead.

Eventually, the owner decided to take over themselves, wipe the box, and let us go. We set our invoice and indicated we would reduced our time billed (bad mistake - never devalue our own time), and he agreed.

Where does the perception come from in our industry that if the task at hand could not be accomplished that our time is worth nothing?

Take a car into a shop to be worked on and try to get it back without paying ... even if the shop did not find a resolution to the problem. That just will not happen.

Then why is it an acceptable practice to not pay us for our time on the job no matter what the problem status at the end of the day?

We are professionals, and just as mechanics we know that some situations cannot be resolved at the drop of a hat. Usually, that means that after a half an hour to an hour of scoping out the situation we are already providing feedback to the client or customer (they are different) that we may not be able to "fix" the problem.

We begin to offer options to either work out the problem, with no guarantees, or we are saying it may be a lot more expedient to move on to other options.

It is a sad day when we encounter a situation where a handshake is not honoured. It is even sadder one when the person we shook hands with is in our own industry. Not honouring one's commitments says a lot about the character of the business owner and their employees who may be shaking hands on their behalf.

One of the key ways that we establish long term client relationships, in our case we have some spanning 10 years now, is by honouring our word. Our commitments are our gold. If we cannot honour our commitments with our clients and with others in our respective industry, we cannot expect to build our business up.

We are in the relationship building business ... I.T. just happens to be the vehicle we are using to get there.

When we have realized that, then we will be hiring people on who will be open to fostering those business relationships and to being formed into the type of I.T. Professional that can be counted on to follow through on their commitments.

The customer may always be right, but the client knows their options and our professional opinion on the direction they should proceed in. That is the difference between them.

Working together, we the I.T. support firm and our clients, along with the strong supplier and vendor relationships we have built, create and maintain a long term technology infrastructure and user skills vision. Along the way, we make sure to form our employees in that vision.

So, now we are in the awkward position of needing to collect on the aforementioned debt. In our five+ years of business, we have only had one payment situation go bad. It is unfortunate that this situation is turning out to be our second. :(

UPDATE 2008-08-11: It seems that paying a personal visit to the I.T. company in question did the trick. A technician appeared from the back, acknowleged my request, and called the owner to indicate that I was there. A cheque soon followed.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

SBS Premium + ISA = You have received an e-card?!?

On the F-Secure Weblog, we have the following article: From SMTP to HTTP to FTP where Mikko talks about the e-card spam evolution.

What Mikko is indicating to us, is that the spammers now send us to a page that will have a link to the virus file via FTP. Note the file link revealing that it is an executable file on an ftp://... at the bottom left of the Hallmark card:

We all love those Greeting Cards! ;)

So, our Favourite User clicks on the link and voila ... they get?

Well, on a vanilla, out of the box SBS 2003 Premium install with ISA 2000/4 installed and configured via the Configure Email and Internet Connection Wizard (CEICW), the user gets absolutely nothing ... zippo ... nada ... and we get a support call from Favourite User wondering why they cannot get their greeting card. ;)

The FTP protocol through the ISA server is disabled by default. We do not enable FTP unless the client specifically needs it for Web site development access to their site root. In some cases, we have a scheduled time to turn FTP access on for our client's site coders when they will be working directly on their sites. We then disable the Rule when they are done.

It has been a long time since we have had a client request FTP access for something other than Web site coding. So many software sites use HTTP for data transfers now that FTP has become something of a special need in our experience.

This situation is a good example of why we have a 95% install base of SBS 2K3 Premium at our client sites.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

SBS - Exchange Email Spam Issue - Error Workaround - Exchange may not be retrying!

In the process of searching for the version numbers for the Exchange SMTPSVC for the previous blog post on using the wizards, we stumbled on what could be a big thing.

Yesterday, we posted about our experiences with two SBS servers, one our client's server and one ours, that seemed to drop email off the planet when hitting a hosting provider's SMTP server that Greylists. SBS - Exchange Email Sam Issue with Question to You.

Not sure how, but in our searches we came up with this:

andy webb View profile More options Mar 17, 2:07 pm
Something I haven't tried yet, but was talking with someone about last week was setting the Glitch Retry registry key. It's possible this isn't correctly being defaulted in SP2 or some version of SMTP.

In HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing, create "GlitchRetrySeconds" as a dword and try a value of 60 or 120. Then restart the SMTP service.

By default, messages receiving a 4xx SMTP response are processed as a "glitch" 3 times before being put back into the queue for processing on the retry interval. It seems like something in this mechanism is failing. [Emphasis ours] So, if assertively setting GlitchRetrySeconds to a value that allows the greylisting conditions to be satisfied, voila, a solution.

This is referenced a couple places:
http://technet.microsoft.com/en-us/library/aa998772.aspx
http://msexchangeteam.com/archive/2005/04/04/403297.aspx

This quote is from microsoft.public.exchange.admin via Google Groups: Exchange-->Greylisting. It is about three quarters of the way down.

This lead to another post on that newsgroup: Greylisting Problem. Here we see that there are indeed others having issue with Exchange not retrying if it receives a 471 Retry from a Greylisting server.

And then, a confirmation that Exchange indeed didn't retry as it should: Nabble.com: Does Microsoft Exzchange Exchange retry delivery correctly?

Now, given our experience working with the hosting company this afternoon and being able to repeat the problem, me thinks the problem is indeed in our court. That is, in Exchange.

As mentioned in the above quote, there is a registry key that needs to be added. From there, restart the SMTP service and hope! :D

So folks, time to get in touch with our clients and get that change in place!

UPDATE: And one more thing: My apologies for the original assumption that our SBS Exchange servers were not at fault. That is the assumption made when we first started into this stuff. And, it looks as though that assumption was dead wrong.

UPDATE 2008-06-18: Fixed the broken link in the TechNet Library referral.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

SBS - Exchange and the dangers of NOT using the wizards!

Here is the answer from a SBS based Exchange server:

220 mysbsserver.myinternaldomain.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Wed, 15 Aug 2007 19:30:25 -0600

Okay, so what is wrong with this picture?

It is pretty obvious that the people who set this one up were not using the CEICW to configure the Internet settings. If they did, Exchange would have answered with at least "myinternetdomain.com" instead of the .local internal domain.

What does that mean? Probably a good chunk of that particular establishment's email won't be getting anywhere fast. Most SMTP servers will perform a reverse DNS lookup on any email they are receiving. The myinternaldomain.local does not exist on the Internet, so their email is toast.

Also, the ESMTP 6.0.37.90.3959 does not line up with any of our installations. My guess is that Exchange SP2 is not installed. Our SBS Exchange SP2 ESMTP answers 6.0.3790.1830.

After a search, we couldn't find the version numbers for the SMTPSVC. Anyone able to fill us in?

So, there are two very important lessons here:

1. Use the wizards! - especially the Configure E-mail and Internet Connection Wizard.
2. Post SBS install should always have the latest updates and service packs.

This last one needs some reflection. Windows Server 2003 Service Pack 2 requires some research first.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

SBS - Exchange Email Spam Issue with Question to You.

Okay folks ... This one has me a bit stumped, but at least we are getting somewhere with it.

After calling two different hosting companies - they each host a domain that our client is trying to communicate with - located locally, we may have something. One of the hosting companies has not returned our call yet, but we got to work with the other for about half an hour testing things.

It turns out that they have their servers set to deny the first connection attempt with a 5.7.1 "Try Again" message. This is verbatim from the technician we were speaking with.

On our client's SBS Exchange server, the message tracking indicates that there was a successful SMTP connection, and that the email message was accepted by the hosting provider's email server successfully too!

We tried sending an email from our own SBS Exchange based domain to our client's intended recipient, and the email disappeared into the ether as well. The hosting email server accepted the SMTP connection and accepted the email with no Deny/Retry indicated. Our SBS Exchange queue indicated the email sent to the intended recipient successfully.

At that point the technician was a bit puzzled but still indicated that the problem was on our end and not theirs. I mentioned that it was strange that two different sending SMTP servers have done this, one while we watched, and he stood by our servers being the culprits.

Me thinks not. Their server received the email, put it in some sort of queue - he could look at the cue but couldn't find the message - and their email server would then wait for the sender's server to try to send the email again.

Well, Exchange is not going to try again, because the email was "accepted" by the hosting company's email server. Both of our SBS Exchange message tracking logs indicated thus.

He requested that I send a second email which I did, and it got through with no problems. Again, our SBS Exchange message tracker indicated a successful transfer of the email to the hosting company's email server.

It is strange that both our client's SBS Exchange and our own SBS Exchange servers indicated a successful transmission of the email but the hosting company's servers seemed to make them "disappear" on the first attempt by those SBS servers.

Anyone else experiencing this kind of issue?

It is looking like the hosting company has a configuration issue with their email servers.

For the email server experts out there ... is it proper to have an email server deny the first attempt to connect by a SMTP email server?

Somehow I find this to be a bit strange in my experiences working with Exchange all these years to do that as an anti-spam technique.

Hopefully we hear back from the second hosting company. It would be interesting to see if they are doing the same thing.

BTW: By default Exchange will retry to send a message after 10 minutes if it had received the Deny/Retry message.

UPDATE 2007-08-15: We have subsequently found out that the second hosting provider is only hosting the Web site. So, our next step is to look to the internal email setup for that one.

The hosting provider that we did speak with yesterday contacted us today as we sent in a message requesting further clarification.

They graciously forwarded the logs from yesterday.

This is a screen shot modified to pull relevant data:


So, as the fellow mentioned, there is a "4.7.1 Please try again later" message in the log. I do believe that these logs may not reflect the very first attempt to send the intended recipient an email as there was no retry. If there was as this log shot shows, then their email server vapourized our email as indicated by the second acceptance message in their log!

We ran through a series of tests again today, only this time Exchange did get the 4.7.1 message and retried 1 minute later.

Perhaps they made some changes? Not too sure about that. BTW, they are running the Merak Email Server by IceWarp.

It would be interesting to see if these issues are primarily with smaller outfits like this one.

UPDATE TO THE UPDATE - IMPORTANT:

This one deserves its own post...SBS - Exchange Email Spam Issue - Error Workaround - Exchange may not be retrying!

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

We are back and buried! ;)

As things go, we have had a bunch of things to take care of after our break.

So, posting may be light as we catch up, but we do have a number of new Mac on SBS related posts to take care of.

A little spam monster is rearing its ugly head on the spam front: We are finding that some of our clients are hitting mysterious disappearances of their emails sent to their own clients. Hopefully, we can get some cooperation out of the recipient's IT department to find out what spam filters they are running and whether they are in-house or a third party service. And, why the chicken they can't seem to add email domains to a "whitelist" on their spam filters.

More to come on the spam filter front...

Anyone else encountering clients getting frustrated that their email isn't getting through?

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.