Zen Internet Support Forum

Hello all - Recently we've had a few users complaining that emails are getting bounced back, typically reporting SMTP communication errors.  I'm by no means an expert when it comes to this sort thing of thing but I’ve been doing a little digging about to see what I could come up with.

 

First things first... the setup.

•  We've got an Exchange 2003 server that resides at our head office.
•  We've got a multi-wan setup, all of our email and web traffic get's routed in and out via a Zen Business 8MB ADSL service
•  Email coming into the organisation has to go via a 3rd party email filtering service (maildefender) before getting forwarded to our exchange server.
•  A firewall rule states that only maildefender can communicate with exchange.
•  Our domain name is hosted with zen

I've checked our MX records for our domain and they seem to make sense, we've got 5 entries, the first 4 being maildefender servers and the last one pointing to mail.my-company.org.uk (which resolves to the zen adsl static IP we have).

 

So... my question is... if I did a reverse dns on that static ip, then should I get mail.my-company.org.uk?  Because at present it comes back with a  dsl-255-255-255-255.zen.co.uk style entry?  Which, as far as I know is wrong and could be causing the problem?

 

Can anyone shed any light?

 

Many thanks in advance :)

 

Garrie

I dont have the same set up as you but I have been suffering from bounce emails recently as well.

Has Zen any idea what is going on?, It seems to coincide with the move.

---

Amateur Radio Call sign: M0ZDG

When you say "SMTP communication errors" could you give a few examples - maybe PM me directly with those as it'd be useful to have as much information as possible ?

The PTR entry may affect things but only in terms of the receiving server's anti-spam style controls, e.g. they may be set to block anything with 'dsl' in the name - we do exactly that with some South American ISPs in that I've blocked all their *.dsl.tld entries (based upon the name, not the IP address) from sending to our MX servers due to the sheer volume of spam.

To be of much more help I need more information. One question, do you send out via our smarthosts (mailhost.zen.co.uk) or direct from your exchange server ?

---

--
Jerry Nicholls
Principal Systems Engineer
perl -e '$_=q(print "perl -e \x27\$_=q($_);eval\x27\n");eval'

Hi Jerry - Thanks for the input.

 

Our email goes out straight out from our exchange server.

 

The bounce backs are pretty much all the same, an example below:

 

on 19/02/2008 11:44

There was a SMTP communication problem with the recipient's email server.  Please contact your system administrator.

<EXCHANGE.************.org.uk #5.5.0 smtp;501 Syntax error in parameters or arguments>

 

We've had problems sending to a range of a different providers, from AOL to local councils... Also it doesn't seem to be consistent, one day you can send to a particular email address, others you can't.

 

Thanks again for your time :)

 

Garrie

 

Okay. I'll now openly admit that I'm no fan of Exchange as from my experience diagnosing problems can be very difficult due to the way it responds to issues and how it logs communications.

Have you ever seen this problem when sending email into a Zen address ? If so I may be able to cross check against our logs to see if there is anything obvious.

It's a real pity that it's inconsistent since if you could repeat the problem I'd suggest using Wireshark to look at the SMTP transaction on the wire.

It certainly doesn't (immediately) look to be a PTR or MTU issue since the based on that error message the remote server is complaining about something in the SMTP transaction as opposed to rejecting outright or suffering a timeout respectively. Googling for that error is bringing up all sorts of possibilities. The best I can suggest at this time is to increase the logging on your server and wait for it to happen again, maybe then there will be enough evidence to identify the issue.

---

--
Jerry Nicholls
Principal Systems Engineer
perl -e '$_=q(print "perl -e \x27\$_=q($_);eval\x27\n");eval'

I've never heard of this error occurring when sending and email to a zen address, council addresses seem to cause the most problems.  

I've enabled logging on the SMTP virtual server and hopefully that will yield some valuable information.  If your happy it's not a PTR issue then that’s good enough for me :)  I thought it was unlikely, as you'd assume that every email we sent to that server would bounce back rather than just the odd one.

I'll keep googling :) Thanks again for all the input, it's much appreciated.