Re: cyrus-imapd 2.1.15, sieve, lmtpd, and return-path header
On Mon, 22 Sep 2003, Pat Lashley wrote:
> Return-Path doesn't exist at all until final delivery, at which point, I
> believe it is optional.
from RFC2821 (which, I realize, is smtp and not lmtp)
When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data. This use of return-path is required; mail systems MUST support
it. The return-path line preserves the information in the
path from the MAIL command.
> And, as I recall, the Envelope-To: header is completely non-standard;
> though widely used; and when used, it is in a manner similar to Return-
> Path: (I.e., Any existing one is removed and a new one is added only at
> the point of final delivery.)
I'm not familiar with Envelope-To and have no idea what uses it or might
use it. I don't really care about (and am not complaining about) any
specific headers.
My problem is this:
- a message is passed to lmtpd via lmtp
- lmtpd writes the mail headers to disk and caches the headers in ram
- lmtpd generates and writes a Return-Path header to disk but does not
cache it in ram
- lmtpd generates and writes other headers to disk but does not cache
them in ram either
- sieve operates by checking against the headers in the cache
- sieve can't check all of the headers, because not all of them are in
the cache
That, imho, is not correct behavior.
> What is your MTA? Have you checked to see whether that header is
> optional? (Or does LMTPd create it?) Perhaps you -shouldn't- see the
> Return-Path header when you pull a message from the store.
lmtpd generates a Return-Path for every message. Look at lmtpengine.c
around line 1002. The MTA isn't important as far as the return path is
concerned in this case: it isn't the final delivery step, lmtpd is.
> --On Monday, September 22, 2003 19:32:07 -0700 Chris Stromsoe <[EMAIL PROTECTED]>
> wrote:
>
> > The expectation is that sieve will be able to match on any header in
> > the message. But, right now, it can't, because the generated headers
> > are only written to disk and never inserted into the header cache.
>
> What, if anything, does the Sieve RFC have to say about Return-Path? I
> suspect that if it were allowed by the standard, then there would have
> been no need for an "envelope" extension. (Does the envelope RFC/draft
> say why it is necessary?)
I don't what the Sieve RFC says about return-path. I'm pretty sure that
it isn't germane to this topic.
> Smartsieve should either be smart enough to automatically translate the
> condition; or smart enough to warn the user that it won't work as
> expected.
smartsieve can't be smart enough to automatically translate the condition.
It seems like you're suggesting that smartsieve (and any other program
that generates sieve rules) should be following behind lmtpd, trying to
guess at what special header might map to which special sieve function.
I don't believe that is a sustainable long-term model. lmtpd should make
sure that the on-disk headers actually match what is stored in the header
cache.
> > I'm not sure why the script won't work with any other conformant sieve
> > implementation. This has nothing to do with sieve... it has to do with
> > lmtpd writing one thing to disk and keeping a separate thing in ram.
>
> Because other sieve implementations are likely to be in an environment
> where that header does not yet exist to be tested.
I'm not sure what you mean here. Or maybe I am not being clear. To
restate myself: this issue has _nothing to do with sieve_. I am not
trying to patch sieve and I don't want to be. The patch changes the
behavior of lmtpd so that the on-disk and in-memory represention of the
headers is the same. (Rather, the patch is a start; since it doesn't yet
include the last-hop Received header they don't completely match.)
> Your solution has the advantage of being simple and fairly easy to
> implement. That doesn't make it the right one.
>
>
> The envelope extension exists to provide the functionality you need.
The envelope extension does not provide the functionality that I need.
Open any message that is stored in cyrus and was delivered via lmtp.
Look at the headers. The first header that you will see looks something
like:
Return-Path: <[EMAIL PROTECTED]>
I need to be able to filter on that header. In my opinion, sieve code
like
if anyof (header :contains "return-path" "[EMAIL PROTECTED]") {
fileinto "cbs";
}
needs to work
-Chris
> -Pat
>
Re: can´t compile cyradm
But i already have the second stone in my way and the name is CYRADM. The problem is
that i have installed cyrus-imap into /opt directory, the library are into
/opt/lib/sasl2 and the include files are into /opt/include/sasl. Then, i´km trying
to compile cyradm following the documentation and i can´t, the compiled proccess is
getting this message.
Note (probably harmless): Not found libsasl2
---
For all of you who install packages into their own directories, under "/opt", here is
some advice: *make symbolic links*.
I come from Tru64 UNIX and it inherits on long standing DEC's practice, which can be
summarized as follows:
- make a package (SETLD package in my case), determine which files belong in it
- separate files into subsets (these are RPM equivalents), one package can hold N
subsets
- for each subset separate files as follows:
+ "/opt/${PKGNAME}" should hold all files needed at startup
This accounts for startup files, kernel modules, etc...
+ "/usr/opt/${PKGNAME}" should hold all files that do not change during normal
operation
This is the bulk of the package, executables, shared and static libs, header files
configuration files, documentation, static data files,...
+ "/var/opt/${PKGNAME}" should hold all files that do change during normal operation
These would be spools, logs, databases, mailboxes,...
- for all files that are expected to be in some defined path, make symbolic links
This is handled automatically by the subset control helper routines, for all marked
files
Now, I know that Linux is built with only one "/opt" directory in mind and I don't
think we can change it now. What most packagers end up with, is treating "/opt" as
DEC's "/usr/opt" + "/opt", while for "/var/opt/${PKG}" they create links to
"/var/".
So, create symbolic links. That will make your life substantially easier.
Nix.
Re: cyrus-imapd 2.1.15, sieve, lmtpd, and return-path header
--On Monday, September 22, 2003 19:32:07 -0700 Chris Stromsoe <[EMAIL PROTECTED]> wrote: Why? Return-Path is clearly a header. What's special about it as opposed to Subject or Date or From or anything else? It's not a standard header, as such. Subject, Date, From, and most other headers are written by the originating MUA; and remain intact throughout the life of the message. Primary exceptions are Message-Id; which should be added by an MTA if it isn't already there; and Recieved: which is is added by each MTA that processes the message. Return-Path doesn't exist at all until final delivery, at which point, I believe it is optional. And, as I recall, the Envelope-To: header is completely non-standard; though widely used; and when used, it is in a manner similar to Return- Path: (I.e., Any existing one is removed and a new one is added only at the point of final delivery.) So you wind up with sieve scripts that won't work as expected on other conformant sieve implementations. Right now I've got sieve scripts that don't work as expected. When you pull a message out of the store, it clearly has a Return-Path _header_. What is your MTA? Have you checked to see whether that header is optional? (Or does LMTPd create it?) Perhaps you -shouldn't- see the Return-Path header when you pull a message from the store. The expectation is that sieve will be able to match on any header in the message. But, right now, it can't, because the generated headers are only written to disk and never inserted into the header cache. What, if anything, does the Sieve RFC have to say about Return-Path? I suspect that if it were allowed by the standard, then there would have been no need for an "envelope" extension. (Does the envelope RFC/draft say why it is necessary?) Smartsieve should either be smart enough to automatically translate the condition; or smart enough to warn the user that it won't work as expected. I'm not sure why the script won't work with any other conformant sieve implementation. This has nothing to do with sieve... it has to do with lmtpd writing one thing to disk and keeping a separate thing in ram. Because other sieve implementations are likely to be in an environment where that header does not yet exist to be tested. Your solution has the advantage of being simple and fairly easy to implement. That doesn't make it the right one. The envelope extension exists to provide the functionality you need. -Pat
Re: cyrus-imapd 2.1.15, sieve, lmtpd, and return-path header
On Mon, 22 Sep 2003, Pat Lashley wrote: > --On Monday, September 22, 2003 19:02:11 -0700 Chris Stromsoe <[EMAIL PROTECTED]> > wrote: > > On Mon, 22 Sep 2003, Pat Lashley wrote: > > > >> Can't you get what you want using the "envelope" extension? > > > > Probably. "But..." the rules are being generated by smartsieve. > > Relying on smartsieve to know that return-path is special (compared to > > any other random header) and that it should use envelope seems a > > little goofy. I can also see some utility in having the return-path > > and other generated headers in the header cache. > > I would think that the right solution would be to make smartsieve know > about the envelope extension and have it explicitly offer comparisons > against envelope sender and envelope recipient rather than the > Return-Path and possible Envelope-To headers. Why? Return-Path is clearly a header. What's special about it as opposed to Subject or Date or From or anything else? > > Anyway, the attached (compiled but untested) patch splits fill_cache() > > into a second piece (insert_cache_element()), and uses the new > > function to insert the return-path into the header cache. > > So you wind up with sieve scripts that won't work as expected on other > conformant sieve implementations. Right now I've got sieve scripts that don't work as expected. When you pull a message out of the store, it clearly has a Return-Path _header_. The expectation is that sieve will be able to match on any header in the message. But, right now, it can't, because the generated headers are only written to disk and never inserted into the header cache. I'm not sure why the script won't work with any other conformant sieve implementation. This has nothing to do with sieve... it has to do with lmtpd writing one thing to disk and keeping a separate thing in ram. -Chris
Re: cyrus-imapd 2.1.15, sieve, lmtpd, and return-path header
--On Monday, September 22, 2003 19:02:11 -0700 Chris Stromsoe <[EMAIL PROTECTED]> wrote: On Mon, 22 Sep 2003, Pat Lashley wrote: Can't you get what you want using the "envelope" extension? Probably. "But..." the rules are being generated by smartsieve. Relying on smartsieve to know that return-path is special (compared to any other random header) and that it should use envelope seems a little goofy. I can also see some utility in having the return-path and other generated headers in the header cache. I would think that the right solution would be to make smartsieve know about the envelope extension and have it explicitly offer comparisons against envelope sender and envelope recipient rather than the Return-Path and possible Envelope-To headers. Anyway, the attached (compiled but untested) patch splits fill_cache() into a second piece (insert_cache_element()), and uses the new function to insert the return-path into the header cache. So you wind up with sieve scripts that won't work as expected on other conformant sieve implementations. -Pat
Re: cyrus-imapd 2.1.15, sieve, lmtpd, and return-path header
On Mon, 22 Sep 2003, Pat Lashley wrote:
> --On Monday, September 22, 2003 18:08:23 -0700 Chris Stromsoe
> <[EMAIL PROTECTED]> wrote:
>
> > From what I can tell, ...
> >
> > While there may not be much call to match against the last-hop
> > received header (unless maybe you want to take different actions
> > depending on the origin of mail from different remote last-hop LMTP
> > mta's), there is interest (at least here) for being able to filter on
> > return-path.
>
> Can't you get what you want using the "envelope" extension?
Probably. "But..." the rules are being generated by smartsieve. Relying
on smartsieve to know that return-path is special (compared to any other
random header) and that it should use envelope seems a little goofy. I
can also see some utility in having the return-path and other generated
headers in the header cache.
Anyway, the attached (compiled but untested) patch splits fill_cache()
into a second piece (insert_cache_element()), and uses the new function to
insert the return-path into the header cache.
-Chris--- /usr/local/src/bol/cyrus-imapd-2.1.15/imap/lmtpengine.c 2003-07-22
12:17:15.0 -0700
+++ lmtpengine.c2003-09-22 18:56:21.891697000 -0700
@@ -892,6 +892,50 @@
return 0;
}
+
+static int insert_cache_element (message_data_t *m, char *name, char *body) {
+
+int cl, clinit;
+
+/* put it in the hash table */
+clinit = cl = hashheader(name);
+while (m->cache[cl] != NULL && strcmp(name, m->cache[cl]->name)) {
+cl++; /* resolve collisions linearly */
+cl %= HEADERCACHESIZE;
+if (cl == clinit) break; /* gone all the way around, so bail */
+}
+
+/* found where to put it, so insert it into a list */
+if (m->cache[cl]) {
+/* add this body on */
+m->cache[cl]->contents[m->cache[cl]->ncontents++] = body;
+
+/* whoops, won't have room for the null at the end! */
+if (!(m->cache[cl]->ncontents % 8)) {
+/* increase the size */
+m->cache[cl] = (header_t *)
+xrealloc(m->cache[cl],sizeof(header_t) +
+ ((8 + m->cache[cl]->ncontents) * sizeof(char *)));
+}
+
+/* have no need of this */
+free(name);
+} else {
+/* create a new entry in the hash table */
+m->cache[cl] = (header_t *) xmalloc(sizeof(header_t) +
+8 * sizeof(char*));
+m->cache[cl]->name = name;
+m->cache[cl]->contents[0] = body;
+m->cache[cl]->ncontents = 1;
+}
+
+/* we always want a NULL at the end */
+m->cache[cl]->contents[m->cache[cl]->ncontents] = NULL;
+
+return 0;
+}
+
+
static int fill_cache(struct protstream *fin, FILE *fout, message_data_t *m)
{
int r = 0;
@@ -899,7 +943,6 @@
/* let's fill that header cache */
for (;;) {
char *name, *body;
- int cl, clinit;
if ((r = parseheader(fin, fout, &name, &body)) < 0) {
break;
@@ -909,40 +952,7 @@
break;
}
- /* put it in the hash table */
- clinit = cl = hashheader(name);
- while (m->cache[cl] != NULL && strcmp(name, m->cache[cl]->name)) {
- cl++; /* resolve collisions linearly */
- cl %= HEADERCACHESIZE;
- if (cl == clinit) break; /* gone all the way around, so bail */
- }
-
- /* found where to put it, so insert it into a list */
- if (m->cache[cl]) {
- /* add this body on */
- m->cache[cl]->contents[m->cache[cl]->ncontents++] = body;
-
- /* whoops, won't have room for the null at the end! */
- if (!(m->cache[cl]->ncontents % 8)) {
- /* increase the size */
- m->cache[cl] = (header_t *)
- xrealloc(m->cache[cl],sizeof(header_t) +
-((8 + m->cache[cl]->ncontents) * sizeof(char *)));
- }
-
- /* have no need of this */
- free(name);
- } else {
- /* create a new entry in the hash table */
- m->cache[cl] = (header_t *) xmalloc(sizeof(header_t) +
- 8 * sizeof(char*));
- m->cache[cl]->name = name;
- m->cache[cl]->contents[0] = body;
- m->cache[cl]->ncontents = 1;
- }
-
- /* we always want a NULL at the end */
- m->cache[cl]->contents[m->cache[cl]->ncontents] = NULL;
+ insert_cache_element(m, name, body);
}
if (r) {
@@ -994,6 +1004,8 @@
if (m->return_path && func->addretpath) { /* add the return path */
char *rpath = m->return_path;
const char *hostname = 0;
+ char *name, *body;
+ int bodylen = 0;
clean_retpath(rpath);
/* Append our hostname if there's no domain in addres
Re: cyrus-imapd 2.1.15, sieve, lmtpd, and return-path header
--On Monday, September 22, 2003 18:08:23 -0700 Chris Stromsoe
<[EMAIL PROTECTED]> wrote:
From what I can tell, ...
While there may not be much call to match against the last-hop received
header (unless maybe you want to take different actions depending on the
origin of mail from different remote last-hop LMTP mta's), there is
interest (at least here) for being able to filter on return-path.
Can't you get what you want using the "envelope" extension?
Here's a fragment from my sieve script; dealing with filing messages
from this mailing list into my INBOX.cyrus.imapd mailbox:
# The envelope capability allows comparisons of the envelope addresses
require "envelope" ;
# The fileinto capability allows delivery to other mailboxes
require "fileinto" ;
# The subaddress capability allows matching on the individual parts
# of a [EMAIL PROTECTED] style address.
require "subaddress" ;
if envelope :detail "to" "cyrus" {
if envelope :localpart :is "from" "owner-info-cyrus" {
fileinto "INBOX.cyrus.imapd" ;
}
elsif envelope :localpart :is "from" "owner-cyrus-sasl" {
fileinto "INBOX.cyrus.sasl" ;
}
else {
# INBOX.cyrus isn't a mailbox; so if we can't figure out
# which sub-mailbox to file it in, send it to my main inbox
# where I'll be annoyed enough to fix the script...
fileinto "INBOX.DEBUG" ;
}
}
-Pat
Re: cyrus-imapd 2.1.15, sieve, lmtpd, and return-path header
>From what I can tell, lmtpengine.c:lmtpmod() calls lmtpengine.c:savemsg()
to read the message and get it onto disk, then lmtpd.c:deliver() to call
sieve rules and deliver the message.
lmtpengine.c:savemsg() calls fprintf() to add the Return-Path header to
the output on disk. lmtpengine.c:fill_cache() loops over input, reading
headers one by one, adding to the header cache.
lmtpd.c:deliver() matches headers from the header cache. But, since
lmtpengine.c:savemsg() never adds the generated Return-Path to the cache,
so the generated Return-Path can't be matched against. This is also the
case for the locally generated Received: header.
While there may not be much call to match against the last-hop received
header (unless maybe you want to take different actions depending on the
origin of mail from different remote last-hop LMTP mta's), there is
interest (at least here) for being able to filter on return-path.
Would you (CMU) take a patch splitting fill_cache into two parts --
fill_cache() and insert_cache_element()? insert_cache_element() could
then be used earlier in savemsg() to insert the generated headers into the
header cache so that sieve recipes could use them. Does that sound like
the correct fix?
-Chris
On Mon, 22 Sep 2003, Chris Stromsoe wrote:
> Before I start digging through the source, does lmtpd add the
> Return-Path header before or after calling sieve routines? The first
> recipe below works, the second does not.
>
> # works
> require ["fileinto","regex"];
> if allof (header :regex "From" ".*") {
> fileinto "test1";
> }
>
> #fails
> require ["fileinto","regex"];
> if allof (header :regex "Return-Path" ".*") {
> fileinto "test1";
> }
>
>
>
>
> -Chris
>
Re: RE : RE : Problem moving mailboxes under murder
Christian Schulte schrieb: Are the changes from 2.1.13 to 2.1.14 also in 2.2-cvs ? I setup a test-murder with two backends, one frontend and one mupdate-master. Everything seems to work except renaming/transferring mailboxes with similar behaviour. Could it be that in imapd.c => function cmd_xfer() it should call mboxname_tointernal() instead of mboxname_hiersep_tointernal() ? The problem seems to be that imapd does not correctly transform the mailbox-name to the internal representation in cmd_xfer() and thus mlookup fails to find a mailbox like [EMAIL PROTECTED] There seems to be 'confusion' in imapd.c when to call mboxname_tointernal() and when mboxname_hiersep_tointernal() ! Could it also be that nearly any call to mboxname_hiersep_tointernal() could be replaced with mboxname_tointernal() in imapd.c ? I did not recompile the whole installation right now but I could bet that this causes my problems during rename and xfer somewhere (at least in cmd_xfer)... --Christian
Re: RE : RE : Problem moving mailboxes under murder
On Tue, 23 Sep 2003, Christian Schulte wrote: > Could it be that in imapd.c => function cmd_xfer() it should call > mboxname_tointernal() instead of mboxname_hiersep_tointernal() ? The > problem seems to be that imapd does not correctly transform the > mailbox-name to the internal representation in cmd_xfer() and thus > mlookup fails to find a mailbox like [EMAIL PROTECTED] No. tointernal does the namespace conversion (e.g. shared folders/foo) while hiersep_tointernal will convert dots to ^ and /'s to .s. I'm almost certian that hiersep_tointernal is the "right thing" for this call (in fact, we fixed a bug in cmd_xfer where tointernal was being used instead.) -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: RE : RE : Problem moving mailboxes under murder
Luc Germain schrieb:
Actually, I'm pretty sure this has been fixed in 2.1.14 (now that I've
done the research and couldn't come up with a code path that
would cause
this ;-).
Could you try the new version and let me know?
I installed 2.1.14 on all servers in the murder, and now I can successfully
do a rename of a user between the backend servers (good!) BUT only if the
user doesn't have subdirectories in his mailbox.
Are the changes from 2.1.13 to 2.1.14 also in 2.2-cvs ? I setup a
test-murder with two backends, one frontend and one mupdate-master.
Everything seems to work except renaming/transferring mailboxes with
similar behaviour.
cyradm on the frontend (this is unchanged; its a test-setup):
frontend>lm
user/test/Folder1/Folder2/[EMAIL PROTECTED] (\HasNoChildren)
user/test/Folder1/[EMAIL PROTECTED] (\HasChildren)
user/test/[EMAIL PROTECTED] (\HasChildren)
user/[EMAIL PROTECTED] (\HasNoChildren)
user/[EMAIL PROTECTED] (\HasChildren)
user/[EMAIL PROTECTED]
frontend>rename user/[EMAIL PROTECTED] user/[EMAIL PROTECTED] linux2
renamemailbox: Mailbox does not exist
frontend>rename user/[EMAIL PROTECTED] user/[EMAIL PROTECTED] linux2!default
renamemailbox: Mailbox does not exist
frontend>xfermailbox user/[EMAIL PROTECTED] linux2
xfermailbox: Unrecognized command
frontend>
cyradm on the first backend:
linux1>lm
user/test/Folder1/Folder2/[EMAIL PROTECTED] (\HasNoChildren)
user/test/Folder1/[EMAIL PROTECTED] (\HasChildren)
user/test/[EMAIL PROTECTED] (\HasChildren)
user/[EMAIL PROTECTED] (\HasNoChildren)
user/[EMAIL PROTECTED] (\HasChildren)
linux1>rename user/[EMAIL PROTECTED] user/[EMAIL PROTECTED] linux2
renamemailbox: Unknown/invalid partition
linux1>xfer user/[EMAIL PROTECTED] linux2
xfermailbox: Mailbox does not exist
cyradm on the second backend:
linux2>lm
user/[EMAIL PROTECTED] (\HasNoChildren)
linux2>rename user/[EMAIL PROTECTED] user/[EMAIL PROTECTED] linux1
renamemailbox: Unknown/invalid partition
linux2>xfer user/[EMAIL PROTECTED] linux1
xfermailbox: Mailbox does not exist
I have allowusermoves: 1 in all imapd.conf files and virtual domain
support and altnamespace and unixhierarchysep all turned on. What could
be the problem ? All servers authenticate against each other as a global
admin using auxprop mysql and everything else seems to work as expected
but xfer and rename! Renaming a mailbox without moving it to another
server also works:
linux1>rename user/[EMAIL PROTECTED] user/[EMAIL PROTECTED]
linux1>lm
user/another-name/Folder1/Folder2/[EMAIL PROTECTED] (\HasNoChildren)
user/another-name/Folder1/[EMAIL PROTECTED] (\HasChildren)
user/another-name/[EMAIL PROTECTED] (\HasChildren)
user/[EMAIL PROTECTED] (\HasChildren)
user/[EMAIL PROTECTED] (\HasNoChildren)
linux1>rename user/[EMAIL PROTECTED] user/[EMAIL PROTECTED]
linux1>lm
user/another-name/Folder1/Folder2/[EMAIL PROTECTED] (\HasNoChildren)
user/another-name/Folder1/[EMAIL PROTECTED] (\HasChildren)
user/another-name/[EMAIL PROTECTED] (\HasChildren)
user/[EMAIL PROTECTED] (\HasChildren)
user/[EMAIL PROTECTED] (\HasNoChildren)
--Christian
-- cyrus Mon Sep 22 16:50:28 2003
<1064242228<4 RLIST "" ""
>1064242228>* LIST (\Noselect) "/" ""
4 OK Completed
<1064242230<5 RLIST "" "*"
>1064242230>* LIST (\HasChildren) "/" "user/[EMAIL PROTECTED]"
* LIST (\HasChildren) "/" "user/test/[EMAIL PROTECTED]"
* LIST (\HasChildren) "/" "user/test/Folder1/[EMAIL PROTECTED]"
* LIST (\HasNoChildren) "/" "user/test/Folder1/Folder2/[EMAIL PROTECTED]"
* LIST (\HasNoChildren) "/" "user/[EMAIL PROTECTED]"
* LIST (\HasNoChildren) "/" "user/[EMAIL PROTECTED]"
5 OK Completed
<1064242283<6 RENAME user/[EMAIL PROTECTED] user/[EMAIL PROTECTED] linux2
>1064242283>6 NO Mailbox does not exist
<1064242299<7 RENAME user/[EMAIL PROTECTED] user/[EMAIL PROTECTED] linux2!default
>1064242299>7 NO Mailbox does not exist
<1064242307<8 XFER user/[EMAIL PROTECTED] linux2
>1064242307>8 BAD Unrecognized command
<1064242316<9 XFER user/[EMAIL PROTECTED] linux2!default
>1064242316>9 BAD Unrecognized command
-- cyrus Mon Sep 22 16:51:07 2003
<10642422671064242267>* CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
>NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT
>THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE LOGINDISABLED
>MUPDATE=mupdate://192.168.1.56/ LISTEXT LIST-SUBSCRIBED X-NETSCAPE
C1 OK Completed
<1064242267<6 XFER {17+}
user/[EMAIL PROTECTED] {6+}
linux2
>1064242267>6 NO Mailbox does not exist
<1064242282<7 XFER {17+}
user/[EMAIL PROTECTED] {6+}
linux2 {7+}
default
>1064242282>7 NO Mailbox does not exist
<10642423001064242301>* BYE LOGOUT received
Q01 OK Completed
Re: can´t compile cyradm
On Monday 22 September 2003 15:45, Danny García Hernández wrote: > ldd command show: > > [EMAIL PROTECTED] cyrus-imapd-2.2.1-BETA]$ ldd > /usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so > libssl.so.2 => /lib/libssl.so.2 (0x40018000) > libcrypto.so.2 => /lib/libcrypto.so.2 (0x40046000) > libc.so.6 => /lib/libc.so.6 (0x4010c000) > libdl.so.2 => /lib/libdl.so.2 (0x40233000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) > [EMAIL PROTECTED] cyrus-imapd-2.2.1-BETA]$ > > I think that i have to problems: > > 1- Why perl Makefile.PL can´t find my libsasl2 into /opt/lib ? > 2- After fix Makefile.PL with the correct path to INCs and LIBs, why i > can´t exceute cyradm? I really don't know because I've never compiled cyradm "standalone" like that. Chances are if you fix #1 you will automagically fix #2 as well. --Jo
Re: can´t compile cyradm
ldd command show: [EMAIL PROTECTED] cyrus-imapd-2.2.1-BETA]$ ldd /usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so libssl.so.2 => /lib/libssl.so.2 (0x40018000) libcrypto.so.2 => /lib/libcrypto.so.2 (0x40046000) libc.so.6 => /lib/libc.so.6 (0x4010c000) libdl.so.2 => /lib/libdl.so.2 (0x40233000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) [EMAIL PROTECTED] cyrus-imapd-2.2.1-BETA]$ I think that i have to problems: 1- Why perl Makefile.PL can´t find my libsasl2 into /opt/lib ? 2- After fix Makefile.PL with the correct path to INCs and LIBs, why i can´t exceute cyradm? Thanks Danny - Original Message - From: "Joakim Ryden" <[EMAIL PROTECTED]> To: "Danny García Hernández" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, September 22, 2003 11:55 PM Subject: Re: can´t compile cyradm What does 'ldd /usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so' show? --Jo On Monday 22 September 2003 15:21, Danny García Hernández wrote: > Yes, i did it. > > My cyrus-imap was compiled with sasl support. Right now, i need to compile > the perl scripts and cyradm administrative tool, and here is the the > problem. I was looking for into Makefiel.PL and changind the SASL_INC and > SASL_LIB values, the compile process finish OK, but executing cyradm i get > this errors: > > [EMAIL PROTECTED] cyrus-imapd-2.2.1-BETA]# /usr/bin/cyradm > Can't load > '/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so' for > module Cyrus::IMAP: > /usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so: > undefined symbol: sasl_client_init at > /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. > at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Admin.pm line 44 > Compilation failed in require at > /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Admin.pm line 44. > BEGIN failed--compilation aborted at > /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Admin.pm line 44. > Compilation failed in require at > /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Shell.pm line 60. > BEGIN failed--compilation aborted at > /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Shell.pm line 60. > Compilation failed in require. > BEGIN failed--compilation aborted. > > Any advice will be very appreciated > Thanks > Danny > > - Original Message - > From: "Etienne Goyer" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, September 22, 2003 10:39 PM > Subject: Re: can´t compile cyradm > > > I guess you want to specify "--with-sasl=/opt/include/sasl" or something > > along that line to ./configure. Have you tried it ? > > > > On Mon, Sep 22, 2003 at 09:28:57PM +0200, Danny García Hernández wrote: > > > Ken, thank for the first answer to my fisrt problem with cyrus-imapd. > > > > > > But i already have the second stone in my way and the name is CYRADM. > > The problem is that i have installed cyrus-imap into /opt directory, the > library are into /opt/lib/sasl2 and the include files are into > /opt/include/sasl. Then, i´km trying to compile cyradm following the > documentation and i can´t, the compiled proccess is getting this message. > > > > Note (probably harmless): Not found libsasl2 > > > > > > Can any one advice with this? > > > > > > Thank in advanced > > > Danny > > > > -- > > Etienne GoyerLinux Québec Technologies Inc. > > http://www.LinuxQuebec.com [EMAIL PROTECTED] > > !DSPAM:3f6f6e31166561399114306!
Re: can´t compile cyradm
What does 'ldd /usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so' show? --Jo On Monday 22 September 2003 15:21, Danny García Hernández wrote: > Yes, i did it. > > My cyrus-imap was compiled with sasl support. Right now, i need to compile > the perl scripts and cyradm administrative tool, and here is the the > problem. I was looking for into Makefiel.PL and changind the SASL_INC and > SASL_LIB values, the compile process finish OK, but executing cyradm i get > this errors: > > [EMAIL PROTECTED] cyrus-imapd-2.2.1-BETA]# /usr/bin/cyradm > Can't load > '/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so' for > module Cyrus::IMAP: > /usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so: > undefined symbol: sasl_client_init at > /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. > at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Admin.pm line 44 > Compilation failed in require at > /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Admin.pm line 44. > BEGIN failed--compilation aborted at > /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Admin.pm line 44. > Compilation failed in require at > /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Shell.pm line 60. > BEGIN failed--compilation aborted at > /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Shell.pm line 60. > Compilation failed in require. > BEGIN failed--compilation aborted. > > Any advice will be very appreciated > Thanks > Danny > > - Original Message - > From: "Etienne Goyer" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, September 22, 2003 10:39 PM > Subject: Re: can´t compile cyradm > > > I guess you want to specify "--with-sasl=/opt/include/sasl" or something > > along that line to ./configure. Have you tried it ? > > > > On Mon, Sep 22, 2003 at 09:28:57PM +0200, Danny García Hernández wrote: > > > Ken, thank for the first answer to my fisrt problem with cyrus-imapd. > > > > > > But i already have the second stone in my way and the name is CYRADM. > > The problem is that i have installed cyrus-imap into /opt directory, the > library are into /opt/lib/sasl2 and the include files are into > /opt/include/sasl. Then, i´km trying to compile cyradm following the > documentation and i can´t, the compiled proccess is getting this message. > > > > Note (probably harmless): Not found libsasl2 > > > > > > Can any one advice with this? > > > > > > Thank in advanced > > > Danny > > > > -- > > Etienne GoyerLinux Québec Technologies Inc. > > http://www.LinuxQuebec.com [EMAIL PROTECTED] > > !DSPAM:3f6f6e31166561399114306!
Re: can´t compile cyradm
Yes, i did it. My cyrus-imap was compiled with sasl support. Right now, i need to compile the perl scripts and cyradm administrative tool, and here is the the problem. I was looking for into Makefiel.PL and changind the SASL_INC and SASL_LIB values, the compile process finish OK, but executing cyradm i get this errors: [EMAIL PROTECTED] cyrus-imapd-2.2.1-BETA]# /usr/bin/cyradm Can't load '/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so' for module Cyrus::IMAP: /usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Cyrus/IMAP/IMAP.so: undefined symbol: sasl_client_init at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Admin.pm line 44 Compilation failed in require at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Admin.pm line 44. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Admin.pm line 44. Compilation failed in require at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Shell.pm line 60. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Cyrus/IMAP/Shell.pm line 60. Compilation failed in require. BEGIN failed--compilation aborted. Any advice will be very appreciated Thanks Danny - Original Message - From: "Etienne Goyer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 22, 2003 10:39 PM Subject: Re: can´t compile cyradm > I guess you want to specify "--with-sasl=/opt/include/sasl" or something > along that line to ./configure. Have you tried it ? > > On Mon, Sep 22, 2003 at 09:28:57PM +0200, Danny García Hernández wrote: > > Ken, thank for the first answer to my fisrt problem with cyrus-imapd. > > > > But i already have the second stone in my way and the name is CYRADM. The problem is that i have installed cyrus-imap into /opt directory, the library are into /opt/lib/sasl2 and the include files are into /opt/include/sasl. Then, i´km trying to compile cyradm following the documentation and i can´t, the compiled proccess is getting this message. > > > > Note (probably harmless): Not found libsasl2 > > > > Can any one advice with this? > > > > Thank in advanced > > Danny > -- > Etienne GoyerLinux Québec Technologies Inc. > http://www.LinuxQuebec.com [EMAIL PROTECTED] >
Re: Changing Cyrus to accept 8bit subjects
I don't have a patch, but it should be fairly easy, just open the two files "imap/lmtpengine.c" and "imap/message.c" and search for 'X' (quote X quote) and comment the lines, it should be one line per file. I am using version 2.1.13 and the lines are: lmtpengine.c line 861 message.c line 271 Patrick T. Tsang wrote: Could you show me the modification and let me test them? Thanks [EMAIL PROTECTED] Actually most of the users just set a default charset and everything works fine with them. I know it breaks the standard, but we have to do it. Rob Siemborski wrote: On Mon, 22 Sep 2003, Rayed Alrashed wrote: I just modified my Cyrus IMAP to make it accept 8 bit subjects without changing it to the letter 'X', I changed these two files: imap/lmtpengine.c imap/message.c I tested it and it seems to work fine. My question is this change safe? I am afraid it might break Cyrus database format. Since the messages aren't really usable anyway, the change is "safe". But the messages are meaningless -- without being properly encoded with a character set, 8 bit characters are just as useful as an 'X'. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
permission problem with cyrdeliver
Hello, I'm trying to use cyrdeliver with another user than cyrus. So I wondered what I have to do to achieve that? When I run cyrdeliver with another user than cyrus I get the following error message: command "/usr/sbin/cyrdeliver -a wojtek -m user.wojtek" exited 75 couldn't connect to lmtpd: Permission denied)), skipping Thanks in advance, Wojtek -- Best regards, Wojtek mailto:[EMAIL PROTECTED]
Re: can´t compile cyradm
I guess you want to specify "--with-sasl=/opt/include/sasl" or something along that line to ./configure. Have you tried it ? On Mon, Sep 22, 2003 at 09:28:57PM +0200, Danny García Hernández wrote: > Ken, thank for the first answer to my fisrt problem with cyrus-imapd. > > But i already have the second stone in my way and the name is CYRADM. The problem is > that i have installed cyrus-imap into /opt directory, the library are into > /opt/lib/sasl2 and the include files are into /opt/include/sasl. Then, i´km trying > to compile cyradm following the documentation and i can´t, the compiled proccess is > getting this message. > > Note (probably harmless): Not found libsasl2 > > Can any one advice with this? > > Thank in advanced > Danny -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED]
can´t compile cyradm
Ken, thank for the first answer to my fisrt problem with cyrus-imapd. But i already have the second stone in my way and the name is CYRADM. The problem is that i have installed cyrus-imap into /opt directory, the library are into /opt/lib/sasl2 and the include files are into /opt/include/sasl. Then, i´km trying to compile cyradm following the documentation and i can´t, the compiled proccess is getting this message. Note (probably harmless): Not found libsasl2 Can any one advice with this? Thank in advanced Danny
Re: Changing Cyrus to accept 8bit subjects
Could you show me the modification and let me test them? Thanks [EMAIL PROTECTED] > Actually most of the users just set a default charset and everything > works fine with them. > I know it breaks the standard, but we have to do it. > > > Rob Siemborski wrote: > > >On Mon, 22 Sep 2003, Rayed Alrashed wrote: > > > > > > > >>I just modified my Cyrus IMAP to make it accept 8 bit subjects without > >>changing it to the letter 'X', I changed these two files: > >>imap/lmtpengine.c > >>imap/message.c > >>I tested it and it seems to work fine. > >> > >>My question is this change safe? I am afraid it might break Cyrus > >>database format. > >> > >> > > > >Since the messages aren't really usable anyway, the change is "safe". > >But the messages are meaningless -- without being properly encoded with a > >character set, 8 bit characters are just as useful as an 'X'. > > > >-Rob > > > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > >Research Systems Programmer * /usr/contributed Gatekeeper > > > > > > > > > >
Re: Changing Cyrus to accept 8bit subjects
Actually most of the users just set a default charset and everything works fine with them. I know it breaks the standard, but we have to do it. Rob Siemborski wrote: On Mon, 22 Sep 2003, Rayed Alrashed wrote: I just modified my Cyrus IMAP to make it accept 8 bit subjects without changing it to the letter 'X', I changed these two files: imap/lmtpengine.c imap/message.c I tested it and it seems to work fine. My question is this change safe? I am afraid it might break Cyrus database format. Since the messages aren't really usable anyway, the change is "safe". But the messages are meaningless -- without being properly encoded with a character set, 8 bit characters are just as useful as an 'X'. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: virtual domains
Danny García Hernández wrote: Hello, i´m trying to install a cyrus-imapd-2_2 server with virtual domains support. Right now i have a server (cyrus-imap-2.1.9) with this support, using mysql and one cyrus.conf file by domain. Also, I have separated imap directory for each (/var/imap/example1.net and /var/imap/example2.net) I was reading into cyrusv2 docs that a new clause was included into conf file to give support for virtual domains. Can any one explain me how mail boxes are create into separated domain directory?. Unless you want to know what it looks like in the filesystem, doc/install-virtdomains.html should tell you what you need to know. Doing tools/mkimap in my new system, create some subdirectories under /var/imap but user and quota directories are missing. In 2.2, all of the user meta-data directories are created on the fly, that is why mkimap doesn't do it. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
virtual domains
Hello, i´m trying to install a cyrus-imapd-2_2 server with virtual domains support. Right now i have a server (cyrus-imap-2.1.9) with this support, using mysql and one cyrus.conf file by domain. Also, I have separated imap directory for each (/var/imap/example1.net and /var/imap/example2.net) I was reading into cyrusv2 docs that a new clause was included into conf file to give support for virtual domains. Can any one explain me how mail boxes are create into separated domain directory?. Doing tools/mkimap in my new system, create some subdirectories under /var/imap but user and quota directories are missing. Thank in advanced Danny
Re: Changing Cyrus to accept 8bit subjects
On Mon, 22 Sep 2003, Rayed Alrashed wrote: > I just modified my Cyrus IMAP to make it accept 8 bit subjects without > changing it to the letter 'X', I changed these two files: > imap/lmtpengine.c > imap/message.c > I tested it and it seems to work fine. > > My question is this change safe? I am afraid it might break Cyrus > database format. Since the messages aren't really usable anyway, the change is "safe". But the messages are meaningless -- without being properly encoded with a character set, 8 bit characters are just as useful as an 'X'. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Can I use sieve scripts with procmail
I have been using lmtp and am considering using procmail instead Will sieve work with procmail as well Thanks Ram
cyrus-imapd 2.1.15, sieve, lmtpd, and return-path header
Before I start digging through the source, does lmtpd add the Return-Path
header before or after calling sieve routines? The first recipe below
works, the second does not.
# works
require ["fileinto","regex"];
if allof (header :regex "From" ".*") {
fileinto "test1";
}
#fails
require ["fileinto","regex"];
if allof (header :regex "Return-Path" ".*") {
fileinto "test1";
}
-Chris
Changing Cyrus to accept 8bit subjects
Hello all, I just modified my Cyrus IMAP to make it accept 8 bit subjects without changing it to the letter 'X', I changed these two files: imap/lmtpengine.c imap/message.c I tested it and it seems to work fine. My question is this change safe? I am afraid it might break Cyrus database format. Thanks Rayed
