You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2017/08/06 19:14:37 UTC

[Bug 7446] DKIM-Signature increases URI count

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7446

Karsten Bräckelmann <gu...@rudersport.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|DKIM-Signature increases    |DKIM-Signature increases
                   |URI cont                    |URI count

--- Comment #10 from Karsten Bräckelmann <gu...@rudersport.de> ---
For reference, see bug 6700 (disabling this behavior) and bug 7087 (adding it
back in as option parse_dkim_uris) and their discussions.


(In reply to Alex from comment #0)
> It appears that when DKIM is involved, any URI in the DKIM-Signature causes
> __HAS_ANY_URI to always hit, increasing the total count of URIs listed in
> the email. This impacts me by increasing by one my (__KAM_COUNT_URIS >= 1)
> rules...

Please note that this initial report is not correct as stated. The observed
behavior is not due to the existence of DKIM headers, but those headers with
the parse_dkim_uris option enabled.

While potentially confusing, the behavior is exactly as documented: Enabling
parse_dkim_uris results in DKIM headers being "parsed for URIs to process
alongside URIs found in the body with some rules and moduels", see M::SA::Conf.

It is also worth pointing out, that this option is enabled as part of
third-party rules and configuration, and effects a custom rule. Generally
outside this bugzilla's scope.


There is one side to this though, that definitely could be considered a SA
issue: The stock __HAS_ANY_URI sub-rule is affected by this behavior. While
adding the domain found in the DKIM header for uri tests by this option is
intended and exactly as documented, it most likely is *not* intended that uri
rule to fire on the DKIM header domain without any other domain in a textual
part.

The work around mentioned by RW in comment 6 and duplicate bug 7440 should fix
this immediate issue: Domains parsed from textual parts are added to the uri
lists in multiple variants, including with and without a protocol. The domain
parsed from the DKIM header is bare only, no protocol prepended.

To fix this stock sub-rule to hit as intended regardless of parse_dkim_uris
option, I'm +1 on the proposed change by RW:

  uri __HAS_ANY_URI  /^\w+:\/\//

That is, make that test check for a protocol (possibly prepended by SA),
instead of using /./ to check for its mere existence.

-- 
You are receiving this mail because:
You are the assignee for the bug.