narendra singh bisht | 17 Dec 22:31 2014
Picon

Deleting Gmail Starred mail.

Hey Folks,

I am seeing the below behavior in case of Gmail Drafts mail.

Anyone know if it is an intended behavior?

 

I have a Drafts mail with subject M1.

M1 is starred.

When I edit M1 and change subject to M2 from client (mobile device), what I do is APPEND the new M2 and set the /DELETE flag for M1.

But on the Gmail web client, I can still see the M1 intact in Drafts mailbox, I also see M2.

 

Can’t we delete starred mail by setting /DELETE flag?


Thanks in advance

--
Thanks & Regards
-Narendra
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jamie Nicolson (倪志明 | 5 Dec 23:02 2014
Picon

client support for RFC 3516 (BINARY)?

Anyone know of clients that support RFC 3516? It seems like it could be particularly useful for mobile clients, to reduce both download size and CPU usage for base64-decoding.
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Timo Sirainen | 2 Dec 07:39 2014
Picon
Picon

Fetching short text snippet for mails

Nowadays many mail clients want to show about 100 chars of the beginning of mail, so there should be a nice and
efficient way for clients to request this. I'm now wondering what would be a nice IMAP way of implementing
this. Does anyone have some suggestions? There's what I've come up with so far:

a) FETCH n (SNIPPET)
 - Would require writing a new RFC (or just use X-SNIPPET for internal use)

b) FETCH n (ANNOTATION (/vendor/vendor.dovecot.snippet))
 - Would require implementing ANNOTATE, which is a lot of work. But it could also be implemented just
minimally for this specific command.
 - Standardizing vendor.dovecot.snippet would probably require new RFC

c) CONVERT n ("text/vnd.dovecot.snippet" ("length" "100")) BINARY[BODY]
 - Would require implementing CONVERT, which is a lot of work. But it could also be implemented just
minimally for this specific command.
 - Standardizing vnd.dovecot.snippet would probably require new RFC

d) CONVERT n ("text/plain") BINARY[BODY]<0.100>
 - CONVERT RFC says it's legal to convert entire multiparts, but doesn't say exactly what should be done with
them. This is probably a valid use case though.
 - Downside to this compared to others is that this always fetches the first 100 chars, while the others could
also be smarter and skip over quoted text and such.

I think I'm leaning towards b)

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Jayantheesh S B | 12 Nov 23:22 2014

Re: [IMAP] International mailbox names

Dear All,

 

Please share your response on this below query.

 

Regards,

Jay

 

From: Jayantheesh S B
Sent: Tuesday, November 11, 2014 6:21 PM
To: 'imapext <at> ietf.org'
Cc: Jayantheesh S B
Subject: [IMAP] International mailbox names

 

Dear All,

 

As per RFC 3501, for international mailbox names, MODIFIED UTF 7 CHARSET format should be used.

 

we see Yahoo IMAP server is not honoring the request with this charset, whereas other ISP like, Gmail, AOL, Isode supports it.  

 

We are not sure how many providers available in the market really honoring this format.

 

Is there any way email client can know, all the charset supported by the IMAP server?  So, that client can ignore the particular charset format with that server.

 

Please find the log snippet below.

 

Yahoo:

---------

>>> 114 CAPABILITY

<<< #null# ["CAPABILITY", "IMAP4rev1", "ID", "NAMESPACE", "X-ID-ACLID", "UIDPLUS", "LITERAL+", "CHILDREN", "XAPPLEPUSHSERVICE", "XYMHIGHESTMODSEQ", "AUTH=PLAIN", "AUTH=LOGIN", "AUTH=OAUTH2", "AUTH=XYMCOOKIE", "AUTH=XYMECOOKIE", "AUTH=XYMCOOKIEB64", "AUTH=XYMPKI"]

 

>>> 77 STATUS "&C4cLqAvNC6QLvwuvC74-" (UIDVALIDITY)

<<< #77# ["NO", ["CANNOT"], "STATUS Mailbox name(s) cannot be encoded using the specified charset"]

 

>>> 79 CREATE "&C4cLqAvNC6QLvwuvC74-"

<<< #79# ["NO", ["CANNOT"], "CREATE Mailbox name(s) cannot be encoded using the specified charset"]

 

action=create newMailboxName=இந்தியா result=failure reason=#79# ["NO", ["CANNOT"], "CREATE Mailbox name(s) cannot be encoded using the specified charset"]

 

 

Gmail:

---------

 

>>> 74 CAPABILITY

<<< #null# ["CAPABILITY", "IMAP4rev1", "UNSELECT", "IDLE", "NAMESPACE", "QUOTA", "ID", "XLIST",  "CHILDREN", "X-GM-EXT-1", "UIDPLUS",  "COMPRESS=DEFLATE", "ENABLE", "MOVE",  "CONDSTORE", "ESEARCH", "UTF8=ACCEPT"]

 

>>> 49 STATUS "&C4cLqAvNC6QLvwuvC74-" (UIDVALIDITY)

<<< #49# ["NO", ["NONEXISTENT"], "Invalid folder: &C4cLqAvNC6QLvwuvC74- (Failure)"]

 

>>> 51 CREATE "&C4cLqAvNC6QLvwuvC74-"

<<< #51# ["OK", "Success"]

 

action=create newMailboxName=இந்தியா result=success

 

Regards,

Jay

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 12 Nov 00:21 2014

[IMAP] International mailbox names

Dear All,

 

As per RFC 3501, for international mailbox names, MODIFIED UTF 7 CHARSET format should be used.

 

we see Yahoo IMAP server is not honoring the request with this charset, whereas other ISP like, Gmail, AOL, Isode supports it.  

 

We are not sure how many providers available in the market really honoring this format.

 

Is there any way email client can know, all the charset supported by the IMAP server?  So, that client can ignore the particular charset format with that server.

 

Please find the log snippet below.

 

Yahoo:

---------

>>> 114 CAPABILITY

<<< #null# ["CAPABILITY", "IMAP4rev1", "ID", "NAMESPACE", "X-ID-ACLID", "UIDPLUS", "LITERAL+", "CHILDREN", "XAPPLEPUSHSERVICE", "XYMHIGHESTMODSEQ", "AUTH=PLAIN", "AUTH=LOGIN", "AUTH=OAUTH2", "AUTH=XYMCOOKIE", "AUTH=XYMECOOKIE", "AUTH=XYMCOOKIEB64", "AUTH=XYMPKI"]

 

>>> 77 STATUS "&C4cLqAvNC6QLvwuvC74-" (UIDVALIDITY)

<<< #77# ["NO", ["CANNOT"], "STATUS Mailbox name(s) cannot be encoded using the specified charset"]

 

>>> 79 CREATE "&C4cLqAvNC6QLvwuvC74-"

<<< #79# ["NO", ["CANNOT"], "CREATE Mailbox name(s) cannot be encoded using the specified charset"]

 

action=create newMailboxName=இந்தியா result=failure reason=#79# ["NO", ["CANNOT"], "CREATE Mailbox name(s) cannot be encoded using the specified charset"]

 

 

Gmail:

---------

 

>>> 74 CAPABILITY

<<< #null# ["CAPABILITY", "IMAP4rev1", "UNSELECT", "IDLE", "NAMESPACE", "QUOTA", "ID", "XLIST",  "CHILDREN", "X-GM-EXT-1", "UIDPLUS",  "COMPRESS=DEFLATE", "ENABLE", "MOVE",  "CONDSTORE", "ESEARCH", "UTF8=ACCEPT"]

 

>>> 49 STATUS "&C4cLqAvNC6QLvwuvC74-" (UIDVALIDITY)

<<< #49# ["NO", ["NONEXISTENT"], "Invalid folder: &C4cLqAvNC6QLvwuvC74- (Failure)"]

 

>>> 51 CREATE "&C4cLqAvNC6QLvwuvC74-"

<<< #51# ["OK", "Success"]

 

action=create newMailboxName=இந்தியா result=success

 

Regards,

Jay

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 6 Nov 21:40 2014

Re: [IMAP] APPEND Command Usage

Hi All,

Please find the updated version of the Draft attached.

I have addressed the review comments related to ABNF and updated RFC reference section. 

Regards,
Jay
-----Original Message-----
From: Jayantheesh S B 
Sent: Saturday, November 01, 2014 11:26 PM
To: 'Jan Kundrát'; 'imapext <at> ietf.org'
Subject: RE: [imapext] [IMAP] APPEND Command Usage

Hi Jan,

Please find my response inline. 

Regards,
Jay
-----Original Message-----
From: Jan Kundrát [mailto:jkt <at> flaska.net]
Sent: Friday, October 31, 2014 9:08 PM
To: imapext <at> ietf.org
Subject: Re: [imapext] [IMAP] APPEND Command Usage

On Saturday, 1 November 2014 01:37:15 CEST, Jayantheesh S B wrote:
> I have created a short document “IMAP APPENDLIMIT extension” , which 
> proposes the CAPABILITY based solution for the APPEND command usage 
> issue.

I tend to think that using QUOTA for this would be a bit more intuitive, but CAPABILITY will of cousre work as
well. I don't think there's much real-world need for per-mailbox APPEND size limits.

> capability    =/ "APPENDLIMIT=" size-param
> 
> A decimal number indicating the fixed maximum message size in bytes 
> that the server will accept. The syntax of the parameter is as 
> follows, using the augmented BNF notation of [RFC 822]:
> 
> size-param = [1*DIGIT]

You could probably use a nz-number from RFC3501 here. Also, you put the grammar within square brackets
which mean that this is an optional production, and therefore you allow a capability named just
"APPENDLIMIT=". 
Is that what you mean? If so, how should a client interpret that?

[Jay] Thanks for your review comments. This number is not the optional one, hence I will change the grammar
accordingly. 
         As per your comments, I will update the value as well to nz-number. 

With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/



INTERNET-DRAFT                                           Jayantheesh S B 
Intended status: Standards Track                                 Samsung
Expires: May 2015                                   Narendra Singh Bisht
                                                                 Samsung
                                                        November 6, 2014

                      The IMAP APPENDLIMIT Extension
                draft-jayantheesh-imap-appendlimit-extension-01

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, and
derivative works of it may not be created, except to publish it as an
RFC and to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This Internet-Draft will expire on May, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.

Abstract

This memo defines an extension to the IMAP service whereby a server can
advertise its capability, to support maximum mail upload size using
CAPABILITY command.

Jayantheesh & Narendra       Expires May, 2015               [Page 1]

Internet-Draft               IMAP APPENDLIMIT           November 2014

1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.

Example lines prefaced by "C:" are sent by the client and ones prefaced
by "S:" by the server.  The five characters [...] means that something
has been elided.

2. Overview

Several IMAP server have limitation in mail upload size which is not
published to the email client.  When email client APPEND a mail with
huge attachments, it fails due to size restriction set by the IMAP
server.  This results in unnecessary resource usage, especially in the 
mobile device environment, appending mail with huge attachment consumes
device resources like device battery power and mobile data.

The IMAP APPENDLIMIT extension provides an ability to advertise maximum
upload size allowed by the IMAP server, so that email client knows the
size limitation beforehand.

As part of CAPABILITY response, IMAP server should publish the supported
mail upload size.  The following example demonstrates its usage.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
S: t1 OK foo

By looking at the upload size restriction set by the IMAP server, client
SHALL not try to upload mail more than advertised limit in the APPEND
command.

3. Formal syntax

The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234] including the core
rules in Appendix B.1.  [RFC3501] defines the non-terminals
"capability".

Jayantheesh & Narendra       Expires May, 2015               [Page 2]

Internet-Draft               IMAP APPENDLIMIT           November 2014

Except as noted otherwise, all alphabetic characters are case-
insensitive.  The use of upper or lower case characters to define
token strings is for editorial clarity only.  Implementations MUST
accept these strings in a case-insensitive fashion.

capability    =/ "APPENDLIMIT=" nz-number

A non zero number indicating the fixed maximum message size in bytes
that the server will accept.  The syntax of the parameter follows the
augmented BNF notation of [RFC5322, RFC6854].  If the capability is
omitted, no information is conveyed about the server's fixed maximum
message size.

4. Security Consideration

It is believed that this extension doesn't add any new security
considerations that are not already present in the base IMAP
protocol [RFC3501].

5. IANA Considerations

The IANA is requested to add APPENDLIMIT to the IMAP4 Capabilities
Registry.  [[Note to RFC-editor: please remove the following before
publication: This registration should take place at the following
location: http://www.iana.org/assignments/imap4-capabilities]]

6. References

6.1 Normative References

The following documents contain definitions or specifications that
are necessary to understand this document properly

[RFC2119]  Bradner, "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, Harvard University, March
           1997.

[RFC3501]  Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
           University of Washington, March 2003

[RFC5234]  Crocker, Overell, "Augmented BNF for Syntax
           Specifications: ABNF", RFC 5234, Brandenburg
           Internetworking, Demon Internet Ltd, January 2008

[RFC5322]  P. Resnick, Ed, "Internet Message Format", RFC 5322,
           Qualcomm Incorporated, October 2008

[RFC6854]  B. Leiba, "Update to Internet Message Format to Allow
           Group Syntax in the "From:" and "Sender:" Header Fields",
           RFC 6854, Huawei Technologies, March 2013

Jayantheesh & Narendra       Expires May, 2015               [Page 3]

Internet-Draft               IMAP APPENDLIMIT           November 2014

6. 2 Informative References

The following documents describe related protocols:

[RFC2087]  Myers, J., "IMAP4 QUOTA extension", RFC 2087,
           January 1997

7. Acknowledgement

TBD

8. Author's Address

Jayantheesh S B
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: jayantheesh.sb <at> gmail.com

Narendra Singh Bisht
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: narendrasingh.bisht <at> gmail.com

(RFC Editor: Please delete everything after this point)
Changes since -00

    - Updated the latest RFC reference section

    - ABNF grammar updated 

    - Format modified
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 29 Oct 17:26 2014

[IMAP] APPEND Command Usage

Dear All,

 

We are facing an issue while uploading (APPEND) a mail to a IMAP mailbox.

 

We see IMAP server rejects the APPEND command, if the mail size exceeds certain limit.

 

Email client is not aware of the maximum size supported by the IMAP server.

 

Is there any way for email client to know the IMAP server maximum supported size limit  ?

 

Please find the success and failure APPEND command transaction below.

 

Failure Transaction

>>> 290 APPEND "Drafts" (\SEEN \DRAFT) {50287114}

<<< #290# ["BAD", "parse error: request too long"]

 

Successful Transaction

>>> 90 APPEND "Drafts" (\SEEN \DRAFT) {42222}

<<< #+# [" "]

<<< #null# ["49", "EXISTS"]

<<< #90# ["OK", ["APPENDUID", "1", "5340"], "APPEND completed"]

 

Regards,

Jay

 

 

 

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
RFC Errata System | 27 Aug 01:40 2014

[Errata Verified] RFC5255 (4092)

The following errata report has been verified for RFC5255,
"Internet Message Access Protocol Internationalization". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5255&eid=4092

--------------------------------------
Status: Verified
Type: Technical

Reported by: Chris Newman <chris.newman <at> oracle.com>
Date Reported: 2014-08-26
Verified by: Barry Leiba (IESG)

Section: 3.5

Original Text
-------------
    lang-range-quoted = astring
        ; Once any literal wrapper or quoting is removed, this
        ; follows the language-range rule in [RFC4647]

Corrected Text
--------------
    lang-range-quoted = astring
        ; Once any literal wrapper or quoting is removed, this
        ; follows the language-range rule in [RFC4647],
        ; or is the 7-character string "default"

Notes
-----
This change makes the ABNF comment match the prose and example in section 3.2.

--------------------------------------
RFC5255 (draft-ietf-imapext-i18n-15)
--------------------------------------
Title               : Internet Message Access Protocol Internationalization
Publication Date    : June 2008
Author(s)           : C. Newman, A. Gulbrandsen, A. Melnikov
Category            : PROPOSED STANDARD
Source              : Internet Message Access Protocol Extension
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

RFC Errata System | 27 Aug 01:31 2014

[Technical Errata Reported] RFC5255 (4092)

The following errata report has been submitted for RFC5255,
"Internet Message Access Protocol Internationalization".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5255&eid=4092

--------------------------------------
Type: Technical
Reported by: Chris Newman <chris.newman <at> oracle.com>

Section: 3.5

Original Text
-------------
    lang-range-quoted = astring
        ; Once any literal wrapper or quoting is removed, this
        ; follows the language-range rule in [RFC4647]

Corrected Text
--------------
    lang-range-quoted = astring
        ; Once any literal wrapper or quoting is removed, this
        ; follows the language-range rule in [RFC4647],
        ; or is the 7-character string "default"

Notes
-----
This change makes the ABNF comment match the prose and example in section 3.2.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5255 (draft-ietf-imapext-i18n-15)
--------------------------------------
Title               : Internet Message Access Protocol Internationalization
Publication Date    : June 2008
Author(s)           : C. Newman, A. Gulbrandsen, A. Melnikov
Category            : PROPOSED STANDARD
Source              : Internet Message Access Protocol Extension
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

narendra singh bisht | 22 Aug 21:26 2014
Picon

How to delete a mail permanently without going to trash

I want to delete a mail from ,say, Drafts folder permanently without going to Trash to delete it again.
I tried EXPUNGE command with Gmail, but it moves the deleted mail to Trash.

Is there any way/command to delete a mail permanently without going to Trash folder.

Thanks in advance.

--
Thanks & Regards
-Narendra
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
IESG Secretary | 27 May 19:32 2014
Picon

WG Action: Conclusion of IMAP QRESYNC Extension (qresync)

The IMAP QRESYNC Extension (qresync) working group in the Applications 
Area has concluded. The IESG contact persons are Barry Leiba and Pete 
Resnick.

With the publication of RFC 7162, the qrecync working group has
completed its work and will be closed. I thank Dave Cridland and
Eliot Lear for chairing, Alexey Melnikov for editing the updated
document, and all participants for their work on the update.

As always, the <imapext <at> ietf.org> mailing list will remain open for
further discussion of IMAP extensions.

Barry Leiba, Applications AD

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext


Gmane