Resumo

  • Um artigo de colaborador publicado em 17 de setembro no blog do LACNIC afirma que o XARF v4 exige no mínimo sete campos. A especificação atual enumera oito campos obrigatórios no nível superior.
  • A contagem curta deixa de fora sender. O XARF o mantém separado de reporter para representar um CERT, provedor de infraestrutura ou outro intermediário que envia a denúncia em nome de quem a formulou.
  • A divergência não prova que um relato tenha sido perdido nem que o LACNIC imponha o XARF. Ela mostra a necessidade de vincular cada resultado à versão exata do esquema, aos requisitos usados, aos papéis, à entrega e à triagem.

O campo esquecido é justamente o intermediário

Uma lista de requisitos pode virar código mais depressa do que uma ressalva vira prática. Se a lista tiver sete posições, um relatório pode preencher todas e ainda assim não informar quem o transmitiu. Isso importa quando a organização que detectou o abuso não é a mesma que opera o canal de envio.

Esse é o ponto concreto aberto pelo texto “How to Keep an Abuse Report from Getting Lost in Your Mailbox”, publicado no blog do LACNIC em 17 de setembro. O artigo de Guillermo Pereyra descreve o XARF v4 como um formato JSON mantido pela comunidade, com 32 tipos de incidente agrupados em sete categorias.

Ao resumir a estrutura, o texto fala em um mínimo de sete campos: versão do esquema, identificador único, instante do incidente, reportante, origem do abuso, categoria e tipo. A especificação técnica atual do XARF v4, porém, enumera oito campos obrigatórios de primeiro nível: xarf_version, report_id, timestamp, reporter, sender, o campo identificador da origem, category e type.

A referência de campos comuns confirma os oito e detalha atributos obrigatórios dentro de reporter e sender. Esquemas de categorias específicas ainda podem acrescentar outros requisitos. Portanto, oito é o número dos campos superiores universais, não o total de valores exigidos em toda modalidade.

O próprio artigo do blog explica sender logo depois e o inclui no JSON de exemplo. Também informa que as opiniões pertencem ao autor e não necessariamente ao LACNIC. A leitura correta é limitada: há uma inconsistência documental verificável, não evidência de que o LACNIC tenha adotado um validador incompleto, de que o XARF esteja quebrado ou de que um caso real tenha sumido.

O campo ausente da contagem guarda uma diferença de autoridade. reporter identifica a organização que detectou ou denunciou o abuso. sender identifica a organização que efetivamente transmitiu o pacote. Em um caso simples, são iguais. Em outros, um serviço antiabuso, uma empresa de proteção de marca, uma plataforma de envio ou um CERT nacional atua em nome de outra entidade.

Sem essa separação, a mesa receptora perde perguntas úteis. Quem fez a alegação? Qual sistema autenticou e enviou o relato? Quem pode corrigir a serialização? Um segundo pacote é duplicata de transporte ou uma denúncia independente? O mesmo incidente pode ter várias testemunhas e uma testemunha pode usar vários canais.

Também é preciso evitar que a conformidade com o formato vire sinônimo de mérito. O XARF marca source_port, evidence, evidence_source e confidence como campos comuns recomendados. Cada categoria pode exigir dados adicionais. O modo padrão cobra os campos obrigatórios comuns e específicos; o modo estrito também cobra os recomendados.

Assim, um relato permissivamente válido pode não trazer um conjunto de evidências. Outro pode conter evidência irrelevante. O e-mail pode falhar, cair em uma fila errada, não receber revisão humana ou relatar fatos contestados. Validação, entrega, roteamento, triagem, decisão e remediação não são o mesmo evento.

O texto do blog preserva essa distinção ao afirmar que a evidência, embora recomendada no esquema, costuma dar caráter acionável ao relato. Ele também aceita texto simples quando houver recurso afetado, horário UTC, tipo de abuso, evidência e um contato que responda. Um texto completo continua melhor do que um JSON pobre. XARF é uma linguagem possível, não um filtro que autoriza ignorar todo o resto.

A seção 12 do Manual de Políticas do LACNIC explica o contexto regional. O contato de abuso deve ser administrado, os relatos podem ser manuais ou automáticos e o denunciante não pode ser obrigado a preencher um formulário. A regra trata de alcance e operação da caixa. Não torna o XARF obrigatório nem valida a alegação de um caso.

O transporte tem limite semelhante. O artigo menciona ARF e RFC 5965. O documento define um formato extensível de feedback por e-mail, mas deixa fora de escopo o destino, a validação do conteúdo e a confiança entre geradores e receptores. RFC 6650 é a declaração de aplicabilidade posterior. Uma embalagem padronizada não decide o conteúdo.

O mecanismo de controle pode caber em um recibo de entrada. Ele registra nome e versão semântica do esquema, hash do arquivo ou documentação usada e inventário exato dos campos universais e específicos. Mantém reporter e sender separados, mesmo quando apontam para a mesma organização.

O mesmo recibo anota modo, resultado e alertas da validação; quantidade e hash do pacote de evidências, quando houver; identificador da mensagem, endpoint e horário de recebimento; fila responsável, estado de triagem e caminho de correção. Hash prova que os bytes são os mesmos, não que a narrativa é verdadeira.

Se a documentação for corrigida amanhã, a organização saberá quais relatos foram verificados sob cada regra. Poderá revalidar um conjunto delimitado sem reescrever o histórico. Sem isso, “XARF válido” parece uma certeza técnica, mas muda de significado conforme a página ou o código consultado.

Fontes