TLS encryption Based on Envelope Sender

austintxeric_ironport · ‎11-16-2009

I just wanted to pass on a feature request that we have recently run across in our environment that we would find extremely useful. I wanted to pass on the request and encourage anyone that would also like to see this feature implemented to contact your SE or Customer Care at Ironport.

enhancement request #53372
ability to enforce TLS encryption - based on the envelope sender

Has anyone else experienced the need for this? We have many partners/customers who we have contractual obligations to enforce TLS both Inbound and Outbound. It seems that more and more of them utilize 3rd party MTAs to send their mail, and most of the time those MTAs are not in the same domain as the "envelope sender". They also may switch IP addresses of their MTAs or switch providers routinely. This isn't that hard to manage if you only have a few TLS required partners, but when you have to manage over 100 policies, it gets difficult to manage. We would like the ability to enforce INBOUND TLS in much the same way we can enforce outbound TLS using destination controls which looks at the envelope recipient address to determine whether or not to enforce TLS.

Would love to hear any feedback from other customers on this.

Eric

joe_ironport · ‎11-16-2009

I also have the same problem managing my TLS policies and would welcome this “feature”.

Wargot_ironport · ‎11-17-2009

I would love these feature also, however I don't think it is possible without changing the way in with the IronPort works.

The TLS Connection is initiated at the initial connection from the sending MTA. Therefore the only information that is available is the IP address or host name of the sending MTA which could be a 3rd patry system.

This is the issue that we spend a number of days trying to come up with a solution for. In the end we concluded that we just needed to turn on Preferred TLS for all inbound connections. We would then have to ask the 3rd patry to ensure that they turn on Forced at their end via their provider.

We do turn on Forced from certain parties, but only if they maintain their own MTA. If they go via a 3rd patry we will not Force it as this will cause delivery issues with other customers that use the 3rd party, but don't pay of or use the TLS option (as we found out during our testing).

If IronPort are able to do this then great, but I can't see it happening without them chaning the fundamental way that IronPort works.

austintxeric_ironport · ‎11-17-2009

Unfortunately we have certain contractual obligations that require us to enforce all directions between certain partners. It should be technically possible to do a check on the inbound side once the conversation starts to see if the conversation is in fact using TLS, if NOT and we had a policy set to require it for that envelope sender domain, then the message could be bounced with a 500 message stating a custom error code. This would be similar to a message being rejected during the conversation if there was an invalid recipient.