RATS-dyna blacklist & reverse DNS

[HCHTech]

I have a client that is reporting random delays on sent email being received by the certain recipients. If I open Exchange manager, I can see these messages are stuck in the outgoing queue with the error

421 4.4.0 Remote server response was not RFC conformant

After a fashion, the messages will send. Researching that error a bit pointed to problem with the reverse DNS.

After finding nothing obviously wrong with their SBS2011 Exchange setup, I ran their domain through MXToolbox, which found a couple of things.

- They are on the RATS-dyna blacklist, and
- There is an SMTP warning that "Reverse DNS does not match the SMTP banner"

Exploring the RATS-dyna removal page, I find this:

=================
You should ONLY need to remove yourself from this list IF you are running your own mail server, "Best Practices" says that the reverse DNS that mail originates from, should resolve to the company that is responsible. For example:

mail.yourdomain.com-- or --gateway.yourdomain.com
If it is 'generic_addressing_style.upstream_provider.com' it will probably get blocked by Anti-Spam technology anyways.

This represents approximately 50% of the most abusive forms of wasted overhead facing mail servers.

NOTE! Remember, you should ONLY use this if you are checking if it one of your customers (RELAY CLIENT SET)

NOTE! Do not use this at the global level unless you have some way of ensuring that it only affects inbound mail.
=================
and also this:
=================
Remember, you can ONLY remove your IP from this list, IF you have corrected your reverse DNS entry, which was one of the reasons you got on this list in the first place, to better conform to 'Best Practices'. Make sure that enough time has passed for DNS propagation.
=================

So it appears (at least) that a bad reverse DNS might be responsible for being on the blacklist, which also might be responsible for email delays to clients whose mailservers check for blacklist residence.

If I telnet into the server on port 25, I should get the current SMTP banner, yes? So if I do that, I get (domain redacted):

220 SBSSERVER.xxxxxxxx.local Microsoft ESMTP MAIL Service ready at Tue, 21 Jun 2016 16:53:13 -0400

I've read that you can change the banner with a (Set-ReceiveConnector –identity “ServerConnectorname” –Banner “220 banner text”) powershell command, but the current banner was clearly created by one of the SBS wizards and there is no way I'm going to screw with that unless I know for sure what effect it will have.

Is it that important that the reverse DNS match the SMTP banner - obviously it was working before, and it only shows as a warning on MXToolbox, not an error.

I also don't want to request removal from the blacklist until I'm sure the problem that got me there in the first place is fixed. We have run scans on all computers just in case and they are not infected.

There are too many variables here and I'm not sure which direction to go first. Can someone provide some clarity?

 

[nlinecomputers]

SBSSERVER.xxxxxxxx.local?? That should be your domain name and it should have an MX record. So if your MX record says mail.example.com then the banner should be the same.

 

[TurricanII]

Do you know what a reverse DNS entry is, i.e. have you emailed their ISP and asked them to add a free DNS record so that their IP address resolves back to the same host as specified in their MX record e.g. mail.cleint.com?

You can change the banner/response by right clicking the Internet Receive connector under Servers in the Exchange GUI and setting the server name there. You will see the .local server name is still in there. You can not break anything by changing that value (or at least since 2000 I have not seen any ill effects). Change it!

Another approach would be to buy an online email SPAM filter like Max Mail/Messagelabs and route all inbound AND outbound email through that,. added bonus - email can be queued while your Internet is offline, and the virus/SPAM filtering is generally better than the in house stuff.

Edited to add - When you telnet to the Exchange server on port 25, are you doing that from inside or outside the network? The banner is usually different when telnetting in from outside..

 

[HCHTech]

SBSSERVER.xxxxxxxx.local??

Oh, right - I had a VPN tunnel up when I did that, so I was really inside the network. I'll have to try it outside and see.

 

[nlinecomputers]

Oh, right - I had a VPN tunnel up when I did that, so I was really inside the network. I'll have to try it outside and see.

A VPN connection wouldn't affect the banner. . local is what you are displaying to the world, hence the error message.

 

[HCHTech]

You can change the banner/response by right clicking the Internet Receive connector under Servers in the Exchange GUI and setting the server name there. You will see the .local server name is still in there. You can not break anything by changing that value (or at least since 2000 I have not seen any ill effects). Change it!

Ok, awesome - thanks! GoDaddy has their domain, so I'll give them a call tomorrow to get the reverse entry sorted.

 

[TurricanII]

A VPN connection wouldn't affect the banner. . local is what you are displaying to the world, hence the error message.

A VPN may well affect the Receive Connector and therefore SMTP banner that the server applies. The receive connectors are scoped by source IP address ranges. VPN-ing in often means you have a LAN IP and subsequently telnetting it on the internal IP appears to the Exchange server that you are a LAN client and you get the internal server name.

The Internet receive connector is best tested by disconnecting the VPN and, for certainty, telnetting the public IP.

 

[TurricanII]

Ok, awesome - thanks! GoDaddy has their domain, so I'll give them a call tomorrow to get the reverse entry sorted.

No it is not DoDaddy as the domain DNS holder/registrar that you need to talk to.

The DNS host is where you set the FORWARD DNS (i.e. you need to turn a host name into an IP) The IP address on their Internet is assigned to them by their ISP/phone company. You need to call the ISP and ask them to put the REVERSE DNS in. Reverse DNS is when you know the IP address and you look up the host name from that. The ISP controls the IP addresses and so they provide/update the reverse DNS server.

Now, if the client is using a residential Internet connection then the ISP may not provide reverse DNS and may not really allow you to run an email server. In that case I would advocate an online mail service as noted above.

 

[HCHTech]

local is what you are displaying to the world, hence the error message.

Ok - that is a problem, then. I wonder how that happened (sheepish grin) - I'm surprised it worked as long as it did!

 

[nlinecomputers]

A VPN may well affect the Receive Connector and therefore SMTP banner that the server applies. The receive connectors are scoped by source IP address ranges. VPN-ing in often means you have a LAN IP and subsequently telnetting it on the internal IP appears to the Exchange server that you are a LAN client and you get the internal server name.

The Internet receive connector is best tested by disconnecting the VPN and, for certainty, telnetting the public IP.

That's right. I'm an idiot. But I'm betting that she is displaying local to the world. I've seen that plenty of times.

 

[TAPtech]

Yep....need to contact ISP and setup an rDNS pointer with your proper internet facing domain name. Oh and keep in mind uh... it's backwards

Some ISP guys may help you out with this while others are going to ask you exactly what you need the rDNS ptr to be. So get your ducks in a row!

 

[HCHTech]

No it is not DoDaddy as the domain DNS holder/registrar that you need to talk to.

Ok, fine I think I understand what you are trying to say there - I concede. Looks like I have a lot of phone time ahead of me tomorrow. GoDaddy is their host. Verizon is their ISP - they have business service, so hopefully I won't spend half a day getting through level 1.

I'm guessing the importance of this is increases as spam filters & other security checks get stronger. I'll also guess that there are a lot of mail servers out there that don't have it right.

 

[TurricanII]

And for completeness, check and add an SPF record for them next! That's a godaddy DNS text record

 

[YeOldeStonecat]

Ok - that is a problem, then. I wonder how that happened (sheepish grin) - I'm surprised it worked as long as it did!

There are STILL tons of mail servers out there setup improperly..they've worked years ago when anti spam measures were weak. They're kept working up until recently because antis-spam measures slowly got stricter and stricter.

If you go get an anti-spam appliance, and if you turn on ALL the checks....it will reject way too much email..because so many "legit" businesses still run email servers that are not up to proper setup yet. The RevDNS/PTR is a very common one that is not setup...as is the banner ID.

 

[HCHTech]

Just to get the correct information in this thread for posterity. Note the servers computer name is SBSSERVER.

@nlinecomputers - I believe the banner is really remote.xxxxxx.com. In Exchange manager, under the properties of Server Configuration--->HubTransport, there are 3 receive connectors, and I believe I was looking at the wrong one. They are:

Default SBSSERVER - the banner listed there is SBSSERVER.xxxxxx.local
SBS Fax Sharepoint Receive SBSSERVER - the banner listed there is SBSSERVER.xxxxxx.local
Windows SBS Internet Receive SBSSERVER - the banner listed there is remote.xxxxxx.com

Also to illustrate the impact of the VPN, when I telnet to the server (using remote.xxxxxx.com) on port 25 *WITH* a VPN connection, I get:

220 SBSSERVER.xxxxxx.local Microsoft ESMTP MAIL Service ready at Wed, 22 Jun 2016 10:45:42 -0400

When I telnet to remote.xxxxxx.com on port 25 *WITHOUT* a VPN connection, I get "could not open connection to the host on port 25, connection failed". Ok, so my Sonicwall is working.

I know they have an A record for mail.xxxxxx.com pointing to their external IP address, so telnetting to THAT address on port 25 (no VPN) gets a successful connection.

220 mia0vm-cass01.colo.sonicwall.com ESMTP SonicWALL (8.2.2.5547)

When I telnet to the server using their external IP address on port 25 - again without a VPN connection, I get

220 mia0vm-cass04.colo.sonicwall.com ESMTP SonicWALL (8.2.2.5547)

I believe that makes sense, but I'm out of my depth here, so I'm going to seek some assistance.

@turricanll - Checking at viewdns.info, under MX Record tests, there is a reverse DNS entry, but it looks like a Verizon default - (I've redacted the actual IP #s)

[backwardsIP].in-addr.arpa <--> static-[forwardsIP].pitbpa.fios.verizon.net.

The format look right, but we obviously need one pointing to the domain name, not the IP.

So, I'm off to do some homework with GoDaddy to see exactly what their DNS records are, then speak with Verizon to get the rDNS entry. I suspect I'm going to need to change the banner for the internet receive connector to mail.xxxxxx.com as part of this project.

 

[TurricanII]

I will add that the banner does not usually affect mail flow and the rfc standard for greetings banners only demands that the banner starts with 220:

---
3.1 Session Initiation

An SMTP session is initiated when a client opens a connection to a
server and the server responds with an opening message.

SMTP server implementations MAY include identification of their
software and version information in the connection greeting reply
after the 220 code, a practice that permits more efficient isolation
and repair of any problems. Implementations MAY make provision for
SMTP servers to disable the software and version announcement where
it causes security concerns.
---
As long as the banner is not the internal domain name the I'd leave it.

If your concern is with outbound email then I would your send connectors to ensure that they have the MX record name so that when they begin to transmit an email they will announce the correct host name from which they are sending the email

 

[YeOldeStonecat]

I will add that the banner does not usually affect mail flow and the rfc standard for greetings banners only demands that the banner starts with 220:

Depends on various anti-spam filters....
here's a page of one, with settings relative to HELO and the banners....
Most settings here are "off"...if I flip them on, soooo much e-mail will be stopped/rejected..and tons of clients will call up complaining that they're not getting e-mail from so-and-so.

 

[TurricanII]

Depends on various anti-spam filters....
here's a page of one, with settings relative to HELO and the banners....
Most settings here are "off"...if I flip them on, soooo much e-mail will be stopped/rejected..and tons of clients will call up complaining that they're not getting e-mail from so-and-so.

When I say 'banner' I mean the receiving server's greeting in reply to the sending server's connection, as configured on the receiving server's receive connector. That doesn't affect much at all and indeed the standard allows for the banner to be simply '220'. Most of our clients are set to return '220 Unauthorised login attempts will be reported to your ISP'.

I can't read all of those settings above but they appear to be only for examining the HELO or EHLO command that the sending server sends to the receiving server to introduce itself. The HELO command SHOULD specify a valid hostname according to the standard, and this is hostname is the one configured (in Exchange) on the properties of the Send Connector of the sender's mail server. Of course I agree with you - so many servers send a duff HELO hostname it is impractical to use that as a means for SPAM detection.

 

[YeOldeStonecat]

When I say 'banner' I mean the receiving server's greeting in reply to the sending server's connection, as configured on the receiving server's receive connector. That doesn't affect much at all and indeed the standard allows for the banner to be simply '220'. Most of our clients are set to return '220 Unauthorised login attempts will be reported to your ISP'..

Yup...I know what you mean.
The settings in above screenie actually do refer to the receiving servers greeting banner....
Here's a copy 'n paste from the Help section of that page.....but what I'm getting at, the OPs server is sometimes having issues sending out e-mail, and the symptoms he reports...makes me think some recipients are running spam filters that do not fully accept his clients servers configuration, and are at the least....greylisting the server or tarpitting the server...because it's not passing the pre-req checklist.

***********
:: SMTP Controls::

These options allow you to screen email content on the Mail Firewall Appliance based on the initial SMTP connection. Some unsolicited commercial email (UCE) can be blocked here by applying strict SMTP checks. This will block some UCE software that violates the SMTP protocol.

:: HELO Restrictions ::

Activate the Require HELO (EHLO) if you want the relay to require that connecting clients send a HELO (or EHLO) command at the beginning of an SMTP session. Requiring this will stop some UCE software. By default, SpamTitan does not require the use of HELO (EHLO).

Activate the Require Fully Qualified Hostname setting to reject the request when the hostname in the client HELO (EHLO) command is not in fully-qualified domain form, as recommended by the RFC.

Big one here ==> Activate the Require Resolvable Hostname setting to reject the request when the hostname in the client HELO (EHLO) command has no DNS A or MX record.

The Reject HELO Hostname Restrictions allows you to list HELO hostname entries that will be rejected if used by the connecting client HELO (EHLO) command. For instance, nobody should HELO as localhost since we are localhost.

Conversely, the Allowed HELO Hostname Restrictions can be used to allow connections from clients who may not adhere to the RFC. For instance if you are checking for HELO FQDNs and/or resolvable HELO hostnames, and a particular client does not meet these requirements, then you can enter that clients HELO entry here to allow the connection to be accepted. Note: The connection may still be rejected, if for instance, the client fails an RBL check or recipient verification check.

:: Sender/Recipient Restrictions ::

Activate the Enforce RFC Compliance setting to control how tolerant Postfix is with respect to addresses given in the MAIL FROM or RCPT TO SMTP commands. If enabled, Postfix will require envelope addresses to be within angle brackets (<>) and without extraneous information as required by the RFC. Unfortunately, the widely-used Sendmail program tolerates lots of non-standard behaviour, so a lot of software expects to get away with it. As such, being strict to the RFC not only stops unwanted mail, it may also block legitmate mail from poorly-written mail applications. This option is disabled by default.

Activate the Require Fully Qualified Domain Names setting to reject connections if the address in the client MAIL FROM command is not in fully-qualified domain form or if the address in the client RCPT TO command is not in fully-qualified domain form.

> Activate the Reject Unknown Sender Domain to reject the request when the sender mail address has no DNS A or MX record.
********************

 

[marley1]

Sound like you need to use an outgoing smart host instead of sending by DNS....