Exchange cluster responds with incorrect IP address

[routerman]

This was put to me by a customer, I dont know anything about exchange cluster or spam relay checking , but think this may be a configuration issue.

An email sent to certain ISP's gets queried to see if the sender is a relay, the cluster replies to this query via a different IP address.

So in a bit more detail outgoing email comes from the cluster IP address, this is NATed via the firewall to a specific outside address. The source IP address is queried by the ISP, but the response to that query comes from one of the individual servers within the cluster. So the firewall NAT's that address to the outgoing PAT address.

The ISP gets the reply orginating from a differnet IP address, so drops the email.

Question is how can they change the cluster to respond to the query with the cluster address?

Andy

 

[kmcferrin]

I cannot tell from your explanation what the ISP is doing to verify your servers, so this is rather generic advice.
I've never heard of an ISP that dynamically checked your server to see if it is an open relay. Many ISPs and business do check lists of known open relays and compromised systems to and drop email from those hosts or addresses. Your customer should verify that they aren't on one of those RBLs. They will also do queries to verify that email is coming from a legitmate mail exchanger (MX) for your domain, or to see if the IP address of the sending host belongs to a machine in your domain, etc. Some companies (like mine) utilize greylisting, which is described at

http://www.greylisting.org.

There are many many ways that ISPs and companies filter spam.

In a multi-server Exchange environment you should always utilize the concept of an SMTP gateway. The SMTP gateway is simply an Exchange server that receives all inbound messages and processes all outbound messages. The purpose of this is:

1. It frees up the rest of your Exchange servers to handle internal messages, serving mailboxes, etc.

2. It gives you a single choke-point to scan messages for viruses, spam, etc.

3. The same machine always sends the outbound email messages from the same IP address.

If you have a larger installation you should configure a second SMTP gateway server for redundancy/workload. For the sake of reference, I used to work for a large international company that had approximately 50,000 users and 175 Exchange servers scattered throughout the world, but only 4 SMTP gateway servers to handle all of the inbound/outbound messages. This was more than sufficient to handle the workload.

To make an SMTP gateway, go into each routing group defined in your organization (this is in Exchange System Manager) and define an SMTP connector. Make the Local Bridgehead the server that you want to be the gateway. Afterwards, all SMTP traffic will be routed to that server for delivery.

Things to watch for:

1. The SMTP gateway server (or servers) should all be listed in your Internet DNS with MX records. This is because some ISPs will do an MX query to verify that it is receiving email from a legitimate mail exchanger for your domain. Also, if they're not listed as an MX record then you'll never get inbound mail through them.

2. The SMTP gateway server should be in your DMZ and not hidden behind NAT/port forwarding. It should have a legitimate public IP address that it uses for sending and receiving email, otherwise receiving systems may mistake it for a rogue machine/mail relay.

The best way to really become familiar with all of this is to try implementing some anti-spam systems yourself so that you see how they work. Once you see the various options for filtering you can start proactively looking at your installations to make sure that they would pass all of the potential tests. A really good anti-spam program is called XWall, you can get it from

http://www.dataenter.co.at.

I've used their product at several jobs, and I have never seen a product that offerred so many ways to filter email. It's very inexpensive compared to most other solutions, and is free to try for 30 days. It also has a nice option for dealing with NATed addresses, whereby you can specify the name/address to be used by the machine that is sending the email.

 

[routerman]

Thanks for the comprhensive reply, I may have found the issue, another of my customers has run into the same issue with ths same ISP, AOL.

The MX record points at the SMTP address, which is the specific outside address used for mail. I'm told the fix is to add a PTR record for the outside address of the firewall, which in this case is the PAT address. This way when one of the individual servers in the cluster send traffic using its own address and the ISP does the reverse lookup its accepted.

I'll have a look at the program you mentioned, and I've been looking at some information on the AOL postmaster site.

 

[kmcferrin]

The AOL postmaster site isn't bad, there's lots of helpful information. On the other hand, AOL is a pain to deal with. Literally 100% of my email support calls in the past month have been regarding AOL users. We get a lot of delivery failures when sending to AOL users that are accompanied by vague bounce messages like the one enclosed below:

Your message

 From:	<USER@DOMAIN.com>

 To:	USER@aol.com

 Subj:	SUBJECT
 Sent:	2005-06-20 15:37

has encountered a delivery problem.


Reason: Mailbox exists but is disabled
The mailbox exists but is not accepting messages.
This may be a permanent error if the mailbox will never be re-enabled or a transient error if the mailbox is only temporarily disabled.

Transcript of session:
DATA
354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
554-:  (RLY:BD) [URL unfurl="true"]http://postmaster.info.aol.com/errors/554rlybd.html[/URL]
554 TRANSACTION FAILED

If the user re-sends the message it gets through. Then the next message after that bounces again. We've been having a lot of cases where email sent to AOL addresses comes up garbled in the recipient's mailbox for no apparent reason, even though the message is sent by our server in plain text.

I am very close to sending out an email to all of our users indicating that we will no longer support email to/from AOL addresses. AOL does a miserable job of conforming to published standards (not just regarding email, but web browsers, etc). Instead of using one of the dozens of standards-compliant methods of handling mail, they invent some wacky system that only they use, but eventually ends up causing more headaches than it's worth. And if you try to talk to them their attitude is "We have millions of subscribers so you'll just have to figure out a way to work with it." If they actually had an email system that worked properly with everybody else's then they wouldn't need the Postmaster web site.

BTW, AOL's idea of providing notice about not having the PTR record was not posted very conspicuously. Any time your mailserver connects to one of the MX servers you get a banner message from them explaining their new policy. But unless you are actively reading the contents of each SMTP session between your email server and any other email server, you would have never seen it. It is enclosed below:

05-06-22 08:25:33 0005: Processing outbound message ended
05-06-22 08:25:33 0005: Resolving MX for aol.com (MSGdqln7)
05-06-22 08:25:34 0005: MX for aol.com is mailin-04.mx.aol.com [64.12.138.152]
05-06-22 08:25:34 0005: MX for aol.com is mailin-01.mx.aol.com [205.188.156.185]
05-06-22 08:25:34 0005: MX for aol.com is mailin-02.mx.aol.com [205.188.159.217]
05-06-22 08:25:34 0005: MX for aol.com is mailin-03.mx.aol.com [64.12.137.249]
05-06-22 08:25:34 0005: Connecting with mailin-04.mx.aol.com [64.12.138.152]
05-06-22 08:25:35 0005: Error: Unable to establish a connection with mail host [14]
05-06-22 08:25:35 0005: Connecting with mailin-01.mx.aol.com [205.188.156.185]
05-06-22 08:25:35 0005: Connection established with mailin-01.mx.aol.com [205.188.156.185]
05-06-22 08:25:35 0005: < 220-rly-ya03.mx.aol.com ESMTP mail_relay_in-ya3.6; Wed, 22 Jun 2005 08:24:26 -0400
05-06-22 08:25:35 0005: < 220-America Online (AOL) and its affiliated companies do not
05-06-22 08:25:35 0005: < 220-     authorize the use of its proprietary computers and computer
05-06-22 08:25:35 0005: < 220-     networks to accept, transmit, or distribute unsolicited bulk
05-06-22 08:25:35 0005: < 220-     e-mail sent from the internet.  Effective immediately:  AOL 
05-06-22 08:25:35 0005: < 220-     may no longer accept connections from IP addresses which 
05-06-22 08:25:35 0005: < 220      have no reverse-DNS (PTR record) assigned.
05-06-22 08:25:35 0005: > EHLO SERVER.DOMAIN.com