SMTP email nightmare!

Prophet

Prophet

Prophet

Soldato
Joined
5 Oct 2004
Posts
7,398
Location
Notts
One of our customers is set for SMTP email (in/out) using SBS2003. They havent received any email for a couple of days. The ISP isnt the cause and I've telnet'd into the server to check the SMTP which works OK. The router is configured correctly too.

Outgoing mail is fine.

Any ideas?
 
DNS?

Are the MX records for the domain correct?

Perform an nslookup to determine the MX record(s) an then telnet to that from an external source. If that's all hunky dory then its gonna be a config thing at which point i'll kindly step down and let someone who know SBS a lot better than me advise on how to resolve the problem.

Dan.
 
is this exchange based account that is being used via pop3 or is it a basic mailsite account ? You should have a webmail accesspoint for both services though, either a mailsite express or an outlook web access - try logging in via the webmail area to see if mails are in there.

Do they get any pop/smtp error messages?

Can you send them a test message? can you replicate the issue on your local macgine by using their credentials?

Things worth trying :)

Also make sure no mail forwarding is enabled!
 
CoXeY said:
DNS?

Are the MX records for the domain correct?

Perform an nslookup to determine the MX record(s) an then telnet to that from an external source. If that's all hunky dory then its gonna be a config thing at which point i'll kindly step down and let someone who know SBS a lot better than me advise on how to resolve the problem.

Dan.
Click to expand...

I've checked this and it all looks fine! I did think it was something to do with the IMF as we are having similar problems here, but when I checked its not enabled on their server!
 
mrk said:
is this exchange based account that is being used via pop3 or is it a basic mailsite account ? You should have a webmail accesspoint for both services though, either a mailsite express or an outlook web access - try logging in via the webmail area to see if mails are in there.

Do they get any pop/smtp error messages?

Can you send them a test message? can you replicate the issue on your local macgine by using their credentials?

Things worth trying :)

Also make sure no mail forwarding is enabled!
Click to expand...

Its exchange but uses SMTP both ways. This is authenticated by their fixed IP address. It difficult to replicate this on our machines as its fixed to their IP.
 
MX

INFO MX Record Your 2 MX records are:
20 mxbackup.griffin.com. [TTL=3600] IP=83.148.189.24 (No Glue) [TTL=3600] [GB]
10 mail.magfern.com. [TTL=3600] IP=85.189.37.132 [TTL=3600] [GB]

PASS Low port test OK. Our local DNS server that uses a low port number can get your MX record. Some DNS servers are behind firewalls that block low port numbers. This does not guarantee that your DNS server does not block low ports (this specific lookup must be cached), but is a good indication that it does not.

PASS Invalid characters OK. All of your MX records appear to use valid hostnames, without any invalid characters.

PASS All MX IPs public OK. All of your MX records appear to use public IPs. If there were any private IPs, they would not be reachable, causing slight mail delays, extra resource usage, and possibly bounced mail.

PASS MX records are not CNAMEs OK. Looking up your MX record did not just return a CNAME. If an MX record query returns a CNAME, extra processing is required, and some mail servers may not be able to handle it.

PASS MX A lookups have no CNAMEs OK. There appear to be no CNAMEs returned for A records lookups from your MX records (CNAMEs are prohibited in MX records, according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3).

PASS MX is host name, not IP OK. All of your MX records are host names (as opposed to IP addresses, which are not allowed in MX records).

PASS Multiple MX records OK. You have multiple MX records. This means that if one is down or unreachable, the other(s) will be able to accept mail for you.

PASS Differing MX-A records OK. I did not detect differing IPs for your MX records (this would happen if your DNS servers return different IPs than the DNS servers that are authoritative for the hostname in your MX records).

PASS Duplicate MX records OK. You do not have any duplicate MX records (pointing to the same IP). Although technically valid, duplicate MX records can cause a lot of confusion, and waste resources.

PASS Reverse DNS entries for MX records OK. The IPs of all of your mail server(s) have reverse DNS (PTR) entries. RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. Note that this information is cached, so if you changed it recently, it will not be reflected here (see the www.DNSstuff.com Reverse
DNS Tool for the current data). The reverse DNS entries are:
24.189.148.83.in-addr.arpa mxbackup.griffin.com. [TTL=21600]
132.37.189.85.in-addr.arpa 85.189.37.132.griffin.managedbroadband.co.uk. [TTL=3600]


MAIL

FAIL Connect to mail servers ERROR: I could not complete a connection to one or more of your mailservers:
mail.magfern.com: Timed out [Last data sent: [Did not connect]]

PASS Mail server host name in greeting OK: All of your mailservers have their host name in the greeting:

mxbackup.griffin.com:
220 mxbackup.griffin.com NO UCE ESMTP

PASS Acceptance of NULL <> sender OK: All of your mailservers accept mail from "<>". You are required (RFC1123 5.2.9) to receive this type of mail (which includes reject/bounce messages and return receipts).

PASS Acceptance of postmaster address OK: All of your mailservers accept mail to [email protected] (as required by RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1).

PASS Acceptance of abuse address OK: All of your mailservers accept mail to [email protected].

PASS Acceptance of domain literals OK: All of your mailservers accept mail in the domain literal format (user@[83.148.189.24]).

PASS Open relay test OK: All of your mailservers appear to be closed to relaying. This is not a thorough check, you can get a thorough one here.
mxbackup.griffin.com OK: 554 <Not.abuse.see.www.DNSreport.com.from.IP.85.189.73.16@DNSreport.com>: Relay access denied

WARN SPF record Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).
 
Orange Peel said:
One of our customers is set for SMTP email (in/out) using SBS2003. They havent received any email for a couple of days. The ISP isnt the cause and I've telnet'd into the server to check the SMTP which works OK. The router is configured correctly too.

Outgoing mail is fine.

Any ideas?
Click to expand...

Well if I try and connect to the mailserver from here and I can't connect;

C:\>telnet mail.magfern.com 25
Connecting To mail.magfern.com...Could not open connection to the host, on port 25: Connect failed
Click to expand...

Have you checked the firewall, hardware or software, hasn't been changed ?

Have you tried restarting the SMTP service on the SBS server ?

Can you see any connection attempts at all to the SMTP service in the SBS logs ?
 
derfderfley said:
Well if I try and connect to the mailserver from here and I can't connect;

Have you checked the firewall, hardware or software, hasn't been changed ?

Have you tried restarting the SMTP service on the SBS server ?

Can you see any connection attempts at all to the SMTP service in the SBS logs ?
Click to expand...


The firewall is forwarding all port 25 traffic to the exchange server so that looks OK.

I've restarted the server and all the exchange services.

I've used telnet to prove the SMTP is working. I've done this from the server in question and my PC which is connected via a VPN.

I'm not sure which logs your refering to. Can you point me in the right direction?
 
It's no good trying to telnet in when you are inside the network, even via a VPN, i tried as well to telnet in, with no success.

double check the exchange settings, just to make sure they are set ok, and check the firewall.

does the mail go through anyone else before them, like messagelabs?
 
Baz said:
It's no good trying to telnet in when you are inside the network, even via a VPN, i tried as well to telnet in, with no success.

double check the exchange settings, just to make sure they are set ok, and check the firewall.

does the mail go through anyone else before them, like messagelabs?
Click to expand...

The mail goes through 'griffin internet' They've checked their servers and say everything is OK. Should you be able to telnet into a mail server from anywhere? That part is new to me so I don't know!

When I checked the router logs there's activity coming from the mail.server.com so its being routed correctly. Its got to be something on the exchange server. Just don't know what as it was working OK last week and nothing has been changed!!
 
Orange Peel said:
The mail goes through 'griffin internet' They've checked their servers and say everything is OK. Should you be able to telnet into a mail server from anywhere? That part is new to me so I don't know!

When I checked the router logs there's activity coming from the mail.server.com so its being routed correctly. Its got to be something on the exchange server. Just don't know what as it was working OK last week and nothing has been changed!!
Click to expand...

Yes, you should be able to connect to the mailserver from any IP, or you wouldn't get any mail. Posting mail though the server should be restricted for obvious reasons. Connecting from the inside, which you are when you are connected by VPN just proves that the mailserver is responding correctly to requests originating from the local network.

In the logs on the SBS server you should be able to see incoming and outgoing SMTP connections been made. This needs checking on the SBS server, not the router, if you turn the logging levels up you should be able to see what happens to each SMTP requests incoming or outgoing. This should piont you in the right direction as to why the server is not responding to SMTP mail requests that are coming from external networks.

As for nothing been changed, how many people have admin access to the router, firewall and SBS server. If it's only a few ask around and see if anyone owns up to changeing things.

I have a feeling this is going to be one that needs a site visit to get to the bottom of it I'm afraid :(
 
derfderfley said:
In the logs on the SBS server you should be able to see incoming and outgoing SMTP connections been made. This needs checking on the SBS server, not the router, if you turn the logging levels up you should be able to see what happens to each SMTP requests incoming or outgoing. This should piont you in the right direction as to why the server is not responding to SMTP mail requests that are coming from external networks.

As for nothing been changed, how many people have admin access to the router, firewall and SBS server. If it's only a few ask around and see if anyone owns up to changeing things.

I have a feeling this is going to be one that needs a site visit to get to the bottom of it I'm afraid :(
Click to expand...

Are you refering to the logs made in the windows\system32\logfiles\W3SVC1 directory?

Only our company has access to this server with a total of 3 people having the password. One is on holiday, one is my boss who has been one site for a week and one is me!

Its a real head scratcher! I've checked everything I can think of, just need to decrypt the log file as it look greek to me!
 
Orange Peel said:
Are you refering to the logs made in the windows\system32\logfiles\W3SVC1 directory?

Only our company has access to this server with a total of 3 people having the password. One is on holiday, one is my boss who has been one site for a week and one is me!

Its a real head scratcher! I've checked everything I can think of, just need to decrypt the log file as it look greek to me!
Click to expand...

Sorry couldn't tell you where the logs live.

I would start by making sure that SMTP (TCP Port 25) is correctly forwarded to the SBS server and take it from there. If you can I'd forward a couple of other ports (set up RDP to a machine on the network?) through to a different machine on the network to make sure the router/firewall is working correctly. Or that it is at least working in the way you think it is.

Could also be worth port scanning the server and see if port 25 is reported as been open?
 
If you can't telnet over port 25 to the external IP of your firewall (telnet 85.189.37.132 25) from outside your network and get a response from the exchange server then you will not get any email.

If there is no reply then try to telnet over port 25 to the internal IP of the exchange server from inside the network. A response from this will indicate that the server is listening on port 25 and the problem will therefore be with the firewall.

If this is the case try removing the rule pointing smtp to the exchange server and recreate it, often works for me. Otherwise you may be looking at a busted firewall.

Also worth running the Exchange Best Practices Analyser to identify any possible issues with the exchange server.
 
Last edited:
I would start with the firewall rules too.

On the subject of SMTP logging, it's not always enabled. To enable:

Exchange System Manager
Drill down through
Servers
<YourServer>
Protocols
SMTP
Default SMTP Virtual Server
Right click this > Properties
Enable logging on the dialogue box, I prefer MS IIS Format. I also move the logs into an easy to find folder eg C:\SMTP Logs
 
As said, it's not letting SMTP traffic on port 25 in. Nothing goes 'through' griffin internet, it is first attempted to be delivered to mail.magfern.com, which I assume is pointed at your public IP.

It's most likely a firewall/forwarding problem.

Fortunately, the griffin mxbackup server is probably hoarding all your mail waiting for you to fix the problem... so nothing should be lost, just bloody late.
 
Thanks for all the replies :)

I've gone through everything mentioned above (a few times) with no success! I've changed the firewall/router but that didnt work.

In the end I've had to admit defeat (for now) and change over to pop3 incoming email. This worked straight away as expected.

I will get it working on SMTP but the customer was waiting for several emails and I needed a quick fix.

I'll let you know what eventually fixes the problem as and when I find a solution!

Thanks again for all your help :)
 
You must log in or register to reply here.
Back
Top Bottom