Summary

  • Under the behavior documented in RFC 3164, a relay that recognized PRI but not TIMESTAMP inserted its own current local time and preferably the device identity as the relay knew it.
  • The enlarged packet still had to fit within 1,024 bytes. If the new fields pushed it over the limit, the relay had to cut the tail, where the original message might have placed its most important detail.
  • Later syslog standards separated originator, relay, collector and transport roles more precisely. They did not make clean syntax, exact framing or a TLS peer identity proof of an unaltered end-to-end origin.

The repair had to be paid for in payload

Syslog already had a history when RFC 3164 was published in 2001. The document described observed BSD practice. It called the machine that generated a message a device, a machine that received and forwarded messages a relay, and a machine that received without forwarding a collector. A sender did not have to know which role waited at the next hop.

The relay began by inspecting PRI, the priority enclosed in angle brackets, and then the form of TIMESTAMP. If both were valid and its configuration selected that priority for forwarding, the relay had to send the packet without changing it. It did not have to determine whether the stated time was accurate. It did not have to confirm that HOSTNAME matched the network source.

“Valid” in this branch therefore meant recognizable enough to route unchanged. It was not a finding that the header told the truth.

The more consequential branch began when PRI was valid but TIMESTAMP was missing or malformed. The relay had to insert a timestamp and a space immediately after PRI. That value was the relay’s current local time. It was not a recovered originator clock reading or an estimate of when the application event occurred.

The relay should also insert HOSTNAME. It used the device name as the relay knew it, or the device’s IP address when it could not determine a name. Everything else that had arrived became CONTENT and followed those new fields. Because the relay could not recover the originating process, it did not manufacture a TAG.

The result now carried more coordinates: a time at which this relay observed the packet and an identity that this relay associated with the previous device. But RFC 3164 still required the entire packet to be no more than 1,024 bytes. After inserting a timestamp, or a timestamp and hostname, the relay had to count again. If the packet had grown beyond the ceiling, it had to truncate it to 1,024 bytes.

The specification states the consequence plainly: vital information might be lost from the end of the original packet. Context did not arrive with extra storage. It competed with the content it was meant to explain.

An alert could retain a regular priority, a plausible date and a recognizable host while losing the entity name, error code, result or final qualification. The collector acquired a record that was easier to file and harder to interpret correctly.

The packet without a priority spent even more on normalization

RFC 3164 provided a third path for a packet with no identifiable PRI. The relay inserted a default priority of 13, added its timestamp, preferably added a hostname and treated the entire received packet as CONTENT. It then applied the same 1,024-byte test and mandatory truncation.

The worse the incoming structure, the more bytes its normalization could consume. Yet a later relay might see the repaired PRI and TIMESTAMP as valid and forward the result untouched. A collector retaining only the final copy was not necessarily told which header fields came from the device and which came from the first relay. Nor would the absent suffix announce that it had once existed.

The legacy timestamp added a separate uncertainty. It held month, day and local time, but no year and no time zone. A collector could infer a year from the archive period, but delayed packets and year boundaries weakened that association. A relay-inserted timestamp most directly located the relay’s observation, not the originator’s event.

Exact framing could preserve an already incomplete message

RFC 5424, published in 2009, formalized the terms originator, relay, collector, transport sender and transport receiver. Its header includes VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID and MSGID, followed by structured data and an optional message. The clearer role vocabulary made it easier to ask whose assertion each field represented.

It also moved message-size support into transport mappings. Every transport receiver had to accept messages through 480 octets and should accept them through 2,048 octets. A receiver encountering more than it supported should truncate the payload or could discard the message.

If it truncated, the cut had to occur at the end. That preserved the prefix but did not guarantee a valid remainder: UTF-8 or structured data could end in the middle of an encoding. The security discussion warned that truncation could be used to hide vital log information and advised placing important information as early as possible.

Prefix survival became an explicit design consideration. It was not a guarantee of completeness.

The TLS mapping in RFC 5425 frames each syslog message with a decimal octet count and a space. The receiver knows the exact message boundary even when a message spans TLS records or several messages occupy one record. It must process at least 2,048 octets and should process at least 8,192.

TLS nevertheless protects syslog hop by hop. RFC 5425 explicitly notes that the authenticated transport sender identity need not correspond to HOSTNAME inside the syslog message. A complete TLS frame proves what one peer delivered over that protected connection. It does not prove that a previous relay never altered or shortened the content.

The UDP mapping in RFC 5426 places exactly one syslog message in each datagram, and that message may be complete or truncated. The TCP practices documented in RFC 6587 include octet counting and delimiter-based non-transparent framing. Both distinguish message units. Neither reconstructs a tail removed before the unit reached them.

The IANA Syslog Parameters registry assigns facility, severity, version and structured-data identifiers. It is evidence for decoding a value. It is not evidence that a particular implementation supports it, that a message was delivered, that HOSTNAME was authentic or that the retained record was complete.

Sources