Hi, Thank you Jeff san.
It seems to be able to work fine in IMAP, without FTS. But I hope FTS to find addresses. And I reported this to the developers of email solutions which adding such MIMEd display name. But for older mails or another email softwares, I hope this problems to be solved in Dovecot with FTS. Thank you. ----- Original Message ----- > On Tue, Jul 21, 2020 at 08:18:21 +0900, TACHIBANA Masashi wrote: > > Hi, > > > > Thank you for your reply. > > > > I hope this bug to be fixed soon. :) > > It is a tricky one because as far as I can tell, the From header is invalid. > So, we have to figure out the best way to handle such input. > > The input is invalid because '@' is not allowed by the RFC to be in the name > portion of an email address without quoting. In other words, these are ok: > > t...@example.com > <t...@example.com> > Test <t...@example.com> > "t...@example.com" <t...@example.com> > > but this one is bad: > > t...@example.com <t...@example.com> > > In your case, the name is encoded but not quoted so even though the email > contains: > > =?UTF-8?B?dXNlcjJAZXhhbXBsZS5jb20=?= <us...@example.com> > > the parser sees: > > us...@example.com <us...@example.com> > > Which is invalid. > > Dovecot parsing needs to be improved, but as I already mentioned it is an > improvement to handling of malformed input. So, as a workaround, if you > control the software/system that generates these emails, try to change it so > it doesn't generate headers that are invalid. As far as I can tell, the > parser in Dovecot handles those just fine. > > Jeff. > > > Thank you. > > > > Tachibana > > > > ----- Original Message ----- > > > On Mon, Jul 20, 2020 at 09:43:12 -0400, Josef 'Jeff' Sipek wrote: > > > > On Mon, Jul 20, 2020 at 20:24:13 +0900, TACHIBANA Masashi wrote: > > > ... > > > > Thanks for the report. I reproduced it locally, but I'm not sure what > > > > is > > > > causing it yet. > > > > > > Alright, it is actually a parsing bug. The problem seems to be when the > > > code encounters a "name <address>" format where the name is a valid > > > address. > > > This accidentally makes the parser stop parsing - making any additional > > > addresses ignored. > > > > > > E.g., > > > > > > t...@example.com <t...@example.com>, Name <ot...@example.com> > > > > > > The parser stops after the first address's name thinking it is just a bare > > > address (without a name). That is, after the first loop iterating while > > > parsing, the "cursor" is at the first space and not at the comma. > > > > > > /- parsing should stop here > > > v > > > t...@example.com <t...@example.com>, Name <ot...@example.com> > > > ^ > > > `- parsing stops here > > > > > > This is obviously wrong. I'll have to dig in more to figure out what it > > > will take to fix this. > > > > > > Thanks again, > > > > > > Jeff. > > > > > > -- > > > FreeBSD 12.1 > > > > > -- > > TACHIBANA Masashi QUALITIA CO., LTD. > > mailto:tachib...@qualitia.co.jp > > > > 株式会社クオリティア > > https://www.qualitia.co.jp/ > > > > > > -- > Hegh QaQ law' > quvHa'ghach QaQ puS > -- TACHIBANA Masashi QUALITIA CO., LTD. mailto:tachib...@qualitia.co.jp 株式会社クオリティア https://www.qualitia.co.jp/
