Stu Brandt | 6 May 00:18 2015

Re: IMAP REPLACE extension

Pete -

Thanks for your response. My comments are inline.

On 5/5/15 2:35 PM, Pete Maclean wrote:
> Stu,
>
> This is a good start indeed but I find a few things to mention.
>
> Is UID REPLACE valid in the authenticated state?  My assumption would be
> that it is but it might be good for the text to make that explicit.

I was hoping that section 3.5 would have covered that. Specifically my 
statement of...

  "Unlike the APPEND command which is valid in the authenticated state,
    the REPLACE command MUST only be valid in the selected state. "

...was intended to answer your question. In my proposal, I'm intending 
to say it's valid ONLY in SELECTED state.  Does that wording cover it 
for you or can you help detail the ambiguity in the wording?

>
> Can REPLACE be used to replace a message in a mailbox other than the one
> the client has selected?  Surely it should not be.  Which perhaps
> suggests that REPLACE should not have a mailbox-name argument.

Yeah, I spent a lot of time going back and forth on this question.
Ultimately where I ended up is that since the problems that REPLACE 
solves (specified in section 2) exist regardless of whether the new 
(Continue reading)

Michael M Slusarz | 4 May 07:56 2015

IMAP SNIPPET extension (initial draft)

A little late, but here's my efforts on an initial draft regarding  
SNIPPET so that it can be added to the WG.

Based on the conversation that occurred on this list a few months  
back, I made these editorial decisions:

   - Extend FETCH: several people said this would not be implemented  
if it used ANNOTATE/CONVERT
   - Allow multiple different algorithms

I think the main point of discussion going forward is whether to  
explicitly define an algorithm for snippet generation (i.e. threading)  
or to allow the default algorithm to be entirely server-defined (i.e.  
FUZZY searching).  For now, I went with the latter, and even named it  
FUZZY.

Another issue regards the size of snippet return.  In this draft, this  
is not client configurable.  For the FUZZY algorithm, I used 150  
octets as SHOULD and MUST NOT ever exceed 300 octets.  (Snippet data  
must be returned as UTF-8).

But hopefully this is a decent enough starting point where it can be  
used to continue the discussion going forward.

michael

----------------

Internet Engineering Task Force                          M. Slusarz, Ed.
Internet-Draft                                                   Dovecot
(Continue reading)

Stu Brandt | 29 Apr 15:45 2015

IMAP REPLACE extension

As promised, here's a draft of a REPLACE extension.

Since the most obvious question is going to be "Why REPLACE and not an 
option on APPEND?",  I'll answer it straight away...

First, APPEND is valid in the authenticated state. REPLACE requires the 
selected state. I chose not to generate a mixed state scenario for 
APPEND. Secondly, REPLACE is similar to MOVE in that it avoids a number 
of issues that come with a serialized non-atomic sequence attempting to 
perform a single operation. MOVE is not an option on COPY, so I chose to 
follow the same precedent.

Here's the writeup.

------------------------------------------------------------------------

Network Working Group                                          S. Brandt
Internet-Draft                                                       AOL
Intended status: Standards Track                          April 29, 2015
Expires: October 31, 2015

                          IMAP REPLACE Extension
                       draft-brandt-imap-replace-00

Abstract

    This document defines an IMAP extension which can be used to replace
    an existing message in a message store with a new message.  Message
    replacment is a common operation for clients that automatically save
    drafts or notes as a user composes them.
(Continue reading)

Naren | 14 Apr 17:11 2015
Picon

Re: imapext Digest, Vol 32, Issue 14

The charter text looks ok.
Both the deliverable are related to each other.

Thanks
-Naren

On Tue, Mar 31, 2015 at 3:00 PM, <imapext-request <at> ietf.org> wrote:
Send imapext mailing list submissions to
        imapext <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/imapext
or, via email, send a message with subject or body 'help' to
        imapext-request <at> ietf.org

You can reach the person managing the list at
        imapext-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of imapext digest..."

Today's Topics:

   1. Charter Proposal for a new IMAP related Working Group
      (Alexey Melnikov)


---------- Forwarded message ----------
From: Alexey Melnikov <alexey.melnikov <at> isode.com>
To: IMAPEXT <imapext <at> ietf.org>
Cc: 
Date: Tue, 31 Mar 2015 03:08:19 +0100
Subject: [imapext] Charter Proposal for a new IMAP related Working Group
Hi,

I've asked Barry earlier what he would like to do about
draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he
asked for a charter for a new short term IMAP related WG. Here is a
proposal:


The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands
for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for
transferring blocks of data. When sending a literal from a client to a server,
RFC 3501 requires the client to wait for the server to send a command
continuation request between sending the octet count and the string data.
This complicates client implementations and resulted in definition
of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form
of literal which does not require this network round trip. While this
extension is quite commonly supported by servers, some implementations
decided to disable it because it is frequently abused by naive clients
that try to upload big messages without checking whether servers can
accept big messages.

The IMAP APPEND extension (imapappend) working group has two related
deliverables which are targeted at improving the current situation. One
deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03
and defines a way for servers to announce APPEND limit for a particular
server or a particular mailbox. The second deliverable is based on
draft-melnikov-rfc2088bis-01. It describes implementation choices for
server supporting LITERAL+ extension and also defines LITERAL- extension
which have similar properties, but is easier for servers to implement
while preventing denial of service attacks from malicious and naive IMAP
clients. Both deliverables will be Standards Track documents.

As part of the protocol development, implementation experience on both
the client and server side is highly desireable, so that the actual
operational value of this extension can be assessed. The working group
will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

------
Comments:


1) I don't particularly care if LITERAL- is standardized or not, but I would like the problem to be solved. If we can't agree on LITERAL-, then draft-melnikov-rfc2088bis can just become a revision of LITERAL+.

2) I've also heard some interest in standardizing the SNAPSHOT facility. I am ambivalent on whether it should be added to the above. (If you think it should, please suggest a new paragraph to add). I would like to keep the charter to no more than 3 deliverables.

Any opinions on the proposal?

Best Regards,
Alexey



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



_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
narendra singh bisht | 2 Apr 17:19 2015
Picon

Problem with Yahoo SMTP server SIZE attribute.

Hi all,

I am facing a problem with Yahoo account.

Yahoo SMTP server broadcast the SIZE as "SIZE 41697280".

So when I am trying to send a mail with ~28.8 MB of attachment to Gmail/AOL,
sending of the mail succeeds but I am getting a MAILER-DAEMON saying :
Remote host said:
552-5.2.3 Your message exceeded Google's message size limits.


What should I do, as a mail client. Should i not honor the SIZE attribute and use 25 MB as the upper limit?

--
Thanks & Regards
-Naren
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Alexey Melnikov | 31 Mar 04:08 2015

Charter Proposal for a new IMAP related Working Group

Hi,

I've asked Barry earlier what he would like to do about
draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he
asked for a charter for a new short term IMAP related WG. Here is a
proposal:

The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands
for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for
transferring blocks of data. When sending a literal from a client to a server,
RFC 3501 requires the client to wait for the server to send a command
continuation request between sending the octet count and the string data.
This complicates client implementations and resulted in definition
of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form
of literal which does not require this network round trip. While this
extension is quite commonly supported by servers, some implementations
decided to disable it because it is frequently abused by naive clients
that try to upload big messages without checking whether servers can
accept big messages.

The IMAP APPEND extension (imapappend) working group has two related
deliverables which are targeted at improving the current situation. One
deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03
and defines a way for servers to announce APPEND limit for a particular
server or a particular mailbox. The second deliverable is based on
draft-melnikov-rfc2088bis-01. It describes implementation choices for
server supporting LITERAL+ extension and also defines LITERAL- extension
which have similar properties, but is easier for servers to implement
while preventing denial of service attacks from malicious and naive IMAP
clients. Both deliverables will be Standards Track documents.

As part of the protocol development, implementation experience on both
the client and server side is highly desireable, so that the actual
operational value of this extension can be assessed. The working group
will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

------
Comments:

1) I don't particularly care if LITERAL- is standardized or not, but I 
would like the problem to be solved. If we can't agree on LITERAL-, then 
draft-melnikov-rfc2088bis can just become a revision of LITERAL+.

2) I've also heard some interest in standardizing the SNAPSHOT facility. 
I am ambivalent on whether it should be added to the above. (If you 
think it should, please suggest a new paragraph to add). I would like to 
keep the charter to no more than 3 deliverables.

Any opinions on the proposal?

Best Regards,
Alexey

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

Pete Maclean | 20 Mar 17:10 2015

Re: The IMAP APPENDLIMIT Extension - version 04

Thanks, Bron.  I am aware of Java's lack of unsigned integers having 
had to work around it before.  (I find it a curious lack although I 
have no idea of the rationale behind it.)  So, yes, I come to agree 
that UINT64_MAX would be a poor choice, never mind an unnecessarily 
large one.  So how about a compromise of, say, UINT48_MAX?

Pete

At 02:18 AM 3/19/2015, Bron Gondwana wrote:
>On Thu, Mar 19, 2015, at 09:02 AM, Pete Maclean wrote:
> >
> > >1.  APPENDLIMIT value should be UINT32_MAX or UINT64_MAX ?
> >
> > UINT64_MAX
>
>Most of the world is going with half that in new standards, for
>compatibility with languages that offer a signed 64 bit numeric value
>only (aka - java 7 and below).  It makes mapping the values through said
>languages a lot easier, and 63 bits should be enough for anyone (or
>something).
>
>Alternatively, there's 53 bits, which is the maximum that javascript can
>represent:
>
>http://stackoverflow.com/questions/307179/what-is-javascripts-highest-integer-value-that-a-number-can-go-to-without-losin
>
>It's not going to matter in practice, because that's still fricking huge.
>
>Bron.
>
>--
>   Bron Gondwana
>   brong <at> fastmail.fm
>
>_______________________________________________
>imapext mailing list
>imapext <at> ietf.org
>https://www.ietf.org/mailman/listinfo/imapext

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

Pete Maclean | 18 Mar 23:02 2015

Re: The IMAP APPENDLIMIT Extension - version 04


>1.  APPENDLIMIT value should be UINT32_MAX or UINT64_MAX ?

UINT64_MAX

>2.  APPENDLIMIT value in SELECT/STATUS response: Whether APPENDLIMIT 
>is needed in both SELECT

I don't feel strongly about this but, considering the recent 
arguments on the matter, I lean toward having it only in STATUS.

Pete Maclean

>and STATUS response?
At 03:47 PM 3/18/2015, Jayantheesh S B wrote:
>All,
>
>Can you please share your views regarding the below item to come to 
>a consensus?
>
>1.  APPENDLIMIT value should be UINT32_MAX or UINT64_MAX ?
>
>2.  APPENDLIMIT value in SELECT/STATUS response: Whether APPENDLIMIT 
>is needed in both SELECT and STATUS response?
>
>Please share your thoughts.
>
>Regards,
>Jay
>
>-----Original Message-----
>From: Alexey Melnikov [mailto:alexey.melnikov <at> isode.com]
>Sent: Monday, March 09, 2015 8:00 AM
>To: Michael M Slusarz; imapext <at> ietf.org
>Subject: Re: [imapext] The IMAP APPENDLIMIT Extension - version 04
>
>Hi,
>After thinking more about this topic (I might have changed my 
>position on a few minor issues):
>
>On 06/03/2015 21:27, Michael M Slusarz wrote:
> > Quoting Chris Newman <chris.newman <at> oracle.com>:
> >
> >> Q for list: If the server has a message larger than UINT32_MAX in the
> >> store and a client tries to fetch it, should the server just go ahead
> >> and violate the base-spec's UINT32_MAX limit or should the data be
> >> NIL unless the client uses ENABLE to tell the server it accepts
> >> larger-than-uint32-max literals on messages? If this extension fixes
> >> that base spec limitation in addition to enabling better client
> >> diagnostics for overlarge messages, I think that's cool.
> >
> > I agree that the max limit should be extended.  However, it doesn't
> > seem like the APPENDLIMIT document is the (best) place to do that
> > since burying a change in a document devoted to APPEND behavior that
> > affects a general IMAP limit, e.g. changing FETCH behavior, doesn't
> > seem to be the model of clarity.
>I agree.
> >
> >> Having two different ways to access a per-folder limit is a violation
> >> of good protocol design practices. Specifically 3.1 and 3.2 provide
> >> two ways to access the same appendlimit. I believe the document would
> >> be improved by the removal of section 3.1. Some problems with the
> >> current two-mechanism proposal:
> >
> > +1.  This is what I had written about previously.
>Not really a violation, because the data is the same whether 
>returned by STATUS or SELECT
> >> * Which limit will the client use if the two limits are different?
> >> * Should a client SELECT a mailbox before doing an APPEND? This is
> >> not required by the base spec and is less efficient. The presence of
> >> section 3.1 implies a client should do this. I do not think a client
> >> should do this.
> >> Removing section
> >> 3.1 removes this issue as a problem.
> >
> > More important... this may be a non-trivial value to calculate for the
> > server.
>(Depending on how accurate a server might want to make this information.
>This is a quality of implementation issue.)
> >
> >> * The addition of APPENDLIMIT as a response to SELECT even for
> >> clients that don't understand it penalizes all clients with
> >> unnecessary network traffic.
> >> While it's not a big response by itself, we're starting to get a
> >> death-of-1000-cuts problem with SELECT responses, so unless it's
> >> really important (and in most cases I think the capability is good
> >> enough) I'd rather not add that extra traffic (and potential battery
> >> life cost on mobile devices).
> >
> > To me the most common use case for APPEND is sent-mail saving.
> > Generally this will occur in one of two situations:
> >
> > 1.) Replying/Forwarding to an existing message. In these cases, it is
> > likely that at the time of sending that the client will still be in
> > the same mailbox - most people tend to write a message in one sitting
> > so they won't change their mailbox - and this mailbox will NOT be the
> > sent-mail mailbox.
> > 2.) Composing a New Message. The client IMAP connection may be in
> > either a selected or non-selected state depending on their previous
> > actions in the client UI, but odds are high that they are unlikely to
> > be in the Sent mailbox.
> >
> > In either of these cases it is going to be a MUCH less expensive
> > operation to grab the APPENDLIMIT with a STATUS(-like) call followed
> > by an APPEND rather than SELECTing the mailbox and then APPENDing.
> > Not only will the client code have to do the normal state
> > initalization of opening a mailbox, which probably isn't necessary
> > from a UI perspective since the user doesn't care about the
> > contents/status of the sent-mail mailbox, but this initialization
> > could involve other delays if the server is doing things like
> > on-demand new message tasks within that mailbox (e.g. header caching,
> > search indexing).
> >
> > TLDR: APPENDs to a sent mail mailbox are the most common real-world
> > APPEND action, and these APPENDs rarely occur when in selected state
> > within the sent mail mailbox.
>Ok, I don't have a strong preference one way or another, but I find 
>your argument convincing and I can live without APPENDLIMIT be 
>returned on SELECT.
> >> * The document does not state if the APPENDLIMIT response is a
> >> MUST/SHOULD/MAY.
> >> If it's a MAY, my server implementation won't send it, in which case
> >> why is it in the spec? If it's a SHOULD, I'll include a product
> >> option so admins can disable it. If it's a MUST, I object to
> >> advancing the proposal.
> >
> > Agree.  It can be argued that this would actually make things slightly
> > slower for the vast majority of clients, with no (or microscopic) gain
> > to APPENDLIMIT aware clients.
>Right.
>
>   [snip]
>
>
>_______________________________________________
>imapext mailing list
>imapext <at> ietf.org
>https://www.ietf.org/mailman/listinfo/imapext

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

Valerio Valerio | 12 Mar 08:06 2015

NIL boundary in multipart emails

Hi All,

while chasing a bug in our IMAP implementation noticed that one server 
replies to a BODYSTRUCTURE fetch command with a structure containing NIL 
boundary for multipart emails, e.g:

SEND UID FETCH 36 (FLAGS UID INTERNALDATE RFC822.SIZE BODYSTRUCTURE 
RFC822.HEADER)
RECV: * 7 FETCH (FLAGS (\Unseen) UID 36 INTERNALDATE "12-Mar-2015 
09:25:30 +0300" RFC822.SIZE 18142 BODYSTRUCTURE (("text" "plain" 
("charset" "utf-8") NIL NIL "quoted-printable" 34433 0 NIL NIL NIL 
NIL)("text" "html" ("charset" "utf-8") NIL NIL "quoted-printable" 108403 
0 NIL NIL NIL NIL) "alternative" ("boundary" NIL)) RFC822.HEADER {2558}

I can gracefully handle this situation, but by my understanding of RFC 
2046[1], this is invalid, first the boundary does exist and is not empty 
and in case it was empty server should send something like "". Since 
this server always reply like that and is a big provider in 
Russia(mail.ru) I was wondering if I'm missing something here ?

Thanks in advance.

Best regards,

Valério

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 10 Mar 22:08 2015

IMAP COMPRESS=DEFLATE Support

All,

 

I am facing an issue with IMAP COMPRESS=DEFLATE feature. After COMPRESS DEFLATE command,

deflate stream is opened and sent the NAMESPACE request to server.  Request is sent successfully, but response was not received.

 

After Socket read timeout, it’s coming out from the Read block. Currently I am using java.util.zip.* package for creating the deflate stream.

Please share if you face any similar issues, during the implementation.  Kindly throw some light on this issue.

 

Log Snippet:

03-10 17:42:31.482 18173 18182 D MailTransport: *** IMAP open demo.isode.com:143

 

03-10 17:42:32.072 18173 18182 D MailTransport: >>> 1 CAPABILITY

03-10 17:42:32.392 18173 18182 D Email   : <<< #null# ["CAPABILITY", "IMAP4rev1", "UIDPLUS", "LITERAL+", "UNSELECT", "NAMESPACE", "SORT", "BINARY", "MULTIAPPEND", "THREAD=ORDEREDSUBJECT", "THREAD=REFERENCES", "ESEARCH", "LIST-EXTENDED", "IDLE", "URLAUTH", "CATENATE", "CONDSTORE", "QRESYNC", "ENABLE", "STARTTLS", "ACL", "RIGHTS=kxet", "QUOTA", "COMPRESS=DEFLATE", "SASL-IR", "WITHIN", "CONTEXT=SEARCH", "SEARCHRES", "SPECIAL-USE", "MOVE", "AUTH=SCRAM-SHA-1", "AUTH=DIGEST-MD5", "AUTH=CRAM-MD5", "AUTH=PLAIN"]

03-10 17:42:32.472 18173 18182 D Email   : <<< #1# ["OK", "CAPABILITY Completed"]

 

03-10 17:42:32.492 18173 18182 D MailTransport: >>> 2 AUTHENTICATE DIGEST-MD5

……………………….

 

03-10 17:42:33.222 18173 18182 D MailTransport: >>> 3 COMPRESS DEFLATE

03-10 17:42:33.352 18173 18182 D Email   : <<< #3# ["OK", "Compression active"]

 

03-10 17:42:33.392 18173 18182 D MailTransport: >>> 4 NAMESPACE

03-10 17:42:33.412 18173 18182 D IMAPSocketOutputStream: RawBytes >>78 9C

03-10 17:42:33.422 18173 18182 D IMAPSocketOutputStream: RawBytes >>120

03-10 17:42:33.462 18173 18182 D IMAPSocketOutputStream: RawBytes >>-100

 

03-10 17:42:33.532 18173 18182 D ImapResponseParser: parseResponse

03-10 17:42:33.552 18173 18182 D IMAPSocketInputStream: read

 

Regards,

Jay

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Arnt Gulbrandsen | 3 Mar 19:46 2015
Picon

create-special-use

Hi,

do any servers implement that? If so, which?

Some Gmail-specific clients create an x-gm-label called Later. I don't see 
a way to do anything equivalent using create-special-use, am I overlooking 
anything?

Arnt

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


Gmane