Viktor Dukhovni:
> On Sun, Jan 12, 2020 at 11:09:12AM -0500, Wietse Venema wrote:
> 
> > > Glad that you propose to implement this way. However things will
> > > be more complicated : should new smtpd_reply_filter_maps and
> > > smtpd_reject_footer_maps be executed in sequence ? or be exclusive ?
> > 
> > I think that for outgoing data, the filter should go last.
> 
> My instinct was to suggest that the filter goes first, and then the
> footer gets added, but usability rather depends on how the pending
> multi-line response is presented to the filter.  If it is easy for the
> filter to match and selectively retain the footer, then you're probably
> right and the filter should have the final say.  If, on the other hand,
> it becomes hard to selectively retain the footer, then I'd be tempted to
> add it last.
> 
> The "\c" trick no longer works once the footer is combined with the
> original text, because (at least in principle) by that point the
> original text could have a verbatim "\c" in it, that is not intended to
> become a line-break.

\c in a reply filter? I don't see any need for any special
sequences other than ${number} which is already supported.

> If the footer can be assumed to be a single line, then the line breaks
> could take the form of LF characters in the input string to the filter,
> and the footer could matched via:
> 
>     /<whatever>.*\n(.*)\z/
> or
>     /(<whatever>).*(^.*)\z/m  REPLACE ...

The sole purpose if xxx_filter is to replace text, so the REPLACE
command would not be needed.

But yeah, the Postfix SMTP server's handling of multiline responses
is not organized, whether they come from Milters or elsewhere.

- The Postfix SMTP server's EHLO handler will output a multiline
  response one line at a time.

- All code that handles Milter responses will output a multiline
  response as a string with embedded \r\n sequences because that
  is what output from Milters looks like.

- The cleanup daemon propagates multiline Milter responses to the
  Postfix SMTP server, and the Postfix SMTP server preserves those
  embedded \r\n sequences.

- The Postfix SMTP server's session history reporter does not split
  text with embedded \r\n sequences into separate records. That is
  not entirely clean. Multiline responses should probably be split
  before being appended one line at a time to the session history.

So we need a canonical multiline representation before we can even
think about filtering SMTP server replies. It's probably going to
be embedded \r\n sequences, with smtpd_chat_reply() implementing
the filter-then-footer or footer-then-filter, and then splitting
the multiline text into separate lines, before doing output and
appending to the session history.

Which is better, filter-then-footer or footer-then-filter? I would
let that depend on the usability for users, not the implementation
effort for Postfix developers. We may well have to do filter-then-footer.

        Wietse

Reply via email to