On 30/12/2018 20:20, John Fawcett wrote: > On 30/12/2018 18:05, Wietse Venema wrote: >> John Fawcett: >>> On 30/12/2018 01:19, Wietse Venema wrote: >>> Here's a revised patch implementing the above logging. >>> >>> I did not take out the existing pipelining logging since it provides >>> additional info over the new error summary in the disconnect line, >>> though if it's no longer judged useful (postscreen can already handle >>> unauthorized pipelining) it could be removed. >> As a proof of concept this seems to work. As for redundancy, I think >> it is useful to log the pipelining violation detail once per session >> because it immediately answers the question 'why' Postfix did something. >> >> However, there is a difference between proof of concept and full >> implementation. For example, if RCPT TO was rejected, then one would >> expect that 'errors=' always shows some error category. You can >> already see where this is going. >> >> Therefore, at this point it may be better to just log that the >> client sent plaintext, once per session. >> >> I have real work that leaves few cycles for Postfix, and a full >> implementation of errors= stats may therefore have to wait until >> after the stable 3.4 release. >> >> JFTR, this is what a full implementation would look like. >> A full implementation would update a new SMTP_STATE violation_mask >> field for specific violation categories (syntax, pipelining, >> plaintext, relay, unverified-address, unknown-user, access-deny, >> dnsbl, tls-handshake, lost-connection, timeout, etc). >> >> This has a huge code footprint, because every piece of code that >> detects a violation will need to set a violation category bit. TBD >> is which error categories: we don't want too few (then we could >> just use the existing 'protocol', 'software', 'policy', 'resource', >> etc. break-down) or too many buckets. >> >> For output, the implementation would use str_name_mask(), probably >> called from a separate function smtpd_format_error_stats(). >> >> Wietse > Thanks for the feedback. > > I can take a look at it, but aside from time, I agree that any invasive > modifications would be better done in a new experimental release. I also > would not put the a temporary modification in 3.4 since people may > become accustomed to it, when it is likely to change again. > > John > To take this one step further, I have documented the current behaviour for errors during the smtp chat, indicating whether they are chatted to the client, logged to maillog and whether they set existing error flags. I did that so far for smtpd.c, smtpd_sasl_glue.c and smtpd_sasl_proto.c from postfix-3.4-20181229-nonprod. I did not include normal smtp chats, verbose logging or logging done outside an smtp session or done during initializations.
I suppose that the next step would be to evalute which of these errors are worthy of being reported in the disconnect line, with a particular eye to errors that are currently not logged in the maillog and that would not be available if postmaster notifications are disabled (more likely for PROTOCOL and POLICY errors). Any thoughts about this approach? PS the attachment is a LibreOffice spreadsheet. Let's see if it gets through. John
postfix smtpd errors.ods
Description: application/vnd.oasis.opendocument.spreadsheet
