https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6490

           Summary: Mail::SpamAssassin::Plugin::SPF - Two enhancement
                    issues
           Product: Spamassassin
           Version: 3.3.1
          Platform: PC
        OS/Version: Windows ME
            Status: NEW
          Severity: trivial
          Priority: P5
         Component: Plugins
        AssignedTo: [email protected]
        ReportedBy: [email protected]


1)  There are three conditions that the SPF.pm module does not set any internal
state for:  NONE, TEMPERROR, and PERMERROR.  Although I agree that for the two
error conditions no relevant information is returnable, the NONE condition
(meaning that an SPF lookup based on the sender or HELO parameter failed to
return any record to check) is a condition that some people may wish to score
[toward spaminess] on.  Therefore, it should be added.

Ruleset - file:  25_spf.cf

header    SPF_NONE    eval:check_for_spf_none()
describe  SPF_NONE    SPF: sender SPF record missing
score     SPF_NONE    0.0 0.0 0.0 0.0                (default it to 0)

This is the one case I can think of where a rule's score should default to zero
and let it be overridden in a local.cf file should people want to use it.

Of course, in the SPF.pm module, add the function (similar to all the other
functions) and the internal variable.  Similarly for the
check_for_spf_helo_none() version.

=========================
2) I also note that the SPF module may (if permitted by the configuration) look
at a prior result stored in the message itself.  However, the current system
only looks for RFC 4408 "Received-SPF" headers and NOT the newer RFC 5451
"Authentication-Results" header.  As long as we're scanning the headers for a
previously-determined result, shouldn't we look for BOTH types?

The regex match to look for is probably (something like) this, similar to the
existing comparison at line 321 ("if ($hdr =~ /^received-spf:/i) {"):

  if ($hdr =~ /^Authentication-Results:.*;\s*SPF=([^;]*)(;.*)?$/i) { ...

Parsing results:
$1 => The SPF result (pass, fail, neutral, none, etc..., from RFC 4408) and its
other information (optionally including literals for "smtp.mailfrom=_domain_"
or "smtp.helo=_domain_", plus CWFS comments regarding the SPF result).  We need
to set the $result and $identity variables based on this string.

$2 => Information from other tests (to be ignored/discarded by this module)

Note that RFC 5451 dictates an additional result option:  "Policy".  This
result means that the true SPF result is being overridden by some other
information and thus should be ignored (but not the same as "NONE" or
"NEUTRAL").  RFC 5451 also suggests "hardfail" instead of RFC 4408's "fail" -
but I disregard such as an error in the RFC proposal.

The ".*" before the semicolon should contain the reporting hostname and
optionally another semicolon and other test results that we discard.  We also
discard everything after a trailing semicolon following the SPF result as for
other, non-SPF tests.  Recall that RFC 5451 permits the reporting of multiple
tests on a single header as well as each separate test reported on its own A-R
header line.

Much of the existing code, with a little massaging for the different REGEX
matches, following SPF.pm line 321 may be reused for this.

-- 
Configure bugmail: 
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to