Skip to content

bug: decode RFC 2047 headers for Email::MIME address parsing #1141

Closed

Description

@fglock

Summary

The CPAN compatibility run 20260826-133502-83100 fails Email::MIME 1.954 while processing RFC 2047 encoded headers and encoded display names. The same failures reproduce on both the JVM and interpreter backends.

Email::MIME is pure Perl. Its upstream test suite passes completely under system Perl 5.42.2 when run with the distribution's required dependencies in an isolated library.

Upstream baseline

System Perl passes the complete Email::MIME 1.954 suite:

Files=21, Tests=297
Result: PASS

PerlOnJava failures

Encoded headers are not decoded

t/unicode.t fails 30 of 59 assertions on both backends. For example, a UTF-8 encoded-word display name remains encoded instead of decoding:

got:      =?UTF-8?B?RMO2eQ==?= <test@example.com>
expected: Døy <test@example.com>

Long encoded subjects are similarly returned as RFC 2047 encoded words rather than decoded text.

Address-list parsing fails after encoded words

t/header-addresslist.t fails while parsing encoded display names and group addresses, then dies while accessing an expected parsed address object:

Can't call method "phrase" on an undefined value at t/header-addresslist.t line 58.

For example, an encoded address header is returned as encoded words rather than as the decoded quoted phrases expected by the test.

Reproduction

From an unpacked Email::MIME 1.954 distribution, after building its blib directory and making its normal prerequisites available:

jperl -Iblib/lib -It t/unicode.t
jperl -Iblib/lib -It t/header-addresslist.t

jperl --interpreter -Iblib/lib -It t/unicode.t
jperl --interpreter -Iblib/lib -It t/header-addresslist.t

Observed results on both backends:

t/unicode.t:            30/59 failed
t/header-addresslist.t: fails assertions 3-4, 6, 8-9, 11, 13-14, 16-18; exits when calling phrase on undef

Expected behavior

RFC 2047 encoded words must be decoded before the values are exposed through Email::MIME's header and address-list APIs. Encoded display names and group-address syntax must then parse into the same values and address objects as system Perl.

Likely scope

The common behavior across these tests suggests a compatibility gap in encoded-word handling at the Email::MIME / Email::Simple header boundary, with the address-list failures as a downstream consequence. Both execution backends are affected, so the issue is likely shared runtime or bundled-module behavior rather than JVM-only compilation.

Activity

  1. added a commit that references this issue on Aug 27, 2026
    5e53fd5
  2. reopened this on Sep 24, 2026
  3. fglock commented on Sep 24, 2026

    @fglock
    OwnerAuthor

    Follow-up verification from CPAN random-tester run 20260924-085657-82687:

    Email::MIME 1.954 still reproduces the RFC 2047/header compatibility failure on current PerlOnJava.

    • System Perl passes the complete upstream suite: 21 files, 297 tests.
    • PerlOnJava fails 42/252 tests across t/unicode.t and t/header-addresslist.t.
    • The failure reproduces on both JVM and interpreter backends.
    • Encoded UTF-8 subjects and display names remain as =?UTF-8?...?= strings instead of decoding.
    • Address-list parsing consequently returns incorrect values or undefined address objects.

    This confirms that the behavior described by this issue remains reproducible after the previous RFC 2047 autoload fix. The stable upstream tests are t/unicode.t and t/header-addresslist.t.

  4. fglock commented on Oct 23, 2026

    @fglock
    OwnerAuthor

    Resolved by merged PR #1872. Email::MIME 1.954 passes all 21 upstream files and 297 tests on JVM and interpreter; the focused encoded-header/address regression and system Perl baseline pass as well. Closing as completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:cpan-portCPAN compatibility ports and providersbugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions