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=127.0.0.2*weight1, dnswl2.example.com=127.0.0.1*weight2 > dnsbl3.example.com=127.0.0.3*weight3, dnsbl4.example.com=127.0.0.1*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. -- Stan
