api and tagging

I am interested in being able to tag messages by matter/project and then
being able to retrieve messages outside of imap via some kind of api.

Are these features available?  I read a message from 2009 that said that
a "dbmail-httpd" implementing a rest-ful api was being worked on.

I also saw that there is some kind of tagging function in one of the
latest versions.

Any information would be appreciated.

Mark B

Re: api and tagging

_______________________________________________
DBmail mailing list
DBmail <at> dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: api and tagging

Thanks, Lou  and Happy New Year to you as well. 

Glad to hear that the potential I am hoping for is in the works.  I have
never used dbmail but I have always been impressed with its well
designed deconstruction of emails into their constituent parts for
efficient storage purposes. 

If the mail store could also become a useful backend for non-imap
access, this could allow dbmail to remedy the weakness currently found
in many many existing crm and case management applications: allowing
incoming and outgoing emails (and their attachments) to be fully
integrated as  first class objects into the application's data structure.

I'm looking forward to hearing more about how and when these two
functions (tagging and an API) will be available for general use.

Mark B

On 1/1/2011 10:24 AM, Lou Picciano wrote:
> Lou Picciano

saslauthd + rimap + dbmail-imapd(3rc1) = unexpected response

_______________________________________________
DBmail mailing list
DBmail <at> dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: api and tagging

On 01/01/2011 05:36 PM, Mark Bronstein wrote:
> Thanks, Lou  and Happy New Year to you as well. 
> 
> Glad to hear that the potential I am hoping for is in the works.  I have
> never used dbmail but I have always been impressed with its well
> designed deconstruction of emails into their constituent parts for
> efficient storage purposes. 
> 
> If the mail store could also become a useful backend for non-imap
> access, this could allow dbmail to remedy the weakness currently found
> in many many existing crm and case management applications: allowing
> incoming and outgoing emails (and their attachments) to be fully
> integrated as  first class objects into the application's data structure.
> 
> I'm looking forward to hearing more about how and when these two
> functions (tagging and an API) will be available for general use.

Mark,

the http api is not finished. Mostly incomplete, but also not as
REST-full as I thought.

Concerning REST: the REST definition uses GET for read, POST for create,
PUT for update, and DELETE for removing entries. DBMail's http currently
uses GET/POST only! Using POST for updates and deletes. Maybe that
should change to better align with REST conventions.

Concerning functionality:

some things there already:

list users, list mailboxes per user, create/delete mailboxes
create/delete messages in mailboxes
fetch messages and message headers

some obvious things missing:

create/edit/delete users
edit message meta-data (flags and labels)
searching mailboxes

adding these - and fixing the REST api along the way - is trivial. These
functions are well defined in the code base, and only need to be exposed
in the http layer.

If people are willing to help me out with testing and discussing these
issues, I'm more than happy to work on this and finish it in the 3.0.x
series.

Apart from this I'm sure you and Lou can come up with non-trivial things
to add. If and how they can be added depends and the feature. Basically
anything that accesses multiple mailboxes and/or users is terra
incognita. Multi-mailbox operations are well described in several imap
extensions, multi-user operations would be logical extensions of those.
But no such functionality exists in the current code. Adding
multi-mailbox imap extensions (and http entry points for them) would
obviously take longer - depending on time, resources and proper
motivation. However, they won't happen in the 3.0 series, but may well
be added to the 3.2 targets - still to be determined.

--

-- 
  ________________________________________________________________
  Paul Stevens                                      paul at nfg.nl
  NET FACILITIES GROUP                     GPG/PGP: 1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl

Re: saslauthd + rimap + dbmail-imapd(3rc1) = unexpected response

Martin,

please try attached patch.

On 01/02/2011 01:33 AM, Martin Senebald wrote:
> Hi  <at> all,
> 
> I have a problem with the dbmail-imapd and saslauthd using rimap. 
> 
> I get this nice errormsg in my log
> "saslauthd[28383]: auth_rimap: unexpected response to auth request: *
> CAPABILITY IMAP4rev1 ID ACL RIGHTS=texk NAMESPACE CHILDREN SORT QUOTA
> THREAD=ORDEREDSUBJECT UNSELECT IDLE
> saslauthd[28382]: do_auth         : auth failure: [user=msen]
> [service=imap] [realm=] [mech=rimap] [reason=[ALERT] Unexpected response
> from remote authentication server]"
> 
> When I use the right login.
> testsaslauthd -u msen -p test
> 0: NO "authentication failed"
> 
> When I use the wrong password
> testsaslauthd -u msen -p wrongpw
> 0: NO "authentication failed"
> 
> Then i have a propper log entry
> "saslauthd[28383]: do_auth         : auth failure: [user=msen]
> [service=imap] [realm=] [mech=rimap] [reason=remote server rejected your
> credentials]"
> 
> dbmail-imapd -V
> This is DBMail version 3.0.0-rc1
> 
> saslauthd -v
> saslauthd 2.1.22
> authentication mechanisms: sasldb getpwent kerberos5 pam rimap shadow ldap
> 
> So it looks, that the OK msg is kind of faulty for salsauthd. I'm not
> sure if it's a problem with dbmail-imapd or salsauthd. 
> Does someone has the same problem? Or any idea for a quick fix?
> 
> Cheers
> Martin S.
> 
> 
> 
> _______________________________________________
> DBmail mailing list
> DBmail <at> dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

--

-- 
  ________________________________________________________________
  Paul Stevens                                      paul at nfg.nl
  NET FACILITIES GROUP                     GPG/PGP: 1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl

_______________________________________________
DBmail mailing list
DBmail <at> dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: api and tagging

Thanks, Paul. 

My project is still in the planning stages and I will keep this info in
mind.

Best regards, 

Mark B.

On 1/2/2011 6:52 AM, Paul J Stevens wrote:
> On 01/01/2011 05:36 PM, Mark Bronstein wrote:
>> Thanks, Lou  and Happy New Year to you as well. 
>>
>> Glad to hear that the potential I am hoping for is in the works.  I have
>> never used dbmail but I have always been impressed with its well
>> designed deconstruction of emails into their constituent parts for
>> efficient storage purposes. 
>>
>> If the mail store could also become a useful backend for non-imap
>> access, this could allow dbmail to remedy the weakness currently found
>> in many many existing crm and case management applications: allowing
>> incoming and outgoing emails (and their attachments) to be fully
>> integrated as  first class objects into the application's data structure.
>>
>> I'm looking forward to hearing more about how and when these two
>> functions (tagging and an API) will be available for general use.
> Mark,
>
> the http api is not finished. Mostly incomplete, but also not as
> REST-full as I thought.
>
> Concerning REST: the REST definition uses GET for read, POST for create,
> PUT for update, and DELETE for removing entries. DBMail's http currently
> uses GET/POST only! Using POST for updates and deletes. Maybe that
> should change to better align with REST conventions.
>
> Concerning functionality:
>
> some things there already:
>
> list users, list mailboxes per user, create/delete mailboxes
> create/delete messages in mailboxes
> fetch messages and message headers
>
> some obvious things missing:
>
> create/edit/delete users
> edit message meta-data (flags and labels)
> searching mailboxes
>
> adding these - and fixing the REST api along the way - is trivial. These
> functions are well defined in the code base, and only need to be exposed
> in the http layer.
>
> If people are willing to help me out with testing and discussing these
> issues, I'm more than happy to work on this and finish it in the 3.0.x
> series.
>
> Apart from this I'm sure you and Lou can come up with non-trivial things
> to add. If and how they can be added depends and the feature. Basically
> anything that accesses multiple mailboxes and/or users is terra
> incognita. Multi-mailbox operations are well described in several imap
> extensions, multi-user operations would be logical extensions of those.
> But no such functionality exists in the current code. Adding
> multi-mailbox imap extensions (and http entry points for them) would
> obviously take longer - depending on time, resources and proper
> motivation. However, they won't happen in the 3.0 series, but may well
> be added to the 3.2 targets - still to be determined.
>
>
>

transaction-isolation=READ-COMMITTED

hi at all, happy new year and thanks 3.0 RC
sounds like a real good shit to me 

I found this some minutes ago because i can not sleep and so
i started google something useful, is it safe for dbmail
to set "transaction-isolation=READ-COMMITTED" or better
leace the defaults to not hurt anything?

http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

> Also check if your application can run in READ-COMMITED isolation mode – if it
> does – set it to be default as transaction-isolation=READ-COMMITTED. This
> option has some performance benefits, especially in locking in 5.0 and even
> more to come with MySQL 5.1 and row level replication.

http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_read-committed

A somewhat Oracle-like isolation level with respect to consistent (nonlocking)
reads: Each consistent read, even within the same transaction, sets and reads
its own fresh snapshot. See Section 13.2.8.2, “Consistent Nonlocking Reads”.

For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), InnoDB locks
only index records, not the gaps before them, and thus permits the free insertion
of new records next to locked records. For UPDATE and DELETE statements, locking
depends on whether the statement uses a unique index with a unique search condition
(such as WHERE id = 100), or a range-type search condition (such as WHERE id > 100).
For a unique index with a unique search condition, InnoDB locks only the index record
found, not the gap before it. For range-type searches, InnoDB locks the index range
scanned, using gap locks or next-key (gap plus index-record) locks to block insertions
by other sessions into the gaps covered by the range. This is necessary because
“phantom rows” must be blocked for MySQL replication and recovery to work.

--

-- 

Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/

Apache authenticate against DBMail user database

Just finished configuring Apache to authenticate against DBMail's user
database - I wrote this summary,
http://jdbates.blogspot.com/2011/01/recently-required-little-research-to.html

Goes off on some non-DBMail tangents, but maybe interesting to some
other DBMail folks?

Re: transaction-isolation=READ-COMMITTED

Harald,

Postgresql already runs in read-committed by default. So it is most
likely safe to use that for mysql as well.

DBMail currently uses only a few multi-query transactions, so this issue
is moot for most people. Only on highly concurrent system will you run
into isolation issues. Some of the imap synchronisation issues with high
concurrencies on the *same* mailbox (clients > 100) will most likely
require much stricter handling of isolation.

Let us know your results if you test this.

On 2011-01-03 02:34, Reindl Harald wrote:
> hi at all, happy new year and thanks 3.0 RC
> sounds like a real good shit to me 
> 
> I found this some minutes ago because i can not sleep and so
> i started google something useful, is it safe for dbmail
> to set "transaction-isolation=READ-COMMITTED" or better
> leace the defaults to not hurt anything?
> 
> http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
> 
>> Also check if your application can run in READ-COMMITED isolation mode – if it
>> does – set it to be default as transaction-isolation=READ-COMMITTED. This
>> option has some performance benefits, especially in locking in 5.0 and even
>> more to come with MySQL 5.1 and row level replication.
> 
> http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_read-committed
> 
> A somewhat Oracle-like isolation level with respect to consistent (nonlocking)
> reads: Each consistent read, even within the same transaction, sets and reads
> its own fresh snapshot. See Section 13.2.8.2, “Consistent Nonlocking Reads”.
> 
> For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), InnoDB locks
> only index records, not the gaps before them, and thus permits the free insertion
> of new records next to locked records. For UPDATE and DELETE statements, locking
> depends on whether the statement uses a unique index with a unique search condition
> (such as WHERE id = 100), or a range-type search condition (such as WHERE id > 100).
> For a unique index with a unique search condition, InnoDB locks only the index record
> found, not the gap before it. For range-type searches, InnoDB locks the index range
> scanned, using gap locks or next-key (gap plus index-record) locks to block insertions
> by other sessions into the gaps covered by the range. This is necessary because
> “phantom rows” must be blocked for MySQL replication and recovery to work.
> 

--

-- 
  ________________________________________________________________
  Paul Stevens                                      paul at nfg.nl
  NET FACILITIES GROUP                     GPG/PGP: 1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl