Re: looking for Cyrus mail format documentation

Hello,

You are correct on all counts. I was simply trying to make a point,
and IMAP is the major protocol used to access the mail store, at
least it is here. Nor did I mean to imply that any server that one
set's up to see how things worked should be a production machine.
In fact, because one would be changing things to see how they
affected clients, etc. I would expect it to be a test platform.

But that does now beg the question. There must be some form of
coordination between the various processes as they access the
mail store. Can this not be abstracted out and put in an API to
make it easier for people to write their own applications?  I would
venture a guess to say that the API already exists in some form,
it just needs to be formalized and published.

Regards,
Earl Shannon

Rob Siemborski wrote:
> On Fri, 31 Jan 2003, Earl R Shannon wrote:
>
>
> > Cyrus documentation calls the IMAP server a black box. This is defined
> > to mean that the users do not have access to the account/data accept
> > through the well defined ( :-/ ) IMAP protocol. This black box concept
> > also extends to a certain extent to the administrators of the servers.
>
>
> Obviously the mail store access is not limited to the IMAP protocol, one
> can also use LMTP and POP3, and NNTP if you're using the 2.2 branch.
>
> There's also some utilities such as deliver that can let you do various
> things to the mail store.
>
>
> > Best way to learn something is through experience. Set up a server and
> > look at how it does things. If you opt for compiling it yourself choose
> > the flat file options for all the databases. This will leave the data in
> > a format that is human readable, sorta, and you can figure out what is
> > going on.
>
>
> This is really only useful for educational purposes, not for actually
> running a mail store where other programs want direct access.  The only
> way to accomplish the latter legitimately is to use the cyrus source
> directly.
>
> Often times mailbox access semantics change slightly from version to
> version, and if you're not using all the same code (which assumes it is
> only dealing with one version of itself), then you can run into trouble.
>
> -Rob
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
> Research Systems Programmer * /usr/contributed Gatekeeper