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 2015/08/07 14:12:41 UTC

[Bug 7233] New: make dkim test permerror

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

            Bug ID: 7233
           Summary: make dkim test permerror
           Product: Spamassassin
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Rules
          Assignee: dev@spamassassin.apache.org
          Reporter: me@junc.eu

Authentication-Results:example.org; dkim=permerror (bad message/signature
format)

imho a small bug in opendkim aswell it did miss the space after : but only
happens on permerror in opendkim6

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

[Bug 7233] make dkim test permerror

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7233

Kevin A. McGrail <km...@pccc.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kmcgrail@pccc.com

--- Comment #1 from Kevin A. McGrail <km...@pccc.com> ---
I'm sorry but I don't follow.  Can you give some insight what the problem is
and how we can recreate it?  And is there a fix or a workaround you see?

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

[Bug 7233] make dkim test permerror

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7233

--- Comment #8 from Benny Pedersen <me...@junc.eu> ---
it was just that i showed a diffrence in opendkim and mail::dkim

and that i think permerror could be used in a good meta rule

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

[Bug 7233] make dkim test permerror

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7233

--- Comment #5 from Mark Martinec <Ma...@ijs.si> ---
The DKIM plugin (when validating) does not enforce that a DKIM
signature must also sign a From header field, although the RFC
does require a signer to include a From header field in a signature.

If a DKIM signature does include a From header field in a signature
(the 'h' tag) but the From is missing or has been changed in transit,
the signature won't be considered valid, same as with any other
message modification.

There is no requirement that a domain name of the author address
in a From header field must match the signing domain (the 'd' tag)
of a signature: if it does match, the signature is called
author domain signature, otherwise it is a third-party signature.
Same goes for an incomplete author address (i.e. a missing domain),
which can only be treated as a third-party signature.

What is a value of a valid signature (author-domain signature
_or_ a 3rd party signature) solely depends on a reputation of
a signing domain. A reputable signing domain can be used for
whitelisting or adding some negative score points. A DKIM signature
from a non-reputable domain is not worth anything: as far as the
score goes it is equivalent to a broken (non-valid) or absent
signature.

Apart from informational/debugging purposes, I see no point in
providing extra rules just to distinguish a valid DKIM-signed
third-party signature with a missing domain in a From header field
from any other valid third-party signature (likely it won't be
valid anyway). Similarly there is no point in distinguishing
an invalid (or missing) signature based on the presence or
absence of a sensible address in a From header field.

It all boils down to a reputation of a signing domain: if a
seemingly reputable signing domain is willing to sign such mail
with an incomplete author address, perhaps its reputation is
overrated.

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

[Bug 7233] make dkim test permerror

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7233

Benny Pedersen <me...@junc.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |me@junc.eu

--- Comment #2 from Benny Pedersen <me...@junc.eu> ---
Mail::SpamAssassin::Plugin::DKIM does not imho check dkim permerror, the header
show if it did it could be DKIM_PERMERROR in sa

to test it, create a email with

To: "me" <fo...@example.org>
From: "bar"
subject: testing

this will not be valid in opendkim since it misses sender from
<ba...@example.net> or another mail addr

and current rule set in spamassassin does nothing there :/

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

[Bug 7233] make dkim test permerror

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7233

--- Comment #3 from Mark Martinec <Ma...@ijs.si> ---
No idea what this is all about.

The DKIM plugin neither reads nor creates the Authentication-Results
header field.

If the Mail::DKIM module would encounter some error, it would
be logged (at least in the debug log) and the DKIM_VALID rule
would _not_ be triggered.  So a permerror is essentially
indistinguishable from a broken or missing signature, which
is by design.

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

[Bug 7233] make dkim test permerror

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7233

--- Comment #4 from Benny Pedersen <me...@junc.eu> ---
1: +1
2: i did not say DKIM should add AR header, i just wanted to note that DKIM did
not show PERMERROR as a fail in spamassassin
3: how does spamassassin tag this case ?

is it needed to make a 

meta DKIM_INVALID_FROM (!DKIM_VALID)

?

and possible add dsn test, i have shown a simple rule to trigger opendkim, but
its not working in spamassassin or does it ?

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

[Bug 7233] make dkim test permerror

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7233

Dave Jones <da...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davej@apache.org

--- Comment #6 from Dave Jones <da...@apache.org> ---
The presence of DKIM_VALID_AU means the email is authentic from the From:
author's domain.  The sender could be whitelisted with a "whitelist_auth" entry
if the domain is considered trustworthy.  That's all.  It can not be used any
more than that to determine ham or spam -- just the authentication of the email
was from who it said it was From:.

The absence of DKIM_VALID_AU does not mean anything anything other than it was
not authentic.  It could have been spoofed if the email is trying to appear to
be from a major brand or company that it's not.

There is no reason to need a DKIM_PERMERROR since the only DKIM fact that is
useful is DKIM_VALID_AU for a positive assertion.  Negative assertions mean
nothing.

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

[Bug 7233] make dkim test permerror

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7233

Bill Cole <sa...@billmail.scconsult.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sa-bugz-20080315@billmail.s
                   |                            |cconsult.com
         Resolution|---                         |WONTFIX

--- Comment #7 from Bill Cole <sa...@billmail.scconsult.com> ---
I agree with Mark and Dave. 

This is effectively a new rule request that is inconsistent with the conscious
design of the underlying tech (DKIM) and appears to be trivial to implement
locally without code changes. Without evidence of the proposed rule actually
being useful, there's no sound rationale for adding it to the default set or
leaving this ticket open.

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