Date: 2007-03-09 17:55:46 -0500
Subject: Re: Feedback desired about black / white listing support.
More information..: http://www.milter.info/#Support
Anthony Howe wrote:
>>> c) Related to b) revisit what RHS values are supported? Should RELAY
>>> white list or be ignored?
> By definition in sendmail's cf/README, RELAY is equal to OK plus relay
> and so is currently treated as white list entry. Steve's argument is
> that in many cases you want to relay, but still filter a message before=
> relaying it. Because of the current B/W design, many sites would end up=
> passing mail marked as RELAY without any filtering applied. So in order=
> to get the correct behaviour you have to add a lot of milter-NAME-TYPE:=
> SKIP tags or similar. When you have one milter, this is not too
> burdensome, but as you add more milters, maintenance of the access.db
> becomes an issue.
That was the point of saying "is the most general form of whitelist", I w=
thinking of Sendmail's rules, not milter specific rules.
So for me the idea is if I use a "top level" rule, then it should apply a=
if I want higher detail (more control), then I use a milter specific rule=
On the other hand, I understand the issue about keeping other policies, w=
not a problem if I use a 2-level approach like I do with MailScanner: eve=
n if I
allow relaying MailScanner does scan/detect viruses and spam. But if I o=
milters (and also sendmail's use of RBLs falls into this) then things get=
the only clean way to deal with this is setting milter priorities, which =
exist so far, and would let me specify at least if a milter should apply =
> I suppose the real question concerning my milters is what is the most
> common default _expectation_ of how RELAY should be applied w.r.t. milt=
> white list and pass through (current & technically literal design)
> filter before relay
If the milter could reject the message, then what good is white list?
In other words, the expectation is to be able to control the milter, no
surprises. I don't use milters to reject spam/viruses (I quarantine them=
MS) so I haven't thought much about this, but it seems to me that if I pu=
in a rule I have to understand the consequences (and of course in the cas=
virus/spam I still want the message to be tagged even if I relay) which i=
what the milter can do and what it cannot do.
>>> e) Consider new tags to provide delay-check like behaviour with combo=
>>> lookups, ie. Connect:From:, Connect:Auth:, Connect:To:, From:To: I ha=
> Yes, but at the sake of more access.db lookups which could be a
> performance issues on high volume sites. Does the feature warrant the
> extra overhead?
No, it does not. Clearly we have coped without this feature since I have=
seen it implemented or requested too much. MailScanner has it, and that'=
I use it, and very seldom at that.
Copyright 2009, 2012 by SnertSoft. All rights reserved.