Resumo

  • :raw mantém a representação sem decodificar, :content escolhe partes MIME e :text usa a melhor extração disponível. O mesmo arquivo pode oferecer palavras diferentes a implementações conformes.
  • Para uma ação importante, preserve mensagem, versão do motor, transformação, seletor, comparador, falhas e partes omitidas. Match não é veredito de malware; miss não é prova de ausência.

O corpo já pode desaparecer antes da transformação. Uma mensagem só com cabeçalhos, sem a linha vazia que os separaria do corpo, produz um conjunto vazio de cadeias. Todo teste body é falso, inclusive aquele que procura uma chave vazia. Ausência de objeto e objeto vazio são fatos distintos.

Quando existe corpo, o RFC manda primeiro extrair cadeias. Elas não correspondem necessariamente a cada linha física e podem conter CRLF. Depois entram comparador e match type. O Boolean é o fim de uma cadeia; sozinho, não descreve o que foi observado.

Raw também lê a embalagem

:raw trata todo o corpo não decodificado como um item. Preserva content-transfer-encoding e transforma boundaries multipart e cabeçalhos MIME internos em material pesquisável. Erros sintáticos não dispensam o filtro, salvo rejeição anterior pelo ambiente.

Assim, a palavra pode vir de base64, de um boundary ou de Content-Type, não da frase apresentada ao leitor. O acerto é uma prova fiel da representação e uma prova fraca da comunicação humana.

Como tudo forma um item, um wildcard pode atravessar regiões que a árvore MIME separaria. Trocar raw por content muda a pergunta, mesmo sem alterar mensagem ou termo.

Content delimita as partes autorizadas

:content escolhe tipos MIME e percorre recursivamente multipart e message/rfc822. Um tipo/subtipo completo é exato; um tipo cobre seus subtipos; seletor vazio aceita todos. Barras mal posicionadas ou repetidas selecionam nenhum tipo.

Cada parte é comparada isoladamente. Uma expressão não atravessa a fronteira entre duas partes, ainda que o cliente as mostre lado a lado. Pró­logo e epílogo do container têm cadeias próprias; cabeçalho de mensagem aninhada e corpos internos seguem seleções diferentes.

O servidor decodifica encodings obrigatórios e converte texto compatível para UTF-8. Porém, uma parte impossível de converter pode virar US-ASCII, ser omitida ou seguir convenção local. Um resultado falso pode esconder uma ausência de observação.

Text incorpora a política do fornecedor

:text é best effort e o default. Um motor simples pode enxergar só partes text. Outro remove markup, converte documentos e aplica OCR. O RFC não exige a mesma saída nem o mesmo número de cadeias.

Upgrade de biblioteca ou migração de provedor altera a política efetiva. Um conversor novo revela palavras antigas; um OCR novo perde outras. O script continua igual e a superfície muda.

Por isso, “rule matched” é insuficiente. A auditoria precisa de versão, capacidades, warnings, partes ignoradas e hashes da saída. Sem esses dados, não há como repetir a medição.

Segurança exige outro recibo

O RFC avisa que raw pode ser mais geral do que o pretendido e que texto não substitui filtro de spam, vírus ou segurança. Também exige dimensionamento e restrição para impedir negação de serviço causada pelo próprio matching.

Um falso positivo pode apagar correio legítimo por causa da embalagem. Um falso negativo pode liberar anexo perigoso porque o tipo não entrou ou a conversão falhou. O Boolean não classifica nenhuma dessas causas.

O tema de RFC 5229 continua separado: variáveis e capturas. Wildcards de body não preenchem ${1} e similares. Isso limita o efeito lateral, mas não completa a extração.

Fontes