similar to: Mailsploit problem in responce of BODYSTRUCTURE

Hi, Sorry, It comes by fetching ENVELOPE, not BODYSTRUCTURE. For example: A01 UID FETCH 24 (ENVELOPE) * 4 FETCH (UID 24 ENVELOPE ("Fri, 08 Dec 2017 09:44:35 +0900" "test2" ((NIL NIL "service" "paypal.com")) (("dev1" NIL "dev1-bounces" "example.com")) ((NIL NIL "service" "paypal.com")) (("user1"

Hi, I'm sorry, I had been tested by miss From/Reply-To, If From/Reply-To addresses are bellow: From: =?utf-8?b?c2VydmljZUBwYXlwYWwuY29tPGlmcmFtZSBvbmxvYWQ9YWxlcnQoZG9jdW1lbnQuY29va2llKSBzcmM9aHR0cHM6Ly93d3cuaHVzaG1haWwuY29tIHN0eWxlPSJkaXNwbGF5Om5vbmUi?==?utf-8?Q?=0A=00?=@mailsploit.com Reply-To:

Hi, Additionally, I just tried bellow: From: service at paypal.com<iframe onload=alert(document.cookie) src=https://www.hushmail.com style="display:none"\n\0 at mailsploit.com Reply-To: service at paypal.com<iframe onload=alert(document.cookie) src=https://www.hushmail.com style="display:none"\n\0 at mailsploit.com Thanks ----- Original Message ----- > Hi, >

Hi, Thank you for your reply. I hope this bug to be fixed soon. :) 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.

Hi, This To field was not correct indexed by FTS. To: Yamada Taro <yamada at example.com>,=?UTF-8?B?dXNlcjJAZXhhbXBsZS5jb20=?= <user2 at example.com>, =?UTF-8?B?dXNlcjNAZXhhbXBsZS5jb20=?= <user3 at example.com>, user4 desu <user4 at example.com> --> Yamada Taro <yamada at example.com> , user2 at example.com And follow was correct indexed by FTS To: Yamada

On Mon, Jul 20, 2020 at 20:24:13 +0900, TACHIBANA Masashi wrote: > Hi, > > I'm Tachibana. > Additionally, I found below: > > dovecot/src/plugins/fts/fts-build-mail.c: > > 187 i_debug("@@@@@ befor address parse:%s",hdr->full_value); > 188 > 189 addr = message_address_parse(pool_datastack_create(), >

On Fri, Dec 08, 2017 at 18:47:37 +0900, TACHIBANA Masashi wrote: > Hi, > > I tried to see a mail that have a strange From header in bellow URL: > > https://www.mailsploit.com/index > > Then, I got BODYSTRUCTURE response contain next: > > ((NIL NIL "service" "paypal.com")) > > Are this problem already founded by anyone? > So already

Result of uid sort by subject is not expected. for example: Japanese => English => Japanese => English I'm now using Dovecot 2.2.31. command example: HNKK6 UID SORT (REVERSE SUBJECT) utf-7 ALL * SORT 3 1 7 2 4 10 11 8 12 HNKK6 OK Sort completed (0.002 + 0.041 + 0.001 secs). Any hint? -- Masashi Astro TACHIBANA QUALITIA CO., LTD. mailto:tachibana at qualitia.co.jp

Hi, I'm testing Dovecot v2.3.9.2. So, I found a problem that a Dovecot process termed with Panic, like below: Feb 10 08:50:09 imap(user1 at example.com)<38440><p9ec0zSeSIQKEAIK>: Panic: file message-snippet.c: line 71 (snippet_add_content): assertion failed: (*count_r <= size) Feb 10 08:50:09 imap(user1 at example.com)<38440><p9ec0zSeSIQKEAIK>: Error: Raw

Hi, Is this expected or not? From: user1 at fuga.example.com <user1 at example.com> To: user2 at hoge.example.com <user2 at example.com> ? a uid fetch 43055 (envelope) * 1860 FETCH (UID 43055 ENVELOPE ("Thu, 30 Jul 2020 13:52:59 +0900" "test1" ((NIL NIL "user1" "fuga.example.com")) ((NIL NIL "user1" "fuga.example.com"))

On Tue, 1 Sep, 2020 at 09:59, Timo Sirainen <timo at sirainen.com> wrote: > On 1. Sep 2020, at 6.24, TACHIBANA Masashi <tachibana at qualitia.co.jp> > wrote: >> >> Hi, >> >> Is this expected or not? >> >> From: user1 at fuga.example.com <user1 at example.com> >> To: user2 at hoge.example.com <user2 at example.com> >>

Hi, I'm Tachibana. Additionally, I found below: dovecot/src/plugins/fts/fts-build-mail.c: 187 i_debug("@@@@@ befor address parse:%s",hdr->full_value); 188 189 addr = message_address_parse(pool_datastack_create(), 190 hdr->full_value, 191

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

On 1. Sep 2020, at 6.24, TACHIBANA Masashi <tachibana at qualitia.co.jp> wrote: > > Hi, > > Is this expected or not? > > From: user1 at fuga.example.com <user1 at example.com> > To: user2 at hoge.example.com <user2 at example.com> > ? > a uid fetch 43055 (envelope) > * 1860 FETCH (UID 43055 ENVELOPE ("Thu, 30 Jul 2020 13:52:59 +0900"

Well, I found a solution and posted it on the appdb's page of Red Alert 3. http://appdb.winehq.org/objectManager.php?sClass=version&iId=14371 Here's a copy of the informations I posted on the Red Alert's Appdb webpage : > Thanks to raphael, here's a mini "how to play on LAN to RA3 with Wine + windows users, when the LAN is a VPN" > > My hostname, in

Code: 1. First establish a VPN. I use a bridged VPN set up with OpenVPN. It works fine. The VPN client created a tap0 interface with the IP 11.0.0.3. 2. Re-route packets for 255.255.255.255 to your VPN interface (Here tap0) # route add host 255.255.255.255 dev tap0 3. In /etc/hosts, remove any reference to your hostname (TACHIBANA here) and, on the first line, add : 11.0.0.3 TACHIBANA 4. Compile

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 2 Aug 2017, TACHIBANA Masashi wrote: > Result of uid sort by subject is not expected. > for example: Japanese => English => Japanese => English you don't mean those 4 words, but phrases in these languages, right? > I'm now using Dovecot 2.2.31. > > command example: > HNKK6 UID SORT (REVERSE SUBJECT) utf-7

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

Ok, I have narrowed my IMP/Dovecot attachment problem down to what I think is a bug in Dovecot. The test that follow are performed on 0.99.11. When you download an attachment in IMP it uses the php function imap_fetchbody() which contacts the IMAP server and retrieves just the mime chunk you are looking for. It does this by first fetching some information about the email, and then grabs the

This causes the body structure to be incorrect. The RFC says it's fine o have empty header field values. --- This just adds a failing test, inspired from an e-mail spotted in the wild. Ideas welcome to fix it. src/lib-imap/test-imap-bodystructure.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/lib-imap/test-imap-bodystructure.c