A NOTE has been added to this issue.
======================================================================
http://www.dbmail.org/mantis/view.php?id=377
======================================================================
Reported By: idk
Assigned To:
======================================================================
Project: DBMail
Issue ID: 377
Category: IMAP daemon
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
target:
======================================================================
Date Submitted: 14-Jul-06 16:18 CEST
Last Modified: 03-Sep-06 14:05 CEST
======================================================================
Summary: IMAPD returns invalid FETCH ENVELOPE field when
there are multiple addresses
Description:
I have a message with header
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED];[EMAIL PROTECTED]
When I fetch this message
A001 UID FETCH 315406 (ENVELOPE)
I got on Fedora Core 3
* 59 FETCH (ENVELOPE ("date" "subject" ((NIL NIL "sender" "my.dom")) ((NIL
NIL "sender" "my.dom")) ((NIL NIL "sender" "my.cz")) ((NIL NIL "one"
"my.dom;")("two" "my.dom")) NIL NIL NIL "id") UID 315406)
A001 OK UID FETCH completed
and on Fedora Core 5
* 59 FETCH (ENVELOPE ("date" "subject" ((NIL NIL "sender" "my.dom")) ((NIL
NIL "sender" "my.dom")) ((NIL NIL "sender" "my.cz")) ((NIL NIL "one"
"my.dom;two" "my.dom")) NIL NIL NIL "id") UID 315406)
A001 OK UID FETCH completed
(the difference is in "to" field:
((NIL NIL "one" "my.dom;")("two" "my.dom"))
vs.
((NIL NIL "one" "my.dom;two" "my.dom"))
no one is good)
======================================================================
----------------------------------------------------------------------
idk - 14-Jul-06 18:03
----------------------------------------------------------------------
One more info: header with additive ", " string is stored into database on
FC3, but FC5, so the issue is (maybe) when message is to be inserting into
database (MySQL), so LMTP daemon?
If so, I have find on the wrong place :(
----------------------------------------------------------------------
idk - 14-Jul-06 18:27
----------------------------------------------------------------------
:(
tcpdump on local lmtp port shows me an additive ", " string in incomming
request, so the "comma issue" begins in postfix - on FC3 is 2.1.5 postfix
installed and on FC5 2.2.8
Ok, now I know from where is a ", " string. But stills problem with
delimiter. The delimiter in 822 message is (fixme if it's not true) ";"
char. And multiple "@" chars makes multiple and nonsense field outputs in
FETCH reply.
----------------------------------------------------------------------
paul - 14-Jul-06 20:14
----------------------------------------------------------------------
>From your report it is unclear how this impacts 2.1.x. If you say there are
no significant diffs between 2.0.10 and 2.1.6 you're not looking at the
right source code. They are vastly different especially in this area:
mime-parsing.
This also smells like a bug in gmime Robbie Stone reported in
http://www.dbmail.org/mantis/view.php?id=368. Could
you please compare notes with that bug and also, if it looks similar,
please test svn-trunk?
For the record: mime bugs in 2.0 will (most likely) not be fixed. Not be
me anyway.
----------------------------------------------------------------------
idk - 15-Jul-06 03:20
----------------------------------------------------------------------
Ok, here is the complete story:
At April I did an installation 2.1.5 on clean FC5. I have seen OE client
after moving old messages from local folder do IMAP folder didn't list all
moved messages, but other clients (incl. SquirrelMail) shown all messages.
I had no time to discover issue, so I recomended using other clients. I
have dismiss.
At June I had to reinstall another mailserver on new hw, before it was
FC3/2.0.8, the new one is FC5/2.0.10. Then I discovered similar issue with
showing not all messages on OE - client tell me about new meesages, but I
didn't seen them. In other client (SM) all messages was seen (readable,
deletable, movable...).
So, I found some time for discovering this issue. First of all I diffed
2.0.8 and 2.0.10, because in 2.0.8 this was not occurred. About this diff
I wrote before.
Then I locate difference in storing in database - the same message
inserted (sendmail user <message.eml) via LMTP was inserted into 2.0.8
with additive ", " between two addreeses in "To" header delimited by ";",
whereas into 2.0.10 this header was inserted unchanged. As I announced
before, postfix made this change (I mean, I captured internal
postfix->dbmail LMTP communication).
So, in 2.0.x is show_address_list function which splits address list in
header by "," delimiter. If postfix (eg on FC3) alters original
To: [EMAIL PROTECTED];[EMAIL PROTECTED] to
To: [EMAIL PROTECTED];, [EMAIL PROTECTED]
then DBMail interprets this field as two addresses
[EMAIL PROTECTED]; NIL NIL one dom;
[EMAIL PROTECTED] NIL NIL two dom
But when postfix don't alters field (eg on FC5), then DBMail interprets
field as one address with two "@"
[EMAIL PROTECTED];[EMAIL PROTECTED] NIL NIL one dom;two dom
which is syntax (parsing) error and OE don't display this message (other
clients may ignore this error and display message though).
I thought issue 2.1.5 from April and issue 2.0.10 are the same, so I join
them together. But the reason of issue 2.1.5 is different.
Summarization for 2.0.10: when field from/to/reply-to/sender contains
multiple addresses delimited by ";" char without "," commas, FETCH IMAP
command returns more elements than 4 (exactly: when there is no comma
between two "@"s).
I tried 2.1.5 for same situation ([EMAIL PROTECTED];[EMAIL PROTECTED]), 2.1.5
returns ((NIL
NIL one dom)) only, but correct response is ((NIL NIL one dom)(NIL NIL two
dom)), so 2.1.5 ignores subsequently addresses in list.
But this is not cause to parsing error (in address column is less
information only). I searched for historical messages on customer server
from April with OE parsing errors and I found this:
a uid fetch 808 (envelope)
* 1 FETCH (UID 808 ENVELOPE ("date"
"=?ISO-8859-2?Q?E-mail=20noviny=2016/06:=20Vli?=
=?ISO-8859-2?Q?v=20p=F8=EDjm=F9=20ze=20zam=ECstn=E1n=ED=20n?=
=?ISO-8859-2?Q?a=20z=E1lohy=20fyzick=FDch=20osob?=" (("=?ISO-8859-2?Q?
"Verlag=20Dash=F6fer=20-=20DU.cz?= =?ISO-8859-2?Q?" ?=" NIL "e-noviny"
"smtp.dashofer.cz")) (("=?ISO-8859-2?Q? "Verlag=20Dash=F6fer=20-=20DU.cz?=
=?ISO-8859-2?Q?" ?=" NIL "e-noviny" "smtp.dashofer.cz")) (("Verlag
Dashöfer " NIL "e-noviny" "dashofer.cz")) ((NIL NIL "user" "dom")) NIL NIL
NIL "<[EMAIL PROTECTED]>"))
a OK UID FETCH completed
I see the main problem is unescaped quotas in addresses names. Original
header seems as
To: [EMAIL PROTECTED]
Subject: =?ISO-8859-2?Q?E-mail=20noviny=2016/06:=20Vli?=
=?ISO-8859-2?Q?v=20p=F8=EDjm=F9=20ze=20zam=ECstn=E1n=ED=20n?=
=?ISO-8859-2?Q?a=20z=E1lohy=20fyzick=FDch=20osob?=
Sender: =?ISO-8859-2?Q? "Verlag=20Dash=F6fer=20-=20DU.cz?=
=?ISO-8859-2?Q?"
?= <[EMAIL PROTECTED]>
Reply-To: =?ISO-8859-2?Q?Verlag=20Dash=F6fer=20?= <[EMAIL PROTECTED]>
From: =?ISO-8859-2?Q? "Verlag=20Dash=F6fer=20-=20DU.cz?=
=?ISO-8859-2?Q?"
?=
<[EMAIL PROTECTED]>
I tried svn trunk version too with the same result. Version 2.0.10 solves
this issue by reply with {len} literal.
Summarization for 2.1.5: when address field has multiple addresses
delimited by ";", only first address is returned in reply to FETCH
request; second issue is when address field (maybe any field) has quotas,
they aren't escaped/replaced (by \").
I read issue 0000368 and I found partial conformity only.
If this will not be fixed in 2.0 branch, I have two quetions:
a) when will be 2.2 stable branche available
b) when will be migration scripts from 2.0 available
----------------------------------------------------------------------
idk - 21-Jul-06 13:18
----------------------------------------------------------------------
I added patch for 2.0.x branch to solve ";" as a delimitor problem (I
tested it for 5 days successfully).
----------------------------------------------------------------------
paul - 03-Sep-06 14:05
----------------------------------------------------------------------
I think Aaron fixed this. Aaron?
Issue History
Date Modified Username Field Change
======================================================================
14-Jul-06 16:18 idk New Issue
14-Jul-06 18:03 idk Note Added: 0001300
14-Jul-06 18:27 idk Note Added: 0001301
14-Jul-06 20:14 paul Note Added: 0001302
14-Jul-06 20:14 paul Severity major => minor
14-Jul-06 20:14 paul Status new => feedback
15-Jul-06 03:20 idk Note Added: 0001303
21-Jul-06 10:59 idk File Added: imaputil.c.diff
21-Jul-06 11:00 idk Note Added: 0001312
21-Jul-06 13:18 idk Note Edited: 0001312
03-Sep-06 14:05 paul Note Added: 0001386
======================================================================
