none
SPF record check issue

    Question

  • I received and email from one of our supplier and in the headers there were following lines:

    X-MS-Exchange-Organization-AuthAs: Anonymous
    X-MS-Exchange-Organization-PRD: softkey.ru
    X-MS-Exchange-Organization-SenderIdResult: PermError
    Received-SPF: PermError (exch-my.domain: domain of
     pivovarov007@softkey.ru used an invalid SPF mechanism)
    X-MS-Exchange-Organization-SCL: -1

    Message was sent from softkey.ru domain.

    I check TXT records for that domain and found out that there are two records:

    softkey.ru      text =
            "mailru-verification: 13ff5e46aa57c133"
    softkey.ru      text =
            "v=spf1 +ip4:194.85.111.16 +ip4:194.85.111.20 +a:mail.softkey.net. +a:mout.softkey.net. -all"

    I think the problem is that Exchange got "mailru-verification" record first, decided that it's malformed and stopped processing TXT.

    The questions are:

    1. That is "mailru-verification"?
    2. How to walk-around the issue with PermError?

    Thanks a lot.

    PS: RFC4408 (4.5) states that records had no "v=spf1" should be discarded; 4.6 states that PermError should be returned only for remaining record (that passed "v=spf1" check); am I correct? Does Exchange meet the standard? 

    • Edited by QRS Wednesday, July 04, 2012 6:40 AM
    Wednesday, July 04, 2012 6:35 AM

Answers

  • On Mon, 9 Jul 2012 05:24:33 +0000, QRS wrote:
     
    >
    >
    >We have the same result:
    >
    >
    >
    >>Test-SenderId -IPAddress 194.85.111.16 -PurportedResponsibleDomain softkey.ru Status : PermError FailReason : None Explanation :
    >
    >Thanks for your support.
     
    You might ask the admin at softkey.ru to publish a spfv2.0 record in
    addition to (not as a replacement for) the spf1 record they already
    have.
     
    The semantics in checking the PRA using spf1 and spf2.0 are different
    and whether or not they want the MFROM or PRA (or both) to apply is up
    to them.
    http://www.openspf.org/SPF_vs_Sender_ID
     
    If I were forced to guess, I'd say that the "+" in front of the "ip4"
    and "a" mechanisms are what migh be freaking out Exchange. But that's
    just a guess. Maybe it's the trailing "."?
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    • Marked as answer by QRS Monday, August 20, 2012 10:15 AM
    Monday, July 09, 2012 9:58 PM
  • Hi, Rich Matheisen.

    You are right: PermError is because of trailing dot.

    I tried tio create test zone and published TXT-record as I got it from softkey... Test-senderID returned PremError. Then I removed trailing dots and the result became Pass.

    So the question is: does Exchange 2010 conform to RFC (4408) and if it's worth to open ticket in MS support?

    • Marked as answer by QRS Monday, August 20, 2012 10:15 AM
    Tuesday, July 10, 2012 10:27 AM

All replies

  • On Wed, 4 Jul 2012 06:35:22 +0000, QRS wrote:
     
    >
    >
    >I received and email from one of our supplier and in the headers there were following lines:
    >
    >X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-PRD: softkey.ru X-MS-Exchange-Organization-SenderIdResult: PermError Received-SPF: PermError (exch-my.domain: domain of pivovarov007@softkey.ru used an invalid SPF mechanism) X-MS-Exchange-Organization-SCL: -1
    >
    >Message was sent from softkey.ru domain.
    >
    >I check TXT records for that domain and found out that there are two records:
    >
    >softkey.ru text = "mailru-verification: 13ff5e46aa57c133" softkey.ru text = "v=spf1 +ip4:194.85.111.16 +ip4:194.85.111.20 +a:mail.softkey.net. +a:mout.softkey.net. -all"
    >
    >I think the problem is that Exchange got "mailru-verification" record first, decided that it's malformed and stopped processing TXT.
     
    I doubt that. If that were true then none of Office 365 would work!
     
    >The questions are: 1. That is "mailru-verification"?
     
    Looks like they might be using or evaluating Office 365 or a reseller
    of Office 365, or some other service provider. The TXT record is a
    "proof" that they own the domain.
     
     
    >2. How to walk-around the issue with PermError?
     
    Set-SenderIdConfig -BypassedSenderDomains softkey.ru
     
    >Thanks a lot.
    >
    >PS: RFC4408 (4.5) states that records had no "v=spf1" should be discarded; 4.6 states that PermError should be returned only for remaining record (that passed "v=spf1" check); am I correct? Does Exchange meet the standard?
     
    It should.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, July 04, 2012 3:19 PM
  • Then why do I get PermError?
    Wednesday, July 04, 2012 4:54 PM
  • On Wed, 4 Jul 2012 16:54:35 +0000, QRS wrote:
     
    >Then why do I get PermError?
     
    As I said, "it should". I don't have access to the source code, nor do
    I (or you) know for sure the contents of TXT record that was
    evaluated.
     
    All we know is that the diagnosis was "invalid SPF mechanism" even
    though the domain's SPF record (at least the one retrieved from a
    NSLOOKUP) passed all the tests at
    http://www.kitterman.com/spf/validate.html.
     
    It may be a cached query result your transport server is using. You
    might try clearing the local resolver cache.
     
    If it continues to fail, and you're opposed to using the workaround I
    suggested, you can engage Microsoft. You didn't mention what release
    of Exchange you're using or what update rollup but it it's not
    up-to-date you should try update Exchange first.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, July 04, 2012 11:18 PM
  • We have single Exchange 2010.SP2.RU3, so it's up-to-date.

    I'll continue monitoring such messages arriving from the domain.

    Thursday, July 05, 2012 4:48 AM
  • Hi,

    PermError:  There is an unrecoverable error, such as an error in the record format. Accept None No Sender ID records are published in DNS for the domain.

    I recommend you contact administrator from your supplier to check the record again.


    Xiu Zhang

    TechNet Community Support

    Thursday, July 05, 2012 9:59 AM
  • On Thu, 5 Jul 2012 09:59:27 +0000, Xiu Zhang - MSFT wrote:
     
    >PermError: There is an unrecoverable error, such as an error in the record format. Accept None No Sender ID records are published in DNS for the domain.
    >
    >I recommend you contact administrator from your supplier to check the record again.
     
    You're missing the point, here.
     
    The published SPF record isn't in error but the Exchange server
    complains that it is. The SPF record passes the SPF checks at this
    URL:
     
    http://www.kitterman.com/spf/validate.html
     
    Perhaps you can explain why Exchange says there's an invalid mechanism
    in the TXT record?
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Thursday, July 05, 2012 9:36 PM
  • Hi,

    Base on my research, office365 may need two record in TXT record, one for SPF, one for domain verification. That is true.

    Besides, from http://www.mxtoolbox.com/SuperTool.aspx?action=mx%3asoftkey.ru#, IP 194.85.111.16 has been listed in one blacklist.


    Xiu Zhang

    TechNet Community Support

    Friday, July 06, 2012 5:21 AM
  • On Fri, 6 Jul 2012 05:21:21 +0000, Xiu Zhang - MSFT wrote:
     
    >Base on my research, office365 may need two record in TXT record, one for SPF, one for domain verification. That is true.
     
    Office 365 may, or may not, require any SPF data but even if it does
    that doesn't explain what Exchange thinks is wrong with that perfectly
    legitimate SPF data in the TXT record.
     
    >Besides, from http://www.mxtoolbox.com/SuperTool.aspx?action=mx%3asoftkey.ru#, IP 194.85.111.16 has been listed in one blacklist.
     
    .. . . nor does an IP address being listed in a DNSBL that registers
    the IP addresses of sites that accept an e-mail address and then send
    a NDR if it can't be delivered have anything to do with Exchange
    claiming that the SPF data contains an invalid mechanism.
     
    Here are the results of a test I just ran. Do you get the same
    results? If you do, you should submit an internal bug report or at
    least get an answer from one of the escalation folks or developers and
    let us know why this fails.
     
    [PS] C:\>test-senderid -IPAddress 194.85.111.16
    -PurportedResponsibleDomain softkey.ru
     
     
    RunspaceId : f5cdf21a-b1c8-4e9a-9294-d16dacbdb402
    Status : PermError
    FailReason : None
    Explanation :
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Saturday, July 07, 2012 1:01 AM
  • Hi,

    I have escalated the issue. Any update will post here.

    Thanks


    Xiu Zhang

    TechNet Community Support

    Monday, July 09, 2012 2:48 AM
  • We have the same result:

    >Test-SenderId -IPAddress 194.85.111.16 -PurportedResponsibleDomain softkey.ru
    Status      : PermError
    FailReason  : None
    Explanation : 

    Thanks for your support.

    Monday, July 09, 2012 5:24 AM
  • On Mon, 9 Jul 2012 05:24:33 +0000, QRS wrote:
     
    >
    >
    >We have the same result:
    >
    >
    >
    >>Test-SenderId -IPAddress 194.85.111.16 -PurportedResponsibleDomain softkey.ru Status : PermError FailReason : None Explanation :
    >
    >Thanks for your support.
     
    You might ask the admin at softkey.ru to publish a spfv2.0 record in
    addition to (not as a replacement for) the spf1 record they already
    have.
     
    The semantics in checking the PRA using spf1 and spf2.0 are different
    and whether or not they want the MFROM or PRA (or both) to apply is up
    to them.
    http://www.openspf.org/SPF_vs_Sender_ID
     
    If I were forced to guess, I'd say that the "+" in front of the "ip4"
    and "a" mechanisms are what migh be freaking out Exchange. But that's
    just a guess. Maybe it's the trailing "."?
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    • Marked as answer by QRS Monday, August 20, 2012 10:15 AM
    Monday, July 09, 2012 9:58 PM
  • Hi, Rich Matheisen.

    You are right: PermError is because of trailing dot.

    I tried tio create test zone and published TXT-record as I got it from softkey... Test-senderID returned PremError. Then I removed trailing dots and the result became Pass.

    So the question is: does Exchange 2010 conform to RFC (4408) and if it's worth to open ticket in MS support?

    • Marked as answer by QRS Monday, August 20, 2012 10:15 AM
    Tuesday, July 10, 2012 10:27 AM
  • On Tue, 10 Jul 2012 10:27:22 +0000, QRS wrote:
     
    >
    >
    >Hi, Rich Matheisen.
    >
    >You are right: PermError is because of trailing dot.
    >
    >I tried tio create test zone and published TXT-record as I got it from softkey... Test-senderID returned PremError. Then I removed trailing dots and the result became Pass.
    >
    >So the question is: does Exchange 2010 conform to RFC (4408) and if it's worth to open ticket in MS support?
     
    I suppose that depends on your interpretation of the RFC!
     
    4.8. Domain Specification
     
    Several of these mechanisms and modifiers have a <domain-spec>
    section. The <domain-spec> string is macro expanded (see Section
    8). The resulting string is the common presentation form of a
    fully-qualified DNS name: a series of labels separated by periods.
    This domain is called the <target-name> in the rest of this
    document.
     
    Not that is says "separated by periods". That, to me, doesn't mean
    that a trailing period is legitimate. It also says "the common
    presentation form of a fully-qualified DNS name" -- i don't know too
    many people that add a period at the end of FQDN unless they're making
    an explicit statement to a DNS query. So what's
    "common form" to mean?
     
    And a little later in the RFC you find:
     
    8.1. Macro Definitions
     
    Many mechanisms and modifiers perform macro expansion on part of
    the term.
     
    domain-spec = macro-string domain-end
    domain-end = ( "." toplabel [ "." ] ) / macro-expand
     
    toplabel = ( *alphanum ALPHA *alphanum ) /
    ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
    ; LDH rule plus additional TLD restrictions
    ; (see [RFC3696], Section 2)
     
     
    Here, the definition of "domain-end" includes a trailing period.
     
    But none of the examples (except the contents of a DNS zone where the
    trailing period is a requirement) show a trailing period.
     
    The telling portion of the RFC, however, is page 27 of the RFC in
    section 8.1:
     
    By default, strings are split on "." (dots). Note that no special
    treatment is given to leading, trailing, or consecutive delimiters,
    and so the list of parts may contain empty strings. Older
    implementations of SPF prohibit trailing dots in domain names, so
    trailing dots should not be published by domain owners, although
    they must be accepted by implementations conforming to this
    document. Macros may specify delimiter characters that are used
    instead of ".".
     
    That "...trailing dots should not be published by domain owners..."
    pretty much says it all for me.l
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, July 11, 2012 12:16 AM
  • SPF Record seems to okay to me for "softkey.ru"

    But RFC states that: http://www.ietf.org/rfc/rfc4408.txt

    3.1.  Publishing

       Domain owners wishing to be SPF compliant must publish SPF records
       for the hosts that are used in the "MAIL FROM" and "HELO" identities.
       The SPF records are placed in the DNS tree at the host name it
       pertains to, not a subdomain under it, such as is done with SRV
       records.  This is the same whether the TXT or SPF RR type (see
       Section 3.1.1) is used.

    Do you know what domain name is being sent by Sender after HELO or EHLO? Is it "softkey.ru"?

    Thanks,

    Padam


    Padamdeep Singh

    Thursday, August 02, 2012 7:11 AM
  • Hi,

    Did you get chance to find out answer of my question?


    Padamdeep Singh

    Saturday, August 18, 2012 3:42 PM
  • Unfortunately we don't have constant communication with the domain and we have no logs for smtp-receive.

    So, I think the answer is found (dots were the reason).

    Thanks a lot!

    Monday, August 20, 2012 10:15 AM