none
Received-SPF: TempError (xxx: error in processing during lookup of xxx: DNS timeout

    Question

  • I have two authoritative Domains (this.at and haberl.com) plus some External Relay domains.

    I use Sender-ID / SPF against header spoofing.

    SPF works fine with the External Relay domains.

    For Mails with a "MAIL FROM:"-header like something@this.at or something@haberl.com the SPF check fails with a TempError.

    Received-SPF: TempError (VIKING.corp.haberl.com: error in processing during lookup of something@this.at: DNS timeout)


    My DNS Servers seem to be fine and responding quickly (dns1.this.at and dns2.this.at - both Bind)

    The SPF records seem to be okay:
    this.at. IN TXT "v=spf1 mx a:mx-01.sil.at a:mx-05.sil.at a:excsvr.corp.haeusler.co.at  mx:haeusler.co.at mx:silagro.at mx:sil.at ip4:62.116.13.56/29 ip4:86.59.12.198 ip4:62.116.83.14 -all"

    haberl.com. IN TXT "v=spf1 mx include:this.at -all"

    And finally, the Test-Senderid Powershell cmdlet works fine!
    Test-SenderId -IPAddress 64.85.73.124 -PurportedResponsibleDomain this.at
    -> correctly results in "Fail/NotPermitted"
    Test-SenderId -IPAddress 62.116.13.56 -PurportedResponsibleDomain this.at
    -> correctly results in "Pass"

    I use Zonedit SMTP test utility to test this, and this shows that my server (exchange.this.at) accepts messages it should be rejecting, while another Server I administer (sbs.silagro.at) rejects them correctly with 550 5.7.1 Sender ID (PRA) Not Permitted

    Sunday, May 24, 2009 3:45 PM

Answers

  • Okay: There are two workarounds for this bug, but no solutions yet.

    1. Create a Primary (Forward Lookup) Zone on the internal, AD-integrated DNS Servers for the domains affected by the bug.

    Downside: You have to make all changes twice, once on the external, authoritative DNS servers, once on the internal, AD-integrated DNS Servers. A secondary zone may also do the trick, but I have not managed to successfully create a secondary of a Bind Server on a Windows DNS - Bind is set up to allow zone transfers, but Windows DNS logs event 6534 ("Failed transfer of zone haberl.com from DNS server at 192.168.10.18.  The DNS server at 192.168.10.18 aborted or failed to complete transfer of the zone.  Check the DNS server at 192.168.10.18 and ensure it is properly functioning and authoritative for zone haberl.com") But that's a whole different topic...

    2. Edit the SPF record and remove all MX machanisms that point back to the Exchange Server itself

    So for example if the exchange server is exchange.this.at then this would be a "bad" SPF record for this.at and cause the Temperror:
    "v=spf1 mx a:mx-01.sil.at a:mx-05.sil.at a:excsvr.corp.haeusler.co.at mx:haeusler.co.at mx:silagro.at mx:sil.at ip4:62.116.13.56/29 -all"
    The first mx  is "bad" because exchange.this.at is the primary MX for this.at  and the second one ("mx:silagro.at") is "bad" because exchange.this.at is the secondary mx (backup mail server) for silagro.at
    Note that you do not have to remove all mx machanisms in the SPF record, as long as they don't point back to your exchange server.

    Downside: The SPF record is less flexible and less readable that way, you may have to change it more often as IP addresses or hostnames change (rather than just updating the MX records)


    Why Exchange behaves the way it does, I don't know. Maybe it's a bug, maybe intended behaviour. (security?) Anyway, as long as I don't hear any official word on this from Microsoft I'll keep calling it a bug ;-)

    EDIT 2009/7/14: Here is some info from Microsoft PSS that indicates that the way MXQueries are done is to blame for this behaviour:

    "The MXRequest object is utilized to retrieve back data on an MXQuery. In the call to FindAliases, if ANY alias is the local IP of the calling client it will return a –1. This could be the query as a result of an A record, AAAA, MX. The MXRequest object is agnostic in regards to who made the call an d provides NO features to skip this behavior"

    • Marked as answer by habnix Friday, July 03, 2009 9:24 AM
    • Edited by habnix Tuesday, July 14, 2009 10:37 AM
    Friday, July 03, 2009 9:24 AM

All replies

  • I'm seeing this exact same thing.

    The Test-SenderId works fine but all emails coming from "our" domain end up with a tempfail DNSTimout

    Habnix, are you IPv6 enabled? We are and I wanted to rule that out as a issue.

    Anyone have any idea on how to debug this?

    Tuesday, May 26, 2009 4:37 PM
  • Hi,

    did you solve the problem?
    i have the same issue and i don't think it relies on a dns or spf failure?

    thanks

    julian
    Wednesday, May 27, 2009 8:39 AM
  • IPv6 was enabled - I disabled it and will let you know if that changed anything...
    Wednesday, May 27, 2009 11:35 PM
  • No, haven't solved the problem.
    I have a suspicion though - since it only happens for the authoritative domains - maybe those have to be on internal, AD-integrated DNS Servers- I have them on external Bind servers...

    If I don't find a solution soon, I will use one of my free Support Calls to Microsoft.
    Wednesday, May 27, 2009 11:36 PM
  • same thing on my side. My AD domain is corp.example.com and that dns zone is hosted off AD

    My real domain is example.com which is on bind 9.5 and thats where the SPF record resides.
    Thursday, May 28, 2009 1:12 AM
  • I'm having this same issue (I have another thread going on it).

    Anyone sitting behind a TMG/ISA firewall?

    Here is my thread on this-

    http://social.technet.microsoft.com/Forums/en-US/exchangesvrantivirusandantispam/thread/44a0e9b3-1c57-4111-aace-782aa3f77eb8
    Thursday, May 28, 2009 3:11 AM
  • Anyone have any more input on this issue?
    Tuesday, June 02, 2009 1:23 AM
  • I have the same issue too. External and Internal DNS records are correct - nslookup using TXT records come back okay as does the test tool.

    Thursday, June 04, 2009 9:49 AM
  • It seems that no one here in this thread, or over in the other thread at http://social.technet.microsoft.com/Forums/en-US/exchangesvrantivirusandantispam/thread/44a0e9b3-1c57-4111-aace-782aa3f77eb8?prof=required has yet found a solution.

    I will open a Support call, when I have more time...

    I think this is a bug.
    Since Test-SenderID works, and *all* other servers have absolutely no problem with these domains SPF records, only the Exchange Server that has these domains as authoritative domains.
    Thursday, June 04, 2009 10:09 AM
  • There is one thing we could try - Let's add the zones that have the domains spf records to the internal, AD-integrated DNS Servers - that wouldn't be a good permanent solution, but maybe a temporary workaround until the bug gets fixed.
    Thursday, June 04, 2009 10:11 AM
  • Anyone sitting behind a TMG/ISA firewall?
    No. Not me.
    Thursday, June 04, 2009 10:12 AM
  • Hi - do you mean have it on the internal DNS server? Yes, that is on already.

    Note - on my configuration the AD domain is .corp but the emails domain is .com.

    Should that matter?

    Thursday, June 04, 2009 12:23 PM
  • I have same problem. 
    When I executing the command on a server "Test-SenderID-IPAddress 95.58.34.53-server Exch01-PurportedResponsibleDomain mydomain.ru" I receive status=fail and FailReason=NotPermitted. All OK.
    However from my workstation (through the console installed locally), I receive TempError when executing the same command.

    My users have a lot of spam from spoffed addressed of my domain. And I cannot repair this error in any way.

    /Sorry for my English/
    Friday, June 26, 2009 5:34 AM
  • Hi,

    what happens if you start the Exchange Troubleshooting Assistant? Do you see something like this:

    DNS MX request for server firma.de
    DNS BeginResolve, MX firma.de, (query id:42148) 
    DNS EndResolve, MX firma.de, (query id:42148), status Success
    DNS MX record firma.de 10 : 100-mail.firma.de
    DNS MX record firma.de 10 : 102-mail.firma.de
    DNS Alias (IPv4) email1.firma.de : 19.16.22.21 
    DNS Alias (IPv4) email1.firma.de : 19.16.22.23 
    DNS Alias 19.16.22.23 matches a loopback address. Pruning records with preference >= 10 
    DNS MX request complete [InfoMxLoopback].
    Agent Result of CheckHost - Status: TempError ; FailReason: None; Explanation: ""

     

    Maybe one of the next 2 ideas could help you out (even if you do not experience the above Problem):

    1. change the spf record and do not include MX in   it... instead use the ipaddresses (or range) 
    2. Change permissions on receive connector: 
    Get-ReceiveConnector <CONNECTORNAME> | add-adpermission –User AnonymousUsers –ExtendedRights ms-Exch-Accept-Authoritative-Domain-Sender –Deny

     

    Tuesday, June 30, 2009 3:44 PM
  • Sorry, where can one download the Exchange Troubleshooting Assistant? All over the web one finds the download link http://www.microsoft.com/downloads/details.aspx?familyid=4BDC1D6B-DE34-4F1C-AEBA-FED1256CAF9A&displaylang=en - however this page just returns "We are sorry, the page you requested cannot be found."

    Or do you mean the Mail Flow Troubleshooter included in the Exchange Management Console's Toolbox? That wizard however poses questions none of which match my problem...
    Tuesday, June 30, 2009 11:10 PM
  • 1. change the spf record and do not include MX in   it... instead use the ipaddresses (or range) 
    2. Change permissions on receive connector: 
    Get-ReceiveConnector <CONNECTORNAME> | add-adpermission –User AnonymousUsers –ExtendedRights ms-Exch-Accept-Authoritative-Domain-Sender –Deny


    1. didn't change anything, mail still gets accepted with Temperror.
    2. probably is a valid solution against header spoofing, but it's a workaround, as it completely makes it impossible to send from any other ip outside of the Exchange organization (unencrypted SMTP). That's why I am using SPF. It doesn't solve the SPF problem.

    I am on the way to another workaround. Adding the zones to the internal DNS may work. Creating an Active Directory integrated zone on the internal DNS has resulted in a temporary success, however I am still testing if a secondary or stub zone will be sufficient.

    I think this is a bug or at least unexpected behaviour. I think what happens is that Hub/Edge Transport makes a DNS request for the TXT / SPF header for the respective Domain, gets as a result the name of the authoritative DNS servers, and treats that as a timeout, because it doesn't expect to get forwarded to an external dns.
    Wednesday, July 01, 2009 7:38 AM
  • I have seen this error on occasion. Did not find a solution either but ended up editing the SPF record to include only IP instead of mx.
    from: "v=spf1 mx -all"
    to: "v=spf1 ipv4:a.b.c.d/mask -all" or "v=spf1 ipv4:a.b.c.d ipv4:a.b.c.e -all"

    this seems to make senderID checks to work as expected.

    lasse at humandata dot se, http://anewmessagehasarrived.blogspot.com
    • Marked as answer by habnix Friday, July 03, 2009 7:31 AM
    • Unmarked as answer by habnix Friday, July 03, 2009 9:24 AM
    Thursday, July 02, 2009 4:19 AM
  • I have seen this error on occasion. Did not find a solution either but ended up editing the SPF record to include only IP instead of mx.
    from: "v=spf1 mx -all"
    to: "v=spf1 ipv4:a.b.c.d/mask -all" or "v=spf1 ipv4:a.b.c.d ipv4:a.b.c.e -all"

    this seems to make senderID checks to work as expected.

    lasse at humandata dot se, http://anewmessagehasarrived.blogspot.com

    I will try this workaround.- I think that Exchange must internally have a different timeout setting for spf checks/dns lookups of it's own domains i.e. "autoritative" domains vs. external domains, because the same SPF record works fine on other Exchange 2007 servers - just not on the one to which the domains belong.
    If we could figure out where this timeout setting can be changed, we could possibly fix this behaviour.
    Thursday, July 02, 2009 7:31 AM
  • I just found an interesting blog post from a Microsoft employee which indicates that Microsoft themselves have the same problem looking up their own SPF record:

    http://blogs.msdn.com/larryosterman/archive/2008/10/14/i-get-spam.aspx

    (XXX.microsoft.com: error in
    processing during lookup of customerservice@microsoft.com: DNS timeout)

    Looking at Microsoft's SPF record and the rest of the mail headers in the blog post, this should have triggered a SOFTFAIL and SCL should definately be higher than 0.

    I hope Microsoft improves the way SPF, Whitelisting (safelist-aggregation) and the SCL-rating / IMF(Content Filtering) work together in Exchange 2010. For example it would be nice to be able to set a rule that an SPF softfail will increase SCL by 3 points, a FAIL will increase it by 5 points or something like that and if and how SPF overrides whitelisting. but this is going off-topic...

    Thursday, July 02, 2009 8:30 AM
  • Sounds like what several have noted before..

    Your Firewall could be restricting a path. That could be from having a oriented core networking list, and that path is just simply being blocked. You might just need to tweak your firewall core networking properties. To fix that Time Out from that server.

    A network Time Out is usually from a unresponsive side. Having strict policies that require encryptions/fixed ports can lead to that problem.

    Friday, July 03, 2009 2:07 AM
  • No, don't do that IPv6 is a adapter that is needed to access the net.
    Friday, July 03, 2009 2:08 AM
  • Okay: There are two workarounds for this bug, but no solutions yet.

    1. Create a Primary (Forward Lookup) Zone on the internal, AD-integrated DNS Servers for the domains affected by the bug.

    Downside: You have to make all changes twice, once on the external, authoritative DNS servers, once on the internal, AD-integrated DNS Servers. A secondary zone may also do the trick, but I have not managed to successfully create a secondary of a Bind Server on a Windows DNS - Bind is set up to allow zone transfers, but Windows DNS logs event 6534 ("Failed transfer of zone haberl.com from DNS server at 192.168.10.18.  The DNS server at 192.168.10.18 aborted or failed to complete transfer of the zone.  Check the DNS server at 192.168.10.18 and ensure it is properly functioning and authoritative for zone haberl.com") But that's a whole different topic...

    2. Edit the SPF record and remove all MX machanisms that point back to the Exchange Server itself

    So for example if the exchange server is exchange.this.at then this would be a "bad" SPF record for this.at and cause the Temperror:
    "v=spf1 mx a:mx-01.sil.at a:mx-05.sil.at a:excsvr.corp.haeusler.co.at mx:haeusler.co.at mx:silagro.at mx:sil.at ip4:62.116.13.56/29 -all"
    The first mx  is "bad" because exchange.this.at is the primary MX for this.at  and the second one ("mx:silagro.at") is "bad" because exchange.this.at is the secondary mx (backup mail server) for silagro.at
    Note that you do not have to remove all mx machanisms in the SPF record, as long as they don't point back to your exchange server.

    Downside: The SPF record is less flexible and less readable that way, you may have to change it more often as IP addresses or hostnames change (rather than just updating the MX records)


    Why Exchange behaves the way it does, I don't know. Maybe it's a bug, maybe intended behaviour. (security?) Anyway, as long as I don't hear any official word on this from Microsoft I'll keep calling it a bug ;-)

    EDIT 2009/7/14: Here is some info from Microsoft PSS that indicates that the way MXQueries are done is to blame for this behaviour:

    "The MXRequest object is utilized to retrieve back data on an MXQuery. In the call to FindAliases, if ANY alias is the local IP of the calling client it will return a –1. This could be the query as a result of an A record, AAAA, MX. The MXRequest object is agnostic in regards to who made the call an d provides NO features to skip this behavior"

    • Marked as answer by habnix Friday, July 03, 2009 9:24 AM
    • Edited by habnix Tuesday, July 14, 2009 10:37 AM
    Friday, July 03, 2009 9:24 AM
  • During my troublshooting this problem,I used netmon and verified that DNS queries and responses did come back as they should do. And traddic was really fast, correct answers come back withimicroseconds.

    I agree that firewalls and other network equipment or restrictions in network traffic could be the cause, thats why I used network monitor to very traffic flow.


    lasse at humandata dot se, http://anewmessagehasarrived.blogspot.com
    Friday, July 03, 2009 2:24 PM
  • Any solutions found for this problem? I have same problem and it is urgent - my organization has E-mail adreses used by spamers as From adreses.
    Our Exchange 2007 treats these e-mails SPF status as TempError and therefore are not filtered out by Sender ID functionality. E-mails, sent from our domain by the same and only one server to outside recipients has PASS SPF records, that means DNS, SPF and other configuration is correct. 
    AT
    Sunday, February 14, 2010 3:16 PM
  • On Sun, 14-Feb-10 15:16:20 GMT, Armndscom wrote:

    >Any solutions found for this problem? I have same problem and it is urgent - my organization has E-mail adreses used by spamers as From adreses. Our Exchange 2007 treats these e-mails SPF status as TempError and therefore are not filtered out by Sender ID functionality. E-mails, sent from our domain by the same and only one server to outside recipients has PASS SPF records, that means DNS, SPF and other configuration is correct.
    >AT

    Does the machine performing the SenderID checking use the correct DNS
    (external vs. internal)?

    If the machine is having a problem accessing the appropriate DNS
    server you'll see softfail errors.

    I've never been a fan of using anything except ip4 addresses in the
    published SPF record. What's in yours?
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, February 14, 2010 6:55 PM