5 Replies Latest reply on Jan 29, 2014 10:03 AM by Regis

    Forcing TLS mail sending to a domain that's a postini customer

    Regis

      Greetings,

       

      Quick questions:

       

      1. Has anyone had success configuring a MEG (preferably <7.6, ideally at 7.0.3 or 7.0.4)  to do TLS to a specific domain that's a postini customer without breaking mail sending to other postini customers?
      2. Also, what if any TLS pitfalls have you encountered breaking outbound mail flow by moving from a Never to a "When availalable" setting for *  under Email> Encryption> TLS> When Sending Mail (gateway acting as a client)

       

      Details that might inspire "TL:DR" but some might be interested in :

       

      The only way I've succeeded in sending TLS to such a domain  is to specify an encryption policy at the top of the Email> Encryption> TLS> When Sending Mail (gateway acting as a client) list  to force TLS to

      • *thedomain.com (as one might expect) 
      • as well as *.psmtp.com (as one would not expect, ... cue dissonant horns and 3 men in red vestments).

       

      The downside that makes it unworkable:

      • suddenly you're forcing TLS to domains that are postini customers, who might not even be set up to deal with TLS

       

      Things that have been tried that didn't work:

      • just the domain
      • *domain.com
      • adding the specific quartet of postini email servers that make up the target domain's MX records doesn't work.  Only *.psmtp.com seems to for some reason.
      • adding thedomain.com.*.pstmp.com   (an internal wildcard there)
      • only *domain.com   and *.psmtp.com    together at the top of the sending mail tls  policy will deliver with TLS.  Everything else goes plain ole smtp.

       

      Unfortunately, I can't  leave that *.psmtp.com in there as I'm strongly cautioned by an experienced mail adminstrator who's a postini customer that forcing TLS to  *.psmtp.com  would be a Very Bad Idea(TM) as apparently  postini customers who haven't specifically configured themselves for TLS...   either the mail gets accepted and then not delivered, or it bounces?    As I'm not a postini customer, I'm ignorant of the exact specifics, but I'd welcome any other experience on this front.    But apparently you need to pay postini extra for TLS goodies, and you need to ensure you plumb a TLS connection from your premises mail gateway to postini if you're a customer who wants to do TLS with postini.  And it's a fair assumption that not all are.  

       

      Apparently other commercial mail appliances understand a notion of per-domain  encryption settings and gracefully handle when said domains use third party mail server from ends like postini, but apparently MEG is perhaps only getting this in 7.6.1?  

       

      If anyone's slayed this dragon or can confirm what I'm seeing, I'm all ears.   Thanks in advance for any insights!  A support escalation has been made and has tier3 attention but so far we haven't divined any way for this in 7.0.3.   

       

      Thanks in advance for any info!

        • 1. Re: Forcing TLS mail sending to a domain that's a postini customer
          Regis

          Does anyone send TLS mail outbound to postini customers?   (search for psmtp in MEG logs)? 

           

          Can any postini customers shed additional light on what the configurations look like for TLS?

          • 2. Re: Forcing TLS mail sending to a domain that's a postini customer
            jmickley

            Hi Regis,

             

            Here are the answers to your two questions:

             

            Q:  Has anyone had success configuring a MEG (preferably <7.6, ideally at 7.0.3 or 7.0.4)  to do TLS to a specific domain that's a postini customer without breaking mail sending to other postini customers?

             

             

            A:  You may be able to specifiy the exact hostname as opposed to using a wildcard.  An example would be hostname.psmpt.com as opposed to *.psmtp.com

             

             

            Q:  Also, what if any TLS pitfalls have you encountered breaking outbound mail flow by moving from a Never to a "When availalable" setting for *  under Email> Encryption> TLS> When Sending Mail (gateway acting as a client)

             

            A:  Actually, the default setting is when available.  This is simply called opportunistic TLS and is what the majority of the customers I talk to use.  This simply means that if the recipient server supports TLS, we will send it TLS.  If they don't we will send it in the clear.  This is obviously assuming that the message didn't trigger some type of compliance rule or anything else that has an action that requires delivery using encryption.  Then it would depend on your configuration for secure web mail and so on.

             

            --Jake

            • 3. Re: Forcing TLS mail sending to a domain that's a postini customer
              Regis

              jmickley wrote:

               

              Hi Regis,

               

              Here are the answers to your two questions:

               

              Q:  Has anyone had success configuring a MEG (preferably <7.6, ideally at 7.0.3 or 7.0.4)  to do TLS to a specific domain that's a postini customer without breaking mail sending to other postini customers?

               

               

              A:  You may be able to specifiy the exact hostname as opposed to using a wildcard.  An example would be hostname.psmpt.com as opposed to *.psmtp.com

               

               

               

              Unforutnately this doesn't square with my experience.   Ther'es something Very Strange going on with these entries such that exact matches to the hostname that gets logged in the mail log at least ... didn't work.  I had to widen it out to *.domain.com  to get TLS forced for the domain.    

               

               

              Q:  Also, what if any TLS pitfalls have you encountered breaking outbound mail flow by moving from a Never to a "When availalable" setting for *  under Email> Encryption> TLS> When Sending Mail (gateway acting as a client)

               

              A:  Actually, the default setting is when available.  This is simply called opportunistic TLS and is what the majority of the customers I talk to use.  This simply means that if the recipient server supports TLS, we will send it TLS.  If they don't we will send it in the clear.  This is obviously assuming that the message didn't trigger some type of compliance rule or anything else that has an action that requires delivery using encryption.  Then it would depend on your configuration for secure web mail and so on.

               

              --Jake

               

              Perhaps my policy was carried over from earlier 7.x versions or maybe even intentionally disabled by whatever half baked consultant McAfee subbed to for our installation.  :-\     Understood though.    I'm still trying to rectify  the cautions of  the receiving mail admin who seems to have a lot of experience as a postinini customer and a former MEG customer  with these assurances here that all will be well.  He explains that postini will accepts the TLS but unless the postini customer is specificaly configured and pays for TLS receipt, mail may bounce at the handoff from postini to the end customer.  From teh MEG perspective it'll handoff to postini over TLS fine, but if a postini customer doesn't have their TLS house in order (or doesn't pay for TLS to postini), then bad things occur.  At this point we've punted and held off because it seems that  to do  TLS handling based on the email recipient domain name from teh to: address rather than by the next hop domain name....  7.6.x is the price of admission.         As I can't seem to get 7.0.x stable, this puts me in a bit of a spot.   If the old stable branch isn't stable...  will the feature I need come with more stability in the feature branch?    I'm guessing the magic 8 ball would say "Outlook not so good."   :-\      

              • 4. Re: Forcing TLS mail sending to a domain that's a postini customer
                eplossl

                Actually, I would suggest that the magic 8 ball might well respond with something more like "outlook bright" or the like.  The MEG 7.6 (with P1 or later) software is relatively stable.  There are a number of things fixed in MEG 7.6.1 which make for a more stable and feature-rich product.  I do recommend use of MEG 7.6.  That said, on 7.0.x, I don't see this feature becoming available.  I would also question what this postini customer is advising.  If a customer hasn't paid for TLS features, I would expect Postini to not advertise starttls as an option, and thus we wouldn't use it.  If they have, I would expect starttls to be an available option.  Regardless, * When Available is going to be your best bet at this point.

                • 5. Re: Forcing TLS mail sending to a domain that's a postini customer
                  Regis

                  One would expect....   but this person who's a customer says that expectation supposedly isn't met, and with the number of postini customers we have business relationships with, I don't wanna be in the business of having to debug all of them.  

                   

                  One would also expect MEG 7.0 per domain TLS policies to apply to email destination domains of the To: address  and not the domain of whatever the MX record hostname resolves to!  But I think we know how that one goes.  :-)      

                   

                  Great to hear additional assurances of 7.6 stability since 7.6's handling of TLS  domain policies is much more in the lines of the "one would expect" rule. 

                   

                  Unfortunately we can't roll the dice on the when available setting in our production environment when we have a first hand warning from a postinini and former MEG customer that doing so caused him a lot of problems.  7.6 will allow us a more surgical approach to migrate our postini partners to TLS, and once enough confidence is there,  when available might be trusted for the masses.  

                   

                  Thanks again for the input, but I think you can understand why in production environments, you can't just flip that setting and hope for the best.  :-)

                   

                  on 1/29/14 10:03:31 AM CST