O365 – Mensagens de usuários específicos são enviadas para a quarentena do Exchange Online Protection


By: Caio Ribeiro César

Para um bom entendimento do que é discutido neste artigo, sugiro as leituras dos artigos abaixo:

1) Códigos de Message Headers de Anti-Spam;
2) Spam Confidence Level (SCL);
3) Anti-Spam FAQ;
4) Message trace “detalhado” no EOP – também conhecido como message trace data.

Usuários finais informando que mensagens não chegam na mailbox, ou caindo em quarentena é um cenário relativamente comum no dia-a-dia dos administradores de Exchange Online.

Em alguns destes cenários, é importante coletar logs detalhados de EOP para a análise completa do que ocorre.

Vamos ao cenário: domínio “caioc.com” é classificado como junk no EOP da organização c4iocesar.com.

Uma ação rápida do administrador do domínio que recebe e-mails (c4iocesar.com) é adicionar o domínio sender “caioc.com” como allowed (por ter total confiança do domínio sender).

Após um tempo, vemos que as mensagens passam com o SCL correto e são entregues aos destinatários. Tudo ocorre bem, até que um usuário específico caioc@c4iocesar.com informa que as mensagens estão ainda sendo classificadas como junk – para todos os emails de “steve@caioc.com“.

Cabe ao administrador entender então a coleta de dados:

a) Message header;
b) Trace de mensagem;
c) Trace de mensagem detalhado.

No message header, o administrador consegue visualizar a informação:

From: Steve Silva <steve@caioc.com>
X-Forefront-Antispam-Report:CIP:200.1.1.1;IPV:NLI;CTRY:BR;EFV:NLI;SFV:SKA;SFS:;DIR:INB;SFP:;SCL:-1;SRVR:BL2PR80MB123;FPR:;SPF:None;LANG:;

IPV:NLI – Endereço IP não está listado em nenhum IP reputation list;
CTRY:BR – Mensagem enviada do país “Brasil”;
SFV:SKA – A mensagem pula o filtro e vai a caminho da mailbox, já que está em um allow-list do EOP (neste caso, o allow list criado anteriormente pelo administrador, para confiar no domínio sender).

X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0

Bulk Complain Level – 0 (não foi enviada por um bulk sender);
Phishing Confidence Lvl está como “Neutro”.

O administrador deve então coletar mais informações, para entender o motivo das mensagens serem redirecionadas para a quarentena.

Inicialmente, o log “simples” de trace informa ao administrador que a mensagem está sendo redirecionada para a Quarentena (assim como informado pelo usuário final):

quar1

Como os logs de message trace não são detalhados, o administrador irá executar um message trace data para obter informações verbose:

quar3

O arquivo .csv é coletado, com as informações do trace. É recomendado adicionar o message ID da mensagem em questão para que a captura seja exata.

Abrindo o arquivo de trace, na tab de “source_context”, podemos validar que a mensagem é enviada para a Quarentena:

csv

Filtrando para a primeira linha do trace “CatContentConversion”, vamos para a tab de “custom_data” nesta mesma linha. O resultado é:

ruleId=b12234-4123-47rf-9f01-759cc0b2f47f|st=4/1/2016 7:21:17 PM|action=SetAuditSeverity|action=SetSCL|sev=3|mode=Enforce;S:TRA=ETRP|

A mensagem está fazendo “hit” em uma regra. Esta regra específica é exatamente a criada pelo administrador, para alterar o SCL e também alterar o Audit para “High”. Continuando na leitura dos dados da tab “custom_data”, podemos ver as informações:

sfv=NotSpam rsk=Low scl=0 bcl=0 score=sfp=0|fprx=|mlc=|mlv=| |ctry=|cltctry=|lang=| dir=Incoming|alat=0|mlat=0|rlat=0|asf=|ctid=;S:UGA=V|VCL=0|VL=0;S:CFA=SUM|sfv=NotSpam|rsk=Low|scl=0|bcl=0|score=|sfs=|sfp=0|fprx=|mlc=|mlv=;S:SFA=SUM| SFV=BLK| IPV=NLI|SRV=|SFS=|SCL=6|SCORE=0|LIST=0|DI=SQ|

Nesta coleta, podemos entender o motivo da mensagem ser transferida para a quarentena.

1) Spam Confidence Level. Algo fez com que o SCL da mensagem obtivesse a nota de “6” [SCL=6], sendo então classificada como Spam e redirecionada para a Quarentena.
2) A classificação da mensagem como SCL=6 é uma consequência do valor de SFV. SFV=BLK em questão, significa que a mensagem foi bloqueada pois o endereço do sender está adicionado em um “individual blocked sender list”.

SFV:BLK A filtragem foi ignorada e foi bloqueada a passagem da mensagem porque ela foi enviada de um endereço em uma lista de remetentes bloqueados de um indivíduo.

Tendo o endereço adicionado em uma lista específica de remetentes bloqueados explica o comportamento: um usuário do domínio não recebe e-mails de um sender específico.

Para resolver o problema, valide as configurações de OWA e Outlook do usuário em questão (que não está recebendo os emails):

Bloquear ou permitir (configurações de lixo eletrônico) – OWA
Visão geral do Filtro de Lixo Eletrônico – Outlook

Comments (0)

Skip to main content