search

lieser / dkim_verifier

DKIM Verifier Extension for Mozilla Thunderbird
MIT License
208 stars 34 forks source link

Authentication Results parser fails if smtp.remote-ip/policy.iprev contains an IPv6 address #436

Closed MASHtm closed 5 months ago

MASHtm commented 5 months ago

If the authentication results parser sees something like 

iprev=pass (mail-qt1-x829.google.com) smtp.remote-ip=2607:f8b0:4864:20::829;

it fails with

DKIM_Verifier.AuthVerifier  ERROR    Ignoring error in parsing of ARH DKIM_Error: Parsing error
    match moz-extension://ea39292a-878c-4d82-943c-2ad127dc3587/modules/arhParser.mjs.js:354
    parseResInfo moz-extension://ea39292a-878c-4d82-943c-2ad127dc3587/modules/arhParser.mjs.js:188
    parse moz-extension://ea39292a-878c-4d82-943c-2ad127dc3587/modules/arhParser.mjs.js:158
    getARHResult moz-extension://ea39292a-878c-4d82-943c-2ad127dc3587/modules/authVerifier.mjs.js:265
    verify moz-extension://ea39292a-878c-4d82-943c-2ad127dc3587/modules/authVerifier.mjs.js:177

in the console.

Setting this to an IPv4 address immediately fixes the parser error. Setting "Try to read non RFC compliant Authentication-Results header" also fixes the issue, but this header is RFC compliant enough IMO.

And yes, smtp.remote-ip= is not defined/valid according to the latest IANA registry and it should read

iprev=pass (mail-qt1-x829.google.com) policy.iprev=2607:f8b0:4864:20::829;

which fails to parse as well. I will file a bug for Exim to get this property changed. But AFAIS the extension doesn't care much about unknown ptype.property=value pairs as long as it can parse it as such.

lieser commented 5 months ago

Thanks for the detailed report.

The problem are the : inside the IPv6 address, which is only allowed in a value that is inside a quoted-string.

And yes, smtp.remote-ip= is not defined/valid according to the latest IANA registry and it should read

As you write yourself, this should not be a problem. The extension only cares that the ptype.property=value pairs conform to the syntax in the RFC, not that they are registered in the IANA. One should of course try to use the ones registered where it makes sense.

MASHtm commented 5 months ago

The problem are the : inside the IPv6 address, which is only allowed in a value that is inside a quoted-string.

Only to get that right... you mean according to RFC 8601:2.2. Formal Definition: .... "The "value" is as defined in Section 5.1 of [MIME] with "quoted-string" updated as specified in [RFC6532]" ...

which more or less refers back to RFC5322:3.2.3 Atom ... where dot-atom-atext allows IPv4 addresses, but not IPv6 addresses which needs to be quoted because "specials,, qtext, ...." count.

If I got it right I'll take this to the Exim people ... maybe with a patch in hand;-)

lieser commented 5 months ago

"The "value" is as defined in Section 5.1 of [MIME] with "quoted-string" updated as specified in [RFC6532]" ...

That part is correct, unsure how you are coming to the dot-atom-atext.

From https://datatracker.ietf.org/doc/html/rfc2045#section-5.1

     value := token / quoted-string

     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="
                   ; Must be in quoted-string,
                   ; to use within parameter values

As : is part of tspecials it can only appear inside a quoted-string.

MASHtm commented 5 months ago

thanks. will be fixed in Exim then... closing this issue.