Shulou(Shulou.com)06/03 Report--

The front-end time has dealt with a problem in a production environment, which is not very complex, but it is difficult to find a direction if you can't sort out the train of thought. Next, I would like to share a little bit of the problem handling process.

I. Environmental conditions

1 、 WIndows 2012 R2+Exchange 2016 CU2 .

2. Mail flow: Internet mail gateway [Symantec SMG] Exchange server.

II. Problem phenomenon

The Exchange distribution group is configured to send messages that need to be verified [that is, RequireSenderAuthenticationEnabled is set to True], but third-party mailboxes [e.g. 163or QQ] can still send messages to the Exchange distribution group, and group members of the distribution group will also receive messages.

III. Problem handling process

Just received this question, the first reaction is to first check whether the permission setting of the distribution group is turned on RequireSenderAuthenticationEnabled, and then determine whether this is the case for individual distribution groups or all distribution groups.

1. First of all, check the settings of all distribution groups and turn on RequireSenderAuthenticationEnabled. And tested several distribution groups. This is the case.

2. Exchange mail transmission is realized through the transport agent Agent. Use the command Get-TransportAgent to see if Agent is not working properly, or if there is any other Agent. By getting the results, you can see that there is nothing wrong with TransportAgent.

3. Next, the sender filter is checked through the command, and there is no problem.

4. Try to manually create a transport rule that prevents any external user from sending messages to a specific distribution group. The test results still show that external users are able to send messages to the distribution group. After various attempts, I came here to wonder if there was a problem with the server or the transport service. By default, the transport server caches 4 hours on the Exchange server. Next, the transport service is restarted and the problem remains.

5. Check that the running time of the server is 570 days, that is, the server has not been restarted for a long time. It is suspected that the server has not been restarted with a patch installed. So switch the copy of the database to the standby node and restart the server one by one. The problem persists after the test is completed after the restart.

6. There is no way. This problem must have been left behind somewhere, or the product Bug. By looking at the list of issues fixed by Exchange 2016 CU3-CU11, there is no description of this problem at all. Then it should not be the product Bug.

7. In the end, there is no choice but to look at the transmission log. The transmission process of Exchange has been studied before. normally, when a distribution group message is sent to the Exchange server, the Exchange server will perform an Expand distribution group member expansion action. As follows:

By sending the test mail, sending the test message to the distribution group using an external mailbox, and then using the command to view the mail delivery record, we found that the Expand group address expansion action was not performed on the Exchange server, but the mail was delivered directly to the corresponding mailbox. What does this mean? it is a bold guess that the communication group mail expands the group members before it reaches the Exchange server. In this case, the messages sent to the distribution group are delivered directly to the group members' mailboxes, thus bypassing the distribution group verification mechanism.

8. In order to verify my guess, the current general direction can be located on the mail gateway to do a distribution group member Expand for Exchange. So next look at the configuration of SMG. You can see that the "Enable Distribution Expansion" [enable distribution list extension] feature is enabled on SMG in SMG's active Directory integration.

9. Enable the distribution list extension function of SMG, turn it off, and then test to send mail to the distribution group, and everything will return to normal. Then the Expand action can be captured normally by viewing the transfer log with the command.

IV. Suggestions

1. When using the mail gateway, be sure to pay attention to the settings about the distribution group. Improper setting of the meeting will lead to spam.

2. This case, in turn, can be used as a solution for Exchange distribution groups to receive external mail.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.