Email problem - but I think it's DNS related. 4

[SimonDavis]

Wonder if you can help me here, I have been trying to solve this for weeks.

I have been receiving bounce notices for a few emails to certain domains for a while.

Last week ALL mail stopped going out (incoming is fine), so I spent the weekend working through the problem.

Partial success; I found that the mx record for my mailserver showed it as my ISPs domain - I asked them to change the mx record, which they did to mailserver.mydomain.com (changed to protect etc).

After this, everything started working OK, but after a few days, the bounces started again.

My setup is broadly as follows;

Exchange 5.5/win2k, Outlook clinets. Mail is passed to a mailfilter on another win2k server (also the smtp server), then to a 3rd server running Symantec raptor.

Here's my theory . . .

I have 3 servers in the loop; mailserver.mydomain.com (exchange). mailfilter.mydomain.com (filter and smtp) then firewall.mydomain.com

Could the problem be that the mail is ultimately being sent out by firewall.mydomain.com, then a reverse DNS check is done by the receiving server, and finding the name mailserver.mydomain.com? The full servername isn't the same, although the domain is.

Otherwise, any ideas?

Just for more info, the event viewer on the filter/smtp server reports mainly error 4000 and specifies "the connection was dropped by the remote host", or sometimes "Unable to connect to the remote server".

smtpdiag for the problem domains reports "server rejected the recipient address"

I have made a few tweaks, including changing the mail verb as suggested by MS tech support, but the problem keeps creeping back.

Thanks for your help.

 

[SimonDavis]

Sorry, forgot to add, I have checked against blacklists, and as far as I can see we're OK there as well. The server passes all open relay tests fine, so that's probably not an issue either.

 

[elgrandeperro]

I think lots of inbound MTAS check:
you have a reverse.
that the reversed name isn't machine generated or generic.
also, if you use SPF records then it checks those.

"server rejected the recipient address" that is kinda strange. Do those addresses look valid?


I would use the handy skill of "telnet HOST 25" and spoofing email to see what is happening, probably from firewall.mydomain.com if possible.

eugene

 

[SimonDavis]

Thanks, I'll try that next.

For sure the addresses are valid - these are outgoing mails, to clients etc. They have all worked fine in the past.

Interestingly, I did some tweaking this afternoon, and set the masquerade domain on the smtp server to mailserver.mydomain.com (whereas the fqdn is mailfilter.mydomain.com) and it appears some of the problem mails are getting through now.

I shall do some telnetting anyway, as this problem seems kind of intermittent so the more I know the better I can hunt it down if it starts again.

 

[ForumKB]

You say you checked blacklists, did you check yourself or your host, I used to have a similar problem on my home system because it was through Sky and they had been blacklisted so my IP had been also . . .


Adrian Paris

Paris Engineering Ltd

http://www.ForumKB.com

Google search of just tech forums & articles
(very useful, honest!)

 

[SimonDavis]

Thanks Adrian.

I checked against the servers internet IP address. This actually goes to our firewall, which is a different server, with a different name (although the same domain).

Just seems it depends how tough the recipients setup is as to whether the mail gets through. At least that's what I think is happening - the receiving server is doing a reverse dns lookup, seeing the mail coming from firewall.mydomain.com and not mailserver.mydomain.com (which is what the mx record says it is), and assuming something's wrong.

I may be on the wrong track though, as the masquerade server setting I set up are on the filter - the machine in the middle. It doesn't make much sense, as the mail is still fired out from the firewall machine, but it seems to have helped.

Thanks for your replies though, all worth checking again.

 

[brianinms]

Your mx record, ie mail.yourdomain.com should resolve to the ip address that your mail is being sent as.

For example ...

If your mx record is x.x.x.3

And the server sending your mail is nated to x.x.x.10. Then the other mail servers will drop the traffic.

 

[SimonDavis]

I think it can only be that now - I arrived this morning to a new raft of delays/failures. It is kind of intermittent.

I will ask the ISP to change the dns mx entry to specify the firewall server name, see how that goes.

Thanks all for your help, I'll post back with an update.

 

[ChrisAC]

Your outgoung mail server doesn't have anything to do with your MX record! Your MX record is for inbound mail. Another server can send mail out if you so wish.

You just need to ensure that whatever server is sending your mail out, that it has reverse DNS and also an A record that matches. eg.

mailout.yourdomain.com IN A 1.2.3.4
4.3.2.1.in-addr.arpa PTR mailout.yourdomain.com

Of course, if your inbound and outbound mail servers are the same then just point the PTR to the MX record. As long as the PTR has a matching A record then it really doesn't matter. The point is that mail relays don't look up the MX record of the sending mail system. They just look up the IP address, resolve it to a name and then look for a matching A record.

Chris.



**********************
Chris A.C, CCNA, CCSA
**********************

 

[SimonDavis]

Thanks Chris.

I understand the MX record isn't required to reach the destination server, but is it correct to say that if the destination server is configured to do a reverse DNS check, it would go to the mx record for my domain to do the check?

Again, perhaps I have a vague understanding, but if the mx record for the domain doesn't specify a server with my domain name or the same IP address, some recipient servers will bounce the mail?

Also, wonder if you'd mind expanding a little on the example you posted? It looks familiar, but I don't understand exactly what each part of it means. I suspect understanding that would be a big help.

In the meantime, I have changed our DNS records at the ISP more or less as follows;

1 A record - mx1.mydomain.com .. .. IN .. .. A .. .. 111.111.111.111 (my firewall servers internet address)

mx record - mydomain.com .. .. IN .. .. MX .. .. 5 mx1.mydomain.com

And also put in 4 cnames, pop, smtp, webmail and pop3 all specifying mx1.mydomain.com

So far, this seems to be working. I have had one or two bounces in the last 24 hours, but nothing like the almost 100% failure I was getting.

 

[ChrisAC]

Hi Simon

"but is it correct to say that if the destination server is configured to do a reverse DNS check, it would go to the mx record for my domain to do the check?"

No, it wouldn't check the MX record. It would simply do an RDNS check on the sending email server. When it gets an A record from the RDNS it then checks to see if there is a matching A record for that PTR that points to the same IP address.

For example, the mail server receives a connection from your mail server on 1.2.3.4. It then does a rDNS check on 1.2.3.4 and finds that the PTR points to a server called mailout.acme.com. So, it then looks up the A record for mailout.acme.com and finds that it resolves to the IP address 1.2.3.4. Success. If mailout.acme.com pointed to a different address then the sending mail server could be faking the PTR so it would then fail the reverse check.

I used to have this problem with customers who hosted their own DNS for their domains but then wanted us to create PTR records for them because they were having mails bounced. Of course I'd happily create a PTR as requested but then a week or so later they'd complain that mail was still bouncing. Of course, I'd created a PTR as requested but then they hadn't created a matching A record so the PTR's pointed to non-existent A records/hosts.

Maybe if you provided the IP address of your outbound mail server then I could check the DNS?

Regards,

Chris.


**********************
Chris A.C, CCNA, CCSA
**********************

 

[SimonDavis]

Right, have solved the problem, and I'll put it up here for the benefit of others - I have Googled this one to death for nearly a month, and have never seen this particular issue . . . !

Our firewall server is connected to a Cisco router via a small switch. It turns out that the switch has an intermittent fault, and is causing data packets to disappear.

So, when our mailserver attempts to make a connection to a remote server, much of the time it fails - I was seeing a range of different failures and delays, seemingly at random. Sometimes it would fail to connect at all, and I'd get a 'the remote server did not respond to a connection attempt' error, other times it would fail during the exchange, and I'd get a 'the connection was dropped by the remote host' error. Occasionally nothing went out and it blamed dns.

I got to this conclusion after pinging our mailservers IP address via an external internet connection, and seeing a lot of lost packets.

So, a $10 switch later, we're back in business. thanks all for your help!