headers
Bill Shannon | 12 May 09:21
Favicon

[Imap-protocol] partial fetch of BODY data

Just to make sure I'm interpreting the spec correctly...

The spec says of a FETCH BODY request:

         Any partial fetch that attempts to read beyond the end of the
         text is truncated as appropriate.  A partial fetch that starts
         at octet 0 is returned as a partial fetch, even if this
         truncation happened.

The spec says of a FETCH BODY response:

         If the origin octet is specified, this string is a substring of
         the entire body contents, starting at that origin octet.  This
         means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
         truncated.

It's not clear whether the truncation being talked about is the same in
both cases.  If it were only allowed to truncate the response at the end
of the data, "BODY[]" would be allowed to be truncated as well, so it
seems that it must be talking about truncation for some other reason.

If I do "FETCH 2 (BODY[]<0.16384>)" and the server responds
"2 FETCH (BODY[]<0> {2817}", can I assume that that's the end
of the data or not?

What if I request "FETCH 2 (BODY[]<16384.16384>)" and the response is
"2 FETCH (BODY[]<16384> {2817}"?  Is that a different case than above,
since the request doesn't start at octet 0?

If I do "FETCH 2 (BODY[]<2817.16384>)" and the server responds
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeff McKay | 3 May 01:28

[Imap-protocol] Gmail IMAP

I wonder if any IMAP client developers have had problems using the 
SELECT statement against
Google Gmail "folders" (labels).  I thought this was working fine but 
today I was given access to
a customer's account where some folders work and some do not.  When they 
do not, the response
from the SELECT command is "NO System error (Failure)".  I don't see any 
difference between
working and non-working folders.   All the folders have messages and 
work fine using the web
client.  I get the folder names from the LIST command.  An example of a 
failed SELECT would be:

<send 25>A101 SELECT "Clearwell"
<recv 32>A101 NO System error (Failure)

A working example would be:

<send 24>A101 SELECT "Intransa"
<recv 336>* FLAGS (\Answered \Flagged \Draft \Deleted \Seen $Forwarded 
$MDNSent)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen 
$Forwarded $MDNSent \*)] Flags permitted.
* OK [UIDVALIDITY 1315401400] UIDs valid.
* 11 EXISTS
* 0 RECENT
* OK [UIDNEXT 12] Predicted next UID.

Anybody have an idea about this problem?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Timo Sirainen | 2 May 23:28
Picon
Picon
Favicon

[Imap-protocol] Concurrent flag changes

I don't think IMAP RFCs actually require any specific behavior for this, so this is more of a "any
recommendations?" type of a question:

Clients C1 and C2 send:

C1: a FETCH 1 FLAGS
S1: * 1 FETCH (FLAGS (\Seen \Answered))
S1: a OK

C2: b STORE 1 +FLAGS (\Flagged)
S2: * 1 FETCH (FLAGS (\Seen \Flagged))
S2: b OK

At this point C1 still thinks that 1's flags are (\Seen), and being a little bit stupid it unsets the \Seen
flag by sending:

C1: c STORE 1 FLAGS (\Answered)

Now, I think the possible replies are either of these:

S1: * 1 FETCH (FLAGS (\Answered))
S1: * 1 FETCH (FLAGS (\Answered \Flagged))

Dovecot currently sends the first reply, but I've started thinking that perhaps I should change it to the
second one. The question is really: Should STORE FLAGS be thought of as

a) Reset all the flags that you have currently, whatever they are, and only set these flags.

or
(Continue reading)

Permalink | Reply | 8 comments |
headers
Ashley Clark | 19 Apr 02:32
Gravatar

[Imap-protocol] BODY.PEEK[HEADER] response

I think I may be dealing with a buggy server but I wanted to verify my assumptions first.

upon making this request to a particular server, I'm seeing this kind of response:

C: 3 fetch 1 body.peek[header]
S: * 1 FETCH (BODY[HEADER] {2006}
S: <data>
S: <data>
S: 
S: 
S: )
S: 3 OK FETCH complete

this seems like one newline too many in the response, but I can't find anything specific that dictates how
many newlines are acceptable at the end of a BODY[HEADER] request.

when doing the same request against a Dovecot server I see only one trailing newline pair:

C: 3 fetch 1 body.peek[header]
S: * 1 FETCH (BODY[HEADER] {2004}
S: <data>
S: <data>
S: 
S: )
S: 3 OK FETCH complete

but is that just convention or is this server breaking some part of the spec? if so, which part?

Ashley
Attachment (smime.p7s): application/pkcs7-signature, 4798 bytes
(Continue reading)

Permalink | Reply | 2 comments |
headers
Antoine Nguyen | 15 Apr 09:40

[Imap-protocol] Unseen messages question

Hi list,

I'm trying to understand what is the more efficient way to maintain the
number of unseen messages of the currently selected mailbox. RFC3501 says a
client must not issue a STATUS command to a selected mailbox and that
information sent by a SELECT is enough.

My current idea follows these steps :
* Issue a STATUS before the mailbox is selected =>  I know how many unseen
messages it contains
* SELECT the mailbox =>  I got the eventual first unseen message in this
mailbox but I don't understand how this info can be useful
* Maintain the unseen counter (on client side) according to what the user do
* Send a NOOP command every X minutes and look at the RECENT response to
see if there are new messages

I think it works pretty well when the mailbox is opened only once. Let's
imagine this mailbox is opened twice, by different clients. If one client
marks a message as \Seen, how can the second client know about this change?

Thanks for your help,

Antoine Nguyen
http://modoboa.org/

_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Galton | 27 Mar 23:49
Picon

[Imap-protocol] using a global CONDSTORE mod-sequence for HIGHESTMODSEQ

The RFC states that the mod-sequence represents the highest modification to a given mailbox.  If a mailstore only stored a global (account-wide, across all mailboxes) mod-sequence, could one simply return the current value of such a global mod-sequence when the HIGHESTMODSEQ is called for (SELECT/EXAMINE/STATUS)?


Obviously using this value would trigger the client to followup with a request to find out what has changed since it last sync'd, even if nothing has changed.  Should a client be expected to behave reasonably if it's FETCH CHANGEDSINCE or SEARCH MODSEQ returned items where the highest mod-sequence was less than the advertised HIGHESTMODSEQ or worse, there were no results at all when some were expected?

Thanks,
John
_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
Permalink | Reply | 3 comments |
headers
PA | 21 Mar 21:39
Picon

Re: [Imap-protocol] [ann] lua imap server


On Mar 21, 2012, at 12:08 AM, Pete Maclean wrote:

> I have run a few automated tests against your server.  These test just a few things, some simple some not so
simple, and it has behaved impeccably.

Thanks for giving it a try. Glad it survived your tests :)

>  I was impressed with how fast searches are.

For that aspect, SQLite should get most of the credit.

_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
Permalink | Reply | 0 comments |
headers
Bron Gondwana | 21 Mar 13:58
Favicon
Gravatar

Re: [Imap-protocol] [ann] lua imap server


On Wed, Mar 21, 2012, at 08:13 AM, Barry Leiba wrote:
> >> That most clients send a lot of NOOP commands basically speaks to most
> >> clients being inefficient users of IMAP.  With a well written client
> >> and an active user, you might never see NOOPs, and it's seriously
> >> broken server behaviour to only update the message list when you see a
> >> NOOP.
> ...
> > And we instructors have a saying... if one person in your class makes a
> > mistake, it might be their fault - but if a lot of them get it wrong then
> > IT IS YOUR FAULT.  You didn't cue properly.  Fix it next time you teach
> > that track.
> >
> > Lots of clients get IMAP wrong...
> 
> You're mistaking lots of clients making inefficient use of IMAP
> because their developers took POP clients and modified them, and had
> no incentive to *make* clients that use IMAP efficiently... for those
> who "got it wrong" for some other reason.  Be careful about the
> assumptions you make.

There are a lot of clients out there speaking bad IMAP of various sorts.
You just have to read a protocol trace from just about any client and
you'll see it doing crazy things.  You can sort of deduce the model at
the other end which is causing it to do things that way...

It's not just ex-POP clients.  Though they are indeed spectacularly
ugly in their behaviour.

One reason for that is that a simple client is going to have different
codepaths for handling different commands - they'll send a FETCH and
expect to see just the results they asked for.  If they get something
unexpectedly unsolicited, then they're probably just going to drop it.

It's exactly like waving your arms in some complex pattern and wondering
why most of the class didn't figure out how you wanted them to move next,
even if you happened to drop the name of the move somewhere in the last
5 seconds of random crap you were spouting.  I've seen it done.  I've
done it myself.  The mystified look on the participants' face followed
by a combination of frustration at themselves and annoyance at you is
quite distinct.

And we get specifically warned about that in training, and told that it
is always your fault.  You didn't give them what THEY needed.  The goal
as instructor is to make the participants feel successful.  They get
that when they do something and it happens to be right.  The trick is
to say and do just the right things that they make the right move
without even thinking about it... then it's big smiles all around and
they go away happy.

> And I'm not going to get into further discussion of this: it's
> pointless and endless.

I did say it was my "other" hobby...

Bron.
--

-- 
  Bron Gondwana
  brong <at> fastmail.fm

_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
Permalink | Reply | 0 comments |
headers
John Galton | 20 Mar 19:34
Picon

[Imap-protocol] CONDSTORE mod-sequence values

Hello,

From RFC4551 Introduction: "The server MUST guarantee that each STORE command performed on the same mailbox ... will get a different mod-sequence value."

Can someone explain why the uniqueness requirement is necessary for the modification sequence?  If two metadata items/messages are modified transactionally and share the same mod-sequence I don't really see any way that will break any of the proposed IMAP protocol changes for CONDSTORE (as long as they are updated atomically and a client can't sync between when a first item gets a mod-sequence and a second item gets the same mod-sequence).

Thanks for your time,
John
_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
Permalink | Reply | 7 comments |
headers
Dave Cridland | 20 Mar 10:27

Re: [Imap-protocol] [ann] lua imap server

On Mon Mar 19 22:17:06 2012, Dave Cridland wrote:
> On Mon Mar 19 21:29:08 2012, PA wrote:
>> 
>> On Mar 19, 2012, at 9:46 PM, Bron Gondwana wrote:
>> 
>> > Have you looked at http://imapwiki.org/ImapTest ?
>> 
>> Yes, I have looked at ImapTest.  Didn't quite manage to use it,   
>> even though looking at the test case themselves was instructive.
> 
> It works against Polymer. I can read all the mailboxes, and they  
> seem  reasonable.

TRACE: imap://lua <at> svr225.stepx.com:1143/ 159.693 '9>>> CB NOOP\r\n'
TRACE: imap://lua <at> svr225.stepx.com:1143/ 159.767 '9<<< * 312  
exists\r\n'
TRACE: imap://lua <at> svr225.stepx.com:1143/ 159.819 '9<<< CB ok noop\r\n'
TRACE: imap://lua <at> svr225.stepx.com:1143/ 219.818 '9>>> DB NOOP\r\n'
TRACE: imap://lua <at> svr225.stepx.com:1143/ 219.891 '9<<< * 312  
exists\r\n'
TRACE: imap://lua <at> svr225.stepx.com:1143/ 219.937 '9<<< DB ok noop\r\n'
TRACE: imap://lua <at> svr225.stepx.com:1143/ 279.860 '9>>> EB NOOP\r\n'
TRACE: imap://lua <at> svr225.stepx.com:1143/ 279.934 '9<<< * 312  
exists\r\n'
TRACE: imap://lua <at> svr225.stepx.com:1143/ 279.980 '9<<< EB ok noop\r\n'

No, NOOP is a command that does nothing; an EXISTS response is not  
automatically generated - it can be generated during any command (or,  
for extra bonus points, not during any command), but only when there  
are new messages.

 From §7.3.1:

      The EXISTS response reports the number of messages in the  
mailbox.
      This response occurs as a result of a SELECT or EXAMINE command,
      and if the size of the mailbox changes (e.g., new messages).

Polymer (and probably other clients) doesn't care, but technically  
they could behave oddly in this case.

Incidentally, there are two commands that do nothing in IMAP, and  
both are typically used for checking for new mail. NOOP returns  
instantly, whereas IDLE returns only after the client sends DONE.  
They're allowed to do whatever you want to make this happen behind  
the scenes in your server, of course, they just don't affect the  
state of the mailbox from the client's point of view.

But a client *could* check the mailbox by repeatedly polling with a  
SEARCH command, too.

Dave.
--

-- 
Dave Cridland - mailto:dave <at> cridland.net - xmpp:dwd <at> dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
Permalink | Reply | 21 comments |
headers
PA | 19 Mar 21:02
Picon

[Imap-protocol] [ann] lua imap server

Hello,

Bellow is a preview of a diminutive IMAP server implemented in Lua [1]:

imap://lua:lua <at> svr225.stepx.com:1143/inbox

For these brave enough to give it a try, the user name and password is lua (plain login, no starttls, nor ssl). 

For example:

$ telnet svr225.stepx.com 1143
Trying 212.55.219.225...
Connected to svr225.stepx.com.
Escape character is '^]'.
* ok imap4rev1
123 login lua lua
123 ok login
123 select inbox
* 1000 exists
* 0 recent
* flags (\answered \deleted \draft \flagged \seen)
* ok [permanentflags ()] done
* ok [uidnext 88836] done
* ok [uidvalidity 15986] done
123 ok [read-only] select
123 fetch * fast
* 1000 fetch (flags (\seen) internaldate "27-Feb-2012 01:31:18 +0000" rfc822.size 13981)
123 ok fetch
123 logout
* bye imap4rev1
123 ok logout

The demo server sports the content of the Lua mailing list since its inception until February 2012. About
88K messages.

The server is read only and fronts an email archive stored in SQLite.

The server side implementation details can be found bellow:

http://dev.alt.textdrive.com/browser/Mail/IMAP.lua#L523
http://dev.alt.textdrive.com/browser/Mail/IMAPFetch.lua#L747
http://dev.alt.textdrive.com/browser/Mail/IMAPSearch.lua#L498

The server has been tested for interoperability with the following libraries:

- uw-imap c-client 
- JavaMail
- Perl Mail::IMAPClient
- Python imaplib 
- Ruby Net::IMAP

And the following email clients:

- alpine
- Apple Mail Mac OS X
- Apple Mail iOS
- Mozilla Thunderbird
- Mulberry
- GyazMail
- Sparrow

As the IMAP protocol is rather, hmm, "challenging", help with interoperability testing would be much
appreciated :)

If you manage to connect (or not) to the demo server, could you report back what client or library did or
didn't work as expected?

Thanks in advance.

Cheers,

--

[1] http://www.lua.org/about.html

_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
Permalink | Reply | 7 comments |

Gmane