3 Replies Latest reply: Apr 1, 2014 10:24 AM by dukebox RSS

    SPF 'softfail' treated as 'fail' when 'Include' mecanism present


      Have a case opened with support (and bug traking) about the way EWS manages the SPF checks.


      SPF results can be 'None', 'Neutral' 'Pass', 'Fail', 'SoftFail', 'TempError' or 'PermError'.


      When EWS executes the SPF check there is an issue with the way the result is interpreted when the 'include' mecanism is present in the SPF record that is being validated.


      Here is a concrete example:


      Incoming SMTP connection: smtp.domain1.com (

      Mail From: john@domain1.com



      The SPF record for domain1.com is:


      IN TXT "v=spf1 include:domain2.com ~all"


      This SPF tells EWS to check 'domain2.com' for a match on the incoming IP address.


      if we check the SPF record for 'domain2.com':


      IN TXT "v=spf1 ip4: -all"


      In this specific case, the incoming SMTP ip address does not match any mechanisms in 'domain2.com' and only matches '~all' from the SPF of 'domain1.com'


      The result of this check should be "SoftFail".


      According to RFC4408:

      A "SoftFail" result should be treated as somewhere between a "Fail"

      and a "Neutral".  The domain believes the host is not authorized but

      is not willing to make that strong of a statement.  Receiving

      software SHOULD NOT reject the message based solely on this result,

      but MAY subject the message to closer scrutiny than normal.


      Let's say you have configured your Sender-Authentication policies to check SPF and to "reject/close" the connection when an incoming connection fails the SPF check. In the example above, EWS will 'reject/close' the connection while in fact it should give the choice of taking a different action (like 'tarpit' for example).


      As it stands now, when EWS (and this is also true for MEG7, confirmed by McAfee support) encounters a 'softfail' result, it reacts the same way as a 'fail' result. A 'softfail' should give the choice of taking a different action than 'pass/neutral' or 'fail'. For example, you might want to "greylist' the connection (return an smtp code 451) and then let the SMTP re-connect a second time and then accept the e-mail.


      I was wondering if anybody else ever noticed this beavior? I've opened a case with support and seeing how little priority this bugtrack is getting I am assuming not a lot of McAfee clients are using SPF checks the way we are using it...