John Fawcett:
> >> 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.

Basically everything that detects a violation sets state->error_mask,
and there would need to be another line of code that sets a violation
type bit. That's about 124 places. I don't see that smtpd_chat.c
is in a violation detection code path; it reports violations that
are detected elsewhere.

        Wietse

Reply via email to