[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-devel
Subject:    [Bug 7785] New: DKIM fails with spamass-milter (CRLF problems)
From:       bugzilla-daemon () spamassassin ! apache ! org
Date:       2020-01-18 7:10:13
Message-ID: bug-7785-26 () https ! bz ! apache ! org/SpamAssassin/
[Download RAW message or body]

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

            Bug ID: 7785
           Summary: DKIM fails with spamass-milter (CRLF problems)
           Product: Spamassassin
           Version: 3.4.3
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: Plugins
          Assignee: dev@spamassassin.apache.org
          Reporter: apache@hege.li
  Target Milestone: Undefined

Referring to users-list discussion "Spamassassin always says DKIM_INVALID"

It seems spamass-milter removes CR from wrapped headers when passing CRLF data
to SpamAssassin:

2006-03-23 16:41  Dan Nelson <dnelson@allantgroup.com>
        * spamass-milter.cpp:
        Spamassassin 3.1.1 now emits headers with CRLF if the incoming message
        has CRLFs.  Make sure that we strip the CR from wrapped headers when we
        parse the returned message.

My "optimization" committed in 3.4.3 breaks Mail::DKIM verification, since it
expects all lines ending in CRLF?

http://svn.apache.org/viewvc/spamassassin/branches/3.4/lib/Mail/SpamAssassin/Plugin/DKIM.pm?diff_format=h&r1=1864870&r2=1864869&pathrev=1864870


Snippet of passed data to Mail::DKIM (CR is shown as ^M):

DKIM-Filter: OpenDKIM Filter v2.10.3 mail.bristolweb.net 96BD3320531^M
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkcheck.co.uk;
        s=mail; t=1579001879;
        bh=CxJX/YLOdkbC5W0v1up9JeX5a5WItUgcQd7vfnwSG5I=;
        h=To:From:Subject:Date:From;
        b=PXrrNHdBu6H/qOBbRBZR95X0qfxhAkZHyCDjJZcgAOlQtJ4vQCF1CQKCRR0iPCqKw
         q319iVwREf0DMInvjuCEha1uvEgo5fzf8Iw/sPKAbsx9bc/m+h/urQ76apiTS/uqD5
         Xr93YQCSr6gDuqjZHlEjqUkWTAuRLO52JQiGTzKaxqpkc1+eRh7YyinSFRuu9L58+J
         LOD++Lb0kbOrOIZrkASVo2SnMyYEXnT+XtAS6uJOiueRfekk5dcQ5Co4ret+yUUaGM
         iKXqt8MGAiGIXYrtBWQKSV9k33eTqsItAS8F3t4zK8cJKfgGfLbMq38OBnRfOS5cpa
         DS3ZZ46Ie7sqw==^M
To: Spamassassin <users@spamassassin.apache.org>^M

If I add missing CR back to all the wrapped line endings in DKIM-Signature, the
message passes. I guess if any of the specified h= (To:From etc..) headers were
wrapped similarly, it would break on them too?

So the main question is, should spamass-milter strip CR's from wrapped headers?
Is this based on some RFC or why does it do it?

The answer above affects whether SpamAssassin should naively apply
s/\r?\n/\012\015/gs for data passed to Mail::DKIM, like earlier versions did.
In this case, shouldn't the fix be done at the internal pristine message data
level then, so get_pristine() returns correct data regardless what uses it?

Also this makes me think, if get_pristine() can return CRLF endings, could this
affect "full" rules if they assumed something about line endings? Or DCC/Pyzor
which use it..

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


[prev in list] [next in list] [prev in thread] [next in thread]