Exchange 2010 External Out of Office not working - "550 5.5.0. Sender Domain is empty"
Hello Experts,
Our client's external OoO is not working or more likely being rejected. When I did Exchange message tracking on the automated reply, it fails with an error message: "550 5.5.0. Sender Domain is empty". The customer is using a Smart host pointing to our Fortimail appliance for a spam filtering, but I can't find the message being logged on our end anywhere (Fortimail). I've also disabled any Content filtering on customer's Exchange(for testing only) to no avail.
I know a workaround would be to use DNS (MX) records to route the mail out instead, but they'd get smashed with SPAM obviously..
Was somebody else experiencing this please?
Thanks a lot
Vlas
Our client's external OoO is not working or more likely being rejected. When I did Exchange message tracking on the automated reply, it fails with an error message: "550 5.5.0. Sender Domain is empty". The customer is using a Smart host pointing to our Fortimail appliance for a spam filtering, but I can't find the message being logged on our end anywhere (Fortimail). I've also disabled any Content filtering on customer's Exchange(for testing only) to no avail.
I know a workaround would be to use DNS (MX) records to route the mail out instead, but they'd get smashed with SPAM obviously..
Was somebody else experiencing this please?
Thanks a lot
Vlas
ASKER
Yes, you're correct. The internal OoO works fine.
Hmmm, just did a test with the smart host off, using the DNS MX records and it fails with exactly the same error: "550 5.5.0. Sender Domain is empty" ..when I do Exchange message tracking for automatic reply.
- I haven't restarted the Exchange Transport service" before the test. Might need to re-test after hours again.
Hmmm, just did a test with the smart host off, using the DNS MX records and it fails with exactly the same error: "550 5.5.0. Sender Domain is empty" ..when I do Exchange message tracking for automatic reply.
- I haven't restarted the Exchange Transport service" before the test. Might need to re-test after hours again.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I came across similar article, but can you tell which policy to edit? 
Thanks a lot!
Thanks a lot!
I would guess it would be 16 and 17. Unfortunately I don't have a great deal of experience specifically with fortinet applications so not much use in actually changing the settings but those two seems to be rules applying to external systems.
ASKER
I'm attaching all 4 policies currently created for review. If someone with more networking background could suggest what needs to be changed please. Or should a new policy be created? Thanks 
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you Andy M for your help with this! Appreciated.
ASKER
The issue was resolved by further testing myself at the end.
As you are not seeing the Out Of Office on the logs on your fortinet then the problem would lie either with the client's Exchange or the smart host system. I've known some smarthosts utilsie anti-spam features that prevent out of office responses being sent previously.
On the client's exchange do the smtp logs show the out of office being sent to the smart host successfully or not?
You could temporarily setup a new send connector that just goes directly out (no smart host, just use DNS/MX). Sent that as the primary send connector, run some tests and then set it back again. If Out of Office works fine on that then I'd be looking at the smart host as being the issue in which case you'd need to contact them about it.