0

We got a requirement to reject external emails sent to one distribution group (test_dl1@xyz.com) using exchange 2010 transport rule in this manner. (and send NDR to the original external sender)

enter image description here

We have not restricted external senders in "message delivery restrictions", in test_dl1 distribution group, in this manner. (as per the requirement, goal here is to allow unauthenticated users by the group itself, but control it via above transport rule)

enter image description here

There is only one group member in this distribution group. And the Group member is rejected@xyz.com

enter image description here

Above transport, rule works perfectly fine until up to this step. I have tested using external Gmail address ( that is testing@gmail.com).

(for one thing, I've noticed, NDR initiated from rejected@xyz.com, not the distribution group (test_dl1@xyz.com), which means if I include more members there will be more than one NDR sent to the original sender at this point. )

I get below NDR to testing@gmail.com from postmaster@xyz.com. .

---------------------------------------------------------------------------------------------------------------------------------------------------------------

. enter image description here

.

---------------------------------------------------------------------------------------------------------------------------------------------------------------

.

But

Crazy thing happens when rejected@xyz.com is being forwarded to another external mail address (that is forward@gmail.com) in this manner.

(Where forward@gmail.com is a mail-enabled exchange 2010 contact. )

enter image description here

Sending a test mail using same external sender (** that is testing@gmail.com**), while above forwarding in place, NDR is sent to forward@gmail.com claiming it is not delivered to forward@gmail.com.

(NDR is supposed to send to the original outside sender that is testing@gmail.com)

. . .

---------------------------------------------------------------------------------------------------------------------------------------------------------------

enter image description here

---------------------------------------------------------------------------------------------------------------------------------------------------------------

.

and also at this point, I noticed NDR is sent by Microsoft Outlook .. NDR is supposed to send by postmaster@xyz.com not by Microsoft Outlook and at any point in this testing, I have not used web outlook or Microsoft outlook fat client.

enter image description here

Cannot figure out how to fix the above transport rule to send NDR to the original sender, while forwarding in place.

Already wasted so many hours .. any help would be very much appreciated

Ps: Looks like by allowing un-authenticated users, in a distribution group, ReturnPath is changed from the original sender to the address of the distribution list. and followed by few more changes according to this

https://practical365.com/exchange-server/exchange-server-ndr-loop-distribution-list/

No work around found so far

Aravinda
  • 1,101
  • 5
  • 12
  • 30

1 Answers1

0

As you see in the blog, it's due to Sender Policy Framework (SPF), which means it would not be different in other version of Exchange or other mail servers. We should start with the rules or the groups:

  1. (assuming you have a group named testdl1@xyz.com with a mailbox rejected1@xyz.com, maybe you will add rejected2@xyz.com, rejected3@xyz.com into it later) modify your rule to "when any of the recipients in the To or CC fields is rejected1@xyz.com,rejected2@xyz.com... "
  2. it might be difficult to remove contacts from all users' Outlook OAB, I would remove testdl1@xyz.com as a group and add testdl1@xyz.com as an secondary email address to rejected1@xyz.com. Check the message trakcking log and see if the return-path would be changed then.
Joy Zhang
  • 1,057
  • 1
  • 5
  • 5
  • joy thanks for your post, yet this is production environment and there are 400+ groups + 2500+ users .. so its not a viable thing .. anyway thanks for your post. yet still looking for an alternative – Aravinda Dec 31 '20 at 00:07
  • May have to live with that! No solution found – Aravinda Jan 03 '21 at 00:38