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.
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 ...
Alternatively, if the response that precedes the footer is never
multi-line (perhaps no longer valid once we have milters and/or proxy
filters), then one might match all but the first line.
Otherwise, matching the footer in a filter can become rather tricky.
--
Viktor.
