[
https://issues.apache.org/jira/browse/JAMES-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3854.
-
Resolution: Fixed
> Support RFC-8438 IMAP STATUS=S
[
https://issues.apache.org/jira/browse/JAMES-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-3854:
--
Summary: Support RFC-8438 IMAP STATUS=SIZE (was: Support RFC-8438IMAP
STATUS=SIZE)
> Supp
Hi,
I'm a bit lost...
The vote for imap-0.2.1 is open wich is coherent with [1] (only 0.2 is
release)
However, the beta1 proposal (I'm running fine now btw) refers and
contains a imap-0.2.1 which is not yet released.
I must miss something...
Tks,
- Eric
[1]
Thats right. I included the not yet released imap version in the
beta to speed up things. thats why I said that we first need to
release the imap version .
bye
Norman
Am Sonntag, 12. Juni 2011 schrieb Eric Charles e...@apache.org:
Hi,
I'm a bit lost...
The vote for imap-0.2.1 is
2011/6/11 Eric Charles e...@apache.org:
0.2.x, of course :)
I will add a table on the imap web site with the supported extension per
version.
Sure, we can rely for now on dovecot testsuite. For the how to test, we
can simply link for now to http://www.imapwiki.org/ImapTest
In the long run,
On Sun, Jun 12, 2011 at 8:53 AM, Ioan Eugen Stan stan.ieu...@gmail.com wrote:
2011/6/11 Eric Charles e...@apache.org:
0.2.x, of course :)
I will add a table on the imap web site with the supported extension per
version.
Sure, we can rely for now on dovecot testsuite. For the how to test, we
Hi,
This weekend, I will test server-beta1 (ok so far), imap-2.0.1 and will
update documentation for the releases.
Is the following correct (Norman was so fast I could even not follow him :)
IMAP4rev1 2.0
LITERAL+ 2.0
CHILDREN ?
I18NLEVEL=1 2.0.1
WITHIN 2.0.1
ESEARCH 2.0.1
SEARCHRES 2.0.1
Hi there,
first of its 0.2 and 0.2.1 ;) For the rest see inside
Am Samstag, 11. Juni 2011 schrieb Eric Charles e...@apache.org:
Hi,
This weekend, I will test server-beta1 (ok so far), imap-2.0.1 and will
update documentation for the releases.
Is the following correct (Norman was so
0.2.x, of course :)
I will add a table on the imap web site with the supported extension per
version.
Sure, we can rely for now on dovecot testsuite. For the how to test,
we can simply link for now to http://www.imapwiki.org/ImapTest
In the long run, mailbox-integration-tests could be
On 6/4/08, Ihsiak [EMAIL PROTECTED] wrote:
Hello
Hi
I am part of a team that works on integrating James with webbased
mailing solution. So far, we have sucessfully developed integration for
smtp and pop3, and now we are going to work on IMAP. I know that current
IMAP is not production
Robert Burrell Donkin pisze:
On 6/4/08, Ihsiak [EMAIL PROTECTED] wrote:
Hello
Hi
I am part of a team that works on integrating James with webbased
mailing solution. So far, we have sucessfully developed integration for
smtp and pop3, and now we are going to work on IMAP. I know that
On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak [EMAIL PROTECTED] wrote:
Robert Burrell Donkin pisze:
On 6/4/08, Ihsiak [EMAIL PROTECTED] wrote:
Hello
Hi
I am part of a team that works on integrating James with webbased
mailing solution. So far, we have sucessfully developed integration for
On Wed, Jun 4, 2008 at 2:44 PM, Robert Burrell Donkin
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak [EMAIL PROTECTED] wrote:
Robert Burrell Donkin pisze:
On 6/4/08, Ihsiak [EMAIL PROTECTED] wrote:
Hello
Hi
I am part of a team that works on integrating James
On Wed, Jun 4, 2008 at 2:25 PM, Zsombor [EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 2:44 PM, Robert Burrell Donkin
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak [EMAIL PROTECTED] wrote:
Robert Burrell Donkin pisze:
On 6/4/08, Ihsiak [EMAIL PROTECTED] wrote:
Hello
I am part of a team that works on integrating James with webbased
mailing solution. So far, we have sucessfully developed integration for
smtp and pop3, and now we are going to work on IMAP. I know that current
IMAP is not production ready - yet, so we want to work closely with you
and
Hi!
Since original imap2 branch from apache svn I did the following:
1. integration with current James trunk
At the moment a bit weird. It is based on AbstractJamesService which has
changed a lot since the original branch. ImapHandler does not extend
AbstractJamesHandler at the moment.
2.
Joachim Draeger wrote:
Hi!
Since original imap2 branch from apache svn I did the following:
1. integration with current James trunk
At the moment a bit weird. It is based on AbstractJamesService which has
changed a lot since the original branch. ImapHandler does not extend
Joachim Draeger schrieb:
Hi!
Since original imap2 branch from apache svn I did the following:
1. integration with current James trunk
At the moment a bit weird. It is based on AbstractJamesService which has
changed a lot since the original branch. ImapHandler does not extend
Serge Knystautas wrote:
MIME4J is nowhere ready to be a replacement. It is a read-only API
last I checked.
Noel, you said on server-users@ that you thought IMAP allowed
modification of Messages (using your definition). To my knowledge, this
is not the case (someone please correct me if
Comments inline.
Joe Cheng wrote:
Serge Knystautas wrote:
MIME4J is nowhere ready to be a replacement. It is a read-only API
last I checked.
Noel, you said on server-users@ that you thought IMAP allowed
modification of Messages (using your definition). To my knowledge,
this is not the
Steve Brewin wrote:
Can we agree on org.apache.james.xxx interfaces that capture the behaviour
we need a repository to provide? Jason's existing work has surfaced most of
the requirements.
We can then write adapters for specific implementations such as Javamail or
whatever else we agree upon,
Stefano Bagnara wrote:
We already have this interface: MailRepository.
We simply should deprecate the MailRepository (we can always use the
SpoolRepository instead) and create a new MessageRepository interface.
Thanks for clarifying those relationships, I have
been wondering about those
Jason Webb wrote:
// I'm fairly indifferent to how we get the child reps
// we just need some way to get hold of them
MessageRepository[] getChildren();
void addChild(MessageRepository repository);
I guess we're holding that 'MessageRepository == Folder' ?
Jason Webb wrote:
-Original Message-
From: Stefano Bagnara [mailto:[EMAIL PROTECTED]
Sent: 26 October 2005 17:26
To: 'James Developers List'
Subject: Re: Re: IMAP status
snipped
In my current james (patched trunk) I have this interface for
MessageRepository
On 10/25/05, Noel J. Bergman [EMAIL PROTECTED] wrote:
I had suggested JavaMail, but when we all did further looking, it was
observed that JavaMail is not efficient for server storage, it would tie us
to JavaMail, and worse to MimeMessage. We really want a store that deals
with streams, from
Noel J. Bergman wrote:
I had suggested JavaMail, but when we all did further looking, it was
observed that JavaMail is not efficient for server storage,
it would tie us
to JavaMail, and worse to MimeMessage. We really want a
store that deals
with streams, from which we can easily
Steve Brewin wrote:
Might we move this discussion to [EMAIL PROTECTED] :-)
Good idea!
Sent this to server-dev. Will comment there.
Can we agree on org.apache.james.xxx interfaces that capture the behaviour
we need a repository to provide? Jason's existing work has surfaced most of
the
Steve Brewin wrote:
Steve Brewin wrote:
Might we move this discussion to [EMAIL PROTECTED] :-)
Good idea!
Sent this to server-dev. Will comment there.
Can we agree on org.apache.james.xxx interfaces that capture the behaviour
we need a repository to provide? Jason's existing work
Either way, it would be a help to be able to query the delimiter(s) in use.
This would allow services that use folders, such as future Mailets and
jSieve to construct valid folder paths. Also, it would be good to have two
distinct exceptions. One for a malformed folder path, eg:
To get IMAP working there are major 3 pieces of work that need to be
done:
1) Add attribute support to users (for both file: and db:)- This is
required for storing mailbox settings etc
2) Ensure that all current mail repositories support attributes for
mail - mbox does not for example :)
Is
Cedric Veilleux wrote:
There are no reserved or illegal characters. Each implementation can
decide which delimiter character to use. The client will know the
delimiter of the server by sending a LIST command with no additional
argument. The server should then send .INBOX or /INBOX or whichever
Serge Knystautas wrote:
The delimiter is usually . or /. It might break poorly written
clients to use something else.
Agreed, I've seen clients screwed by anything but / as the
delimiter and
would favor that.
I'ld favour that as the default, possibly with the option to override to
32 matches
Mail list logo
