Exchange mail non-delivery (Telecom to TelstraClear Endpoints, IP Reputation)

Forums › Spark New Zealand (including Skinny and BigPipe) › Exchange mail non-delivery (Telecom to TelstraClear Endpoints, IP Reputation)

coffeenow

33 posts

Geek

ID Verified

Trusted

#100209 5-Apr-2012 09:50

Hi

I have a couple of clients who host their own Exchange server (SBS 2008) and are experiencing a high number of non-deliveries and delay deliveries.

- They are on the Telecom network
- Fixed IP
- Exchange sending directly via DNS
- Most bounces/delays are to clear.net.nz or paradise.net.nz addresses (+ some other domains)
- Error messages suggest IP reputation as reason for rejection
- Delays seem to have occurred since Monday
- PTR record is default Telecom xxx-xxx-xxx-xxx.adsl.xtra.co.nz
- IP address does not appear to be blacklisted anywhere
- www.senderbase.org lists the IP reputation as poor (senderbase

I've asked Telecom to change the PTR record to the mail URL for one of my sites but unsure if this will fix things.

- Is anyone experiencing similar problems with their Exchange server on the Telecom network?
- Has something changed resently at TCL or elsewhere?
- Is there a temporary workaround (is it possible to use send.xtra.co.nz as a smarthost?)
- How do restore the IP reputation?

Thanks in advance.

Tim

Brunzy

2016 posts

Uber Geek

Trusted

#605582 5-Apr-2012 10:52

I had a call am today from a client saying he had been trying to mail me for a few days and it kept getting returned.
I am with TC ( Paradise)

freitasm

BDFL - Memuneh
79266 posts

Uber Geek

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#605583 5-Apr-2012 10:55

If you have a business and depends on email, do yourself a favour and DO NOT USE YOUR ISP'S EMAIL.

Register a domain (what's $20-$30 for a business when considering branding, reliability, etc?) and use a free option such as Windows Live Domains or Google Apps. Or go for a paid option such as Office 365 or Google Apps Enterprise.

I am sad to see people driving around in vans with a web site address and email below is "@xtra.co.nz" or "@paradise.net.nz". They stopped one step short of getting a better life.

CYaBro

4583 posts

Uber Geek

ID Verified

Trusted

#605588 5-Apr-2012 10:58

freitasm: If you have a business and depends on email, do yourself a favour and DO NOT USE YOUR ISP'S EMAIL.

Register a domain (what's $20-$30 for a business when considering branding, reliability, etc?) and use a free option such as Windows Live Domains or Google Apps. Or go for a paid option such as Office 365 or Google Apps Enterprise.

I am sad to see people driving around in vans with a web site address and email below is "@xtra.co.nz" or "@paradise.net.nz". They stopped one step short of getting a better life.

Did you read the original post correctly?
They are using DNS to send their emails and as they are using Exchange they would have their own domain name and wouldn't be using their ISPs email.

Opinions are my own and not the views of my employer.

freitasm

BDFL - Memuneh
79266 posts

Uber Geek

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#605589 5-Apr-2012 10:59

I was replying to Brunzy.

coffeenow

33 posts

Geek

ID Verified

Trusted

#605605 5-Apr-2012 11:13

1) PTR

A reverse PTR record has been created and this hasn't resolved the issue (yet).

2) SPF

I've been through the MS Sender ID Framework SPF Record Wizard at http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/default.aspx and it's produced the SPF value "v=spf1 a mx ptr ~all".

I assume I add the SPF record in DNS with the following values:

Hostname: mail.domain.co.nz
Type: TXT
Value: v=spf1 a mx ptr ~all

3) Smarthost

Can I point an Exchange server at an Xtra smarthost?

send.xtra.co.nz? smtp.xtra.co.nz? SSL or not?

(Port 25 outbound has obviously been opened by Telecom for the server to be able send via DNS)

Sending via a smarthost would give me time to fix the IP reputation (if PTR + SPF is the solution)

Cheers

Tim

Oldhat

180 posts

Master Geek

Lifetime subscriber

#605609 5-Apr-2012 11:24

Using the standard xtra servers probably wouldn't be viable.

To use send.xtra.co.nz you would need to register each of the domain email addresses through the default account to be able to use send. If they only have a few (i.e. 5-10) it might be okay as a temporary workaround.

Using the xtra smtp server would possibly put you in the same boat as you are now.

plambrechtsen

1948 posts

Uber Geek
Inactive user

#605756 5-Apr-2012 15:27

Could it be anything to do with this?

http://www.itnews.com.au/News/296066,having-trouble-sending-email.aspx

Lenovo

Shop now for Lenovo laptops and other devices (affiliate link).

coffeenow

33 posts

Geek

ID Verified

Trusted

#605776 5-Apr-2012 15:40

Good spotting! I think you've hit the nail on the head.

I checked the Cisco reputation site yesterday (www.senderbase.org) and it stated that my client's IP had a poor reputation. Today the site isn't working - I hope that by tomorrow everything will be back to normal.

Just about to get Domainz to add an SPF record so hopefully that won't create other issues.

Cheers

Tim

qraider

374 posts

Ultimate Geek

#605835 5-Apr-2012 18:15

plambrechtsen: Could it be anything to do with this?

http://www.itnews.com.au/News/296066,having-trouble-sending-email.aspx

That explains a lot - nice find, thank you.

Current Phone:
- Android: Samsung SM-G900F Galaxy S5 (XT)
- Win Phone 8: Samsung ATIV S (XT)

Current Tablet:

- Acer Iconia 7" Android Tablet

Twitter: qraider

coffeenow

33 posts

Geek

ID Verified

Trusted

#606029 6-Apr-2012 10:34

Everything looks to be back to normal.

- outbound mail queues on the Exchange servers have cleared
- SenderBase IP reputation scores are now "Neutral"
- senderbase.org website is extremely slow today
- appears to have affected domains registered with MelbourneIT/Domainz

So the problem does look like it was a Cisco screw up that's now been fixed. 5-6 days later.

As a result of this one of my clients now has:

- a Telecom-configured Reverse MX A record (PTR) pointing to their mail server
- an SPF TXT record validating their mail server (v=spf1 a mx ptr ~all)

They never seemed to need these in the past but I guess now they are set up as they should be.

Thanks Peter for pointing out the article.

Cheers

Tim