Wietse Venema put forth on 8/25/2010 4:27 PM:
> Noel Jones:
>> As I see it, there are two complementary paths we can take 
>> with DNS whitelists, each with a slightly different purpose.
>> While these are both useful, neither depends on the other, so 
>> postfix can implement either or both.
> I'll read the entire proposal later.
> Would this notation work:
>   dnswl1.example.com=*weight1, dnswl2.example.com=*weight2
>   dnsbl3.example.com=*weight3, dnsbl4.example.com=*weight4

IMO this really depends on the "role" you expect postscreen to play.  If
it is expected that all Postfix implementations are going to be using
postscreen as in integral important feature, not just the big operations
with hundreds of thousands or millions of connections per day, then I
would suggest this user configuration interface is too complicated.
There will be OPs who simply want to use a single dns whitelist without
any kind of scoring.  They will want an "OK" on any 127.0.x.x response.

> It would reduce the number of config parameters.

Always a plus, but in this case it may sacrifice (ease of) usability for
some OPs.

> Do we want to allow mixing DNSWLs and DNSBLs in one list?

If you're implementing a pure scoring system this might work.  I don't
know what the math should be though for calculating an "OK" threshold.

> Currently, postscreen does not look up the client hostname, that
> is something that can be added later when there is time.

Won't all of these dns lookups slow postscreen down?  I thought it was
supposed to be a really high throughput low latency check/allow/dump
filter mainly to shield smtpd processes from the bot load.  What's the
average dnsxl response time?  50ms?  100ms?  Won't this terribly
decrease the throughput of postscreen?

If postscreen is doing dnsxl lookups merely to decide if a connection
gets past postscreen, and then we do the same dnsbl lookup in smtpd to
decide accept/reject because postscreen doesn't pass the result to
smtpd, it makes me wonder why we're doing two such lookups for each
connect that is OK'd by postscreen.

Again, I'm not so sure that doing dnswl lookups with postscreen is
productive.  Most hosts listed on dnswls are going to pass postscreen's
normal checks anyway.  By doing this it seems we're merely adding
processing latency to a latency sensitive code path, and we're not
really gaining anything by doing so.  These dnswl lookups will have to
be duplicated in smtpd anyway to get the desired whitelisting result OPs
expect from a dnswl positive return.


Reply via email to