Re: [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT IMAP FETCH COMMAND

sayantan pal <sayantan.pal19@gmail.com> Mon, 02 July 2018 06:49 UTC

Return-Path: <sayantan.pal19@gmail.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40122130E17 for <imapext@ietfa.amsl.com>; Sun, 1 Jul 2018 23:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04z-3G6gpsyG for <imapext@ietfa.amsl.com>; Sun, 1 Jul 2018 23:49:39 -0700 (PDT)
Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826D6130DF4 for <imapext@ietf.org>; Sun, 1 Jul 2018 23:49:38 -0700 (PDT)
Received: by mail-lf0-x243.google.com with SMTP id n96-v6so11121647lfi.1 for <imapext@ietf.org>; Sun, 01 Jul 2018 23:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VD0FjvNa5ysoAYdM779+qzyCzn8dScc2uWBzBa02mRU=; b=IDQqcgmBB11qIMkzg0tsRjE4SYLFbI/00lJM/cZQLyvS9NlY+XyS0ihAajMjugMHD+ vwzK+q2sXl9UttKUv7Q/2ZqEmTTuCx8B6naEk6b+vIK49RCF+ihb9jvlp2DEwwGDWWam Z4LsEx1VQKstN7nwZlPEh7Jqz587/PFluyTZfrIeoV7cZrnHhFvuxrVs14YNvIixsbZi mqcd5Sq7wkADuV/+E/KZS0EHnSh88w5+uT7Bmx5JmgPcWzuEc4DDaJN6KY05vfgpBL8A S6sV7r7COGWf/oR5jsXMSYtxAqjtvHoFUxtZn0xq8ctKS1HJoNIeuZ9VrVggO5NyoviD cenA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VD0FjvNa5ysoAYdM779+qzyCzn8dScc2uWBzBa02mRU=; b=GC7MhuxOl0N05PnXkN/TbWzt5VF/0gylLYPxmIn3WzWNyOOadp1yYuDYBKrZ4QfDSX iILyReZcjKJ1vce44BJQcFes9YN1ZTI68uJdCDq3VwZfOLS7W0+h+Wh9Toa1xY6w4dkm ZfQ0aiGr014Wq1+SSOa5bpav+TBRjveQ2YmF60OoT7LLtzc4K5g1Un85OEQawvWzU8CJ rEntyiaufNsNFJz6gFdH1yBqz2ldvaaywcuVnjdFHzczWlWBrOy00J+aDC1H17WaVK1k oDxYZN9U/c3ADSMcy/KBeNCMRv0aT65gaIKEU8qMBGi5sDtMmuvAsC7O9w9VAn5kTNJ/ jMwQ==
X-Gm-Message-State: APt69E34xK83gbWNbmYD6kT4AWaHU3YI/cfE4A6Px2YkQLdhJgW/ntZS Luqmwp/5p/unjzkK+LEVnrjc8cQAci9mO3caySQ=
X-Google-Smtp-Source: AAOMgpeYL8e6B3JsmeRQR1rNEtqvvmsc4U2Nhkkn17Lzu6qwqM2L6adfLLQtYi+REwPPWRja/Wi9z3zCykjql/sBLhc=
X-Received: by 2002:a19:e803:: with SMTP id f3-v6mr15162289lfh.84.1530514176686; Sun, 01 Jul 2018 23:49:36 -0700 (PDT)
MIME-Version: 1.0
References: <CACsjV1zdMJkgsUFrdB8tUbkLw-_N0JzVxd5zQUErV_LhxT_R_Q@mail.gmail.com> <3358ED02-9B0E-419D-9BD2-EA9FD459D7B6@oracle.com> <CACsjV1z3GVT7vAYDLs1SMU_VXtaZvYBpLv-RSDj3UxrLrL879A@mail.gmail.com> <CAC4RtVBXnR0KQXTD8raqS2iYjDCyLiOxwwpPG5JWm+aMmt1R=w@mail.gmail.com>
In-Reply-To: <CAC4RtVBXnR0KQXTD8raqS2iYjDCyLiOxwwpPG5JWm+aMmt1R=w@mail.gmail.com>
From: sayantan pal <sayantan.pal19@gmail.com>
Date: Mon, 02 Jul 2018 12:23:48 +0530
Message-ID: <CACsjV1ydxn1Vo0hEs=uMHDO7aZQ7Gqq7J+G4-xJJzyentvm0_w@mail.gmail.com>
To: barryleiba@computer.org
Cc: Chris Newman <chris.newman@oracle.com>, imapext@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d33cc0056ffe99a8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/ICIoaGz8Ob_ujcVZX2aLzKiCdo8>
X-Mailman-Approved-At: Mon, 02 Jul 2018 09:42:43 -0700
Subject: Re: [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT IMAP FETCH COMMAND
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jul 2018 06:49:42 -0000

Dear Barry Leiba,

    Thank You so much for your highness. You are absolutely correct. The
problem was in header size. I solved this issue. Previously I coded to
calculate the header byte count. Later I found it is actually calculating
the character length. This problem has been solved. The present problem is
in folder synchronisation. I am working on that. If you allow me I can
share the problem.

Thank You,
Sayantan Pal

On Mon, Jul 2, 2018 at 12:15 PM Barry Leiba <barryleiba@computer.org> wrote:

> 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 <sayantan.pal19@gmail.com>
> 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 <A@cogitomail.com>; Mon, 11 Jun 2018 03:47:22 -0700 (PDT)
> > MIME-Version: 1.0
> > From: sayantan pal <sayantan.pal19@gmail.com>
> > Date: Mon, 11 Jun 2018 16:17:04 +0530
> > Message-ID:
> > <CACsjV1wAbBpE2dJ_xzB6qUf2O2nsXsqqGuufLd=zG0L13TXeQA@mail.gmail.com>
> > Subject: 2
> > To: A <A@cogitomail.com>
> > 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 <chris.newman@oracle.com>
> > 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
> >>> imapext@ietf.org
> >
> >
> >
> > _______________________________________________
> > imapext mailing list
> > imapext@ietf.org
> > https://www.ietf.org/mailman/listinfo/imapext
> >
>