locked
Receive connector won't work for TLS-enabled domains RRS feed

  • Question

  • Hi everybody,

    One of my clients tasked me with setting up a send/receive TLS partnership with another domain.  We'll just call my client CUSTOMER.COM and the other domain TLSISFUN.COM.

    On customer.com I followed this article (http://technet.microsoft.com/en-us/library/bb123543.aspx) to set the transportconfig, send and receive connectors appropriately.  

    I need to validate this, but I believe tlsisfun.com is receiving emails via TLS from my customer.  However, when their tlsisfun.com domain sends email to my customer.com domain, my clients never get the emails at all.

    The sender from tlsisfun.com gets a bounceback - something to this effect:

    --

    5.1.0 - Unknown address error 530-'5.7.1 Not authenticated - on relay of: MAIL FROM:<prvs=xxxxxxx=user@tlsisfun.com>' (delivery attempts: 0)

    --

    I cranked up the protocol logging.  I'm not sure exactly what you'd want to see in it, but one lead I'm following that might be the problem is this chunk of the SMTP communication:

    --

    Tarpit for '0.00:00:00.875' due to 'DelayedAck',Delivered

    --

    I'd love some guidance figuring out why these emails never get to their intended recipients.  I must have something configured wrong.

    Thanks,

    Brian

    Friday, November 9, 2012 10:45 PM

Answers

  • Ok, I think we need to step back here. I think you are confusing things.

    If you want domain mutual TLS between  two orgs, then both have to be configured to do so. ( and configured on the device/server that sends/receives mail for the org - in this case, Postini has be configured correctly on one end)

    When you say Postini has TLS on by default, that really means opportunistic TLS. There is a big difference between the two - namely Domain Mutual TLS requires a valid cert and defined established trust for the SMTP transaction to be successful between the orgs. If those dont exist, the SMTP transaction will fail.

    Opportunistic TLS simply means the SMTP server offers TLS and will use TLS for the SMTP transaction if both SMTP servers support it, but the cert will not necessarily be validated, nor will it require a pre-establised trust between the orgs. If the cert fails, or one server doesnt support it, the SMTP transaction will continue in clear text

    If you want to use Opportunistic TLS, and both orgs are using Exchange 2007 and above or SMTP servers that support it like Postini, then you dont have to do anything. TLS will be used.

    If you want to use Mutual Trusted TLS between the org, then you have to configure on both the Postini and Exchange side.

    The correct way to see that TLS is working is with the SMTP protocol logs, not telnet.

    Now having said all that, I can't read those screenshots  :)

    • Proposed as answer by Om Prakash Nath Tuesday, November 13, 2012 7:20 AM
    • Marked as answer by wendy_liu Monday, November 19, 2012 1:53 AM
    Monday, November 12, 2012 10:59 PM
  • Andy,

    OK what I found out last night was that the "Offer basic...after starting TLS" was checked.  I unchecked it and sent some test messages and the behavior was the same.

    However, your note about checking event logs is definitely getting us warmer I think.  App log has #11017 entries from whenever tlsisfun.com sends email to my customer.com:

    --

    A message from domain-secured domain 'tlsisfun.com' on connector 'Default EX02' failed to authenticate because no Transport Layer Security (TLS) certificate was supplied. Contact the administrator for nwielab.com to resolve the problem, or remove the domain from the domain-secured list.

    --

    So does this imply a SEND configuration problem con tlsisfun.com's side?

    Brian

    Be sure to restart the Transport services after making that change.

    And yes that is what that means :

    Contact the administrator for nwielab.com to resolve the problem, or remove the domain from the domain-secured list.

    • Proposed as answer by wendy_liu Monday, November 19, 2012 1:52 AM
    • Marked as answer by wendy_liu Monday, November 19, 2012 1:53 AM
    Tuesday, November 13, 2012 5:45 PM
  • Thanks,

    I'll try to make that receive connector change and bounce transport service, but my problem will remain until the sender side fixes their cert issue right?

    Brian

    Correct. If you want to used Mutual TLS between the orgs and they arent sending a trusted cert, then yea, you will have to get that fixed for sure!

    • Proposed as answer by wendy_liu Monday, November 19, 2012 1:52 AM
    • Marked as answer by wendy_liu Monday, November 19, 2012 1:53 AM
    Tuesday, November 13, 2012 5:54 PM

All replies

  • If you can obtain the protocol log from sender side, it will give you more info.
    Saturday, November 10, 2012 4:05 AM
  • http://paulroman.pras.ro/2012/04/applications-are-unable-to-send-emails.html
    
    

    Saturday, November 10, 2012 7:58 AM
  • Hi

    What authentication / permission groups is set on your connectors?

    If you telnet on port 25 do you get the same error?

    Saturday, November 10, 2012 11:15 AM
  • Review this series of articles, check if you are missing something.

    http://www.msexchange.org/articles_tutorials/exchange-server-2010/security-message-hygiene/exchange-2010-domain-security-part1.html


    ExchangeGeek

    (MCITP,Enterprise Messaging Administrator)

    **My posts are provided “AS IS” without warranty of any kind**

    • Proposed as answer by wendy_liu Monday, November 12, 2012 9:28 AM
    Saturday, November 10, 2012 11:43 AM
  • All - one thing I forgot to mention but not sure if it matters is we are using Postini as inbound email filtering.  I don't think that's an issue as the messages from customer.com seem to be arriving "at my door," but wanted to mention it anyway.

    Li - I will see if I can get that log.  

    Tushar - I'll look into this but I'm not dealing with apps sending/receiving email so not sure this applies here.

    DareDevil - my "Default EX" connector has Anonymous/Exchange users/Exchange servers/Legacy exchange checked on Permission Groups tab.  For authentication, everything on that tab is checked except "Externally Secured."  If I telnet on that port and do a "mail from" command for our partner's domain we want to receive TLS messages from, I do get the same error:


    But if I "mail from" any other domain, we're good to go.

    TheExchangeGeek - we are operating in just a single Ex2010 server environment, but it looks like I have everything right...I issued these commands:

    Set-TransportConfig –TLSSendDomainSecureList tlsisfun.com –TLSReceiveDomainSecureList tlsisfun.com

    I went through the rest of the article and I'm not seeing any red flags.  I'll keep digging but welcome any additional help...

    B


    • Edited by RouterPounder Saturday, November 10, 2012 3:48 PM Had wrong domain in shell commands
    Saturday, November 10, 2012 3:47 PM
  • I assume the MX goes to Postini which then sends to your Exch server right?

    So other external customer who send via TLS have no issue right?

    When you do the mail from, what do you put in there?

    At the same time when you do the above, can you look at the protoco logs and see if the connection is made to Exch and what they exactly say?

    Everything without TLS works fine right? Between you customer and tlsisfun.com?


    Sukh

    Saturday, November 10, 2012 3:55 PM
  • All - one thing I forgot to mention but not sure if it matters is we are using Postini as inbound email filtering.  I don't think that's an issue as the messages from customer.com seem to be arriving "at my door," but wanted to mention it anyway.


    It makes all the difference! If Postini is accepting messages for your domain, then the mutual TLS has to between Postini and the senders domain. Not between the sender and your Exchange Server unless you are bypassing the Postini.

    Saturday, November 10, 2012 3:58 PM
  • You can refer this article on enabling TLS in Postini.

    http://support.google.com/postini/bin/answer.py?hl=en&answer=132376


    ExchangeGeek

    (MCITP,Enterprise Messaging Administrator)

    **My posts are provided “AS IS” without warranty of any kind**

    Sunday, November 11, 2012 9:17 AM
  • All - one thing I forgot to mention but not sure if it matters is we are using Postini as inbound email filtering.  I don't think that's an issue as the messages from customer.com seem to be arriving "at my door," but wanted to mention it anyway.

    In this case, you TLS should be configured between Postini and TLSISFUN.com, not the Exchange server.

    Sunday, November 11, 2012 9:59 AM
  • All,

    Thanks for the continued help.  I checked Postini and actually they don't have any of the TLS menus shown in that article.  I compared to another one of my customers and I DO see those TLS menus.  So I'm thinking there must be several Postini "plans" and maybe my customer doesn't have the right one?  I will check with them and we'll go from there. 

    Thanks,

    Brian

    Monday, November 12, 2012 6:35 PM
  • Hi again,

    Ok so my client spoke with their Postini and was told that TLS is on by default - it tries that first.

    So just for grins, I did a telnet session to Postini and tried the telnet commands to simulate mail coming from tlsisfun.com.  On the left, tlsisfun.com is NOT on the TLSReceiveDomainSecureList on my customer.com Exchange server.  On the right, it is.

    Next I tried telnetting directly to customer.com's firewall on port 25 and ran the telnet commands that way.  The results are the same!  So whether I have Postini in the mix or not, I seem to be stuck at this 5.7.1 problem if tlsisfun.com is part of the TLSReceiveDomainSecureList, which seems to point me back to the drawing board with an Exchange-level config problem?

    Brian

    Monday, November 12, 2012 9:27 PM
  • Both are offering TLS.

    what issue do you exactly have?

     what ndr if ajy do youvget?


    Sukh

    Monday, November 12, 2012 10:29 PM
  • TLS is being offered in both your resutls

    What NDR if any do u get?

    Can u get logs from sender org? send connector logs?

    and what do your logs say on receive connector.

    .


    Sukh

    Monday, November 12, 2012 10:48 PM
  • Ok, I think we need to step back here. I think you are confusing things.

    If you want domain mutual TLS between  two orgs, then both have to be configured to do so. ( and configured on the device/server that sends/receives mail for the org - in this case, Postini has be configured correctly on one end)

    When you say Postini has TLS on by default, that really means opportunistic TLS. There is a big difference between the two - namely Domain Mutual TLS requires a valid cert and defined established trust for the SMTP transaction to be successful between the orgs. If those dont exist, the SMTP transaction will fail.

    Opportunistic TLS simply means the SMTP server offers TLS and will use TLS for the SMTP transaction if both SMTP servers support it, but the cert will not necessarily be validated, nor will it require a pre-establised trust between the orgs. If the cert fails, or one server doesnt support it, the SMTP transaction will continue in clear text

    If you want to use Opportunistic TLS, and both orgs are using Exchange 2007 and above or SMTP servers that support it like Postini, then you dont have to do anything. TLS will be used.

    If you want to use Mutual Trusted TLS between the org, then you have to configure on both the Postini and Exchange side.

    The correct way to see that TLS is working is with the SMTP protocol logs, not telnet.

    Now having said all that, I can't read those screenshots  :)

    • Proposed as answer by Om Prakash Nath Tuesday, November 13, 2012 7:20 AM
    • Marked as answer by wendy_liu Monday, November 19, 2012 1:53 AM
    Monday, November 12, 2012 10:59 PM
  • Andy,

    Thanks.  Yeah let me back up and recap since I've learned a lot from you and the other contributors to this thread:

    I indeed want mutual trusted TLS between my customer (customer.com) and their vendor (tlsisfun.com).  Not opportunistic.  My tech contact at tlsisfun.com has said he is forcing the sending/receiving of TLS messages on his end (tlsisfun.com).  But when he sends email from tlsisfun.com to my customer at customer.com, the message never gets to my customer.  

    I cranked the SMTP send/receive logs up, and when user@tlsisfun.com emails my customer at customer.com, the receive logs look like this:

    --

    MAIL FROM:<prvs=1234123123=user@tlsisfun.com
    *,Tarpit for '0.00:00:30'
    530 5.7.1 Not authenticated,
    QUIT

    --

    In the user@tlsisfun.com's mailbox, his bounceback is:

    --

    530 530 5.7.1 Not authenticated - on relay of: MAIL FROM:<user@tlsisfun.com> (state 13).

    --

    It's this message that throws me off.   Is it really saying that something with the TLS negotiation failed?  I guess I wasn't thinking TLS was even a factor at this point in the transmission, but looking in the SMTP logs ABOVE the "MAIL FROM:<prvs=1234123123=user@tlsisfun.com" line, I see what looks to be a bunch of lines about customer.com's certificate, and this line:

    --

    *,,TlsDomainCapabilities='None'; Status='NoRemoteCertificate'

    --

    So perhaps I've got a cert issue?  The customer.com's mailserver has an SSL cert with mail.customer.com as the name.

    Thanks all,

    Brian

    Monday, November 12, 2012 11:15 PM
  • On the customer.com receive connector that you have set for this, the one that is bouncing the message back ( and you are sure its not Postini bouncing it back), is the "Offer Basic authentication only after starting TLS.” checked under that authentication tab? If so, that would explain that NDR.

    Tuesday, November 13, 2012 12:01 AM
  • I will check when I get home tonight.  Should I have a separate receive connector just for this TLS setup?  Right now I just have the one receive connector from the Internet.  I had followed the MS KB article for this:

    --

    On the Authentication tab, select Transport Layer Security (TLS) and Enable Domain Security (Mutual Auth TLS), and then click OK.

    --

    But you've got me wondering if that "offer basic auth" isn't ticked as well.  I wouldn't have ticked it myself but maybe w/default install of Exchange it's ticked on that connector?

    Anyway like I said I'll check tonight...thanks again for all this help.

    Brian

    Tuesday, November 13, 2012 12:27 AM
  • Do you have 2 3rd party certs , with mutual authentication the connections are authenticated by certs, so confirm this 1st.  If this doesnt exisy, then it will fail.

    read this & compare your logs both receive & send.


    Sukh

    Tuesday, November 13, 2012 1:02 AM
  • Note that If the cert verification is failing, it will definetly be in the event logs of the receiving server.

    Tuesday, November 13, 2012 2:09 AM
  • Andy,

    OK what I found out last night was that the "Offer basic...after starting TLS" was checked.  I unchecked it and sent some test messages and the behavior was the same.

    However, your note about checking event logs is definitely getting us warmer I think.  App log has #11017 entries from whenever tlsisfun.com sends email to my customer.com:

    --

    A message from domain-secured domain 'tlsisfun.com' on connector 'Default EX02' failed to authenticate because no Transport Layer Security (TLS) certificate was supplied. Contact the administrator for nwielab.com to resolve the problem, or remove the domain from the domain-secured list.

    --

    So does this imply a SEND configuration problem con tlsisfun.com's side?

    Brian

    Tuesday, November 13, 2012 4:30 PM
  • Andy,

    OK what I found out last night was that the "Offer basic...after starting TLS" was checked.  I unchecked it and sent some test messages and the behavior was the same.

    However, your note about checking event logs is definitely getting us warmer I think.  App log has #11017 entries from whenever tlsisfun.com sends email to my customer.com:

    --

    A message from domain-secured domain 'tlsisfun.com' on connector 'Default EX02' failed to authenticate because no Transport Layer Security (TLS) certificate was supplied. Contact the administrator for nwielab.com to resolve the problem, or remove the domain from the domain-secured list.

    --

    So does this imply a SEND configuration problem con tlsisfun.com's side?

    Brian

    Be sure to restart the Transport services after making that change.

    And yes that is what that means :

    Contact the administrator for nwielab.com to resolve the problem, or remove the domain from the domain-secured list.

    • Proposed as answer by wendy_liu Monday, November 19, 2012 1:52 AM
    • Marked as answer by wendy_liu Monday, November 19, 2012 1:53 AM
    Tuesday, November 13, 2012 5:45 PM
  • Thanks,

    I'll try to make that receive connector change and bounce transport service, but my problem will remain until the sender side fixes their cert issue right?

    Brian

    Tuesday, November 13, 2012 5:50 PM
  • It will clearly show you in the protocol logs on the sending side.

    Sukh

    Tuesday, November 13, 2012 5:52 PM
  • Thanks,

    I'll try to make that receive connector change and bounce transport service, but my problem will remain until the sender side fixes their cert issue right?

    Brian

    Correct. If you want to used Mutual TLS between the orgs and they arent sending a trusted cert, then yea, you will have to get that fixed for sure!

    • Proposed as answer by wendy_liu Monday, November 19, 2012 1:52 AM
    • Marked as answer by wendy_liu Monday, November 19, 2012 1:53 AM
    Tuesday, November 13, 2012 5:54 PM
  • Sorry for delay all.  Thanks for all the help, particularly Andy D who helped me understand the bigger picture of TLS.  In this case I was not "matching" forced TLS on both ends.  The vendor opted to drop to opportunistic and then everything ran like a champ.


    Brian

    Saturday, November 24, 2012 9:50 PM