VM

vm: vm-mime-encode-headers may mess up recipient addresses

Bug #490021 reported by Manoj
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
VM
Fix Released
Low
Uday Reddy
vm (Debian)
Fix Released
Unknown

Bug Description

When using recipients with full names containing accents, the encoding
done by vm-mime-encode-headers can produce incorrect addresses if a
space is missing after a comma. For instance:

 To: <email address hidden>,François Fleuret <email address hidden>

calling vm-mime-encode-headers produces

 To: =?iso-8859-1?Q?<email address hidden>,Fran=E7ois?= Fleuret <email address hidden>

Hence the first address is not valid anymore. This does not happen if
the space is present.

Regards,

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages vm depends on:
ii emacs22 [emacsen] 22.2+2-5 The GNU Emacs editor
ii make 3.81-5 The GNU version of the "make" util
ii ucf 3.0016 Update Configuration File: preserv

vm recommends no packages.

Versions of packages vm suggests:
ii postfix [mail-transport-agent 2.5.5-1.1 High-performance mail transport ag
ii stunnel 3:4.22-2 dummy upgrade package
ii stunnel4 [stunnel] 3:4.22-2 Universal SSL tunnel for network d

Related branches

Changed in vm (Debian):
status: Unknown → Confirmed
Revision history for this message
Uday Reddy (reddyuday) wrote :

You can control this by setting the variable vm-mime-encode-headers-words-regexp. Copy its definition from vm-vars.el and add a comma wherever a space is present. It occurs to me that you could add other punctuation characters as well. But I can't tell what other implications this might have. -- Uday

Changed in vm:
status: New → Confirmed
importance: Undecided → Low
Uday Reddy (reddyuday)
Changed in vm:
assignee: nobody → Ulrich Müller (ulm)
Uday Reddy (reddyuday)
tags: added: international
Revision history for this message
Ulrich Müller (ulm) wrote :

There were several changes in the code related to MIME header encoding between 8.0.9 and 8.0.12. Can you please verify if this is still an issue in later VM versions (current 8.0.* or 8.1.0-beta)?

Revision history for this message
Uday Reddy (reddyuday) wrote :

Dear Manoj and Ulrich, has there been any more progress on this?

Given that VM is adhering to standards in encoding headers and there is an easy work around available for ill-formed headers, I think it might be best to close this bug report.

Uday

Revision history for this message
Ulrich Müller (ulm) wrote :

Closing this bug, because I think that VM 8.1 is not affected any more.
Please reopen if it is still an issue.

Changed in vm:
status: Confirmed → Fix Released
Changed in vm (Debian):
status: Confirmed → Fix Released
Uday Reddy (reddyuday)
Changed in vm:
status: Fix Released → In Progress
Revision history for this message
Uday Reddy (reddyuday) wrote :

I am sorry guys. I tested the OP's example this morning and the problem is still there. It would be misleading to claim that we have released a fix.

On the other hand, it is not clear to me what the solution is. According to RFC 2047, encoded words can have everything but white space. But to say that they *can* have is not to say that they should have. What characters should be excluded from encoded words is an open question.

For the time being, I am adding ',' as a separator between encoded words, so that at least the OP is satisfied. This will only appear in 8.1.1 release.

But this needs more thought in general.

Cheers,
Uday

Uday Reddy (reddyuday)
Changed in vm:
assignee: Ulrich Müller (ulm) → Uday Reddy (reddyuday)
milestone: none → 8.1.1
status: In Progress → Fix Committed
Uday Reddy (reddyuday)
Changed in vm:
status: Fix Committed → Fix Released
Revision history for this message
Uday Reddy (reddyuday) wrote :

Yuuichi Kagaguchi reports on 13 Dec 2010:

2. When a (long) header line is continue to the next
   line, it is not correctly encoded with
   MIME. Spaces at the head of the second line are
   encoded with MIME (=20), and then `smtpmail.el'
   recognizes the line as incorrect, which will
   cause an error.

I received, for example, an e-mail with header lines
as (Fig .1):

BEGIN--BEGIN
Subject: Re: =?UTF-8?B?W+Wtpuihk+aMr+iIiOWnlOWToeS8ml0g57SA6KaB5oqV56i/6KaP?=
 =?UTF-8?B?56iL562J44Gu5pS56KiCKOahiCk=?=
Date: Fri, 17 Dec 2010 12:30:29 +0900
END---END (Fig. 1)

The first line continues to the second line.
According to the header rule (in RFC?), there is a
white space at the beginnig.

In replying to this with a VM's `R' key, VM encodes
those lines into (Fig. 2):

BEGIN--BEGIN
Subject: Re:
=?utf-8?Q?[=E5=AD=A6=E8=A1=93=E6=8C=AF=E8=88=88=E5=A7=94=E5=93=A1=E4=BC=9A]_=E7=B4=80=E8=A6=81=E6=8A=95=E7=A8=BF=E8=A6=8F
Date: 月, 20 12月 2010 181020 JST
_=E7=A8=8B=E7=AD=89=E3=81=AE=E6=94=B9=E8=A8=82(=E6=A1=88)?=
END---END (Fig. 2)
---------------------------------------

This problem was fixed in this bugfix by encoding entire sequences of words that need encoding so that mail-mode cannot break them in the middle of the header line.

This is not really a fix, but a workaround for mail-mode. This should be fixed eventually by moving to message-mode which breaks the header lines correctly.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.