DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=dicomexpress.com; s=google;
        h=date:from:to:message-id:subject:mime-version;
        bh=7c++UH2JFU8XRxiQfAK/XRsTnNpDIn6Hck84MOZPfCo=;
        b=CSUiNh7YfNj2cRMB/MKxKIfaLvGFJic44SJdKJUD2Qy8XArlAFkSk8dALOI5aqy8E3
         LZAr+FCgqmktPLb02Ea8hP8L3KHHtzihVjgVwv4OVr0to+RK0NIAMjacv8zVlm+y+xZI
         LzYUxLWuBKHRZN8iBr+6IBTZh8mGRo/eZyLpU=


Jul 24 19:54:47.738 [16657] dbg: rules: ran uri rule __KAM_COUNT_URIS ======> got hit: "dicomexpress.com"
Jul 24 19:54:47.738 [16657] dbg: rules: ran uri rule __KAM_COUNT_URIS ======> got hit: "http://thesamschwartz.com/ONBP132044/"

Hi Alex, So do any other headers increase the URI_COUNT?  My guess is no as they shouldn't.  It's an interesting bug.

No, I don't believe other headers affect this. I've tested it with SPF.

As a temporary work-around, I've created separate rules that adjust plus/minus one for with/without the existence of __DKIM_EXISTS.

I seem to remember this being discussed about a week back, and there being a note on the original bugzilla ticket that added URI capture from the DKIM header recognizing this behavior.

I remember suggesting maybe there needs to be a segregated URI list for the ones captured from DKIM so they are used in URIBL lookups but are not visible to URI rules...

Yes, this was from back around Jun 20th, but I forgot to file a bug report then.

There was also something relating to parse_dkim_uris=1 that is specified in the KAM.cf rules that causes this to happen. Users without this setting (or the KAM.cf file) are not impacted by this.

As I pointed out in the user list, it's easy to tell them apart as domains in the body are prepended with  http://, domains from DKIM signatures aren't.

http://foo,example.org
bar.example.net

sa see them all as url

why is it a problem dkim domain is part of url testing ?

also headers is url tested, i dont see this as a bug, but a hidded feature

we could make the dkim if valid au say use this info on same premiss as url skipped if dkim is local whitelisted not just whitelisted

imho change it will open a can of worms without any benefit to have it working better then it already does

One caveat, with  an HTML link without a protocol you get both versions
so for <a href="example.com">test</a>

__ALL_URI ======> got hit: "http://example.com"
__ALL_URI ======> got hit: "example.com"

with plain  "\nexample.com" it's simply

__ALL_URI ======> got hit: "http://example.com"

This  doesn't affect the detection of a link though.

*** Bug 7440 has been marked as a duplicate of this bug. ***

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.

(In reply to documentation quote from comment #10)
> alongside URIs found in the body with some rules and moduels", see
> M::SA::Conf.

Typo in the documentation fixed: revision 1804259 trunk and revision 1804260 stable branch.

(In reply to Karsten Bräckelmann from comment #10)

> 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.

+1

Created attachment 5557 [details]
rule fix

Rule fix as suggested by RW.
As a second step __HAS_ANY_URI and __DOS_HAS_ANY_URI could be merged in a single rule fixing meta rules accordingly.

Committed in r1826769.