strange behaviour

trigger0512 · ‎01-21-2009

Hi Everyone

Wondered if anyone had seen behaviour like this before. 2 appliances in a centralised management deployment.

one listener only on each box with each listner having a relay hat policy and a default incoming policy. We are seeing outbound connections hit ironport 1 from exchange and are seeing instances of this error

Info: ICID xx Receiving failed: Too many messages.

At the same time it looks like messages are reported in the incoming report view (as opposed to outgoing) and also reported as being stopped by reputation filtering??? Under the incoming mail view the sender can be seen to be the IP address of the exchange.

The exchange box is definately specified in the relay hat group and it has an associated "relay" mail flow policy where obviously no SBRS checking is taking place.

Any ideas on what could be causing them to be reported as incoming?

Thanks

kyerramr · ‎01-22-2009

Hello David,

Since you have mentioned that exchange IP is listed in the RELAYLIST of the IronPort, the other issue I could think of is related to the order of SENDER GROUPS. Please verify if your RELAY sender group is listed at the top of the order. If f you can please post a snippet of the mail logs

-Kishore

trigger0512 · ‎01-22-2009

thanks kishore.

relay hat is very top of the list so it really should be catching that.

i'll try and post some of the mail_log later. i cant see why we get the too many messages error either as there is no throttling / specified limits on hats

walkermc_ironport · ‎01-22-2009

We've just implemented an Ironport solution and had *exactly* the same problem.

With the assistance of an Ironport engineer, we've moved to using two interfaces per device on different subnets (one inbound, one outbound) and the problems have instantly gone away.

TBH I think the Ironports simply don't work with a single IP as the incoming and outgoing interface. If you really can only have one interface enabled then apply two IPs on the same subnet to it and use one for inbound and one for outbound. This will resolve your problem. If you do this, ensure that your outgoing IP is the lowest address of the two in the subnet. For some reason, the outgoing listener always uses the lower IP ...

HTH :-)

steven_geerts · ‎01-24-2009

If you do this, ensure that your outgoing IP is the lowest address of the two in the subnet. For some reason, the outgoing listener always uses the lower IP ...

That depends on the IP address of your gateway. this is true if your gateway is located on the lower adrresses of your subnet (like most people have) if your gateway in onone of the higest addresses in your subject it's just the opposite.
A better conclusion would be:
If you do this, ensure that your outgoing IP is the closesed to your gateway of the two in the subnet.

Steven

Bart_ironport · ‎01-24-2009


TBH I think the Ironports simply don't work with a single IP as the incoming and outgoing interface.   If you really can only have one interface enabled then apply two IPs on the same subnet to it and use one for inbound and one for outbound.   This will resolve your problem.   If you do this, ensure that your outgoing IP is the lowest address of the two in the subnet.   For some reason, the outgoing listener always uses the lower IP ...

If all your IPs are in the same subnet, you can use "deliveryconfig" to force all outbound connections to originate from a specific IP. But don't try that if your interfaces are in different subnets - then you'll have to use the automagic behavior.

You can use an ironport with a single IP, but I won't recommend it. Using separate addresses for the inbound and outbound flow makes configuration so much easier. You can suspend them individually, attach configuration such as bounce profiles directly to the listeners,..