[RFC 3164(和訳) 4.3.～4.]

※ここからはrelayする時の話です。

----------
4.3 Relayed syslog Packets

syslogを転送するデバイスでは、PRIがまともかどうかcheckします。
(中略)
考えられるケースとしては以下の通りであり、右に書いた各章で解説します。

1)PRI・TIMESTAMPともに問題なしの場合→Section4.3.1　
2)PRIは正常だが、TIMESTAMPフィールドがなかったり、変な場合→Section4.3.2
3)PRI部分が無いか、PRIとして認識できるものではない場合→Section4.3.3

4.3.1 Varid PRI and TIMESTAMP
(中略)
とはいえ、TIMESTAMPフィールドに入った時間がまともなものかどうかまではcheckしなくてよいです。また、HostnameのIPアドレスがPacketのSrcアドレスと一致しているかどうかも、(前述の通り違っているパターンもあるので)checkする必要はありません。

4.3.2 Varid PRI but no TIMESTAMP or invarid TIMESTAMP

TIMESTAMPフィールドが無かったり、このフィールドのデータとしてはフォーマットがおかしい、という場合は、PRIフィールドの"＞"の後に1スペースあけて、その後にTIMESTAMPをつけてやる必要があります。時間は、relayするデバイスのlocal timeにします。
で、TIMESTAMPの後に1スペース空けた後、HOSTNAMEフィールドを続けます。HOSTNAMEは、relayするデバイスでわかっているならoriginalのhostnameを、分からなければoriginalが使っているアドレスを入れます。
このような修正をしたら、全体のパケット長が1024byte以下であることを確認してください。もしオーバーしていたらtruncate(切りとり)して1024byte以下になるようにします。
このような場合は、MSG部分などデータが不完全になるので、originalの送出段階から、きちんとしたフォームで(PRIやHEADERを作成して)あるべきなのです。

4.3.3 No PRI or Unidentifiable PRI

もしOriginalにPRIが無いとか、PRIかも知れないがPRIとして認識できないPRIのついたsyslog messageを受信した場合はPriorityを13にしたPRIを挿入し、TIMESTAMPフィールド以降も前述の通り追加します。

例えば、PRIは<00>なんかはPRIとして扱われないので、relayされるメッセージではこんな風にします。

     <13>TIMESTAMP HOSTNAME <00>...

ここでもやっぱり、1024byte以下になっているかどうか、確認が必要です。
(以下略)
----------