Resumo

  • O RFC 3164 mandava o relay inserir sua hora local quando o pacote tinha PRI válido, mas não um TIMESTAMP válido; recomendava também a identidade do dispositivo como o relay a conhecia.
  • O pacote ampliado ainda precisava caber em 1.024 bytes. Se não coubesse, o relay cortava o final, podendo perder a parte mais importante do conteúdo original.
  • Os padrões seguintes distinguiram melhor originador, relay, coletor e transporte, sem converter um cabeçalho regular, um quadro inteiro ou uma identidade TLS em prova completa de origem.

O contexto novo não vinha com espaço novo

Publicado em 2001, o RFC 3164 descreveu o syslog BSD que já circulava. Chamava de dispositivo quem produzia a mensagem, de relay quem a recebia e encaminhava, e de coletor quem a recebia sem prosseguir a cadeia. O emissor podia falar com o próximo salto sem saber qual papel ele exercia.

Ao receber o pacote, o relay verificava PRI e depois a forma de TIMESTAMP. Se ambos fossem válidos e sua configuração mandasse encaminhar aquela prioridade, ele repassava os bytes sem alteração. Não precisava confirmar se a hora era correta nem se HOSTNAME combinava com a origem de rede. A regra reconhecia sintaxe; não autenticava a história contada pelos campos.

Com PRI válido e TIMESTAMP ausente ou inválido, o relay precisava inserir um horário logo depois de PRI. Era a hora local atual do próprio relay, não o instante original recuperado do evento. Também deveria acrescentar, quando possível, HOSTNAME: o nome pelo qual conhecia o dispositivo ou o endereço IP quando não conseguia determinar um nome. O restante recebido passava a ser CONTENT.

Então vinha a conta. O RFC limitava o pacote inteiro a 1.024 bytes. Depois de acrescentar horário e nome, o relay precisava medir novamente. Se a expansão ultrapassasse o teto, tinha de truncar o pacote a 1.024 bytes. O documento avisa que informações vitais poderiam desaparecer do final do pacote original.

O relay, portanto, não apenas preenchia lacunas. Ele redistribuía um orçamento fixo. O coletor ganhava uma observação aproximada de tempo e origem, mas podia perder o código, o objeto afetado ou a última oração que transformava um aviso genérico em diagnóstico.

Um pacote sem PRI pagava ainda mais pela normalização

Quando PRI faltava ou não podia ser identificado, o relay inseria a prioridade padrão 13, acrescentava TIMESTAMP, de preferência HOSTNAME, e tratava todo o material recebido como conteúdo. O mesmo corte em 1.024 bytes vinha depois. Quanto mais estrutura precisava ser criada, maior podia ser o pedaço sacrificado.

O salto seguinte encontrava um pacote já regular e podia encaminhá-lo sem mudar nada. Na cópia final, não era obrigatório haver indicação de quais campos tinham vindo do equipamento e quais tinham sido escritos pelo primeiro relay. A aparência uniforme apagava a genealogia da correção.

O TIMESTAMP antigo ainda omitia ano e fuso horário. Um coletor podia inferir o ano com base no arquivo em uso, mas viradas de calendário e atrasos quebravam essa suposição. A hora escrita pelo relay era evidência de sua observação, não substituto automático do relógio do originador.

Delimitar perfeitamente o presente não recompõe o passado

O RFC 5424 formalizou em 2009 originator, relay, collector, transport sender e transport receiver. Seu cabeçalho inclui VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID e MSGID, além de dados estruturados. O tamanho passou a depender do mapeamento de transporte: receptores devem aceitar 480 octetos e deveriam aceitar 2.048.

Se a mensagem for maior do que o receptor suporta, ele deve preferencialmente truncar a carga ou pode descartá-la. Se cortar, o corte ocorre no final. Isso favorece os campos iniciais, embora possa deixar UTF-8 ou dados estruturados inválidos. O texto de segurança alerta que a truncagem pode esconder informação vital e aconselha colocar cedo o que não pode desaparecer.

No RFC 5425, syslog sobre TLS usa uma contagem decimal de octetos, um espaço e a mensagem. O receptor identifica o limite mesmo quando a mensagem atravessa registros TLS. Ainda assim, a identidade autenticada do emissor de transporte não precisa ser a mesma de HOSTNAME. TLS protege o salto, não assina retrospectivamente cada afirmação do cabeçalho.

O RFC 5426 põe uma mensagem syslog, completa ou truncada, em cada datagrama UDP. O RFC 6587 documenta no TCP a contagem de octetos e o enquadramento por terminador. Ambos marcam fronteiras; nenhum deles repõe o sufixo removido antes.

O registro IANA de parâmetros syslog ajuda a decodificar facilities, severities, versões e identificadores estruturados. Um número registrado não prova implementação, configuração, entrega, retenção ou identidade.

O RFC 5424 também criou o elemento opcional timeQuality. O originador pode declarar se conhece o fuso, se o relógio está sincronizado e qual precisão acredita ter. Isso acrescenta contexto que o TIMESTAMP antigo não carregava, mas continua sendo uma declaração do originador. Não equivale a uma verificação independente feita pelo coletor.

Os mínimos do UDP ilustram por que não existe um único novo “limite do syslog”. O RFC 5426 exige que receptores IPv4 aceitem 480 octetos e receptores IPv6, 1.180; recomenda 2.048 para todos. Esses patamares procuram reduzir a necessidade de fragmentação em redes com MTU mínimo. Capacidade local, entrega pela rota e preservação no armazenamento continuam sendo perguntas diferentes.

Uma cópia com exatamente 1.024 bytes, portanto, não prova sozinha que um relay antigo a truncou. Ela pode ter nascido nesse tamanho ou ter sido reduzida em outro ponto. O RFC demonstra uma transformação possível; atribuí-la a um caso real requer bytes nos dois lados e a configuração responsável.

O próprio RFC 3164 ainda discute falsificação, repetição, alteração, perda e chegada fora de ordem. Uma mensagem bem formada pode ser falsa; uma mensagem verdadeira pode chegar tarde ou não chegar. Conformidade de formato, êxito de transporte e verdade do evento não devem virar uma única nota de confiança.

Cada afirmação exige sua própria trilha de evidência.

Fontes