Showing posts with label Spam Error. Show all posts
Showing posts with label Spam Error. Show all posts

Friday, 16 October 2015

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:

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:

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

Friday, 25 July 2008

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.

Wednesday, 15 August 2007

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.

Friday, 2 March 2007

Logos, Images, and E-mail Spammers

To date, I have had our SBSC logo attached to the bottom of my e-mail signature.

For the last while, there have been a number of e-mail messages that have seemingly gone unanswered. That never clicked either until some one's filter finally sent me a response:


Your e-mail was rejected by an anti-spam content filter on gateway ..."Oh really?

I can see why now, with the proliferation of embedding the spam message into the e-mail via a small image that can't be "read" by the spam filters.

I find that the deterioration of e-mail communications to over 95% spam content over the last number of years saddening.

Perhaps when all of the window dressing that is now contained in an e-mail is no longer allowed at all by any major e-mail server out there, people will begin to wake up?

In the meantime, say bubbye to the logo. Put the Blog URL in there instead! :D

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists