--- On Tue, 5/26/09, Martin Blapp <[email protected]> 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:<[email protected]>
> <<< 250 2.1.5 <[email protected]>... 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".
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
