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
Olaf Meeuwissen writes:
Diggign through the Emacs documentation, I discovered a work around.
You can modify the rfc2047-header-encoding-alist to prevent conversion
to MIME encoded-word syntax. Simply replace `address-mime` by `utf-8`
(or another coding system that works for your mail addresses). Doing
so can be done in your ~/.emacs.d/init.el (or ~/.emacs) like so:
(setq rfc2047-header-encoding-alist
'(("Newsgroups")
("Followup-To")
("Message-ID")
("\\(Resent-\\)?\\(From\\|Cc\\|To\\|Bcc\\|\\(In-\\)?Reply-To\\|Sender\\|Mail-Followup-To\\|Mail-Copies-To\\|Approved\\)" . utf-8)
(t . mime))
The drawback of this approach is that if there is any picky mail server,
one that can't handle 8-bit (try utf-7?) or insists on ASCII headers in
the chain from your host to the final destination, your message likely
bounces or in the worst case is dropped.
Hope this helps,
Olaf Meeuwissen writes: This is missing a final ')'. Sorry for not properly testing.
Olaf Meeuwissen writes: Ouch! Just got a bounce from an Alioth hosted mailing list saying: <sane-devel@lists.alioth.debian.org>: 550 improper use of 8-bit data in message header: message rejected Looks like dma had better get fixed.
Any news on this issue? It makes dma unusable.
Looking at this some more, this looks like a bug in some Emacs package. I'm closing this bug, please reopen if you disagree. This is "Arno Töll <arno@debian.org>", encoded in Base 64. This should have been encoded as Arno =?iso-8859-1?Q?T=F6ll?= <arno@debian.org> i.e. the e-mail address itself should not have been encoded, only the real name. 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.
Hi Juliusz, I just reopened this (I hope) because I found out how to reproduce w/o any emacs involved. Juliusz Chroboczek writes: 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'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?= <olaf.meeuwissen@avasys.jp> 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?= <olaf.meeuwissen@avasys.jp> 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 "メイウィッセン オラフ" | 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,
retitle 748901 dma -t fails to parse folded header lines thanks Thanks for the debugging, Olaf. The following snippet reproduces the bug: This breaks dma. EOF --------------------------------------------------
Dear Customer, We could not deliver your parcel. Delivery Label is attached to this email. Regards, Todd Martinez, Sr. Support Manager.
Dear Customer, Your parcel has arrived at October 23. Courier was unable to deliver the parcel to you. Delivery Label is attached to this email. Thanks and best regards, Robert Marsh, Sr. Support Manager.
Dear Customer, Courier was unable to deliver the parcel to you. Shipment Label is attached to this email. Yours sincerely, Jon Chapman, Delivery Manager.
Dear Customer, This is to confirm that one or more of your parcels has been shipped. You can review complete details of your order in the find attached. Yours trully, Dennis Harrington, Operation Manager.
Dear Customer, Your parcel has arrived at November 10. Courier was unable to deliver the parcel to you. Delivery Label is attached to this email. Yours trully, Ray Hudson, Sr. Operation Manager.
Hi, This seems to be the upstream issue relating to this bug: https://github.com/corecode/dma/issues/89 which was closed with this commit: https://github.com/corecode/dma/commit/7024d2e27873598792f095ff832d345388fa4827 which is pretty trivial, so could either be backported or one could perhaps start shipping the unreleased version out of git. I'll be making my own version of dma for local use, as this bug is a bit of a disaster, but for others that are not aware that it's dma that's sabotaging their mail setup, I would say that this bug needs fixing urgently. I'll happily do an NMU with just the single commit applied, if that helps. Cheers, Phil.