Re: Murder + Sieve + multiple backends problem
On 02 Dec 2008, at 10:54, Juergen Wolf wrote:
The mlookup
thing is indeed very simple and already working. The cmd_append() part
is a bit tricky tho, as the LMTPD does not have any imap connection to
the backend as far as I see. I guess LMTP will be the wrong way to
transport the mail to the right backend server.
Right, you'd want an IMAP connection, I would think.
+/* Mailbox not existent, and murder setup ? */
+if (r == IMAP_MAILBOX_NONEXISTENT config_mupdate_server) {
+ /* check the mupdate master */
You don't really want to talk to the mupdate master. You want to
look in the local mailboxes.db (this only works in a unified murder,
obviously).
If you look at cmd_append() in imapd.c, you see mlookup() used to
obtain mailbox information. sieve_fileinto() in lmtp_sieve.c is
structurally similar: it internalizes the mailbox, and then delivers
it. The deliver_mailbox() in lmtpd.c is just an append, just like
cmd_append() is! At least the part after:
/* local mailbox */
in cmd_append() is analogous to the append code in deliver_mailbox
(). The portion of cmd_append() that's missing from deliver_mailbox
() is the first bit:
if (!r (mbtype MBTYPE_REMOTE)) {
/* remote mailbox */
struct backend *s = NULL;
...
s = proxy_findserver(newserver, imap_protocol,
proxy_userid, backend_cached,
backend_current, backend_inbox, imapd_in);
if (!s) r = IMAP_SERVER_UNAVAILABLE;
if (!r) {
int is_active = 1;
s-context = (void*) is_active;
if (imapd_mailbox) {
prot_printf(s-out, %s Localappend { SIZE_T_FMT +}\r\n%s
{ SIZE_T_FMT +}\r\n%s ,
tag, strlen(name), name,
strlen(imapd_mailbox-name), imapd_mailbox-name);
} else {
prot_printf(s-out, %s Localappend { SIZE_T_FMT +}\r\n%s
{ SIZE_T_FMT +}\r\n%s ,
tag, strlen(name), name, 0, );
}
if (!(r = pipe_command(s, 16384))) {
pipe_including_tag(s, tag, 0);
}
s-context = NULL;
} else {
eatline(imapd_in, prot_getc(imapd_in));
}
if (r) {
prot_printf(imapd_out, %s NO %s\r\n, tag,
prot_error(imapd_in) ? prot_error(imapd_in) :
error_message(r));
}
return;
}
Obviously, it would need a little work to merge this in, but I think
it's pretty trivial.
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Murder + Sieve + multiple backends problem
On Mon, 1 Dec 2008 14:22:54 -0500
Wesley Craig [EMAIL PROTECTED] wrote:
On 01 Dec 2008, at 12:18, Duncan Gibb wrote:
Cross-store SIEVE is theoretically the sort of thing that ought to
favour the unified murder design over a conventional layered one...
Absolutely, the backend with the INBOX and SIEVE scripts would need
to know have to have a listing in mailboxes.db for the remote
mailbox. As far as the code goes, sieve_fileinto() would probably
work as-is. deliver_mailbox() on the other hand would have to do an
mlookup() and behave more like cmd_append() does if the mailbox was
remote. Not a large undertaking, tho.
Thanks for the replies. I have taken a look into the code. The mlookup
thing is indeed very simple and already working. The cmd_append() part
is a bit tricky tho, as the LMTPD does not have any imap connection to
the backend as far as I see. I guess LMTP will be the wrong way to
transport the mail to the right backend server.
As I am completly new to the cyrus code, does anybody has any hints
what would be a good start to get this done ?
--- imap/lmtpd.c.orig Tue Apr 22 15:11:18 2008
+++ imap/lmtpd.cTue Dec 2 16:52:00 2008
@@ -487,12 +487,39 @@
int quotaoverride,
int acloverride)
{
-int r;
+int r, type;
struct appendstate as;
time_t now = time(NULL);
unsigned long uid;
const char *notifier;
+
+struct mupdate_mailboxdata *mailboxdata;
+char *server;
+r = mboxlist_detail(mailboxname, type, NULL, NULL, server, NULL,
NULL);
+
+/* Mailbox not existent, and murder setup ? */
+if (r == IMAP_MAILBOX_NONEXISTENT config_mupdate_server) {
+ /* check the mupdate master */
+ if (!mhandle) {
+r = mupdate_connect(config_mupdate_server, NULL, mhandle,
NULL);
+if (r) {
+ syslog(LOG_ERR, couldn't connect to MUPDATE server %s: %s,
+ config_mupdate_server, error_message(r));
+ fatal(error connecting with MUPDATE server, EC_TEMPFAIL);
+}
+/* find what server we're sending this to */
+r = mupdate_find(mhandle, mailboxname, mailboxdata);
+mupdate_disconnect(mhandle);
+ } else {
+/* find what server we're sending this to */
+r = mupdate_find(mhandle, mailboxname, mailboxdata);
+ }
+
+ /* do something to get the mail to the remote mailbox
*/
+ syslog(LOG_INFO, sieve moving message %s to server: %s,id,
(char *) mailboxdata-server);
+}
+
r = append_setup(as, mailboxname, MAILBOX_FORMAT_NORMAL,
authuser, authstate, acloverride ? 0 : ACL_POST,
quotaoverride ? (long) -1 :
Regards,
Jürgen Wolf
--
email: [EMAIL PROTECTED]
gilb: Fraunhofer-Institut fuer Digitale Medientechnologie IDMT
98693 Ilmenau, Ehrenbergstr. 31
Tel.: +49 3677 467-234 Fax: +49 3677 467-467
smime.p7s
Description: S/MIME cryptographic signature
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Murder + Sieve + multiple backends problem
Hi
currently, I test a Cyrus IMAP Murder v2.3.13-openpkg on a solaris
sparc host. While the murder setup went all fine and mail comes in and
can be read by users, there is one thing left I could not fix.
If a user has a sieve script like
#Mail filter rules for wolf
#Generated by wolf using SmartSieve 1.0.0-RC2 2008/11/25 09:02:43
require [fileinto];
if allof (header :contains X-Spam-Status Yes,) {
fileinto INBOX.Spam-Tagged;
}
and the Folder INBOX.Spam-Tagged is located on a different backend
server as the INBOX folder, the sieve script does not work. I get the
following errors on the backend server where the INBOX is located:
lmtp[27859]: sieve runtime error for wolf id
[EMAIL PROTECTED]: Fileinto: Mailbox
does not exist
Is there any way to tell sieve to move mails to the correct backend
server ?
Regards,
Jürgen Wolf
--
email: [EMAIL PROTECTED]
gilb: Fraunhofer-Institut fuer Digitale Medientechnologie IDMT
98693 Ilmenau, Ehrenbergstr. 31
Tel.: +49 3677 467-234 Fax: +49 3677 467-467
smime.p7s
Description: S/MIME cryptographic signature
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Murder + Sieve + multiple backends problem
Juergen Wolf wrote:
Hi
currently, I test a Cyrus IMAP Murder v2.3.13-openpkg on a solaris
sparc host. While the murder setup went all fine and mail comes in and
can be read by users, there is one thing left I could not fix.
If a user has a sieve script like
#Mail filter rules for wolf
#Generated by wolf using SmartSieve 1.0.0-RC2 2008/11/25 09:02:43
require [fileinto];
if allof (header :contains X-Spam-Status Yes,) {
fileinto INBOX.Spam-Tagged;
}
and the Folder INBOX.Spam-Tagged is located on a different backend
server as the INBOX folder, the sieve script does not work. I get the
following errors on the backend server where the INBOX is located:
lmtp[27859]: sieve runtime error for wolf id
[EMAIL PROTECTED]: Fileinto: Mailbox
does not exist
Is there any way to tell sieve to move mails to the correct backend
server ?
From the web site [http://cyrusimap.web.cmu.edu/ag.html section 2.3]:
If a SIEVE http://www.cyrusoft.com/sieve script is present, the
lmtp proxy server must do the processing as the end result of the
processing may result in the mail message going to a different back
end server than where the user's INBOX is. /Note that the current
implementation runs SIEVE on the backend servers, and holds the
requirement that all of a user's mailboxes live on the same backend./
So, you should heed this warning.
-nic
--
Nic Bernstein [EMAIL PROTECTED]
Onlight llc. www.onlight.com
2266 North Prospect Avenue #610 v. 414.272.4477
Milwaukee, Wisconsin 53202-6306 f. 414.290.0335
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Murder + Sieve + multiple backends problem
On 01 Dec 2008, at 10:17, Nic Bernstein wrote: From the web site [http://cyrusimap.web.cmu.edu/ag.html section 2.3]: If a SIEVE script is present, the lmtp proxy server must do the processing as the end result of the processing may result in the mail message going to a different back end server than where the user's INBOX is. Note that the current implementation runs SIEVE on the backend servers, and holds the requirement that all of a user's mailboxes live on the same backend. So, you should heed this warning. While the code is written this way, in an environment where the backends are able to talk to each other, it wouldn't take a ton of work to remove this restriction. :wes Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Murder + Sieve + multiple backends problem
Wesley Craig wrote: Note that the current implementation runs SIEVE on the backend servers, and holds the requirement that all of a user's mailboxes live on the same backend. WC While the code is written this way, in an environment where the WC backends are able to talk to each other, it wouldn't take a ton of WC work to remove this restriction. Cross-store SIEVE is theoretically the sort of thing that ought to favour the unified murder design over a conventional layered one... [light the blue touchpaper and retreat to a safe distance] But the answer to the original question is that this is known not to work - and yes, that is both counter-intuitive for users and inconvenient for administrators. /* FIXME */ Duncan -- Duncan Gibb, Technical Director Sirius Corporation plc - The Open Source Experts http://www.siriusit.co.uk/ Tel: +44 870 608 0063 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Murder + Sieve + multiple backends problem
On 01 Dec 2008, at 12:18, Duncan Gibb wrote: Cross-store SIEVE is theoretically the sort of thing that ought to favour the unified murder design over a conventional layered one... Absolutely, the backend with the INBOX and SIEVE scripts would need to know have to have a listing in mailboxes.db for the remote mailbox. As far as the code goes, sieve_fileinto() would probably work as-is. deliver_mailbox() on the other hand would have to do an mlookup() and behave more like cmd_append() does if the mailbox was remote. Not a large undertaking, tho. :wes Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
