gmane.mail.imap.cyrus

Re: In preparation of Cyrus IMAP 2.5: autoconf and automake

Andrew Morgan — 2012-05-22T19:49:49


Good enough for me then!

 Andy
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

libzephyr and notifications

Bron Gondwana — 2012-05-22T07:40:05

We're having issues building zephyr with the new automake stuff,
and before we spend too much time fixing it - there's a question
worth asking...


Does anyone actually use zephyr?


If not, I'd prefer to remove it and integrate worldline's notification
bus work rather than having multiple competing notification systems.


Bron.

Re: In preparation of Cyrus IMAP 2.5: autoconf and automake

Bron Gondwana — 2012-05-21T20:57:06

We'll probably keep shipping releases with the configure script - but if you're
building from git you need to do the whole dance.

Bron.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: User tags lost

Bron Gondwana — 2012-05-21T20:55:26

IOERROR is a good start.

Bron.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: In preparation of Cyrus IMAP 2.5: autoconf and automake

Andrew Morgan — 2012-05-21T19:03:31


Why is autoreconf/autoconf required?

I have been building Cyrus from source for many years.  The tarballs 
already come with the configure script, so I have never needed to install 
the autoconf package before.

 Andy
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: User tags lost

Tom Plancon — 2012-05-21T18:56:06

Bron,
Thanks for the reply. Yes I am using 2.3.16!
I believe all of the Cyrus logging is into /var/log/maillog. I inherited 
this config. What would I look for in maillog?
Thanks.

Re: unsubscribe

Bron Gondwana — 2012-05-21T14:33:06


On Mon, May 21, 2012, at 02:27 PM, Ian Eiloart wrote:

No worries.  I realise the law is often an ass


There is.  And I would love to see you stand up in a court of law
and explain why you thought this mailing list was breaking it.

Bron ( P.S. [citation needed]  Please point to a legal opinion which is not your
       own which states that a standards compliant List-Unsubscribe header is not
       sufficient.  Bonus points if it's been tested in court )

Re: unsubscribe

Ian Eiloart — 2012-05-21T14:27:33

Thanks for your considered contribution. It's nice to know we're in such good company on this list. 





It's the law in the EU. There's an amazingly good reason for it. It's best if email professionals understand (a) the law, and (b) what is meant by "easy to use" with respect to email.

Re: unsubscribe

Bron Gondwana — 2012-05-21T14:08:54

On Mon, May 21, 2012, at 12:13 PM, Ian Eiloart wrote:

Man - I'm in the EU, and I'm firmly of the opinion "feck off protolawyer".

This is a technical discussion list for users of the software, and you
signed up for it.  It's using THE standard mechanism for detailing how
to unsubscribe.

Short of reaching down through the screen and physically punching you in
the face, I can't see how in particular we are supposed to account for the
deficiencies of the client you choose to use.

Bron ( somewhat annoyed that there's no nice web management interface for the
       list unless you're a CMU user, but still )

Re: unsubscribe

Ian Eiloart — 2012-05-21T12:13:25

Apple Mail, actually. But, it doesn't matter. Neither displays the List-Unsubscribe header by default, or presents the unsubscribe options. And, I doubt that most users would find the option in a menu; it would have to be displayed as a button in the default display. Ideally, such a button would be displayed with the message headers.

As long as most users don't have easy access to the List-Unsubscribe header (Outlook, Apple Mail, etc), then the List-Unsubscribe header can't satisfy the legal requirements of the UK, and most EU countries: that marketing (and this list markets Cyrus mail - at least in the meaning of the legislation) emails must carry an easy to use address for unsubscribing.


Yes, that would be nice. Unfortunately, the most popular clients don't.



I'm afraid it is. I'm forever having to teach people that there are more than four headers in an email. Most people just don't know the others are there.

Re: unsubscribe

Adam Tauno Williams — 2012-05-21T11:49:23

This behavior has been *standard* for decades.  A good mail client even
provides an option - I view a message from the Cyrus list in Evolution
and Message -> Maillist -> Unsubscribe is right there as an option.

You are using Exchange [ + Outlook? ];  so I'm pretty sure that option
is there on your screen somewhere.


You mail client should recognize the presence of this header and provide
an option.   And looking at message headers is hardly a 'profession'
level action.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: unsubscribe

Ian Eiloart — 2012-05-21T11:32:19


Using the mechansims described in the List-Unsubscribe header:

List-Unsubscribe: <https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus>,  <mailto:info-cyrus-request< at >lists.andrew.cmu.edu?subject=unsubscribe>

Having said that, European Union countries usually require that the mechanisms be easy to use. In my view, that means that they should be described in the message footer (not hidden in a header). The more obvious paths from the URLs listed in the footer require cyrus.edu accounts for unsubscription.

The argument that list members ought to be able to find the List-Unsubscribe header because they're email professionals doesn't wash. It can't be presumed that they all are, and those that aren't will be wanting to unsubscribe.

Re: In preparation of Cyrus IMAP 2.5: autoconf and automake

Bron Gondwana — 2012-05-20T18:47:21

Speaking of which, parallel make is still broken if you're using the inbuilt
comerr rather than the system libraries.

Bron.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: mailboxes.db vs IMAP client irregularities

Bron Gondwana — 2012-05-19T21:05:33

Just wait until you get 2.5 :)  There's still lots left to do, but
it's coming along.  I really want to get more of the last years'
worth of development out to people too!

Bron
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: mailboxes.db vs IMAP client irregularities

Stephen Ingram — 2012-05-19T21:02:53

Wow, I never stopped being amazed by the really clever hidden things
in cyrus-imap!


OK, this must be working or I would have tons of DELETED files in
there. However, I see stuff from April that is not gone yet. And, yes,
I actually converted the hex timestamp to a date an it says April too,
certainly more than the 3 day expire time. Hopefully this stuff will
be taken care of when I upgrade to 2.4.16 too!

BTW, I love 2.4. I've been using now for several months and it is such
a HUGE improvement from 2.3. Everything is faster, replication works
better, it's like a whole new program!

Steve
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: mailboxes.db vs IMAP client irregularities

Stephen Ingram — 2012-05-19T20:50:57

Oops, sorry to mislead. Yes, I was lazy and just read a man page from
Google. I will change to delete_mode: immediate.

Steve
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: mailboxes.db vs IMAP client irregularities

Bron Gondwana — 2012-05-19T20:28:18

Hashing is on the second part of the name, rather uninteligently,
no matter what the name - hence it's hashing on:

DELETE.user.x
       ^

:)
 

No - the files will have the delivery date as their age.  The interesting
bit is the final part of the folder name, which is actually a 32 bit
unix timestamp in hex format (yes, really).

cyr_expire will clean it up.  Don't mess with the filesystem under cyrus
if you don't have to.

Bron.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: mailboxes.db vs IMAP client irregularities

Bron Gondwana — 2012-05-19T20:04:54


On Sat, May 19, 2012, at 11:53 AM, Stephen Ingram wrote:

The sort order causes LIST to suppress output lines that it should
not - hence the folder doesn't appear in the output - but it can't
be created either, because it's already there.  It can still be
deleted fine.


They shouldn't matter.  They will be cleaned up by cyr_expire later.


Yes, that's the best idea :)

Bron.

Re: mailboxes.db vs IMAP client irregularities

Simon Matter — 2012-05-19T20:00:02

Just to clear this up, if he's using our invoca rpms then his man page reads:

       delete_mode: delayed
            The manner in which mailboxes are deleted. "immediate" mode is
the
            the mode in which mailboxes are removed immediately.  In
"delayed"
            mode, mailboxes are renamed to a special hiearchy defined  by 
the
            "deletedprefix" option to be removed later by cyr_expire.

       Note:  This Invoca RPM build uses delayed by default instead of
immedi-
       ate for delete_mode.

       Allowed values: immediate, delayed

Regards,
Simon

----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: mailboxes.db vs IMAP client irregularities

Stephen Ingram — 2012-05-19T19:56:44

On Sat, May 19, 2012 at 12:40 PM, Patrick Boutilier
<boutilpj< at >ednet.ns.ca> wrote:


Wow, thanks! I didn't know about that command. It exposed them!
Strange, they were in /var/spool/imap/u/DELETED/ (my mailbox root is
/var/spool/imap). I'm not sure why they wouldn't be in
/var/spool/imap/j/user/jmaxwell (jmaxwell is the user), but perhaps
it's because I haven't defined deleted_prefix as you pointed out
earlier. Maybe /var/spool/imap/u/DELETED is the default.

Looking at all of the files in there, several are older than the 3
days they are supposed to be. I'm guessing that means there was a bug
somewhere. I guess I should remove all of these, reconstruct the
mailboxes.db to match and then probably upgrade as Bron suggested.

Thanks, again. I never would have found those files.

Steve
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: mailboxes.db vs IMAP client irregularities

Patrick Boutilier — 2012-05-19T19:40:14

I am thinking the worst that would happen is you get an I/O error if the 
DELETED hierarchy really doesn't exist.

Have you tried mbpath? For example:

  [root< at >student ~]# /usr/local/cyrus/bin/mbpath DELETED.user.whoj.4FB1557F

/imap/mail/C/DELETED/user/whoj/4FB1557F


----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/