bug#36852: 27.0.50; ietf-drums-parse-address doesn't handle non-ascii properly

[Robert Pluim]

>>>>> On Tue, 30 Jul 2019 11:16:53 +0200, Štěpán Němec <stepnem@gmail.com> said:

    Štěpán> ietf-drums-parse-address (AKA mail-header-parse-address) uses
    Štěpán> ietf-drums-atext-token to parse display-name, but the regexp range 
only
    Štěpán> contains ASCII characters, so e.g. as used in 
debbugs-gnu-show-reports,
    Štěpán> the following happens:

    Štěpán>   (mail-header-parse-address
    Štěpán>    (decode-coding-string "Áaááá Ůůůůů <aaa@example.net>" 'utf-8))

    Štěpán>   ;;=> ("aaa@example.net" . "aááá")

    Štěpán> It actually only cares about the first char of a word:

    Štěpán>   (let ((ietf-drums-atext-token "-ÁŮ^a-zA-Z0-9!#$%&'*+/=?_`{|}~"))
    Štěpán>     (mail-header-parse-address
    Štěpán>      (decode-coding-string "Áaááá Ůůůůů <aaa@example.net>" 'utf-8)))

    Štěpán>   ;;=> ("aaa@example.net" . "Áaááá Ůůůůů")

    Štěpán> I'm not quite sure what the proper fix is, as the ASCII-only thing 
seems
    Štěpán> to be intentional. Maybe it's just not supposed to be used the way 
it is
    Štěpán> used in debbugs-gnu.el?

Mail headers are defined to be ascii-only, although as Iʼve just
discovered, gmail undoes Gnus' perfectly formatted RFC 2047 encoding
and replaces it with UTF-8 characters. Bad Google, bad.

Perhaps mail-header-parse-address could just discard the complete
display string if it finds a non-ascii char? That would at least
prevent it from propagating.

Robert