Bug#1126502: dpkg does not accept non-ascii chars in email address

> On 28 Jan 2026, at 5:27 AM, Guillem Jover <[email protected]> wrote:
> 
> Hi!
> 
> On Tue, 2026-01-27 at 22:15:36 +0530, Nilesh Patra wrote:
>> Package: dpkg
>> Severity: important
>> X-Debbugs-Cc: [email protected] <mailto:[email protected]>.org
>> Control: affects -1 + src:lintian
>> Version: 1.23.5
> 
>> Lintian’s test suite reflects this error:
>> 
>> | dpkg-source: warning: --auto-commit is not a valid option for Dpkg::Source::Package::V3::Native
>> | dpkg-source: error: cannot parse Maintainer field value "Colorful <"colorful"@43-1.org>”
>> | dpkg-buildpackage: error: dpkg-source -iNEVER_MATCH_ANYTHING -INEVER_MATCH_ANYTHING --auto-commit --before-build . subprocess failed with exit status 255
>> | make: *** [/tmp/autopkgtest-lxc.18_8mz9y/downtmp/autopkgtest_tmp/build-and-evaluate-test-packages/package-sources/checks/fields/terminal-control/colorful/Makefile:39: colorful_1.0_amd64.changes] Error 255
> 
> Hmm, TBH I don't think I'm comfortable allowing ANSI escapes as part
> of email addresses? This feels unnecessary and a recipe for terminal
> exploits and similar.

This happens to be allowed by RFC 6532 as such.

>> This is a fallout with #962277.
>> 
>> dpkg should allow domains with non-ascii chars. For now I’ll try to
>> drop this test from lintian test suite.
> 
> Otherwise the parser already supports UTF-8 characters in both the
> local and domain parts:
> 
> $ perl -Mv5.40 -MDpkg::Email::Address -E '\
>    my $e = Dpkg::Email::Address->new("Foo Bar <föo\@bår.org>"); \
>    say $e->as_string(); \
>  '
> Foo Bar <föo@bår.org>
> 
> So, I'm inclined to close this one.

Lintian expects the .dsc/.changes file to be UTF encoded. If someone uses the address, it leads to .changes with a nationally encoded email
and lintian would fail to parse that /o\

This is getting way more complicated than I did think originally.