Re: REQUESTING FOR SUPPORT TO IMPLEMENT IMAP FETCH COMMAND
Barry Leiba <[email protected]> Mon, 2 Jul 2018 02:45:29 -0400
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <CAC4RtVBXnR0KQXTD8raqS2iYjDCyLiOxwwpPG5JWm+aMmt1R=w@mail.gmail.com> |
As Chris said, we're not here to help you debug your implementation.
But I'll give you some hints for free, after a quick check of what you
sent:
> server: * 1 FETCH (UID 2 FLAGS (\SEEN) RFC822.SIZE 4794 BODY[HEADER] {4348}
A quick eyeball of the .msg file that you included shows that both
your RFC822.SIZE and body header literal length value appear to be way
off. The correct body header size looks like it's a little more than
2700 bytes.
The only reason I'm spending a little time on this is to note that
literals are hard for many people to grasp, and lots of implementers
are confused by them at first.
For example, the first line of the message, <<X-Recent: Recent>>
contributes 18 bytes to the BODY[HEADER] literal -- one byte each for
each of the 16 characters there, plus one for the CR and one for the
LF that follow the string. The next header field (the "Received"
header) adds another 72 + 2 + 69 + 2 -- 72 bytes for the first line, a
CRLF, 69 bytes for the second line, and a CRLF. Repeat this through
the whole header, then add another final CRLF. The literal length
count has to match that total *exactly*.
The other thing to realize is that as soon as there's a parsing
problem, it's likely to cascade and turn into an infinite number of
parsing problems because the client and server are completely out of
sync.
Another hint: It would help you a great deal to have protocol logging
in your client, in addition to relying on the server logging. If you
have a clear record of what you sent and how you got there, it could
show errors more clearly, especially once Outlook becomes confused by
what you sent it.
Barry
On Thu, Jun 14, 2018 at 12:34 AM, sayantan pal <[email protected]> wrote:
> Dear Chris,
>
> This is being a client server conversation:
>
> client: xx UID FETCH 2:8 (UID FLAGS RFC822.SIZE BODY.PEEK[HEADER])
> server: * 1 FETCH (UID 2 FLAGS (\SEEN) RFC822.SIZE 4794 BODY[HEADER] {4348}
> X-Recent: Recent
> Received: by mail-lf0-f48.google.com with SMTP id n15-v6so29788633lfn.10
> for <[email protected]>; Mon, 11 Jun 2018 03:47:22 -0700 (PDT)
> MIME-Version: 1.0
> From: sayantan pal <[email protected]>
> Date: Mon, 11 Jun 2018 16:17:04 +0530
> Message-ID:
> <CACsjV1wAbBpE2dJ_xzB6qUf2O2nsXsqqGuufLd=zG0L13TXeQA@mail.gmail.com>
> Subject: 2
> To: A <[email protected]>
> Content-Type: multipart/alternative; boundary="0000000000006f01d7056e5b788f"
>
>
> )
>
> This reply is somehow wrong w.r.t a server reply and I am getting parse
> error from Outlook. I am attaching a .msg file which my server received by
> the smtp service I have developed. Please check. I have not written all the
> headers in this mail. I am retrieving all the header using mailbee
> extension. It has a property named RawHeaders which retrieves all the
> headers.
>
> Thank You,
> Sayantan Pal
>
> On Wed, Jun 13, 2018 at 11:49 PM, Chris Newman <[email protected]>
> wrote:
>>
>> Implementing a mail server is probably much harder than you think it is.
>> Good luck!
>>
>> I recommend using an IMAP client that provides good diagnostics for
>> testing.. Some programming languages, such as Python, include a limited IMAP
>> client library you can use for simple testing.
>>
>> - Chris
>>
>>
>> On 13 Jun 2018, at 5:29, sayantan pal wrote:
>>
>>> Dear Team,
>>>
>>> I am implementing my own mail server and thereby developing IMAP
>>> service by own following RFC3501 and 1705. I am unable to implement the
>>> IMAP fetch header and body command. I am using Outlook 2007 as email
>>> client. I have the log file for reference. I thereby requesting for your
>>> kind support to successfully fetch the header and body of a mail.
>>>
>>> Thanking You,
>>> Sayantan Pal
>>> _______________________________________________
>>> imapext mailing list
>>> [email protected]
>
>
>
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext
>
_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext