mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

[Imap-protocol] Another gmail bug

E-mail headers
From: Andris Reinman <andris.reinman@gmail.com>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:53 -0000
Message-ID: EB485B74-F035-44E5-BAAD-20F9A800DF24@gmail.com permalink / raw / eml / mbox 
Hello,

It seems that recently everyone has been starting to use this mailing list as a GMail issue tracker, so heres my findings as well (do not know if these are known issues or not).

1. If you EXAMINE a mailbox and FETCH a message with (FLAGS BODY[HEADER.FIELDS ?]) then the returned FLAGS list *always* includes the \Seen flag even if the message does not have this flag set. If you omit the headers part and just FETCH (FLAGS) then the \Seen flag is returned as it should. Notice that I am using BODY and not BODY.PEEK to fetch the headers. The actual flags are not changed as the mailbox was EXAMINEd not SELECTed but for this call the response includes the invalid \Seen.

tag EXAMINE INBOX
tag FETCH 123 (FLAGS BODY[HEADER.FIELDS (?))
* 123 FETCH (FLAGS (\Seen))
tag FETCH 123 (FLAGS)
* 123 FETCH (FLAGS ()) <- no \Seen flag anymore

2. If you have a message with an message/rfc822 attachment and the attached message does not have In-Reply-To set in its headers, then the returned ENVELOPE for this attachment uses ?NIL? as a String instead of NIL for the In-Reply-To value.

tag FETCH 123 (BODYSTRUCTURE)
* 123 FETCH (BODYSTRUCTURE ? (?MESSAGE? ?RFC822? ? (NIL NIL ? ?NIL? <- Should be NIL, not ?NIL"

I have also set up simple test cases (as node.js scripts) to verify these bugs: https://gist.github.com/andris9/592d69a40e970ea32597

Best regards,
Andris Reinman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140730/9bbf4329/attachment.html>
Reply
E-mail headers
From: blong@google.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:53 -0000
Message-ID: CABa8R6uOdr2KxOAEYV5n9ZR27UT+_rjxfmyh0QuXka8QAEUH2g@mail.gmail.com permalink / raw / eml / mbox 
bugs filed.

Brandon


On Wed, Jul 30, 2014 at 1:34 AM, Andris Reinman <andris.reinman@gmail.com>
wrote:

> Hello,
>
> It seems that recently everyone has been starting to use this mailing list
> as a GMail issue tracker, so heres my findings as well (do not know if
> these are known issues or not).
>
> 1. If you EXAMINE a mailbox and FETCH a message with
> (FLAGS BODY[HEADER.FIELDS ?]) then the returned FLAGS list *always*
> includes the \Seen flag even if the message does not have this flag set. If
> you omit the headers part and just FETCH (FLAGS) then the \Seen flag is
> returned as it should. Notice that I am using BODY and not BODY.PEEK to
> fetch the headers. The actual flags are not changed as the mailbox was
> EXAMINEd not SELECTed but for this call the response includes the invalid
> \Seen.
>
> tag EXAMINE INBOX
> tag FETCH 123 (FLAGS BODY[HEADER.FIELDS (?))
> * 123 FETCH (FLAGS (\Seen))
> tag FETCH 123 (FLAGS)
> * 123 FETCH (FLAGS ()) <- no \Seen flag anymore
>
> 2. If you have a message with an message/rfc822 attachment and the
> attached message does not have In-Reply-To set in its headers, then the
> returned ENVELOPE for this attachment uses ?NIL? as a String instead of NIL
> for the In-Reply-To value.
>
> tag FETCH 123 (BODYSTRUCTURE)
> * 123 FETCH (BODYSTRUCTURE ? (?MESSAGE? ?RFC822? ? (NIL NIL ? ?NIL? <-
> Should be NIL, not ?NIL"
>
> I have also set up simple test cases (as node.js scripts) to verify these
> bugs: https://gist.github.com/andris9/592d69a40e970ea32597
>
> Best regards,
> Andris Reinman
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140730/c1b3f25c/attachment.html>
Reply