#226 Bad signature of From:\r\n wrapped field

[Ale Vesely]

The long From: problem was discussed last year (Strict canonicalization considered harmful, 5 Dec 2014), and using relaxed was considered a decent workaround. Eventually, though, wrapping before signing seemed to be a better solution.

Now I tested a wrapped From: using both simple and relaxed c14ns. The simple canonicalization succeeded. However, the relaxed one, this time, did not.

I attach two auto-responses from blackops.org.

Please note that the From: field is unwrapped in both responses. I copied the relaxed response's original message to a file and verified it using libopendkim 2.10.1, it failed. Next, I re-wrapped the From: field and verified it again. This time it was ok, how come? It seems a newline is needed in order to get a pass. Yet relaxed c14n is being enforced --see also the third attachment.

Using Mail::DKIM::Verifier.pm I haven't been able to get a pass in either way, so perhaps the signature is bad (it was done with v2.10.1 as well), but verification erroneously passes it because of the same bug?

[Ale Vesely]

Got it. I attach a patch and some details.

The prescription that folded lines "MUST be interpreted without the CRLF" (Section 3.4.2, bullet 2) can be reworded as saying that internal CRLFs be interpreted as spaces, correct?

The signature produced with the patched library is recognized by Mail::DKIM::Verifier.pm.

[Murray S. Kucherawy]

I'm trying to understand what the problem is here. You're concerned about input like:

From:\r\n<sp><...>

Is that correct?

Is something actually generating that?

[Ale Vesely]

That's correct. Courier generates that "From:\r\n<sp><...>" when the content ("<...>" = display phrase + address) is longer than 70 chars or so.

Stuff like "From:<sp>...<sp>\r\n<sp><...>" was hand made in order to understand what's going on. It turns out that v2.10.1 canons out the spaces before \r\n, but not the \r\n itself.

[Murray S. Kucherawy]

This sounds like a bug in Courier. What it's producing isn't wrong, but wrapping before there's any text to wrap seems like broken behavior to me.

Anyway, this will appear in the next release because it looks like Courier's output doesn't violate RFC5322, so we should handle it. Thanks for the patch.

[Murray S. Kucherawy]

v2.10.2 released.

[A. Schulze]

looks like the fix is still not included in v2.10.3
see complete thread on opendkim-users ML: http://lists.opendkim.org/archive/opendkim/users/2016/04/3687.html

for reference I attach a patch here again

[Steve Jenkins]

+1 this should not be marked as "closed-fixed" yet. I now apply this patch in the Fedora/EPEL packaged versions of OpenDKIM 2.10.3.

[Andreas Schamanek]

It is included in opendkim-2.11.0.Alpha0, last modified 2015-10-22.

Unfortunately, this bug breaks a lot of signatures if headers are signed that are often folded such as "Subject:" (especially when encoded), "References:", "In-reply-to:", "Message-IDs" (when long), ...

[Dilian Wesselinov Palauzov]

Problems with wrapping are reported also in [#230], [#259] and [#255].

The specification says: first unfold, then strip the whitespaces after the colon. So
From:\r\n
abc
is normalized as "From:abc", not as "From: abc".