[milters] Archive

Lists Index Date Thread Search

Article: 1421
From: Grant Taylor
Date: 2007-02-06 12:30:21 -0500
Subject: Re: Per user settings

Removal...........: milters-request@milter.info?subject=remove
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. . . .

Lists Index Date Thread Search