How compliant is Symantec DLP Syslog messaging to RFC 3164?

In general:  Syslog is a client/server protocol: the Syslog sender sends a small (less than 1KB) textual message to the Syslog receiver. The receiver is commonly called "syslogd", "syslog daemon" or "Syslog server". Syslog messages can be sent via UDP and/or TCP. The data is sent in cleartext; although not part of the Syslog protocol itself, an SSL wrapper can be used to provide for a layer of encryption through SSL/TLS.

[Reference: http://en.wikipedia.org/wiki/Syslog]

So, we are looking at two areas: protocol and message
The message itself is a simple text message.
The protocol contains additional constraints as outlined below

We do conform to RFC3164, but you have to keep in mind that this is very limited and that for the very reason that it is not fully configurable as the response rule.

In regards to the message, we do not allow the facility to be configured. For all Syslog messages we log to the user level facility (numerical value 1)

Facility values are defined in RFC 3164:

The Facilities and Severities of the messages are numerically coded
with decimal values. Some of the operating system daemons and
processes have been assigned Facility values. Processes and daemons
that have not been explicitly assigned a Facility may use any of the
"local use" facilities or they may use the "user-level" Facility.

Currently we do not send the "Type".  We only have "Info, Warning and Severe" which seem incongruous with the default Syslog levels. So to let them work in the same scope as the response rules the enhancement is files.

As stated in http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf the Syslog message contains the following components:

3.3.1
Syslog Format
Syslog assigns a priority to each message based on the importance of the following two attributes:
- Message type, known as a facility. Examples of facilities include kernel messages, mail system messages, authorization messages, printer messages, and audit messages.
- Severity. Each log message has a severity value assigned, from 0 (emergency) to 7 (debug).

[...]
Syslog is intended to be very simple, and each Syslog message has only three parts. The first part specifies the facility and severity as numerical values. The second part of the message contains a timestamp and the hostname or IP address of the source of the log. The third part is the actual log message content. No standard fields are defined within the message content; it is intended to be human-readable, and not easily machine-parseable. This provides very high flexibility for log generators, which can place whatever information they deem important within the content field, but it makes automated analysis of the log data very challenging. A single source may use many different formats for its log message content, so an analysis program would need to be familiar with each format and be able to extract the meaning of the data within the fields of each format.

On the Syslog Server side:

If collectors are used on the receiving Syslog servers it has to be ensured that they can dump simple messages. Special collectors that expect a specific format may reject the send message. This has been observed when the system event generates a syslog message that the receiving collector is not able to handle. As a workaround a simple message dump should suffice as a fallback collector.

To summarize:
- For all Syslog messages we log to the user level facility (numerical value 1)
- As severity we only pass "Info, Warning and Severe" which seem incongruous with the default Syslog levels; that's where the enhancement comes in
- Server is passed
- Message content is passed as well
- If collectors are used on the receiving Syslog servers it has to be ensured that they can dump simple messages

More in regards to generating syslog messages from the Response Rule or System Alerts can be found in KB TECH218905