none
Mail from internal application still not being relayed to recipients of distribution group

    Question

  • Recently I had an issue where our ticketing system was unable to relay email through our exchange servers to about 90 recipients in a distribution group.  When I looked at the message tracking for the message in question it showed that it was being explicitly discarded and had the event ID HADISCARD.

    The suggested solution was to modify the 'MaxInboundConnectionPerSource' setting to 200, which I did for that receive connector across all of our exchange servers.  Hopeful that would be the solution, today the same email was attempted to send from our ticketing system through exchange and I see the same issue as before, the message has HADISCARD and ExplicitlyDiscarded in the tracking log.

    In doing some research today, I see some users are stating that for a custom SMTP connector where an internal application needs to relay through exchange out to the internet, you should allow not only Anonymous Permission but also the Exchange Server permission.  To me that doesn't make sense but perhaps someone can explain that further to me.

    I have confirmed that the message in question is using the custom SMTP Relay connector.  Below is the output of get-receive connector for the connector in question.  Perhaps someone can review this and let me know if it is in fact configured correctly. 

    Thanks in advance

    [PS] C:\Windows\system32>Get-ReceiveConnector "smtp relay" |fl


    RunspaceId                              : 6b843728-a2a6-4e21-afe3-ab5d430780fa
    AuthMechanism                           : Tls
    Banner                                  :
    BinaryMimeEnabled                       : True
    Bindings                                : {0.0.0.0:25}
    ChunkingEnabled                         : True
    DefaultDomain                           :
    DeliveryStatusNotificationEnabled       : True
    EightBitMimeEnabled                     : True
    SmtpUtf8Enabled                         : False
    BareLinefeedRejectionEnabled            : False
    DomainSecureEnabled                     : False
    EnhancedStatusCodesEnabled              : True
    LongAddressesEnabled                    : False
    OrarEnabled                             : False
    SuppressXAnonymousTls                   : False
    ProxyEnabled                            : False
    AdvertiseClientSettings                 : False
    Fqdn                                    : SERVER.domain.org
    ServiceDiscoveryFqdn                    :
    TlsCertificateName                      :
    Comment                                 :
    Enabled                                 : True
    ConnectionTimeout                       : 00:10:00
    ConnectionInactivityTimeout             : 00:05:00
    MessageRateLimit                        : Unlimited
    MessageRateSource                       : IPAddress
    MaxInboundConnection                    : 5000
    MaxInboundConnectionPerSource           : 200
    MaxInboundConnectionPercentagePerSource : 2
    MaxHeaderSize                           : 128 KB (131,072 bytes)
    MaxHopCount                             : 60
    MaxLocalHopCount                        : 12
    MaxLogonFailures                        : 3
    MaxMessageSize                          : 35 MB (36,700,160 bytes)
    MaxProtocolErrors                       : 5
    MaxRecipientsPerMessage                 : 200
    PermissionGroups                        : AnonymousUsers, Custom
    PipeliningEnabled                       : True
    ProtocolLoggingLevel                    : Verbose
    RemoteIPRanges                          : {172.16.0.0/16, 172.17.0.0/16, 172.18.0.0/16, 192.168.0.0/16}
    RequireEHLODomain                       : False
    RequireTLS                              : False
    EnableAuthGSSAPI                        : False
    ExtendedProtectionPolicy                : None
    LiveCredentialEnabled                   : False
    TlsDomainCapabilities                   : {}
    Server                                  : SERVER
    TransportRole                           : FrontendTransport
    SizeEnabled                             : Enabled
    TarpitInterval                          : 00:00:05
    MaxAcknowledgementDelay                 : 00:00:30
    AdminDisplayName                        :
    ExchangeVersion                         : 0.1 (8.0.535.0)
    Name                                    : SMTP Relay
    DistinguishedName                       : CN=SMTP Relay,CN=SMTP Receive
                                              Connectors,CN=Protocols,CN=SERVER,CN=Servers,CN=Exchange Administrative
                                              Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Domain,CN=Microsoft
                                              Exchange,CN=Services,CN=Configuration,DC=ghc911,DC=org
    Identity                                : SERVER\SMTP Relay
    Guid                                    : 6c1e28d4-4aed-44c5-877a-4c3caf535cbc
    ObjectCategory                          : domain.org/Configuration/Schema/ms-Exch-Smtp-Receive-Connector
    ObjectClass                             : {top, msExchSmtpReceiveConnector}
    WhenChanged                             : 3/22/2018 10:28:00 AM
    WhenCreated                             : 10/31/2017 10:20:11 AM
    WhenChangedUTC                          : 3/22/2018 3:28:00 PM
    WhenCreatedUTC                          : 10/31/2017 3:20:11 PM
    OrganizationId                          :
    Id                                      : SERVER\SMTP Relay
    OriginatingServer                       : DomainController.domain.org
    IsValid                                 : True
    ObjectState                             : Unchanged


    I'm not even supposed to be here today.

    Tuesday, April 17, 2018 3:52 PM

All replies

  • Hi,

    HADISCARD is normal :

    A shadow message was discarded after the primary copy was delivered to the next hop. 

    You will see this on all messages.

    I recommend you use telnet from same server that sends out the same message and fails. In from and to address use the same that has been used before. When it fails, it will state the error.

    Are you sending from and to domain that is in your accepted domain list of your exchange server?


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you. Thank you! Off2work

    Tuesday, April 17, 2018 4:42 PM
  • Hi,

    Thanks for the response.  For a little extra background, the application server in question does regularly relay email via SMTP on a daily basis to both internal as well as external recipients.  Only with this particular email that uses a distribution group containing about 90 external recipients does the email never make it from Exchange to our Mail gateway appliance.

    So where the SourceContext says "ExplicitlyDiscarded" that is also normal to see along with HADISCARD?

    As far as sending from and to domain that is in our accepted domain list, everything sent externally uses a SmartHost send connnector which points to our email gateway appliance.  Typically email from this application server are routed through exchange without problem, except in this instance with the distribution groups and the large number of recipients.


    I'm not even supposed to be here today.

    Tuesday, April 17, 2018 4:50 PM
  • by default, a receive connector does not allow relay to external domains.

    Please use this command:

    Get-ReceiveConnector "Your Exchange Server\SMTP Relay Connector”| Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient

    It is recommended to only use that command on a receive connector that only allow relays from IP on the list.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you. Thank you! Off2work

    Tuesday, April 17, 2018 5:03 PM
  • I have used that command on our SMTP Relay connectors across all exchange servers in the organization...that is how we are able to currently relay email from the application in question to individuals outside of our network, via the internet.  Since we have many different servers that would relay email through that receive connector I have entered the IP ranges that we use within our network.

    Here is a screenshot from ADSI that shows the receive connector in question with the SMTP Accept Any Recipient permission.

    At this point the problem is not being able to relay for the application to the internet, that is working, it just isn't relaying messages for the application when the distribution group is used with the large amount of users.  Conversely, we can send the same email to the same group of external users from outlook and it it sent without issue.

    


    I'm not even supposed to be here today.

    Tuesday, April 17, 2018 5:34 PM
  • i do not see Accept-Any-Recipient, but it might be further down on the list?

    Please use telnet and try to send instead with same from and to address as used in your application.

    Sending from Outlook is authenticated, so it wont use the same connector.

    Otherwise, turn on logging for that connector and check for any error.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you. Thank you! Off2work


    • Edited by Off2work Tuesday, April 17, 2018 5:49 PM Edit
    Tuesday, April 17, 2018 5:48 PM
  • Ok I think we are getting somewhere now.  First, here is a screenshot from powershell which shows the SMTP Accept Any Recipient permission.

    Then, I did as you suggested and logged into the application server having the problem.  Using telnet I queued a message using my email address as the mail from address and the distribution group in question as the RCPT TO address.  I then submitted the message and it was queued for delivery.  Shortly after, I received this NDR from exchange.

    So in the NDR you can see it is saying something about authentication as being the problem.  Which is interesting because again, this system relays email through exchange all day long as it is our primary ticketing system and it sends to external users all the time, but with this particular distribution group it has this problem.  Is it possible that the Exchange server permission needs to be checked for the receive connector in order for this application to pass authentication when trying to relay this message?


    I'm not even supposed to be here today.

    Tuesday, April 17, 2018 6:14 PM
  • Ok so I went into the distribution group in question and changed the delivery management setting from "Only senders inside my organization" to "Senders inside and outside of my organization" and I was then able to telnet to exchange from the application server in question and send the email to the distribution group in question and I see it went out to all of the recipients in the DG.

    Although it is working in this way, it's not ideal, as now anyone from the outside can also send email to that DG. 

    So what is the better solution to this problem?  Adding the Exchange server permission to the SMTP Relay receive connector?

    Thanks for all of your help by the way.  I think we are close to having this resolved once and for all.


    I'm not even supposed to be here today.

    Tuesday, April 17, 2018 6:34 PM
  • hi, 

    Please check the affected Distribution list if it only allows certain people to send to it.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you. Thank you! Off2work

    Tuesday, April 17, 2018 6:37 PM
  • Hi,

    Just checking in to see if above information was helpful. Please let us know if you would like further assistance.

    Regards, 

    Manu Meng


    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 shareexplore and talk to experts about Microsoft Teams.

    Sunday, April 22, 2018 3:26 PM
    Moderator
  • The distribution group is not restricted to particular users.  Now that I have configured it to allow email from internal and external sources, it appears to be allowing email from the application server to go through.  But again, it is not ideal having it open to external sources.  I could add specific users into the list but at the same time, should someone not in the user list attempt to send an email to the group they would then be denied.

    I feel like there should be a better solution that will allow our application server to relay email through the exchange internal SMTP connector without having to change the Delivery Management options of the DG.


    I'm not even supposed to be here today.

    Wednesday, April 25, 2018 2:35 PM
  • Did you find any proper solution, I am facing the same issue.
    Wednesday, January 2, 2019 9:21 AM
  • Try running the following exchange powershell command against the distribution group  in question.

    Set-DistributionGroup -<DistributionGroup> -RequireSenderAuthenticationEnabled $false


    I'm not even supposed to be here today.

    Friday, January 4, 2019 3:06 PM