Possible issue reporting Fail string in sendmail reject message

[gwharton]

Hi, Sendmail 8.15.2 on Ubunti 17.10

In the logs I see

Nov 3 04:07:19 ws1-fra smf-spf[19861]: SPF fail: ip=107.174.52.151, fqdn=[107.174.52.151], helo=so578sy.com, from=[email protected]
Nov 3 04:07:19 ws1-fra sm-mta[23903]: vA347GJM023903: Milter: from=[email protected], reject=550 5.7.1 Command rejected

Any ideas why sendmail is not passing back the proper return string.

I saw this comment in spf-milter.pl source code

            # Need to escape unprotected % characters in spf_smtp_comment,
            # or sendmail will use the default "Command rejected" message instead.
            # Noted by Paul Howarth

Could it be something to do with that?

[jcbf]

I'm a Postfix user and don't have any recent experience with sendmail. I'll have a closer look.

[gwharton]

Let me do some debug at my end and narrow down why sendmail doesnt like the response from the milter.

[jcbf]

I found a bug where the response may not be very correct.

550 4.7.23 Rejected, look at http://www.openspf.org/[email protected]&ip=107.174.52.151&receiver=mta.name.local

The 550 and 4.7.23 may be causing the "Command rejected".

[gwharton]

yes, I've just come to the same conclusion. I was about to prepare a pull request with the required modifications if that helps. I'm just waiting for some spam to arrive for a live test under sendmail.

The 4.7.23 is used in two locations for 550 returns.

[jcbf]

That code needs the change but I was unable to reproduce.
Looking more closely the sm-mta milter is the one sending the "Commnad reject" message not the smf-spf.

[gwharton]

Sendmail documentation for function smfi_setreply() states

The Milter library, except for the single situation described in the next section, will silently
enforce a failure to match the SMTP code to the type of rejection you specified. But note
that if you specify a 5yz code and temporarily fail (temp-fail) the message, your smfi_
setreply() setting will be ignored. Similarly, if you specify 4yz and reject the message, your
custom reply will also be ignored.

I'm not saying the 4.7.23/5.7.23 fix doesn't need applying, as it does, but this doesnt fix my problem with sendmail. It looks like Sendmail does not allow you to set a 450/4.x.x response and then Reject the message with SMFIS_REJECT

The whole Softfail config setting when set to true causes the module to SMFIS_REJECT the message with a 440 code, which is invalid according to the above. This is the real reason for Sendmail replacing the error message with a 550/5.7.1

Tested on Sendmail 8.15.2

Config SoftFail set true (note the extra three lines of debug added to show the return codes and reject string from the milter). Note, sendmail doesnt like this combo, and just flat out 550's it.

Nov 3 16:35:47 ws1-fra smf-spf[18607]: SPF fail: ip=115.79.53.249, fqdn=[115.79.53.249], helo=[115.79.53.249], from=[email protected]
Nov 3 16:35:47 ws1-fra smf-spf[18607]: 450
Nov 3 16:35:47 ws1-fra smf-spf[18607]: 4.7.23
Nov 3 16:35:47 ws1-fra smf-spf[18607]: Rejected, look at http://www.openspf.org/[email protected]&ip=115.79.53.249&receiver=ip1-uk.metalworkingfluids.net
Nov 3 16:35:47 ws1-fra sm-mta[24985]: vA3GZj21024985: Milter: from=[email protected], reject=550 5.7.1 Command rejected

So, looks like the following 2 issues exist

• Setting SoftFail to on, is not compatible with sendmail as 450/4.7.23/SMFIS_REJECT is not a valid combination.
• Setting SoftFail to off, results in 550/4.7.23/SMFIS_REJECT combination being set. Should be 550/5.7.23/SMFIS_REJECT

I think for the time being, I will just make sure SoftFail is set to off in the config and apply the 4.7.23/5.7.23 patch.

In slower time, the whole SOFTFAIL implementation needs a re-look.

[gwharton]

Testing with SoftFail set to off and the 4.7.23/5.7.23 patch applied.

Nov 3 17:38:17 ws1-fra smf-spf[25610]: SPF fail: ip=181.48.177.164, fqdn=[181.48.177.164], helo=[181.48.177.164], from=[email protected]
Nov 3 17:38:17 ws1-fra smf-spf[25610]: 550
Nov 3 17:38:17 ws1-fra smf-spf[25610]: 5.7.23
Nov 3 17:38:17 ws1-fra smf-spf[25610]: Rejected, look at http://www.openspf.org/[email protected]&ip=181.48.177.164&receiver=ip1-uk.metalworkingfluids.net
Nov 3 17:38:17 ws1-fra sm-mta[30399]: vA3HcFIM030399: Milter: from=[email protected], reject=550 5.7.23 Rejected, look at http://www.openspf.org/[email protected]&ip=181.48.177.164&receiver=ip1-uk.metalworkingfluids.net

[gwharton]

I have no idea why I had SoftFail set to on as thats not the behaviour I wanted in the firstplace.

I see that if SPF results in a softfail scenareo the message is accepted and tagged (correct behaviour according to the spec) and actually has nothing to do with the Softfail config setting.

I don't actually understand why the Softfail feature is there in the first place.

It should either
SMFIS_SOFTFAIL, accepting the message and tagging it
SMFIS_TEMPFAIL, with a 450/4.7.23 response
SMFIS_REJECT, with a 550/5.7.23 response

Right, I've had enough of SPF this evening, wine awaits.

[jcbf]

I'm not being able to reproduce the error. Later tonight, I'll create a branch with all the environment used.

[jcbf]

Just released v2.3.1 that has all the changes.
If it fixes your error, please close this issues.

[gwharton]

All looks good to me. Been running on live server and monitoring. Seems to be handling tempfails much better, and rejects fails properly under sendmail when SoftFail is not set.

Closing issue.