Hi,
Le mer. 4 mars 2020 à 14:40, Дилян Палаузов
a écrit :
>
> Hello,
>
> is RFC 5465 (IMAP NOTIFY (https://tools.ietf.org/html/rfc5465.html) supported
> in 3.0 as stated at
> https://www.cyrusimap.org/imap/rfc-support.html ?
I don't see any reference to such RFC 5465 in the code source or in
If I understand this correctly, the uri here then is defined to have to be a
uri that a client could interpret and follow and end up OK with?
Below the definition of the uri parameter from RFC 5423:
uri
Included with all notifications. A reference to the IMAP server,
a
2013/1/9 Greg Banks g...@fastmail.fm:
Those can be made cleaner anyway, by moving them into mboxevent.c. Then
the mailbox.c code would always call mboxevent_* functions but those
functions would, depending on the result of ./configure, either be a
trivial stub that does do nothing or would
2013/1/1 Jenkins do-not-re...@cyrusimap.org:
See http://ci.cyrusimap.org/job/cyrus-imapd-master/1059/
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for JANSSON... no
configure: error: jansson 2.0 or later was not found, but is
2013/1/2 Jeroen van Meeuwen (Kolab Systems) vanmeeu...@kolabsys.com:
On 2013-01-02 10:16, Sébastien Michel wrote:
3 options in this case:
- Install jansson library on the jenkins server
- Add --disable-event-notification in the Cyrus build script
- Disable event notification by default
2012/8/24 Greg Banks g...@fastmail.fm:
I wouldn't describe RHEL 5 and 6 as old yet, their end of production dates
are in 2017 and 2020 respectively.
https://access.redhat.com/support/policy/updates/errata/
You're right.
Running such systems out to a large fraction of their vendors'
2012/8/24 Greg Banks g...@fastmail.fm:
If nobody else expresses opinion, whether to put xjson in libcyrus or
libcyrus_imap, it is up to you. I just told you my opinion.
My 2c: JSON code is a utility and should go in libcyrus.
Indeed.
As discussed on IRC, we decided to change the library to
That requirement would rule out systems like RHEL 5, RHEL 6.
It is thus preferable to not require such version.
On older versions of pkg-config (0.24), the macro will not call
AC_SUBST on generated variables prefix_LIBS and prefix_CFLAGS .
Running it twice, though, will not cause problems. I
please delete imap/Makefile.in : all the build rules are in /Makefile.am .
It's already done. Sorry, I just forgot to mention it.
As libjson supports the .pc format, you can detect libjson in
configure.ac with
PKG_CHECK_MODULES ([libjson], [json = 0.10], [check_libjson=yes],
2012/8/14 Дилян Палаузов dilyan.palau...@aegee.org:
lib/parseaddr.c is used within libcyrus_sieve and imap/, so having it in the
common library libcyrus seems logical. I do not know, why iostat.c is part
of libcyrus.
If nobody else expresses opinion, whether to put xjson in libcyrus or
Le 9 juin 2012 à 09:55, Bron Gondwana br...@fastmail.fm a écrit :
On Sat, Jun 09, 2012 at 12:16:06AM +0200, Sébastien Michel wrote:
Can you and Andreas coordinate / work together on this? If you need push
access to git.cyrusimap.org as well, please send me a public ssh key.
I've done
Hi,
I'm very sorry that Andreas done my job to rebase against the current master...
I plan to do some cleanup of my code : I need to use commit
6735484f76470b02c439cc553149b0beb0e34e81 from branch
dev/sieve/vacation-seconds (instead of mine
77cab79f920629a964340cfcfff14338f161a3c1), merge some
Here's a tip:) it supports IMAP SPECIAL-USE, but *only* in response to
the non-extended IMAP LIST command. The workaround is easy to code in
Cyrus
Cool! Have you coded it yet? I don't see a Bugzilla ticket.
Yes to demonstrate to Apple that their IMAP client doesn't really
support the RFC,
Often, this means IMAP IDLE, but I mean
tools.ietf.org/id/draft-maes-lemonade-p-imap-00.txt
Since apple wants to push iCloud to people, apple doesn't support IMAP
IDLE but supports iCloud, ActiveSync, and PUSH-IMAP on purpose.
Is there any plan to implement PUSH-IMAP in cyrus IMAP?
P-IMAP
Given that the CMU guys have been adding http and XML support to Cyrus for
CalDAV, some of the pieces that ActiveSync needs are coming anyway, so it's
not entirely impossible to imagine some future Cyrus supporting ActiveSync
directly.
Georg, I notice there's a page about Z-Sync on the
2011/10/11 Bron Gondwana br...@fastmail.fm:
Hi,
Is there anyone out there using the SQL backend in production?
Would you be really sad if I redesigned it?
It's OK. We don't use yet the SQL backend but our internal legacy's one.
And if anyone has put together any other backends, I'm
Were/Are you planning to include a database schema beyond key-value blobs?
Agree. The Cyrus key-value store model is very basic. It would be
nice to have a key-structured value model such as redis' one.
Hi all,
progress is being made in the rewrite of our code toward the master branch.
I pushed an update in our github repository, below the changelog :
1) adding the support of these event types:
- MessageAppend
- MessageExpire
2) adding the support of these event parameters:
- MessageNew and
- the ability to turn off notification for SPAM = depends on SPECIAL-USE
Hi Sébastien,
Would you agree it is useful to be able to turn off notification for other
SPECIAL-USE folders as well?
We disable notifications for some technical folders (huge volume and
uninteresting for our case).
I
PS^2; I would also like some input for those of us that enjoy playing,
researching, testing and documenting ;-)
sure !
I've pushed a draft in our github repository :
https://github.com/worldline-messaging/cyrus-imapd branch msgevent.
Most of the commit is viewable here :
Is this the
future Cyrus framework for functionnal testing ?
That's my hope and my intention. Plus, we have nothing else that does
Cyrus-specific testing.
Please let me know if you have any problems or feedback about Cassandane.
The major issue to test the event notification feature is
For 2.5 preview:
All the 2.4.11 stuff, plus:
* per-message annotation support
* fix LIST-EXT support to be standards complient
* fix SORT=DISPLAYNAME cache format for sure
* fix SPECIAL-USE to match the RFC (it changed from the draft I
implemented, doh)
* finalize mailboxes.db format
You are two to compete for this patch :)
http://asg.andrew.cmu.edu/archive/message.php?mailbox=archive.cyrus-develmsg=2984
Your code seems to be good. You can fill an issue in the bug tracker:
https://bugzilla.cyrusimap.org/index.cgi
However I have an open question : does the Date field should be
We have developed some time ago a notification mechanism on mailbox
events. This piece of software is based on the RFC 5423 - Internet
Message Store Events - that defines a number of event types and event
parameters.
Cyrus's processes (imapd, pop3d, lmtpd) and CLI send events to notifyd
daemon. We
= We have defined lot of configuration settings (may be too much for
common usages) :
- eventnotifier, off, STRING : Enables event notification with the
given notification method (see notifyd). i.e mail, log, activemq
- event_subfolder, 0, SWITCH : Enables event notification for subfolders
I'm hoping to release a Cyrus 2.5 in a few months - the blockers are
a couple more RFC compatibility issues, and adding per-message
annotations.
http://www.cyrusimap.org/mediawiki/index.php/RoadMap
I see that it is planned to support IMAP ANNOTATE (RFC5257). It would be
great!
However I
I see that it is planned to support IMAP ANNOTATE (RFC5257). It would be
great!
However I think you mean support IMAP METADATA (RFC 5464) ?
Both actually! We already support METADATA on master, pretty much.
But it is hacked on over the top of the old ANNOTATEMORE code. We
plan to
2011/4/22 Adam Tauno Williams awill...@opengroupware.us
On Fri, 2011-04-22 at 15:38 +0200, Julien Coloos wrote:
However we think that a better way would be to split at attachment
level instead of body level, it could be possible to save base64
overhead, permit de-duping and do data
2011/2/3 Jeroen van Meeuwen (Kolab Systems) vanmeeu...@kolabsys.com
Sébastien Michel wrote:
Our clients ask us to open IMAP (previously mostly POP and Webmail
access)
for their customers.
The impact is significant on I/O, specifically when IMAP clients poll to
ask for new messages
fill their mailbox, we would need to retrieve the quota usage of all
those mailboxes. Unfortunately we still have legacy quota db (that is:
one file per mailbox) on most platforms ... and migrating to other db
formats is not always possible since some clients are very picky about
the
30 matches
Mail list logo
