Hi,

the syslog-ng() destination should use a special format which transfers all name-value pairs to the server side automatically. On the server side this should be handled specially in which case no sudo parser should run.

This is how this is implemented in the server side:

Traditional syslog:

```       

   channel {
                source {
                        network(transport(tcp)
                                port(`tcp-port`)
                                max-connections(`max-connections`)
                                log-msg-size(`log-msg-size`)
                                flags(no-parse, `flags`)
                                hook-commands(`hook-commands`));
                        network(transport(udp)
                                port(`udp-port`)
                                log-msg-size(`log-msg-size`)
                                flags(no-parse, `flags`));
                };
                if {
                        parser { app-parser(topic(syslog-raw) `__VARARGS__`); };
                } else {
                        parser { syslog-parser(flags(syslog-protocol)); };
                        if {
                                parser { ewmm-parser(); };
                        }
                        elif {
                                parser { app-parser(topic(syslog) `__VARARGS__`); };
                        }
                        else {};
                };
        };

```

on port 514, we check if the message is matched by the any parsers registered on the syslog-raw topic.  The sudo parser is not registered here, rather it is registered to "syslog":

```

application sudo[syslog] {
        filter { program("sudo" type(string)); };
        parser { sudo-parser(); };
};

```

In the else branch, we process the incoming stream with the syslog-parser(). ewmm is encapsulated into the syslog format, so it should be successful here. Once that finishes we apply ewmm-parser() which should again succeed, causing the elif branch not to run.

Checking it in practice. I have this config on the client side:

```

@version: 3.28

@include "scl.conf"

log {
source { system(); };
destination { syslog-ng(server("127.0.0.1") port(2000)); };
};
```

I invoked sudo, which triggered this message to be sent to the server:

<85>1 2020-08-06T12:41:08.000+00:00 bzorp @syslog-ng - - [meta sequenceId="1"] {"PROGRAM":"sudo","PID":"243","MESSAGE":"   bazsi : TTY=console ; PWD=/install ; USER=root ; COMMAND=/bin/ls","HOST_FROM":"bzorp","HOST":"bzorp",".unix":{"uid":"0","pid":"243","gid":"1000","cmdline":"sudo ls "},".sudo":{"USER":"root","TTY":"console","SUBJECT":"bazsi","PWD":"/install","COMMAND":"/bin/ls"},".app":{"name":"sudo"},"._TAGS":".app.sudo,.source.#anon-source0"}

Please note the ".sudo" key value pairs above.

I am then sending this to a default-network-drivers() source:

config:

```

@version: 3.28

@include "scl.conf"

log {
    source { default-network-drivers(tcp-port(2514) udp-port(2514) rfc5424-tls-port(6514) rfc5424-tcp-port(2601)); };
    destination { file("/install/foobar.log" template("$(format-json --leave-initial-dot --scope all-nv-pairs)\n")); };
};

```

output in foobar.log:

As you can see the ".sudo" top-level key is there, listing sudo related name-value pairs as extracted on the client. I also checked the debug/trace logs on the server and confirmed that only ewmm parsing was done,