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

- kd6lvw at yahoo.com
Tue May 26 17:25:32 EDT 2009


--- On Tue, 5/26/09, Martin Blapp <mbr at freebsd.org> wrote:
> >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).
> 
> Is this also true for smfi_addrcpt() and smfi_delrcpt() ? If it is allowed
> at this stage, I'm missing the support to delete recipients in the post data
> stage (mf_data) and any support for mf_data() in mimedefang.pl.
> 
> This could be very useful if you still like to be able to  allow SMTP probes
> for SRS-modified recipient adresses in the per-recipient check, but delete
> any bad recipient adresses (with failing or missing BATV/SRS tags) in the
> post data stage, without having to save the whole message data to disk.
> 
> Valid SMTP-probe ...
> 
> >>> MAIL From:<>
> <<< 250 2.1.0 <>... Sender ok
> >>> RCPT To:<admin at mydomain.ch>
> <<< 250 2.1.5 <admin at mydomain.ch>... Recipient ok
> >>> RSET
> <<< 250 2.0.0 Reset state
> >>> QUIT
> <<< 221 2.0.0 mydomain.ch closing connection

Interesting idea.  However, I have this to say:
1)  Probes back to the originator ("Callbacks") are discouraged as abusive, and there are even banlists for systems which do that.  Probes forward to a "downstream MTA" seem to be OK for the moment, but there are other ways to do this.  Only a backup MX server needs the "full range" of destination mailboxes; other forwarders generally deal with a single mailbox - and thus don't really need to call ahead.
2)  For del_rcpt() as a standalone, I don't see the merit.  To exclude a recipient, simply reject that recipient with a 5xx response.  In combination with add_rcpt() to "change" a recipient, shouldn't this be done as either an alias or a forward, not in the milter?
3)  For add_rcpt() as a standalone, perhaps as a "carbon copy" operation, but there's still alias expansion.  I also question whether it's appropriate to add a recipient BEFORE having collected all of them.  filter_begin() or later seems the appropriate place to add recipients not specified in the message.
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).

The initial suggestion to allow (certain trace) headers to be added for filter_sender() (and perhaps filter_recipient(); author's choice) follows certain RFCs (e.g. 4408 - SPF, or draft "I-D.kucherawy-sender-auth-header", now published as RFC 5451) where there are trace headers that are supposed to be prepended to messages where it makes sense to not have to handle the data more than once in order to generate the header.

One issue implied but not stated:  Should the ability to change the envelope sender be permitted?  I say NOT at filter_sender() because there is no need to do so.  In filter_recipient(), we may want to if we somehow know that we're forwarding the message (so we could implement SRS or something similar).  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.

Now, I do see potential merit in being able to set the quarantine status of the ENTIRE message dependent on the sender or a recipient, especially if a sender is on a watchlist or a recipient being a spamtrap.  So, maybe calls to action_sm_quarantine() should be permitted from filter_sender() or filter_recipient().  Note that it is not possible to quarantine parts of a message as no parts have yet been received, so this does NOT apply to action_quarantine().

Note:  The command for the "RESULTS" file to cause a quarantining of the entire message appears to be omitted from the manual page "mimedefang-protocol".



More information about the MIMEDefang mailing list