The Perfect SpamSnake - Ubuntu Jeos 10.10 - SPF DNS Error

Discussion in 'HOWTO-Related Questions' started by mintydave, Apr 13, 2011.

  1. mintydave

    mintydave New Member

    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.
     
    Last edited: Apr 13, 2011
  2. Rocky

    Rocky New Member

    What do you have in your main.cf for whitelist_policy?
     
  3. mintydave

    mintydave New Member

    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.
     
  4. Rocky

    Rocky New Member

    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
     
  5. mintydave

    mintydave New Member

    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
     
  6. mintydave

    mintydave New Member

    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
     
  7. mintydave

    mintydave New Member

    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
     
  8. mintydave

    mintydave New Member



    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
     
  9. Rocky

    Rocky New Member

    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.
     
  10. mintydave

    mintydave New Member

    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
     
  11. mintydave

    mintydave New Member

    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
     
  12. Rocky

    Rocky New Member

    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
     

Share This Page