Can an email override exchange server 'out of office' rules?
August 30, 2011 5:47 AM Subscribe
Can an email message configure itself so that Exchange Server 2007 will send an Out Of Office reply to a 3rd party, not the sender listed as sender?
I've got a small legacy app that use java mail to send an email to an entire corporation. My requirements say that the 'from' id has to be the big bosses' email address, and the reply-to has to be his delegate. That's all working fine, but Exchange 'out of office' processing seems to short circuit this.
It looks like exchange just bounces the mail back to the id listed as 'from', not the delegate. The customer claims that big boss should never see an OOO email, that those should go elsewhere to be tracked, and they also claim that I don't have access to an exchange administrator to set up a rule on big bosses' mailbox as described all over the internet and the public side of MSDN. Is there something that can be done if all I can control is the app that creates the message and sends it off to transport?
I've got a small legacy app that use java mail to send an email to an entire corporation. My requirements say that the 'from' id has to be the big bosses' email address, and the reply-to has to be his delegate. That's all working fine, but Exchange 'out of office' processing seems to short circuit this.
It looks like exchange just bounces the mail back to the id listed as 'from', not the delegate. The customer claims that big boss should never see an OOO email, that those should go elsewhere to be tracked, and they also claim that I don't have access to an exchange administrator to set up a rule on big bosses' mailbox as described all over the internet and the public side of MSDN. Is there something that can be done if all I can control is the app that creates the message and sends it off to transport?
Response by poster: That's a good solution as well, but it requires intervention of an exchange administrator, which as I understand, is verboten for whatever reason. Thanks for adding another arrow to my quiver of reasons to let me have access to this person.
posted by TuffAustin at 8:53 AM on August 30, 2011
posted by TuffAustin at 8:53 AM on August 30, 2011
Best answer: Does the delegate need to see OOO messages at all, or were you just diverting them to the delegate so they would have somewhere to go?
It appears that you can add a header your outgoing message directing Exchange to not send an OOO or autoresponse at all:
X-Auto-Response-Suppress: OOF, AutoReply
Additional values are documented here: http://msdn.microsoft.com/en-us/library/ee219609(EXCHG.80).aspx
I need to go add this to an old app of mine now...
posted by hey you over in the corner at 9:32 AM on August 30, 2011
It appears that you can add a header your outgoing message directing Exchange to not send an OOO or autoresponse at all:
X-Auto-Response-Suppress: OOF, AutoReply
Additional values are documented here: http://msdn.microsoft.com/en-us/library/ee219609(EXCHG.80).aspx
I need to go add this to an old app of mine now...
posted by hey you over in the corner at 9:32 AM on August 30, 2011
Response by poster: According to the customer, they're going to actually gather those OOO/OOF responses, and create some sort of dunning list to go back just to those people when they're back at their desks.
In this case, suppression doesn't work, but thanks for the pointer.. that's the kind of thing I was hoping to find, and you've given me some valuable additional terms on which I should be searching.
posted by TuffAustin at 10:01 AM on August 30, 2011
In this case, suppression doesn't work, but thanks for the pointer.. that's the kind of thing I was hoping to find, and you've given me some valuable additional terms on which I should be searching.
posted by TuffAustin at 10:01 AM on August 30, 2011
Are you using the mailmessage object? Just tried a little code dot net code with the mailmessage object and found another property that might work for you. It will depend on how picky the customer is about how the email shows up.
Example using VB:
With myMsg
.To.Add(New MailAddress("Joe@myco.com"))
.From = New MaiAddress("BigBoss@myco.com")
.Sender = New MailAddress("MyDelegate@myco.com")
end with
Message shows up as a delegate type of email and auto replies are sent to the delegate.
posted by johnn at 10:10 AM on August 30, 2011
Example using VB:
With myMsg
.To.Add(New MailAddress("Joe@myco.com"))
.From = New MaiAddress("BigBoss@myco.com")
.Sender = New MailAddress("MyDelegate@myco.com")
end with
Message shows up as a delegate type of email and auto replies are sent to the delegate.
posted by johnn at 10:10 AM on August 30, 2011
Response by poster: Johnn:
Yup - your code is similar to mine - I create a java message and I call .addRecipient (x) and .setSender(Boss) and .setFrom(Delegate).. I might have those backwards and I'll try the other way around as well just in case.
If I view the header of the message created in a non-outlook client, it is correct as From: Boss Address Reply-To: delegate.
In outlook, if I go to the raw email and view headers, it's correct like that too, but Outlook client is clever by half. Its default configuration takes the "from" email address, and looks up the owner of that address in the global address book, and puts the delegate's full name on the top of the message viewer at this customer. So much for the 'authority' appearance of sending a message from the boss if it's just the delegate's name showing. (aside: my Notes client displays it correctly.)
Your first contribution is probably the way most companies handle this - create a straw-man account on behalf of the bosses.
posted by TuffAustin at 1:25 PM on August 30, 2011
Yup - your code is similar to mine - I create a java message and I call .addRecipient (x) and .setSender(Boss) and .setFrom(Delegate).. I might have those backwards and I'll try the other way around as well just in case.
If I view the header of the message created in a non-outlook client, it is correct as From: Boss Address Reply-To: delegate.
In outlook, if I go to the raw email and view headers, it's correct like that too, but Outlook client is clever by half. Its default configuration takes the "from" email address, and looks up the owner of that address in the global address book, and puts the delegate's full name on the top of the message viewer at this customer. So much for the 'authority' appearance of sending a message from the boss if it's just the delegate's name showing. (aside: my Notes client displays it correctly.)
Your first contribution is probably the way most companies handle this - create a straw-man account on behalf of the bosses.
posted by TuffAustin at 1:25 PM on August 30, 2011
Response by poster: We wound up talking them off the "we need to track those OOFs" requirement, and went the suppression route. This seems to work, albeit it's a tricky thing to unit test: Outlook only sends one OOO message per sender per day, so we've had to recruit some people to set their OOF, let us test, then change our code and test without the flag.
The exchange administrator also would be willing to put the rule on the bosses' box with his approval, but evidently he didn't want to ask him. Not quite sure why no one wants to interact with this boss, but that's fodder for another AskMefi thread.
Thank you all for your contributions!
posted by TuffAustin at 9:54 AM on August 31, 2011
The exchange administrator also would be willing to put the rule on the bosses' box with his approval, but evidently he didn't want to ask him. Not quite sure why no one wants to interact with this boss, but that's fodder for another AskMefi thread.
Thank you all for your contributions!
posted by TuffAustin at 9:54 AM on August 31, 2011
This thread is closed to new comments.
posted by johnn at 7:11 AM on August 30, 2011