[Mimedefang] Adding headers during filter_sender() and 2.68 Beta 1 issue.

[-]

--- On Sun, 5/24/09, David F. Skoll <dfs at roaringpenguin.com> wrote:
> Date: Sunday, May 24, 2009, 4:17 PM - wrote:
> 
> > 1) Please permit filter_sender() to add a header - for SPF check results.
> 
> Milter does not support that, which is why MIMEDefang doesn't.

I am quite aware that the milter interface accepts header changes only during the EOM phase.  However, my hack still registers the change (changes are deferred until EOM).  I certainly did not expect the code to read the "RESULTS" file after filter_sender() returns and try to set them there, otherwise, I would have written a hack that tries to do that (which is impossible as the milter interface would reject it).
 
> > Because filter_sender() is the appropriate place to generate an
> > "Authentication-Results" header (or the now depreciated
> > "Received-SPF" header) to place the results of the check into the
> > message.  There is no way to carry this information from
> > filter_sender() into filter_begin() (or later)
> 
> Yes, there is.  $Sender is available, as is $RelayAddress.

OK, but one then has to REPEAT the test at filter_begin() as the SPF test results are lost.  The alternative is to defer the test to filter_begin(), but that loses the ability to reject forged messages at MAIL FROM, and thus avoid the bandwidth-costly DATA phase (important for large messages) and a potential dictionary attack of the "RCPT TO" phase.  Deferring from filter_sender() to filter_begin() is DANGEROUS for that reason.
 
> > I hacked "insert_header", but perhaps "add_header" should have the
> > same changes.
> 
> I do not think this hack is necessary.  Do your SPF checks in filter_begin.

That's clearly TOO LATE.

> Or do them in filter_sender and record the information for later; see
> the MAINTAINING STATE section of the mimedefang-filter man
> page.

Which tells me that one CANNOT maintain a variable as filter_sender and filter_begin are in different states within the program (or even different sub-processes).

I see no difference between using some random file in the $CWD directory as opposed to writing directly to the "RESULTS" file (as the routines do), so why not directly record into the "RESULTS" file the new header in the format expected per the mimedefang-protocol manual page.  Basically, that's what my hack does - except it uses the existing structure and provided subroutine to do it.  The only difference is that with some random file, I have to read it back in, process what I've read (which may be trivial), and then have it written back out (this time, into the RESULTS file).  Why do things twice?  Let us do it once and forget about it.  So what if the milter interface doesn't process this until the EOM phase?  That's actually a benefit.

That's why my hack changed the opening of the RESULTS file from write-truncate to write-append during the scan phase.  This way, it can exist from the earlier states (filter_sender and filter_recipient) and still have actions recorded then carry through (of which the only action that makes sense is creating new headers or header instances).

To limit the calls that create headers to filter_begin() and after is nonsensical.  Obviously, this change is for headers of a TRACE nature.  If you want, this may be restricted to calls of action_insert_header() where the index is zero (prepend), and omit action_add_header() from the change.