unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* mail-extract-address-components doesn't handle MIME-encoded full name
@ 2003-05-08 19:41 Kevin Rodgers
  0 siblings, 0 replies; 3+ messages in thread
From: Kevin Rodgers @ 2003-05-08 19:41 UTC (permalink / raw)


This is a real example:

(let ((mail-extr-ignore-single-names nil))
   (mail-extract-address-components
    "=?iso-8859-1?q?Laurent=20Laporte?= <laurentlaporte@yahoo.com>"))
=>
("iso" "laurentlaporte@yahoo.com")

mail-extract-address-components should either return the MIME-encoded full name
so the caller can decode it

	("=?iso-8859-1?q?Laurent=20Laporte?=" "laurentlaporte@yahoo.com")

or decode it itself

	("Laurent Laporte" "laurentlaporte@yahoo.com")

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mail-extract-address-components doesn't handle MIME-encoded full name
       [not found] <mailman.5787.1052422971.21513.bug-gnu-emacs@gnu.org>
@ 2003-05-08 22:22 ` Kevin Rodgers
       [not found] ` <mailman.5805.1052432654.21513.bug-gnu-emacs@gnu.org>
  1 sibling, 0 replies; 3+ messages in thread
From: Kevin Rodgers @ 2003-05-08 22:22 UTC (permalink / raw)


I wrote:

> mail-extract-address-components should either return the MIME-encoded 
> full name
> so the caller can decode it
> 
>     ("=?iso-8859-1?q?Laurent=20Laporte?=" "laurentlaporte@yahoo.com")
> 
> or decode it itself
> 
>     ("Laurent Laporte" "laurentlaporte@yahoo.com")

Or perhaps the caller should decode the From: header contents first; that's what
I'm doing for VM now:

(defadvice mail-extr-voodoo (before vm-decode-mime-encoded-words activate)
   "Decode MIME-encoded words before interepreting the buffer contents."
   (vm-decode-mime-encoded-words))

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mail-extract-address-components doesn't handle MIME-encoded full   name
       [not found] ` <mailman.5805.1052432654.21513.bug-gnu-emacs@gnu.org>
@ 2003-05-09 16:48   ` Kevin Rodgers
  0 siblings, 0 replies; 3+ messages in thread
From: Kevin Rodgers @ 2003-05-09 16:48 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

>> mail-extract-address-components should either return the MIME-encoded 
>> full name so the caller can decode it
>>
>>     ("=?iso-8859-1?q?Laurent=20Laporte?=" "laurentlaporte@yahoo.com")

>> 
>> or decode it itself
>>
>>     ("Laurent Laporte" "laurentlaporte@yahoo.com")
> 
> Or perhaps the caller should decode the From: header contents first; 

Apparently not (see attached message).


-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

[-- Attachment #2: mail-extract-address-components --]
[-- Type: text/plain, Size: 2216 bytes --]

>From - Fri May  9 10:45:07 2003
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Path: uni-berlin.de!fu-berlin.de!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!gohan12.FreeBSD.org!not-for-mail
From: kyle_jones@wonderworks.com (Kyle Jones)
Newsgroups: gnu.emacs.vm.info
Subject: Re: mail-extract-address-components doesn't handle MIME-encoded full names
Date: Fri, 9 May 2003 02:21:24 +0000 (UTC)
Organization: Unknown
Message-ID: <b9f3b4$de5$1@carbon.wonderworks.com>
Sender: kyle@carbon.wonderworks.com
References: <3EBAD6A4.8030307@yahoo.com>
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V
X-Complaints-To: abuse@supernews.com
Lines: 26
Xref: uni-berlin.de gnu.emacs.vm.info:15919

Kevin Rodgers  <ihs_4664@yahoo.com> wrote:
 > After I submitted a report to gnu.emacs.bug with the same subject, I
 > realized that it's probably better for VM to to decode the From: header
 > contents before calling mail-extract-address-components.

RFC 2047 advises against this because RFC 822 parsing rules are
no longer applicable to headers containing the decoded text.  If
mail-extract-address-components expects RFC 822 syntax (and I
think it does), then it could be broken by direct exposure to
decoded text.  The paragraph in the RFC 2046 I'm referring to is:

   NOTE: Decoding and display of encoded-words occurs *after* a
   structured field body is parsed into tokens.  It is therefore
   possible to hide 'special' characters in encoded-words which, when
   displayed, will be indistinguishable from 'special' characters in the
   surrounding text.  For this and other reasons, it is NOT generally
   possible to translate a message header containing 'encoded-word's to
   an unencoded form which can be parsed by an RFC 822 mail reader.

This is just for your information.  In practice the worse thing
that will happen is that someday mail-extract-address-components
might throw an error unexpectedly.

-- 
Latest VM: 7.15, see http://www.wonderworks.com/vm/
Latest snapshot: 1.04, see http://freshmeat.net/projects/snapshot/

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-05-09 16:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <mailman.5787.1052422971.21513.bug-gnu-emacs@gnu.org>
2003-05-08 22:22 ` mail-extract-address-components doesn't handle MIME-encoded full name Kevin Rodgers
     [not found] ` <mailman.5805.1052432654.21513.bug-gnu-emacs@gnu.org>
2003-05-09 16:48   ` Kevin Rodgers
2003-05-08 19:41 Kevin Rodgers

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).