[Tickets #13436] Re: IMP does not accept double colon in From header

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13436
------------------------------------------------------------------------------
  Ticket             | 13436
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | IMP does not accept double colon in From header
  Queue              | IMP
  Version            | 6.2.1
  Type               | Bug
  State              | Not A Bug
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2014-08-14 22:30) wrote:

> Some parsing is done by IMAP server, I agree. But this does not  
> matter here. I used Thunderbird to view this email and it showed  
> sender's name and address correctly. I also see it in email source,  
> so this is not an IMAP server issue.

Yes it is an IMAP issue.

Thunderbird is downloading the raw source of EVERY message.  Not super  
efficient, but that's their design choice.  And one they can make when  
the client computer has GBs of memory, TBs of drive space, exclusive  
use of all CPU cores on the local machine, and the ability to download  
(and parse) the mail messages in the background.

Horde has none of those luxuries.  As such, we need to use IMAP  
summary FETCH commands - like ENVELOPE - for performance reasons.   
Which is also a perfectly valid choice.  And the *IMAP server* is  
responsible for parsing addresses in this scenario, as I mentioned  
before.

Example from Dovecot 2.2 - the From address for this message is the  
invalid string "Test : Foo <foo at example.com>":

S: * 181 FETCH (UID 189 FLAGS (\Seen) RFC822.SIZE 492 ENVELOPE ("Sat,  
26 Jul 2008 21:10:00 -0500 (CDT)" "Test e-mail 1" ((NIL NIL "Test"  
NIL)(NIL NIL "MISSING_MAILBOX" "MISSING_DOMAIN")(NIL NIL NIL NIL))  
((NIL NIL "Test" NIL)(NIL NIL "MISSING_MAILBOX" "MISSING_DOMAIN")(NIL  
NIL NIL NIL)) ((NIL NIL "Test" NIL)(NIL NIL "MISSING_MAILBOX"  
"MISSING_DOMAIN")(NIL NIL NIL NIL)) ((NIL NIL "foo" "example.com"))  
NIL NIL NIL "<abcd1234efgh5678 at test1.example.com>") BODY[HEADER.FIELDS  
(IMPORTANCE LIST-POST X-PRIORITY CONTENT-TYPE)] {28}
S: [LITERAL DATA: 28 bytes]
S: )

Sure enough, Dovecot is choking on that message.

As even you admit, that e-mail address is invalid. We need to make  
sure these kind of addresses don't cause a DoS or other crash.  But we  
shouldn't go out of our way to try to parse these broken e-mails.   
(That's not just my conclusion - Dovecot works under the same  
conclusion and it is used on more than half of the mail servers in the  
world).

Not to mention that there are potential privacy/security issues if you  
start to try to "guess" or "repair" broken e-mail messages.