[Mimedefang] Adding headers during filter sender() and 2.68 Beta 1 issue.
-
kd6lvw at yahoo.com
Tue May 26 19:37:39 EDT 2009
--- On Tue, 5/26/09, Martin Blapp <mbr at freebsd.org> wrote:
> >4) To allow these functions in filter_recipient() may cause the addition
> to occur for EACH recipient. That appears inappropriate. In contrast,
> adding a "TRACE" header indicating some sort of "forward looking" status per
> recipient >may be appropriate (although no RFC or standard I'm aware of
> requires such at this time).
>
> In mf_data() all recipients are already collected. mf_data() is the callback that
> happens immediatly after the data command is issued, but before any content
> is
> submitted to the filter. IMHO filter_begin() should be connected to mf_data,
> and not the the stage later. This would safe a lot of IO.
Can't do it. Such is a limitation of the MILTER interface. These changes can only be submitted during the xxfi_eom() call from the interface. That call corresponds to the filter_begin() through filter_end() phase. That's why they're all deferred and collected into the "RESULTS" file, which is processed after filter_end().
> >However, I don't favor SRS. Cooperating forwarding arrangements should
> recognize the valid forwarder (whitelist or >SMTP AUTH) and bypass (only)
> the SPF check, making SRS unnecessary. SPF only works at the front-end
> receiving >MTA. If one cannot trust one's forwarders, maybe that
> relationship shouldn't exist. Therefore, I don't see any >need.
>
> SRS, ok, that may not be needed. But BATV is definitly a good thing to have,
> but maybe in an adaptive way if there are too many bounces in some timeframe.
More information about the MIMEDefang
mailing list