none
Mail sent using the wrong send connector RRS feed

  • Question

  • Hello, I have Exchange 2013 Organization with 2 sites. 2 servers in Site1 (CAS and MBX/HUB) and 2 servers in Site2, same roles.
    I have Fortimail as Smart Hosts in each site. Both connectors has SMTP * with cost 10, but each one has the "Scoped send connector" checkbox checked, and only the corresponding server for that site. So, Site1 send connector has only MBX/HUB server on that site and Site2 the same. No DAG, separated servers with databases in each server,
    The thing is that someone with a mailbox hosted in a database in server in Site2 send a mail, and the mail apparently goes through Site1 send connector. Got the mail and the header says that the sender is the fortimail from Site.
    If I check delivery reports the mail appear as delayed and in the info says that the mail was sent to a remote site. I am scratching my head and thinking which log could I check to know the route is taking the mail to be sent using the wrong connector.
    Something to say, the send connectors are using instead the direct fortimail records, a DNS zone with MX records inside. In site1 the mx record with cost 10 is the site1 fortimail and the mx record with cost 20 is the site2 fortimail. Same thing for DNS zone for site2, but fortimail for site2 has cost 10 and fortimail for site1 has cost 20. This is for failover, so if site2 lost connection with fortimail in site2, goest to site1 fortimail, but don´t know if this is happening because the fortimail is up and sending mails and only happens for this mailbox.
    Is there a tracking log I can check?
    Tuesday, April 9, 2019 3:56 PM

All replies

  • What do you mean by, "...and the header says that the sender is the fortimail from Site."?

    What do the headers show about how the message was routed internally?

    Why are you using MX records to route the outbound mail to fortimail instead of IP addresses or A record hostnames that point directly to their servers?


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Tuesday, April 9, 2019 4:10 PM
    Moderator
  • >> What do you mean by, "...and the header says that the sender is the fortimail from Site."?

    When I receive a mail sent by this mailbox hosted in Site2 server, the external IP address is from Fortimail from Site1. Some emails from other people with mailbox hosted in Site 2 server came with IP address from Fortimail from Site2 which should be the right thing

    >> What do the headers show about how the message was routed internally?

    In the header the first Hop is from the external IP of the fortimail in Site 2 to the destination host. Nothing shows an internal hop from Site 1 fortimail to the Site 2. Is like the send connector for Site 2 goes directly to Site 1 fortimail

    >> Why are you using MX records to route the outbound mail to fortimail instead of IP addresses or A record hostnames that point directly to their servers?

    As I said, I built a DNS domain with both fortimail records with different costs. In Site 1, should use for the cost the Site 1 fortimail and then if Site 1 fortimail doesn´t answer, will use Site 2. The other site is backwards.

    What I will do now for testing is using the send connector for Site 2 pointing directly to fortimail in Site 2 instead using the DNS zone, just for confirm if that is the point of failure.

    Tuesday, April 9, 2019 5:28 PM
  • >>> In the header the first Hop is from the external IP of the fortimail in Site 2 to the destination host. Nothing shows an internal hop from Site 1 fortimail to the Site 2. Is like the send connector for Site 2 goes directly to Site 1 fortimail

    So it sounds as if fortimail is sanitizing the headers, then.  A drawback of this "security" function is that you lose visibility into what's going on before fortimail.  I can't help you figure out what's going on if you let fortimail destroy the evidence.

    >>> As I said, I built a DNS domain with both fortimail records with different costs. In Site 1, should use for the cost the Site 1 fortimail and then if Site 1 fortimail doesn´t answer, will use Site 2. The other site is backwards.

    You shared what you did, not why.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Tuesday, April 9, 2019 5:45 PM
    Moderator
  • Thanks for the answer Ed. Yeah, I mentioned that I made it for failover. Just in case the local fortimail doesn´t answer, use the fortimail in the other site to keep sending emails.
    Anyway, I am trying some other things.
    But in theory what I did (besides the DNS zone with mx records instead A record) about the send connector scoped and only using the server in that site, should be enough to send the mail using that connector right? Or should be another condition? I mean, if the mailbox is in a database in the server indicated in the send connector with no DAG, should be fine?
    Tuesday, April 9, 2019 6:26 PM
  • I think what you've configured should work.  But since you've configured failover, if the Exchange server for whatever reason can't connect to the local Fortimail connection, then it'll try the one in the other site.  Maybe that's what's happening.

    You'd probably be able to learn more if you turn up SMTP protocol logging on the send connectors and examine the protocol logs when such an event happens.  And you'd also find out more if you configure the Fortimail to not strip out the headers, if only temporarily.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Tuesday, April 9, 2019 8:09 PM
    Moderator
  • Hi,

    It seems that the configuration of send connectors is fine. To view detailed records, you can enable protocol logging for send connector in Site2.

    Set-SendConnector <connector name> -ProtocolLoggingLevel Verbose

    For your reference:

    Protocol logging


    Regards,

    Dawn Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, April 12, 2019 9:50 AM
    Moderator