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 > > >
- Re: [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT… sayantan pal
- Re: [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT… sayantan pal
- Re: [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT… Chris Newman
- Re: [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT… Bill Shannon
- Re: [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT… Chris Newman
- [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT IMA… sayantan pal
- Re: [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT… Barry Leiba
- Re: [imapext] REQUESTING FOR SUPPORT TO IMPLEMENT… sayantan pal