Summary

  • RFC 3164 caps the complete legacy syslog packet at 1,024 bytes, then tells a relay to add a missing timestamp and optionally a hostname.
  • If that enrichment pushes the packet over the cap, the relay must truncate it; the RFC warns that the lost bytes may contain vital information from the original message's end.

The header had to fit somewhere

Imagine a router sending a nearly full syslog packet without a usable timestamp. The relay receives it, checks the priority field and prepares to forward it. Under RFC 3164's §4.3.2, the relay must insert its current local timestamp after the PRI field. It should also add a hostname when it can determine one. The remaining original material becomes the message's CONTENT.

That operation is not free. RFC 3164 §4.1 limits the total packet—not only the event text—to 1,024 bytes. The PRI, header and message all spend from one budget. If the timestamp, hostname and separating spaces make the rebuilt packet too long, §4.3.2 requires the relay to check the new length and truncate the packet back to 1,024 bytes. The memo states the consequence plainly: information at the end of the original packet, possibly vital, can be lost.

The subtlety is where the loss occurs. A collector may receive a syntactically recognizable syslog message. Its PRI and newly inserted header may look orderly. Yet the event's final bytes—the clause after “because,” a command result, a device identifier, a checksum, or a second value in a diagnostic—may no longer be there. Those examples are possibilities, not incidents claimed by this article. The protocol makes the ending vulnerable when enrichment pushes an already long input beyond the shared limit.

A standards instruction, not an implementation census

This is a rule in an August 2001 Informational memo describing the BSD syslog protocol, not evidence that every deployed relay followed it. The RFC's section 4.2 says a device's original UDP/514 payload may be any valid syslog message and recommends including the PRI, HEADER and MSG structure because it improves readability and removes the need for relay modification. Section 6.1 separately warns that receivers must not malfunction on longer-than-1,024-byte messages and describes differing receiver behavior.

Neither passage establishes how often real devices emitted long messages, which relays truncated, or what any collector retained.

Nor is the 1,024-byte message ceiling interchangeable with the path MTU. The former is a syslog packet/message rule in RFC 3164; the latter concerns network-layer packet size along a path. IP fragmentation, UDP datagram handling and application-level truncation are distinct mechanisms. A message can fit the protocol's bound while interacting with a smaller path MTU, or exceed the legacy application bound independently of the path.

The added values also have limits as evidence. The timestamp is the relay's current local time, not necessarily the event's original time. The hostname is the device name as known to that relay—or its IP address if the name cannot be determined. RFC 3164 does not require the receiver to validate that hostname against the sender. Enrichment can therefore make the record more legible without proving original event time or cryptographic source identity.

Why a later format matters—but does not settle deployment

RFC 5424 later obsoleted RFC 3164 with a more explicit syslog header and structured data. RFC 6587 describes TCP framing and notes that the legacy 1,024-octet ceiling was expanded for standardized syslog. RFC 3195 took another route: its RAW profile limits each event body to 1,024 bytes while excluding BEEP framing overhead. The comparison is useful because it shows that “1,024 bytes” can measure different things at different layers. It does not show that old senders or relays disappeared when a newer RFC was published.

The historical lesson is narrower: a relay's attempt to improve context can spend the same finite budget as the content it is carrying. The resulting packet may still arrive, parse and be stored. None of those states proves that the full original message survived. To establish that in a real system would require paired evidence—source-side bytes, each relay's input and output, collector parsing, and a later readback—not just a successful send or a well-formed header.

Sources