O envio de mensagens em nome de outro domínio (usando um cabeçalho Remetente:) aumenta as chances de ser marcado como spam?

Question

Nosso departamento de marketing está contratando um serviço que enviará e-mails para possíveis clientes em nosso nome. Pelo que estou reunindo a partir de sua documentação, parece que eles fazem isso através do cabeçalho do remetente (ou seja, o cabeçalho de contém um endereço em nosso domínio e o cabeçalho do remetente contém um de seu domínio). Isso coloca uma tag "via" ou "em nome de" na exibição de alguns clientes de email.

Eles nos dão a opção de instalar um registro DKIM em nosso domínio e fazer com que enviem e-mails diretamente de nosso domínio para seus servidores. (Presumivelmente nós também teríamos que adicioná-los ao nosso SPF, embora eles não tenham mencionado isso.)

Eu entendo as implicações gerais de tudo isso, mas uma afirmação que eles fazem ao tentar empurrar a opção de envio direto é que as mensagens "via" ou "em nome de" têm mais chances de serem marcadas como spam. Isso é realmente verdade na prática?

Em outras palavras, as mensagens com um cabeçalho Remetente diferente do cabeçalho De têm mais probabilidade de serem marcadas como spam do que um enviado apenas com um cabeçalho De (supondo que os registros SPF não atrapalham)?

    

Answer 1

O Sender é um campo padrão originador especificado no formato de mensagem da Internet ( RFC 5322, 3.6.2 ) e, portanto, não deve ser considerado como um erro. Às vezes é até obrigatório.

The originator fields of a message consist of the from field, the sender field (when applicable), and optionally the reply-to field. The from field consists of the field name From and a comma- separated list of one or more mailbox specifications. If the from field contains more than one mailbox specification in the mailbox- list, then the sender field, containing the field name Sender and a single mailbox specification, MUST appear in the message. In either case, an optional reply-to field MAY also be included, which contains the field name Reply-To and a comma-separated list of one or more addresses.

The originator fields indicate the mailbox(es) of the source of the message. The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The Sender: field specifies the mailbox of the agent responsible for the actual transmission of the message.

Eu não posso ter certeza se alguma detecção de spam indica a existência do cabeçalho Sender sozinho, mas podemos começar investigando SpamAssassin Rule QA como um exemplo. A regra para __HAS_SENDER não está atualmente ativa, por exemplo, não atribui qualquer pontuação à mensagem.

Se assinado, o DKIM testa o campo From: contra a assinatura e a assinatura contra a chave pública fornecida no DNS desse domínio e do seletor . A assinatura DKIM deve corresponder ao campo From se o Sender estiver presente ou não. Estes dois não se excluem, mas neste dia e idade é recomendado ter assinaturas DKIM - e aplicar o DKIM com o DMARC . Eu recomendo ter seletor separado (e chaves de assinatura) para todos os provedores de serviços terceirizados.

O SPF, por outro lado, não verifica nada em relação aos cabeçalhos de e-mail. Ele verifica se o domínio usado no envelope remetente (ou seja, o endereço usado no comando MAIL FROM: do SMTP) lista esse MTA como um remetente permitido. Embora o RFC 6854 permita ter vários endereços no campo From , MAIL FROM tem sempre apenas um endereço e sempre é iniciado uma nova transação de e-mail, limpando todos os destinatários e dados de e-mail ( RFC 5321, 3.3 ).

Portanto, o servidor de envio pode usar um domínio próprio em envelope remetente e, idealmente, corresponderia ao cabeçalho Sender , enquanto From corresponde a DKIM. Em seguida, o servidor de destino final registra o remetente do envelope inserindo um terceiro cabeçalho Return-Path , como uma informação de rastreamento ( RFC 5321 , 4.4 . Como essas informações atualmente salvas apenas no destino final podem mudar durante a transmissão, o SpamAssassin tem uma proposta para armazenar essas informações em cada Received header. Não é amplamente aceito, mas o SpamAssassin o suporta desde a versão 3.0.3.