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

Barry Leiba | 26 May 16:55 2014
Picon

Re: RFC 7162 on IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)

> A new Request for Comments is now available in online RFC libraries.
>
>         RFC 7162
>
>         Title:      IMAP Extensions: Quick Flag Changes
>                     Resynchronization (CONDSTORE) and
>                     Quick Mailbox Resynchronization (QRESYNC)
>         Author:     A. Melnikov, D. Cridland

And with the publication of RFC 7162, I will ask the Secretariat to
close the qresync working group.  Thanks to all for the participation,
and thanks to Dave Cridland, Eliot Lear, and Alexey Melnikov for being
chairs and authors.

Barry, Applications AD

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

Jayantheesh S B | 14 May 23:00 2014

Contacts and Calendar Sync for IMAP Protocol

Hi All,

 

IMAP Lemonade provides solution for various problems and defines standards for various protocol, which is very useful for mobile environment.

 

We see lot IMAP extension like IDLE, QRESYNC, CONDSTORE are very useful for the end user, since it consumes less battery usage with less mobile data.

 

Similarly, we see apart from Email sync, Contacts and Calendar sync also gives lot of value addition and useful for end user.  

 

Right now we did not see any standard in IMAP for Contacts and Calendar sync. But Gmail does this with their own propriety protocol.  

 

Kindly throw some light on this and suggest if any standard protocol already available for Contact and Calendar Sync ?

 

Regards,

Jay

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Cyrus Daboo | 14 May 18:08 2014

RFC 5524 - what is the proper capability to use?

Hi,
Whilst researching the issue with missing capabilities in the IANA registry 
I ran into the following: RFC 5524 (Extended URLFETCH for Binary and 
Converted Parts) defines a capability string of "URLAUTH=BINARY" in section 
3 and the ABNF in Section 5. However, the IANA section uses 
"URLFETCH=BINARY", which is what IANA has registered at 
http://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml.

The Dovecot server I use advertises "URLAUTH=BINARY".

So which is correct? What do other servers do? What do clients expect?

--

-- 
Cyrus Daboo

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

Stephan Bosch | 14 May 18:08 2014
Picon

Re: METADATA and METADATA-SERVER not in IANA IMAP capability registry.

(ohw, somehow mailing list got dropped from To:)

Cyrus Daboo schreef op 14-5-2014 17:26:
> OK.
>
> I was going to do a quick scan and see if any other capabilities are
> missing. Here is what I found:
>
> AUTH= (3501) Not sure this is needed given it is in the base spec itself.
>
> URLAUTH=BINARY (5524) - actually this is bad. The spec uses
> "URLAUTH=BINARY" in section 3, but uses "URLFETCH=BINARY" in the IANA
> section (which is registered). However, the Dovecot server I use has
> "URLAUTH=BINARY". I do not see any errata for 5524 so this issue needs
> to be addressed.

Ow. That is quite bad indeed.

We didn't notice that either. Dovecot implementation is based on the ABNF.

I know of at least one other server that supports this capability: Cyrus 
(http://www.imapwiki.org/Specs).

I quickly grepped the source code and, luckily, it uses "URLAUTH=BINARY" 
too.

Still, I wonder whether there are others. The list on the imapwiki is 
far from complete, nor up-to-date.

Isode was involved in writing this RFC, but I don't know whether they 
actually implemented it for their product. Dave?

Regards,

Stephan.

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

Stephan Bosch | 14 May 01:09 2014
Picon

METADATA and METADATA-SERVER not in IANA IMAP capability registry.

Hi,

I just noticed that the IMAP METADATA and METADATA-SERVER capabilities
(RFC 5464) are not listed in the IANA IMAP capability registry:

http://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml

Is there a particular reason for that?

Regards,

Stephan.

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

Nigar Sultana | 6 May 20:13 2014
Picon

Identifying new message from QRESYNC RFC5162

Hello All,

The understanding from RFC5162 is response to QRESYNC on selected mailbox returns the status of old message which is modified. 

There are few case for which i did not got much info in RFC5162: 
1. If the state of the old message is not changed but there are some new messages. The query is: Should server intimate the recent message UID information to client? 

2. If the state of the old message is changed but their are no new messages. -- The understanding is server returns the UID of old message which has the flag/state changes

3. IF the state of the old message is changes and there are some new message. The query is: should server intimate the recent messages UID information to client?

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

Gmane