>Are the files to block subscriber networks done yet?
no, I haven't had to time to put them al together. >Can we get a copy? yes, when it's done >Also can you supply us with the exact command for: >"if PTR unknown, then reject_unknown_hostname" smtpd_restriction_classes = unkn_ptr_and_unkn_helo.class ... you have to postmap unkn_ptr_and_unkn_helo.class into a .db /etc/postfix/unkn_ptr_and_unkn_helo.class contains one line: #if PTR unknown, switch into this class unknown unkn_ptr_and_unkn_helo.class # If PTR unknown, then reject_unknown_(helo)_hostname unkn_ptr_and_unkn_helo.class = reject_non_fqdn_hostname, (if it ain't a fqdn, it ain't knowable) reject_unknown_hostname, (not knowable in DNS) reject_unverified_sender, warn_if_reject check_helo_access pcre:/etc/postfix/helo_world.regexp, permit you can see above that you might want to make a specific helo_world_upuh.regexp file so messages accepted via this class get logged distinctly 4tuple_upuh, where "upuh" is "unk ptr and ukn hostname", so you can see if crap is sneaking in through this class. In smtpd_recipient_restrictions, it's a little tricky where you insert this line: warn_if_reject check_client_access hash:/etc/postfix/unkn_ptr_and_unkn_helo.class, for why, see below. what happens: 1. smtpd restrictions proceed normally until a msg has PTR unknown, then it gets tossed into unkn_ptr_and_unkn_helo.class (and doesn't came back!! to the rest of smtpd restrictions) 2. ... where the above "little" list of restrictions in unkn_ptr_and_unkn_helo.class is applied. so the action is: if ptr unknown, (you're in deep doodoo, one more error (that makes 2) you're gone) reject non FQDN helo hostname reject helo hostname not in DNS but!!! what if it gets past the above, what else do before accepting the msg? reject_unverifeid_sender 4tuple accept the msg So where you put this class in your list of restrictions depends on how you have ordered your restrictions. in stunning ascii art: normal smtpd classless restrictions . . . match a restriction class, take a new path >>> unkn_ptr_and_unkn_helo.class else some restrictions, . permit . permit ... so you can see you have 2 pathways to accept the message. The unknown PTRs get shunted out of the main flow and don't the "else..... permit" restrictions. eg, you certainly want to do unkn_ptr_and_unkn_helo.class after you have done in the main branch done: reject_invalid_hostname helo_hostnames.regexp (IPs as helo) You can use this exmaples as a template to set up for other restriction_classs, where a criteria match routes the msg into a class for special treatment, giving you the famous "multi-criteria" checking. eg, above: if criterion of no PTR, then route into a special class and handling. Another one I do in the advanced config: if helo is (microosft|yahoo|msn|hotmail|etc), the PTR must be one of those. is sender@ is (microsoft|yahoo|msn|hotmail|etc), then PTR must be one of those Len
