In <4049FCB2(_dot_)1040903(_at_)ols(_dot_)es> David <david(_at_)ols(_dot_)es>
writes:
While testing HELO, as while testing the header from for a null sender,
it's ok to convert a softfail result to a fail result ?
SPF can not, of course, dictate how the owner of an MTA must run their
system. So, it is "ok" to do whatever you want to do.
The SPF spec, however, says:
Softfail (~): the message does not meet a domain's strict
definition of legitimacy, but the domain cannot confidently state
that the message is a forgery. MTAs SHOULD accept the message
but MAY subject it to a higher transaction cost, deeper scrutiny,
or an unfavourable score.
So, I would highly recommend against converting softfail into fail.
Doing so will cause publishers of SPF records to be reluctant to use
softfail. If they could confidently state that the message was a
forgery, they would have used fail, not softfail.
I, personally, would like to see something like the following added to
the SPF spec in order to make it clearer what softfail should do:
Softfail (~): [....]
MTAs SHOULD try to inform the recipient and/or sender of the
email that the SPF check did not pass and that the domain owner
is transitioning to a more strict standard. In the future, such
emails may be rejected and that the sender should take corrective
actions now.
For example, the MTA could modify the Subject: header or insert a
warning into the body of the email, similar to how many anti-spam
and anti-virus filters work. The MTA could also issue an SMTP
temporary failure code (4xx) the first time it receives the
particular email with a message that SPF check resulted in a
softfail.
-wayne