ESA deployment in an ISP environment

[henrybett]

Hi All,

I am to deloy an ESA in for an ISP and some questions came up since i mostly deploy in enterprises/offices with a firewall (DMZ) which is very straight forward. For an ISP however, i am having trouble understanding how mail flows from their clients to the ISP then to the internet and back. Can anyone explain how this would be done:

1. the ISP want mail from their clients (who host their own MTAs) to be passed through spam filters (hosted by the ISP) before going out to the internet to avoid the client IPs being blacklisted all the time due to sending spam.

2. ISP wants incoming mail for their clients to go through the ESA before being forwarded to the clients MTAs, which as i said before, are hosted in the clients LAN.

Questions:

1. Where in the ISP network will the ESA sit (is it in a LAN just behind the core router or in the ISP internal LAN behind a firewall?)

2. Does the ISP have to do some kind of re-direction for SMTP traffic to pass through the Ironport ESA before going to the clients (for incoming mail)

3. Does the client and/or ISP need to change their MX records.

I would reaally appreciate a breakdown of how this deployment would be done.

Thanks.

[Ken Stieers]

Henry,

There are some experts around who may be able to point you at some docs on how to deploy for an ISP environment, but I took a shot at answering your questions...

1. You'll have to deploy the ESA such that both interfaces are exposed to the net somehow... Client's "outbound" email would be hitting the "inside" port of the ironport...

2. That would be the MX records and the Network>SMTP Routes page...

3. Yes.  MX records need to be pointed at the Ironport... The client's outbound next hop should be pointed at the Ironport's inside interface.

Some things that are going to be bigger issues...

     1.  How are you handling the Spam Quarentine Auth/Alias consolidation and Accept queries?  Are the clients opening Ldap to you?

     2. you mention 1 box... You can get buried by one of your clients' spam traffic... I hope you got more than one...

Ken

[henrybett]

Thanks Ken,

To answer your questions:

  1.  How are you handling the Spam Quarentine Auth/Alias consolidation and Accept queries?  Are the clients opening Ldap to you?

     2. you mention 1 box... You can get buried by one of your clients' spam traffic... I hope you got more than one...

1. The clients are not opening LDAP, we prefer to just enable Spam notifications (so end users clear their own spam) and a short lifetime for the Spammed messages to avoid the quarantine filling up.

2. Sorry (my poor english )  we will have two ESA boxes, i fully understand the mail traffic is massive at the ISP.

Could you please further explain how the ISP will do SMTP redirection, to ensure all SMTP traffic in their network infrastructure, will be channelled to the ironport FIRST before being forwarded to the clients as specified in the SMTP routes.

Regards,

Henry.

[Ken Stieers · Accepted solution]

Henry,

If you're looking for some network magic... so that it happens without changing MX records, I don't know of any.

The way most cloud-based mail cleaners work (MXLogic, Postini, Cisco Ironport Cloud, etc), the customers have to change their MX record to point to the service, and they point their outboud mail at the service also.

For each of the ISP's customers domains, you'd set a route in Network>SMTP Routes pointed at the customers mail server... where-ever that customer wants inbound mail to be delivered to (eg, where their MX record USED to point to...)

Ken

[henrybett]

Ken,

Thank you very much for the help. It is certain, then, that MX records will have to be changed on the client side to point to the ISP's ironport service.

Regards,

Henry.

[Bob Fayne · Accepted solution]

Henry,

I would also recommend that MX records be changed to allow inbound smtp traffic to pass through your boxes. In the absence of a hardware load balancer you can use two equally weighted MX records, one pointing to each box.

On the inbound side you will end up with recipient validation issues. Spammers and others can and WILL send messages to a lot of bad addresses. If you can't validate them at the edge on the way in then you will get stuck with them on your appliances and they can clog up queues if not managed carefully.

Your options for outbound are limited:

1) Transparent proxy in "stealth" mode

A transparent proxy that would capture SMTP to any address is not a function of an Ironport ESA but you could potentiallty set one up that forwarded everything to the Ironport appliances.

A transparent proxy gets complicated in an ISP environment. Customers may not be so happy with "hidden" traffic manipulation. You would have to turn off Received headers which is not RFC-compliant for edge systems and eventually customers would figure out that the IP where other systems see the mail coming from is not correct. This would make troubleshooting rather complicated. Not to mention that it is a bit heavy-handed.

2) Transparent proxy with headers getting added

3) Block direct outbound so they will be forced to relay through you

Many ISPs do this for residential customers but it tends to be less commonly applied to business customers running their own MTA.

4) Make relaying optional

If customers are going to be looking to you for help with blacklist and delivery issues then optional might not be the best method unless you SWIP networks to your customers (non-portable) so they become the contact of record.

Be aware that MS Exchange can spit out a lot of cruft that will add to your load. Things like Out-Of-Office replies and bounces from email sent to bad addresses can be a measureable percentage of the total email traffic. You can even see things like bounces including a copy of original attachments (WHY?). Just watch your undelivered recipients so that it doesn't get too high.