policyd-weight 0.1.14 Beta 17

policyd-weight allows you to score DNSBLs (RBL/RHSBL), HELO, MAIL FROM and client IP addresses before any queuing is done. It allows you to REJECT messages which have a score higher than allowed, providing improved blocking of spam and virus mails. policyd-weight caches the most frequent client/sender combinations (SPAM as well as HAM) to reduce the number of DNS queries.
After the first three SMTP commands (HELO, MAIL FROM: and RCPT TO:) the clients IP address, corresponding DNS records (A, MX and PTR) and multiple DNSBLs can be checked, verified and scored. If the client tries to forge headers or supplies non-existent DNS or bogus data the spam score will increase, even more so if the client is listed in one or more DNSBLs.
Such mails can be rejected while in transfer, before the mail body is received by your MTA. This is different from SpamAssassin or amavisd-new: for filtering or scoring with these programs, mail needs to be accepted/queued, CPU-time is wasted, bandwidth is used, and mail cannot be rejected without creating a bounce.
Postfix built-in checks can be too tough for poorly configured clients: one hit, and the mail gets rejected. policyd-weight is designed to be fair (DynDNS MX users get through if their MTA is setup properly, even if their ISP net is DUL-listed), because its decision whether to reject or accept a mail is based on multiple factors.
Of course you should still have SpamAssassin and Clamav running (especially if you are responsible for a companys security and data). But these programs will have a lot less to do and thus decrease the need for bandwidth and CPU cycles.
Also you might not need greylisting (which would make sense for users that receive a lot of new spam, though), SPF, extraordinary whitelists or SQL and other DBs anymore.

Main features:>
- Scored evaluation of RBL/RHSBL results
- Scored evaluation of DNS relationships and correctness of HELO and MAIL FROM arguments (MX, A, subdomains) in respect to Client DNS records (PTR, A, subnets) - weighted by RBL scores. It tries as best as possible to find a DNS wise verified relationship between (Client IP, Hostname) and (HELO or FROM), this travells down to subdomains and subnets
- SPAM Cache for "user@senderdomain.tld-123.123.123.123" hashes (precedence of HAM cache)
- HAM Cache for "senderdomain.tld-123.123.123.123" hashes
- Multirecipient aware
- May be used for "all but some specific user" or "only for specific user" via postfix restriction classes. The same goes for clients.
- Own RBL Lookup routine for very fast and cheap DNS RBL/RHSBL lookups
- Configuration file for own adjustments
- Absolutely no database dependencies. No MySQL either ;-)!
- Fast, optimized perl - designed for large scale environments
- In contrast to postfix reject_rbl_client, reject_rhsbl_client, reject_unknown_* and reject_non_fqdn_helo, one hit must not mean that the client will be rejected
- Bandwidth savings: You are able to reject based on "weights" before the DATA content will be received
- CPU savings: Postfix and after queue content filter have less to do as they operate on full content; policyd-weight doesnt - as it fires in very early at RCPT TO stage
- Other resource savings: queue resources, disc access resources, quarantine space

Enhancements:
- Using File::Spec->canonpath for normalization (trailing slashes): Check ownership of real directories to avoid race attacks for symlinks.