Exchange deferred delivery: update message "Date:" header

Question

A client is using the "deferred delivery" feature in Outlook / Exchange. For some reason this feature does preserve the original message creation time (i.e. when the user has hit the "send" button) as the RFC-822 Date: header, so even when the message's delivery is indeed "deferred", the headers still bear the evidence that it has been composed a while before delivery. My client would like to set the Date: header to the time when the message actually leaves the Exchange organization instead, so it would look like it had been composed and sent recently.

The idea to solve this is to set the Date: headers on all outgoing SMTP mail to the server's current time in an Exchange 2007 environment.

I know that I can set up a new-Transportrule with the -Action parameter set to Microsoft.Exchange.MessagingPolicies.Rules.Tasks.SetHeaderAction and define to replace "Date" with a different value. However, I cannot see a way to use a dynamic return value of function like Get-Date in there - at best the result of Get-Date gets converted to a static value it had when executing the new-Transportrule cmdlet.

A lambda expression / closure would perform the required function (i.e. not insert a static value but a function pointer and re-evaluate the expression on each run), but as I understand, Powershell does not support those.

An ugly workaround would be a very frequent redefinition (like once every minute) of the transport rule with the updated current time, but I would like to avoid this if a more elegant solution is available.

Any ideas on this?

---

Edit To give a short explanation on why the feature is used: the client wants to send mail containing a decision result which must not be public before a certain date. Addidionally, he also wants to conceal the date / time when the decision was met to prevent needless discussions.

This is actually a feature of the MUA (Outlook supports this out-of-the box), but server support is of course an added benefit as the mail would be sent even when the client is not running. There also is the problem: the MUA sets the "Date:" header upon message transmission to the server and the server does not change it upon release off the wait queue. There used to be two features in Outlook which performed a similar function - one was called "Deferred delivery", one was called "Deferred Submission". Obviously, the latter is what is neeed here, but it has been removed in Outlook 2000 and was never re-introduced - possibly because the Outlook team was trying to learn from Apple.

Answer 1

Set the Outlook client to not Send immediately when connected. They compose the message and hit Send as they normally would. The message sits in their Outbox. When they "actually" want to send the message, just open it up from their Outbox and click Send again, it will re-timestamp the message. Then do a Send/Receive in Outlook. No evidence of the original composition date/time can be seen in the header. Alternatively (and probably a better solution), just compose and save the message in Drafts and then Send it when you actually want to send it...

I am aware that this is not a solution like you are describing you want at the server level globally for all messages, but more of a workaround for the client. It becomes very annoying if there are a lot of these messages to do this on, but a couple a week/month won't be too bad for them. Weird requirement from the client..."Send the message, but DON'T ACTUALLY send the message until I say so..." If you don't want to send the message, DON'T hit the Send button...

Another possibility is to not even use Outlook to send the message, compose the message in notepad, saving it as an eml file in the supported format, and write a script to drop it in the Pickup folder on the Exchange server at the appropriate date/time to be delivered.

Answer 2

I know that this doesn't answer your question. And I don't expect upvotes but no downvotes.

Deferred delivery is a wrong designed feature. It relieves people from thinking. They can hit "Send", then think and say "Oh, I want to undo 'Send'". But it should be "Think" and then "Send" or "Cancel". The same problem comes with the "Recycle bin"-problem. Somebody invented this terrible feature and now you can see it everywhere. And the people don't think anymore. First delete and then think why deleting was a mistake. Currently everybody complains why there is no recycle bin for everything. (Marry someone and then asking where is the undo button).

But there is another psychological problem coming with that feature. Nowadays everybody thinks that Email is an instant communication medium (it isn't!). While hitting the send button the mail should arrive at the recipient. As this is true for most of all mails, at least within a few seconds, everything that introduces delay is an inconvenience. Deferred delivery on client side and greylisting on recipient side introduce such inconvenience.

I know no mail server that includes this feature out-of-the box. Probably because there is no need for it. In my opinion this is not part of a MTA. This should be the job of a MUA. Before (newly created) mails are delivered to the relay host the client should offer a confirmation dialog: "Do you really want to send this mail? Please review before hitting 'yes'. [YES] [[NO]]" Maybe even with a CAPTCHA.

Saying this you should think about modifying Outlook instead of Exchange to do this.

Answer 3

I can't test this now, but I recall that at the last place I worked we were running Exchange 2007 and Outlook 2010. We actually ran in to another related problem because users on laptops with Outlook in cached mode used this feature and the messages were not delivered unless the client was running and connected to the VPN or in the office. We tracked it down to that if the client is running in cached mode, then the behavior is like Deferred Submit; the message sits in the Outbox on the client instead of the server. The result is that the client must be open to be submitted at the proper time and the timestamp is the submission time.

If I remember correctly and that behavior is unchanged, then that might work.