In message <3hfkyf2ty9zj...@spike.porcupine.org>, wie...@porcupine.org (Wietse Venema) wrote:
>> Either way, an automated whitelisting thing would be useful... >> >> ... but only if it works with Postfix. > >Amavisd has a pen pals feature that should work with smtpd_proxy_filter. >This requires a shared read/write database (MySQL, I believe). As I've mentioned, that seems a bit too heavyweight for my tastes. >In the case of a Postfix-only solution, whitelist updates could be >generated by mis-using smtp_generic_maps, relocated_maps, etc. (add >an address if it isn't already "known") Could you be induced to elaborate on the above comment, hopefully at length? I've never used either of those things you mentioned and have no idea how they might be profitably applied to this problem. >and they could be queried >with check_sender_access (look up a "known" address). This part, at least, I can easily grok. >Before lmdb support was added in Postfix 2.11, there was no good >way to safely share a persistent Postfix database between read-only >processes and read/write processes. Ah! Yes! For what I am talking about, that exact kind of sharing would quite obviously be most helpful. >So, it should be no surprise >that there at thius time no Postfix features that share a database >between read/write clients (smtp_generic_maps, relocated_maps, etc.) >and read-only clients (check_sender_access). Eh? I could not quite parse that. Regards, rfg P.S. I guess that the kind of thing I'm thinking of (an automated whitelisting system, perhaps even with per user data bases) could be done within an external policy daemon. But then again, it often seems to me that virtually every Swell New Idea I think of can likewise be implemented in an external Postfix policy daemon. I'm not sure if that is a tribute to the excellent flexibility of the whole policy daemon concept, or to the meager nature of most of my Swell Ideas. (1/2 :-)
