mailing list archives

Hello,

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

imap://lua:lua@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

On Mon, Mar 19, 2012 at 09:02:38PM +0100, PA wrote:
> 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 :)

Have you looked at http://imapwiki.org/ImapTest ?

Bron.

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.

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.

I'm not sure that it's a very sensible idea to list all email  
addresses of people who have ever posted as the output of:

. LIST "" "names/%"

Might want to change that.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

On Mar 19, 2012, at 11:17 PM, Dave Cridland wrote:

> It works against Polymer. I can read all the mailboxes, and they seem reasonable.

Excellent. Thanks for giving it a try.

> I'm not sure that it's a very sensible idea to list all email addresses of people who have ever posted as the output of:
> . LIST "" "names/%"
> 
> Might want to change that.

The folders are build automatically out of the mail corpus:

http://dev.alt.textdrive.com/browser/Mail/IMAPStore.ddl#L29

It lists names with more than one hundred messages.

What do you see as being problematic with that approach?

On Mon Mar 19 22:27:23 2012, PA wrote:
> It lists names with more than one hundred messages.
> 
> What do you see as being problematic with that approach?

Just not entirely sure you want to make these people's email  
addresses that easily visible - but I don't suppose that spammers are  
likely to write IMAP parser to get at it.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

On Mon, Mar 19, 2012 at 3:27 PM, PA <petite_abeille@mac.com> wrote:

>
> On Mar 19, 2012, at 11:17 PM, Dave Cridland wrote:
>
> > It works against Polymer. I can read all the mailboxes, and they seem
> reasonable.
>
> Excellent. Thanks for giving it a try.
>
> > I'm not sure that it's a very sensible idea to list all email addresses
> of people who have ever posted as the output of:
> > . LIST "" "names/%"
> >
> > Might want to change that.
>
> The folders are build automatically out of the mail corpus:
>
> http://dev.alt.textdrive.com/browser/Mail/IMAPStore.ddl#L29
>
> It lists names with more than one hundred messages.
>
> What do you see as being problematic with that approach?


Sounds cool, but may have some implications on some clients.  There are
some clients which don't support unsubscribing from folders, for instance,
and will happily download all of the mail in those folders, which is
presumably duplicated.  That's probably only an issue if this is a general
purpose server to be used for larger installations, though.

Email addresses are probably good for uniqueness, but may be challenging in
terms of understand-ability, may be challenging for some people to remember
who each address is.

It might also be good to filter based on things like precedence bulk, or
maybe require at least one message sent to that address as well to.

Brandon
-- 
 Brandon Long <blong@google.com>
 Staff Engineer
 Gmail Delivery TLM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20120319/68833ace/attachment.html>

On Mar 19, 2012, at 11:53 PM, Brandon Long wrote:

> Sounds cool, but may have some implications on some clients.  There are
> some clients which don't support unsubscribing from folders, for instance,
> and will happily download all of the mail in those folders, which is
> presumably duplicated.

Yes, there is only one mail corpus per user account. A given message could show up under various (virtual) mailboxes.

>  That's probably only an issue if this is a general
> purpose server to be used for larger installations, though.

This is meant as a front end to a mail archiver of sort.

> Email addresses are probably good for uniqueness, but may be challenging in
> terms of understand-ability, may be challenging for some people to remember
> who each address is.

Yes, these name folders are meant to show the person name at some point. Just didn't get around implementing an UTF7 encoder yet.

> It might also be good to filter based on things like precedence bulk, or
> maybe require at least one message sent to that address as well to.

Yes, there are a couple of additional folders in the pipeline such as mailing lists, keywords, etc. 

In short, the mail store is meant to automatically organize the messages to a certain extend.

Thanks for the feedbacks.