Your message dated Wed, 13 Jan 2016 14:48:41 +0900
with message-id <[email protected]>
and subject line Re: dma: does not recognize addresses in MIME enocded-word
syntax
has caused the Debian Bug report #748901,
regarding dma: does not recognize addresses in MIME enocded-word syntax
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
748901: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748901
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dma
Version: 0.9-1
Severity: important
Dear Maintainer,
I started using dma to get my mail delivered to the company's smarthost.
As long as the addresses are all ASCII this works fine. The trouble is,
most of the mail addresses I use contain Japanese and my mail client
(Emacs' message-mode) dutifully converts those to MIME encoded-word
syntax[1]. Any such address is no longer recognized by dma as a valid
email address. In /var/log/mail.log I see entries such as:
invalid recipient `=?utf-8?B?QXJubyBUw7ZsbCA8YXJub0BkZWJpYW4ub3JnPgo=?='
FWIW, that's Arno's Debian address which also contains some non-ASCII.
I would have expected dma to recognize such addresses as valid. To do
so it probably needs to decode them before further processing. Also, it
should be able to cope with other encodings than UTF-8/base64. On one
of my other machines, Japanese is encoded to iso-2022-jp and I would not
be surprised if in certain situations the Q-encoding gets used.
[1] https://en.wikipedia.org/wiki/MIME#Encoded-Word
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dma depends on:
ii debconf [debconf-2.0] 1.5.53
ii libc6 2.18-5
ii libssl1.0.0 1.0.1g-4
ii ucf 3.0028
dma recommends no packages.
dma suggests no packages.
-- Configuration Files:
/etc/dma/auth.conf [Errno 13] Permission denied: u'/etc/dma/auth.conf'
-- debconf information: (manually anonymized)
* dma/mailname: workstation.example.com
* dma/relayhost: smarthost.example.com
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
--- End Message ---
--- Begin Message ---
Hi Juliusz,
I just reopened this (I hope) because I found out how to reproduce w/o
any emacs involved.
Juliusz Chroboczek writes:
> Looking at this some more, this looks like a bug in some Emacs package.
> I'm closing this bug, please reopen if you disagree.
>
>> invalid recipient `=?utf-8?B?QXJubyBUw7ZsbCA8YXJub0BkZWJpYW4ub3JnPgo=?='
>
>> FWIW, that's Arno's Debian address which also contains some non-ASCII.
>
> This is "Arno T$(D+S(Bll <[email protected]>", encoded in Base 64. This
> should
> have been encoded as
>
> Arno =?iso-8859-1?Q?T=F6ll?= <[email protected]>
>
> i.e. the e-mail address itself should not have been encoded, only the real
> name.
I read up on the MIME encoding bit and you are right that the email
address itself should not be encoded. However, even when that is
handled properly, dma balks.
> I was able to reproduce the bug earlier, but I no longer can -- tried both
> message-mode and SEMI --, so the bug remains a mystery.
I've been experimenting a bit with To: header variations and found that
things go wrong when the email address is on the next line. That is,
To: =?iso-2022-jp?B?GyRCJWElJCUmJSMlQyU7JXMbKEIgGyRCJSolaSVVGyhC?=
<[email protected]>
with the whole address on a single line is processed fine (i.e. without
error messages in the mail logs), splitting this over two lines, like so:
To: =?iso-2022-jp?B?GyRCJWElJCUmJSMlQyU7JXMbKEIgGyRCJSolaSVVGyhC?=
<[email protected]>
is not and leads to an
invalid recipient
`=?iso-2022-jp?B?GyRCJWElJCUmJSMlQyU7JXMbKEIgGyRCJSolaSVVGyhC?=`
error message in the mail logs. So it seems that the header parsing is
buggy for multi-line To: header fields.
My experiments just piped a plain text mail message into `dma -t -i` and
I used something like
printf "$B%a%$%&%#%C%;%s(B $B%*%i%U(B" | iconv -futf-8 -tiso-2022-jp |
base64
to fill in the MIME encoded word bits between =?iso-2022-jp?B? and ?=.
BTW, that's my name in Japanese.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION
Free Software Foundation Associate Member since 2004-01-27
Support Free Software https://my.fsf.org/donate
Support the Free Software Foundation https://my.fsf.org/join
--- End Message ---
