[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