Rocky, It seems that I am still having a few issues with the whitelist on the SpamSnake. I have a sender trying to get through to a recipient behind the spamsnake but the DNS lookup for the SPF portion of the filter is failing: Code: Apr 13 11:43:17 curve postfix/smtpd[1161]: NOQUEUE: reject: RCPT from unknown[99.88.95.18]: 450 4.7.16 <[email protected]>: Recipient address rejected: SPF-Result=mail.senderdomain.com: 'SERVFAIL' error on DNS 'SPF' lookup of 'mail.senderdomain.com'; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.senderdomain.com> It appears that a DNS lookup for type "txt" is being done on the "helo" hostname. Since there is no SPF record for "mail.senderdomain.com", SPF lookup is having a cow. So I added the sender's IP 99.88.95.18 to my Barawa whitelist (from "Lists -> Add to List, added 99.88.95.0,) but the spamsnake is still trying to process this SPF Here is a log excerpt from my local BIND9 server showing the lookup: Code: Apr 13 13:06:57 vector named[554]: client 192.168.66.13#43386: query: mail.senderdomain.com IN SPF + (192.168.66.14) Do I need to do something else to eliminate the SPF processing on whitelisted IP addresses? Respectfully, Dave, Deconn Technical Services.
Rocky, Thanks for the reply. Code: whitelist_policy = check_client_access mysql:/etc/postfix/mysql-global_whitelist.cf, check_sender_access mysql:/etc/postfix/mysql-global_whitelist.cf Code: root@curve:/etc/postfix# cat mysql-global_whitelist.cf #mysql-global_whitelist user = baruwa password = XXXXXX dbname = baruwa query = select concat('PERMIT') 'action' from lists where from_address='%s' AND list_type='1'; hosts = 127.0.0.1 Dave.
Hey, Try adding the following to your helo_restrictions and let me know what happens. smtpd_helo_restrictions = permit_sasl_authenticated,permit_mynetworks, check_helo_access mysql:/etc/postfix/mysql-global_whitelist.cf, permit This will lookup the global whitelist for your domain entries and should bypass helo checks. Remember to reload postfix after you've made the changes. Rocky
Rocky, I have made the change and will report back with results when they are available. Do you have any idea why the SPF module is requesting a DNS lookup for the "helo" instead of the domain for the MAIL FROM: ? Is this really the root cause here? The sender's domain in this incident does not have a TXT or a SPF record in thier zone, so the SPF should just ignore checks in the first place. Best, Dave. Deconn Technical Services
Rocky, I am still getting Code: Apr 15 16:11:55 curve postfix/smtpd[15610]: NOQUEUE: reject: RCPT from unknown[99.88.95.18]: 450 4.7.1 <[email protected]>: Recipient address rejected: SPF-Result=mail.senderdomain.com: 'SERVFAIL' error on DNS 'SPF' lookup of 'mail.senderdomain.com'; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.senderdomain.com> Any other suggestions? Gratefully, Dave. Deconn Technical Services
Update: I added a space after "check_helo_access" Earlier today I just pasted what you typed into my main.cf and postfix hickuped on me, so I put a "," after check_helo_access. After examining the syntax of the other entries in the main.cf, I realized that maybe it was supposed to be a space. Reloaded postfix and am waiting for my "tail -f" to give me results from the offending sender. Dave. Deconn Technical Services
Code: Apr 15 17:29:07 curve postfix/policy-spf[19419]: : Policy action=DEFER_IF_PERMIT SPF-Result=mail.senderdomain.com: 'SERVFAIL' error on DNS 'SPF' lookup of 'mail.senderdomain.com' Apr 15 17:29:07 curve postfix/smtpd[15802]: NOQUEUE: reject: RCPT from unknown[99.88.95.18]: 450 4.7.1 <[email protected]>: Recipient address rejected: SPF-Result=mail.senderdomain.com: 'SERVFAIL' error on DNS 'SPF' lookup of 'mail.senderdomain.com'; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.senderdomain.com> No go on the suggested change to the main.cf Dave. Deconn Technical Services
Yes, sorry, after thinking about it, the helo restriction would make no sense since spf checks would still be done. Please undo the changes made. Please add both the domain and ip to your baruwa whitelist and check it out. It should completely bypass checks and go straight through to postfix for delivery.
Done. As you predicted: Code: Apr 15 21:22:36 curve postfix/smtpd[2530]: warning: 99.88.95.18: address not listed for hostname mail.senderdomain.com Apr 15 21:22:36 curve postfix/cleanup[10216]: 40A2B5E68D: hold: header Received: from mail.senderdomain.com (unknown [99.88.95.18])??by curve.domainservicehost.com (Postfix) with ESMTP id 40A2B5E68D??for <[email protected]>; Fri, 15 Apr 2011 21:22:36 -0 from unknown[99.88.95.18]; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.senderdomain.com> Apr 15 21:22:38 curve postfix/qmgr[15279]: 349705E6C8: from=<[email protected]>, size=12154, nrcpt=1 (queue active) May I ask a related question? It appears to me that the SPF lookup of the "helo" hostname is a problem here. Why would the SPF lookup the helo? Why not a DNS TXT/SPF lookup of the MAIL FROM:? In this particular case, the sender's email is coming from a hosted account on godaddy, and the mail.senderdomain resolves to a CNAME, and that CNAME resolves to another CNAME, which finally resolves to an A record. Code: root@vector:~# dig @ns40.domaincontrol.com mail.senderdomain.com TXT ; <<>> DiG 9.7.0-P1 <<>> @ns40.domaincontrol.com mail.senderdomain.com TXT ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26012 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;mail.senderdomain.com. IN TXT ;; ANSWER SECTION: mail.senderdomain.com. 3600 IN CNAME pop.secureserver.net. ;; AUTHORITY SECTION: senderdomain.com. 3600 IN NS ns39.domaincontrol.com. senderdomain.com. 3600 IN NS ns40.domaincontrol.com. ;; Query time: 47 msec ;; SERVER: 208.109.255.20#53(208.109.255.20) ;; WHEN: Fri Apr 15 21:34:56 2011 ;; MSG SIZE rcvd: 126 I get a fully recursed response which clearly shows there is no TXT record for this domain (which is actually a hostname.) However, if I do the same dig without the "@" (using my locally configured name server) I get a SRVFAIL: Code: root@vector:~# dig mail.senderdomain.com TXT ; <<>> DiG 9.7.0-P1 <<>> mail.senderdomain.com TXT ;; global options: +cmd ;; connection timed out; no servers could be reached So firstly, thank you YET AGAIN for helping me resolve a problem... however, it seems to me there may still be some type of inconsistency with how SPF parses the SMTP conversation for processing the DNS query. Dave. Deconn Technical Services
I have done some more digging. I'll disclose the domain name here so you (or anyone researching this thread) can test for yourself. The "senderdomain" is harmonyescrow.com I have also researched more on OpenSPF.org and found that they always intended for the HELO lookup to be an integral part of the architecture. From what I understand, the HELO DNS lookup is used if the reverse IP can not be looked up (but I could be wrong here.) So I searched all over and found web-based NSLOOKUP services and did a "TXT" type query for "mail.harmonyescrow.com" (which is the "helo" hostname). They all came back "time out" or "SRVFAIL" which is the same behavior I get on my locally configured Bind9 server. I'll do more offline research on this, but I wonder if this is either an issue with BIND and how it processes the lookup or if it's an issue with GoDaddy's name servers and how they process the queries or if it somehow has to do with how GoDaddy sets up their hosted email systems. If I query other domains (mail.someotherdomain.com) for "TXT" or "SPF" type records that I know are hosted on GoDaddy they come back fine without a timeout. Seems like it's only this particular domain i'm having issues with. Either way, I refer back to one of my questions: Should postfix temp fail (450) the session just because of this SRVFAIL? Thanks for commenting. Dave. Deconn Technical Services
Hey, The rejections are based on DNS not being properly setup for the domain which causes SPF to fail. SPF gives postfix the instructions on what to do and how to handle the mail if it fails. SPF is forcing HELO checks by default and is mandatory. If you don't want it to reject on fail, you can try commenting out the entire # Reject on HELO fail section. I haven't tried it to see if it works though. Rocky
