https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7909
Bill Cole <billcole@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
CC| |billcole@apache.org
--- Comment #1 from Bill Cole <billcole@apache.org> ---
This is almost certainly a local configuration error. Absent any details on the
sending domain and relevant SA configuration parameters, it cannot be
considered a bug in SA.
SPF testing by SpamAssassin is done based on the trusted_networks,
internal_networks, and msa_networks settings, which are used to determine which
Received headers to trust as non-forged and which to treat as internal
handoffs. In this case, the final Received header is being treated as internal,
while an internal handoff within Microsoft is being treated as trusted but
non-internal. If you include Microsoft's external IPv4 space in your
"internal_networks" setting g, you probably should also include their public
internal-use IPv6 space to avoid this issue.
You can probably get help on how to configure the *_networks parameters for
your specific circumstances on the SpamAssassin Users mailing list, where
others with vendor relationships with Microsoft and analogous providers can
explain their solutions.
Also:
1. 2603:10a6:20b:284::13 is not "bogus" it is a perfectly valid IPv6 address in
the public 2603:1000::/24 network allocated by ARIN to Microsoft.
2. v3.4.2 is severely outdated and has known functionality and security bugs
which have been fixed in later versions. Please update to 3.4.6 if possible, or
to a packaged version which has critical updates back-ported (e.g the package
maintained by RedHat for RHEL and CentOS)
3. You appear to have locally assigned a score of 5.0 to SPF_FAIL, which is
4.99 points higher than the default score. This will reliably cause non-spam to
get scored as spam, because legitimate domain owners are less diligent about
getting their SPF records correct than are owners of domains used primarily to
spam.
This report is not actionable as a bug due to redactions and lack of config
info, The reported issue appears to be the result of configuration errors, it
is reported for any obsolete version of SpamAssassin, and the
misclassification is the result of a dangerous local score override.
--
You are receiving this mail because:
You are the assignee for the bug.
Bill Cole <billcole@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
CC| |billcole@apache.org
--- Comment #1 from Bill Cole <billcole@apache.org> ---
This is almost certainly a local configuration error. Absent any details on the
sending domain and relevant SA configuration parameters, it cannot be
considered a bug in SA.
SPF testing by SpamAssassin is done based on the trusted_networks,
internal_networks, and msa_networks settings, which are used to determine which
Received headers to trust as non-forged and which to treat as internal
handoffs. In this case, the final Received header is being treated as internal,
while an internal handoff within Microsoft is being treated as trusted but
non-internal. If you include Microsoft's external IPv4 space in your
"internal_networks" setting g, you probably should also include their public
internal-use IPv6 space to avoid this issue.
You can probably get help on how to configure the *_networks parameters for
your specific circumstances on the SpamAssassin Users mailing list, where
others with vendor relationships with Microsoft and analogous providers can
explain their solutions.
Also:
1. 2603:10a6:20b:284::13 is not "bogus" it is a perfectly valid IPv6 address in
the public 2603:1000::/24 network allocated by ARIN to Microsoft.
2. v3.4.2 is severely outdated and has known functionality and security bugs
which have been fixed in later versions. Please update to 3.4.6 if possible, or
to a packaged version which has critical updates back-ported (e.g the package
maintained by RedHat for RHEL and CentOS)
3. You appear to have locally assigned a score of 5.0 to SPF_FAIL, which is
4.99 points higher than the default score. This will reliably cause non-spam to
get scored as spam, because legitimate domain owners are less diligent about
getting their SPF records correct than are owners of domains used primarily to
spam.
This report is not actionable as a bug due to redactions and lack of config
info, The reported issue appears to be the result of configuration errors, it
is reported for any obsolete version of SpamAssassin, and the
misclassification is the result of a dangerous local score override.
--
You are receiving this mail because:
You are the assignee for the bug.