Mark Martinec wrote: > The Postfix policy protocol support is complete, but there is almost > no semantics in-there. Similarly the support for Postfix tcp lookup > maps is there. I did both mostly as a proof-of-concept, because > most of the code is common with AM.PDP protocol support and was > not difficult to add what was missing. > > See sub process_tcp_lookup_request for tcp lookups support > (policy bank on the interface must specify protocol=>'TCP-LOOKUP'), > > and process_policy_request with postfix_policy, which can (syntactically) > handle both the AM.PDP as well as the Postfix policy delegation support. > The Postfix request is distinguished from AM.PDP request by the > presence of the attribute: request=smtpd_access_policy' > > The problem with both is that these are pre-queue requests, > with all the problems this drags along: amavisd would need to > handle numerous sessions comparable to the number of smtpd services, > which is normally by an order of magnitude larger than post-queue > content filtering sessions. Heavy-weight calls to SA are mostly > out of the question for any setup larger than a home or small office > site. ...Which is the reason why I never pushed this beyond > proof-of-concept. Experimentation may be interesting nevertheless.
Mark, many thanks for this. I'd not thought about the problems with performance. However it is precisely because this is prequeue that I am interested. I'm keen to avoid accepting email which is not going to be delivered. I'd rather the server which has the message is responsible for bouncing than us creating back-scatter or silently failing to deliver. Also ultimately I'd like users to be able to chose who they do and don't accept email from. Just because something is blacklisted doesn't necessarily mean it's spam (or that all users wish this address to be blacklisted). There can be personal reasons for blacklisting or commercial emailers that aren't diligent with unsubscription requests. As you probably know Horde (via sam) and a few others apps beside support writing to an amavis preference database so this seemed like a good place for a solution which might work for others too. I've talked to the postfix-users list about per-user mysql lookups and they don't seem keen, which I can understand (see http://archives.neohapsis.com/archives/postfix/2007-01/0992.html) I've also talked to the horde project don't seem keen to write a policy daemon (see http://bugs.horde.org/ticket/?id=4904) and I can understand that too. I'm also sure the world can do without me writing a sloppy coded and poorly performing policy daemon (and adding another to the growing list). I assume when you say there are no semantics you mean it's going to be hard to get AM.PDP to give the answers to Postfix I am looking for? Do you have any other thoughts as to a solution that would work for me and for others or maybe I should just let this go for now. Regards, Rob ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
