From: Grant Taylor
Date: 2007-02-06 12:30:21 -0500
Subject: Re: Per user settings
More information..: http://www.milter.info/#Support
Anthony Howe wrote:
> Hmm. I don't think it does what you expect or both our memories have
> gone funny since that request was commissioned. The problem with this
> option is that some MTA or MUA will abort a message if any recipient is
> rejected, not all continue to deliver with those that were accepted.
I too have heard about such stupidity / brokenness in MUAs and even some
MTAs. One would think that an MTA would play better than an MUA, but
such is not the case.
> I certainly can look into something similar, but the typical behaviour
> for B/W listing has been if any recipient is white listed, then its
> white listed for all recipients, which typically means skipping the
> milter's behaviour. I'll have to refresh my memory as how this option
> works in milter-spamc.
I have also seen such situations where the (not specifically a
SnertSoft) milter will use a default setting verses any single users
setting(s) if there are multiple recipients.
> In a content filter, one possibility is to record those that B/W list
> and after you have a filter result following the final dot, if it would
> be rejected as spam, then remove those recipients that are not white
> listed from the deliver list. The problem with this method is that the
> client MTA gets no feedback as to which recipients were refused, which
> would mean the milter has to generate an DSN to the sender.
Um, no, that is NOT GOOD AT ALL! You will break so many automated
things by doing that. I think a better approach would be to have
multiple servers / daemons. Have the first (in series) MTA run sender
verification so that you have a more likely reliable place to bounce
DSNs to. Then have the second MTA configured to accept single
recipients only such that you could ensure that individual settings are
used in filtering there. Yes, there is duplication in filtering, but I
don't see much of a way around it. I suppose you could alter / augment
filters to put a signed header that would include session information
that the subsequent iteration through the filter could read and
extrapolate with out having to reprocess the entire message.
Something that would be better would be to use LMTP between the first
and second MTA. This way, the filtering could (some how) be applied per
recipient and per recipient reply codes could be returned to the first
MTA. This would allow the message to be transfered one time between
MTAs thus alleviating transfer duplication and / or resource
consumption. However, I don't know if Sendmail will accept LMTP as
input or not, however I suspect it would be trivial to add it.
Grant. . . .
Copyright 2009, 2012 by SnertSoft. All rights reserved.