Troca de entrega adiada: mensagem de atualização "Data:" cabeçalho

Question

Um cliente está usando o recurso "entrega adiada" no Outlook / Exchange. Por alguma razão este recurso preserva o tempo de criação da mensagem original (isto é, quando o usuário pressiona o botão "enviar") como o cabeçalho RFC-822 Date: assim, mesmo quando a entrega da mensagem é realmente "adiada", os cabeçalhos ainda suportam a evidência de que foi composta um pouco antes do parto. Meu cliente gostaria de definir o cabeçalho Date: para o momento em que a mensagem realmente deixa a organização do Exchange, de modo que pareça que ela foi composta e enviada recentemente.

A ideia para resolver isso é definir os cabeçalhos Date: em todos os emails SMTP de saída para a hora atual do servidor em um ambiente do Exchange 2007.

Eu sei que posso configurar um novo-Transportrule com o parâmetro -Action definido como Microsoft.Exchange.MessagingPolicies.Rules.Tasks.SetHeaderAction e definir para substituir "Date" por um valor diferente. No entanto, não consigo ver uma maneira de usar um valor de retorno dinâmico de função como Get-Date lá - na melhor das hipóteses, o resultado de Get-Date é convertido em um valor estático que ele tinha ao executar o cmdlet new-Transportrule.

Uma expressão / encerramento lambda executaria a função necessária (ou seja, não inserir um valor estático, mas um ponteiro de função e reavaliar a expressão em cada execução), mas, como eu entendo, o Powershell não suporta esses recursos.

Uma solução desagradável seria uma redefinição muito frequente (como uma vez a cada minuto) da regra de transporte com a hora atual atualizada, mas eu gostaria de evitar isso se uma solução mais elegante estivesse disponível.

Alguma idéia sobre isso?

Editar Para dar uma breve explicação sobre por que o recurso é usado: o cliente deseja enviar mensagens contendo um resultado de decisão que não deve ser público antes de uma determinada data. Além disso, ele também quer esconder a data / hora em que a decisão foi tomada para evitar discussões desnecessárias.

Este é um recurso do MUA (o Outlook suporta isso imediatamente), mas o suporte ao servidor é, naturalmente, um benefício adicional, já que o e-mail seria enviado mesmo quando o cliente estivesse não está funcionando. Existe também o problema: o MUA define o cabeçalho "Data:" na transmissão da mensagem para o servidor e o servidor não o altera após a liberação da fila de espera. Costumava haver dois recursos no Outlook que executavam uma função semelhante - um deles era chamado de "Entrega adiada", um foi chamado de "Envio diferido". Obviamente, o último é o que é neeed aqui, mas foi removido no Outlook 2000 e nunca foi reintroduzido - possivelmente porque a equipe do Outlook estava tentando aprender com a Apple.

    

Answer 1

Defina o cliente do Outlook para não enviar imediatamente quando conectado. Eles compõem a mensagem e clicam em Enviar como normalmente. A mensagem está na caixa de saída. Quando eles "realmente" quiserem enviar a mensagem, basta abri-la a partir da Caixa de saída e clicar em Enviar novamente. Ela retornará o tempo da mensagem. Em seguida, faça um envio / recebimento no Outlook. Nenhuma evidência da data / hora da composição original pode ser vista no cabeçalho. Como alternativa (e provavelmente uma solução melhor), basta compor e salvar a mensagem em Rascunhos e, em seguida, Enviar quando você realmente quiser enviá-la ...

Estou ciente de que esta não é uma solução como a que você está descrevendo que você quer no nível do servidor globalmente para todas as mensagens, mas sim uma solução alternativa para o cliente. Torna-se muito chato se há muitas dessas mensagens para fazer isso, mas um par de uma semana / mês não será muito ruim para elas. Exigência estranha do cliente ... "Envie a mensagem, mas NÃO REALMENTE envie a mensagem até que eu diga ..." Se você não quiser enviar a mensagem, NÃO pressione o botão Enviar ...

Outra possibilidade é não usar o Outlook para enviar a mensagem, compor a mensagem no bloco de notas, salvá-la como um arquivo eml no formato suportado e escrever um script para soltá-la no Pickup no servidor do Exchange na data / hora apropriada a ser entregue.

    

Answer 2

Eu sei que isso não responde à sua pergunta. E eu não espero votos positivos, mas não votos negativos.

A entrega adiada é um recurso projetado incorretamente. Isso alivia as pessoas de pensarem. Eles podem clicar em "Enviar", depois pensar e dizer "Ah, eu quero desfazer 'Enviar'". Mas deve ser "Pense" e depois "Enviar" ou "Cancelar". O mesmo problema vem com o problema "Reciclagem". Alguém inventou esse recurso terrível e agora você pode vê-lo em todos os lugares. E as pessoas não pensam mais. Primeiro, exclua e depois pense por que excluir foi um erro. Atualmente todo mundo reclama porque não há lixeira para tudo. (Case-se com alguém e depois pergunte onde está o botão de desfazer).

Mas há outro problema psicológico vindo com esse recurso. Hoje em dia todo mundo acha que o email é um meio de comunicação instantâneo (não é!). Ao apertar o botão de envio, o correio deve chegar ao destinatário. Como isso é verdade para a maioria de todos os e-mails, pelo menos em poucos segundos, tudo o que introduz atraso é um inconveniente. A entrega diferida no lado do cliente e a lista cinzenta no lado do destinatário introduz tal inconveniente.

Não conheço nenhum servidor de email que inclua esse recurso fora da caixa. Provavelmente porque não há necessidade disso. Na minha opinião, isso não faz parte de um MTA. Este deve ser o trabalho de um MUA. Antes que os emails recém-criados sejam entregues ao host de retransmissão, o cliente deve oferecer uma caixa de diálogo de confirmação: "Você realmente deseja enviar este email? Por favor, revise antes de clicar em 'yes'. [YES] [[NO]]" um CAPTCHA.

Dizendo isso, você deve pensar em modificar o Outlook em vez do Exchange para fazer isso.

    

Answer 3

Não posso testar isso agora, mas lembro que, no último lugar em que trabalhei, estávamos executando o Exchange 2007 e o Outlook 2010. Na verdade, encontramos outro problema relacionado porque os usuários em laptops com o Outlook no modo em cache usavam esse recurso e as mensagens não foram entregues a menos que o cliente estivesse em execução e conectado à VPN ou no escritório. Nós rastreamos isso até que, se o cliente estiver rodando em modo cache, o comportamento é como Deferred Submit; a mensagem fica na caixa de saída no cliente em vez do servidor. O resultado é que o cliente deve estar aberto para ser enviado no momento adequado e o registro de data e hora é o tempo de envio.

Se bem me lembro e esse comportamento não muda, isso pode funcionar.