On 1/16/2015 1:36 PM, Eugene R wrote: > Hi all! > > I have a fairly standard set of smtpd restrictions implemented and > generally I’m very happy with them (very low spam traffic and no > headaches associated with SpamAssassin or DSPAM). > However, once in a while a legitimate message is rejected because > the other side has misconfigured HELO or DNS or the like. Of course, > they really should know better, but I am not always in position to > explain it to them, and their organization may be too complicated to > react properly. As the things stand, it sometimes creates problems > for us rather than for them =)
If you're rejecting good mail more than "rarely", you should reevaluate your restrictions. In particular, most built-in HELO checks are likely to reject legit mail, and not terribly effective against current spam bots. The "reject_unknown_client" is also likely to reject wanted mail. Use these with caution. > > I have an idea that seems promising, but from reading the docs I > feel that it is not currently possible. However, maybe it could be > included in the next version or someone could suggest another approach. > Basically the goal is to relax ‘hard’ reject restrictions and run > the mails that fail ‘soft’ restrictions through greylisting or other > filtering, without delaying good mail. Alternately, investigate using postscreen with the "after 220" tests enabled. > I am not sure it is wise to try implementing such complex logic in > Postfix configuration file. But I think it is easier and actually Sounds like you're trying to recreate deep inspection in postfix. Use SpamAssassin instead. -- Noel Jones > more powerful simply to expose the ‘fired’ restrictions to the > policy daemon and let it decide how to handle stuff. > > I imagine a syntax like this may be possible (just wild guess): > restrictions_mynetworks = false > restrictions_sasl_authenticated = false > restrictions_invalid_helo_hostname = false > restrictions_non_fqdn_helo_hostname = false > restrictions_unknown_helo_hostname = true > restrictions_rbl_client_zen_spamhaus_org = false > For performance reasons, probably only the restrictions that are > already evaluated at the point where check_policy_service is called > should be available. This would require something like > "defer_rbl_client zen.spamhaus.org" in main.cf to check the > restriction non-destructively. > > Best wishes > Eugene
