Kevin N.:
> > Kevin N.:
> >> For example the following transaction will not show any errors in SYSLOG:
> >>
> >> In: AUTH LOGIN
> >> Out: 503 5.5.1 Error: authentication not enabled
> >> In: QUIT
> >> Out: 221 2.0.0 Bye
> >
> > You can use the existing notify_classes based mechamism and pipe
> > that into syslog.
> >
> > notify_classes = protocol, ...
> > error_notice_recipient = syslog@localhost
> >
> > syslog@localhost can be a transport_maps entry for a pipe(8)
> > service invokes a script like this to log the body of the
> > message:
> >
> > #!/bin/sh
> > PATH=/bin:/usr/bin:/usr/local/bin
> > sed -n '/^$/,$p' | postlog -p info -t transcript
> >
> > Wietse
> >
>
>
> This can do the trick to some extent, but it can still be very verbose
> since (by default) the entire transaction is included in the mail and
> not just the relevant errors.
This 'entire transaction' is only a few lines:
220 greeting
ehlo command + response
mail from + response
rcpt to + response
data + response
quit + response
> Also, at a quick glance, it seems that this approach would be missing
> relevant client information, such as the client host/IP.
You have enough information in the maillog file. Postfix logs the
ehlo, mail from, rcpt to, and more. That same info is also in the
session transcript, therefore connecting them is not difficult.
> With the enhancement I was suggesting a more "tightly coupled" approach,
> like in the case of a "reject" log message.
>
> For example, like this one:
>
> reject: RCPT from unknown[X.X.X.X]: 550 5.7.25 Client host rejected:
> cannot find your hostname, [X.X.X.X]; ...
That is not a protocol error.
To resolve protocol errors, one needs the full SMTP command. The
Postfix error response is not enough. The session transcript provides
the information that is needed to understand protocol errors.
Logging every individual command+error would require major changes
to the SMTP server code.
Wietse
