Servidor Exchange não escrevendo um cabeçalho “Para:” para mensagens com cópia oculta

2

Existe uma maneira de fazer um servidor Exchange definir o cabeçalho To: na mensagem enviada para um destinatário Cco? Nós temos acesso de administrador ao servidor. Outros programas de email fazem isso, então deve ser possível.

Exemplo - se eu enviar um email para [email protected] e bcc para [email protected], user1 verá seu próprio endereço de email no cabeçalho To: . O usuário2 não verá um cabeçalho To: . Eu quero que o user2 veja To: [email protected] .

Como pano de fundo, a razão pela qual eu (acho que) preciso disso é que usamos uma ferramenta de CRM chamada Insightly . Copiamos e-mails de clientes para endereços de e-mail do Insightly específicos do projeto, mas o Insightly não pode lidar se colocarmos o endereço de e-mail no campo bcc no Outlook. Ele lida se eu enviar o mesmo e-mail de uma conta de e-mail baseada no Linux, e a comparação dos cabeçalhos destacou o campo To ausente como o problema mais provável.

Obviamente, minha solução preferida seria fazer com que o Insightly conserte seu software e leia algo como o cabeçalho Received for , mas a equipe de atendimento ao cliente está convencida de que esse bug está ficando.

Editar: Um pouco mais de esclarecimento - quando eu envio e-mail através da minha conta de e-mail pessoal (linux webmail), a pessoa que recebe o cco vê seu próprio endereço no cabeçalho Para. Quando eu envio e-mail através da minha conta de trabalho (Outlook), a pessoa que recebe o cco não vê nenhum cabeçalho Para.

    
por Ian Bamforth 17.06.2014 / 12:50

2 respostas

0

Ian,

Primeiramente, deixe-me compartilhar algumas informações sobre como o Exchange processa as informações do BCC. Há um bom artigo aqui: link

Você também pode encontrar informações que aludem a como o Exchange processa os BCCs aqui: link

Além disso, vou simplesmente copiar / colar a resposta deste funcionário do MS, já que ele explica bem: link

The fields shown in the UI in outlook client have nothing to do with email delivery. They are there for user convenience. When you have outlook client send a message, it compiles an aggregate list of all recipients specified in the (To, Cc, and Bcc) fields displayed in its UI. Using this list of recipients, outlook then issues a RCPT-TO command to the mail server for each recipient. Once that is done, outlook issues one (just one) DATA command that contains your message (headers, blank delimiter line, and body). The mail server has no clue which recipient was specified in which field and it doesn't care. It has been told who are the recipients by the list of RCPT-TO commands that it received. The recipients never get to see the original list of RCPT-TO commands that the sender issued to their sending mail server.

The headers in the message (what gets sent during the DATA command) is whatever outlook puts there. Email clients are NOT supposed to include the Bcc field in their header section in the message but some legacy clients did. Outlook should only insert To and Cc headers that match on the values specified in the To and Cc fields in UI. Since the Bcc field was never copied to a Bcc header in the message, there is nothing within the message's headers to indicate who were the Bcc'ed recipients. And since recipients never get to see the list of RCPT-TO commands issued by the sender to their mail server, there is no way for the recipient to know who got Bcc'ed.

Even for old email clients that used to include the Bcc header in the message based on the value of the Bcc field in their UI (as, say, an option to do so), many receiving mail hosts will strip out that header. It wasn't supposed to get transmitted so it gets stripped out if present. The whole point of the Bcc field is NOT to create a header with that list of recipients.

Então, vamos ao cerne da questão. O Exchange processa de maneira diferente do que você está acostumado em seu servidor de correio Linux.

O que você pode fazer se o Insightly não mudar sua programação?

Aqui estão algumas idéias que posso pensar que podem funcionar:

1) Continue com a ideia de BCC, mas faça 2 saltos. O que quero dizer com isso é criar caixas de correio de recursos ou semelhantes no Exchange para os endereços de email dos projetos do Insightly. Então, os endereços BCC e essas caixas de correio encaminham automaticamente todos os e-mails para o endereço de e-mail do projeto "real" do Insightly. Nesse ponto, o Insightly deve vê-lo como um endereço TO real. Não tenho certeza de como o FW: info seria manipulado por ele, mas valeria a pena.

2) Considere simplesmente mudar o endereço do Insightly. Eu entendo porque você quer fazer o BCC, mas talvez isso seja uma opção?

3) O mesmo que o número 1 acima, mas coloque os endereços de e-mail no servidor de e-mail do Linux. Em seguida, execute esse servidor para o BCC Insightly ao receber um BCC do Exchange. Você precisaria usar um domínio de e-mail diferente no servidor Linux e os usuários do Outlook teriam o e-mail BCC desse domínio (como [email protected]). Em seguida, o Exchange entregaria os emails destinados ao domínio insightly.internal para o servidor Linux. O servidor Linux, em seguida, acionaria um BCC para [email protected]. Frustrante e bobo, mas deve funcionar também.

Espero que ajude um pouco. É uma situação complicada de se estar, e você não pode exatamente excluir o software de CRM por causa disso, eu estou supondo.

    
por 25.06.2014 / 15:57
1

Um bcc não deve adicionar um campo Para: aos cabeçalhos de e-mail. Se isso acontecesse, os destinatários da mensagem poderiam ver para quem a mensagem foi enviada, o oposto do que a bcc pretende fazer. Em vez disso, um bcc adiciona uma linha Cco: ao cabeçalho que é desabilitado pelo servidor de recebimento final. Um cabeçalho Para: nunca é retirado e é passado para a caixa de correio do destinatário.

Normalmente, você adiciona um único To: normal a você mesmo ou a algum endereço público ou sem resposta. Este é o endereço que os destinatários verão. Então você adiciona seus Cco. O destinatário não vê estes.

    
por 17.06.2014 / 22:22