Re: [Dovecot] xexec and dovecot 1.1
Scott Silva wrote: on 3-27-2008 12:30 PM Charles Marcus spake the following: On 3/27/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: Clients would have to be rewritten to support the new IMAP extensions. If the IMAP server supported outgoing email then the client would know it through CAPABILITIES. It would then not need to have any outgoing email settings. It would cut client configuration in half. My server currently uses: Incoming: imap.example.com Outgoing: smtp.example.com If dovecot 'understands' smtp, then why couldn't you just point the outgoing to 'imap.example.com', so no Client mods would be needed? But the clients send to port 25 on the outgoing server, unless you force them to use something different. Port 25 is SMTP. You can have incoming and outgoing on the same server, you just need a MTA running along with the dovecot server. That's right. I'm assuming that anyone who is running Dovecot also runs an MTA. My idea for using IMAP as an outgoing transport is just to move the outgoing message from the client to dovecot, then dovecot hands it off locally to the MTA, and the MTA sends it to the destination. I'm not suggesting Dovecot become an MTA.
Re: [Dovecot] xexec and dovecot 1.1
on 3-27-2008 12:30 PM Charles Marcus spake the following: On 3/27/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: Clients would have to be rewritten to support the new IMAP extensions. If the IMAP server supported outgoing email then the client would know it through CAPABILITIES. It would then not need to have any outgoing email settings. It would cut client configuration in half. My server currently uses: Incoming: imap.example.com Outgoing: smtp.example.com If dovecot 'understands' smtp, then why couldn't you just point the outgoing to 'imap.example.com', so no Client mods would be needed? But the clients send to port 25 on the outgoing server, unless you force them to use something different. Port 25 is SMTP. You can have incoming and outgoing on the same server, you just need a MTA running along with the dovecot server. signature.asc Description: OpenPGP digital signature
Re: [Dovecot] xexec and dovecot 1.1
On 3/27/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: Clients would have to be rewritten to support the new IMAP extensions. If the IMAP server supported outgoing email then the client would know it through CAPABILITIES. It would then not need to have any outgoing email settings. It would cut client configuration in half. My server currently uses: Incoming: imap.example.com Outgoing: smtp.example.com If dovecot 'understands' smtp, then why couldn't you just point the outgoing to 'imap.example.com', so no Client mods would be needed? -- Best regards, Charles
Re: [Dovecot] xexec and dovecot 1.1
Charles Marcus wrote: On 3/27/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: After dovecot receives he outgoing message it will just do an SMTP connection to a server that is set up to receive it and relay it. The question I have is how would you configure the Client to do this? I guess just point it to the same server address as the incoming server? Clients would have to be rewritten to support the new IMAP extensions. If the IMAP server supported outgoing email then the client would know it through CAPABILITIES. It would then not need to have any outgoing email settings. It would cut client configuration in half.
Re: [Dovecot] xexec and dovecot 1.1
on 3-27-2008 11:50 AM Charles Marcus spake the following: On 3/27/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: After dovecot receives he outgoing message it will just do an SMTP connection to a server that is set up to receive it and relay it. The question I have is how would you configure the Client to do this? I guess just point it to the same server address as the incoming server? Someone would have to re-write the clients also. This looks like something else that Outlook will break. -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't signature.asc Description: OpenPGP digital signature
Re: [Dovecot] xexec and dovecot 1.1
On 3/27/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: After dovecot receives he outgoing message it will just do an SMTP connection to a server that is set up to receive it and relay it. The question I have is how would you configure the Client to do this? I guess just point it to the same server address as the incoming server? -- Best regards, Charles
Re: [Dovecot] xexec and dovecot 1.1
Ed W wrote: For the 'Copy to Sent' function... if you sent a message somehow using the IMAP connection, maybe you could save the Client having to upload the same message AGAIN just to copy it to the Sent folder (think 10MB email sent over a 512Kb connection)... No need for a new extension, it's easier to make your MTA deliver a copy of outgoing mail to the 'Sent' folder for those users that want it. OK, I'm game. Design this for me assuming Postfix + Dovecot. Lets assume they are on different servers just to examine the more general situation. We can probably assume an authenticated sasl connection or else it becomes fairly intractable, but we have to assume that customers can choose their FROM address (for many setups the incoming connection might be both unauthenticated AND have random (even forged) FROM addresses...) So what should the config look like? Ed Assuming you are talking about my idea that IMAP have an outgoing mail extension and copies the outgoing message to the sent folder. After dovecot receives he outgoing message it will just do an SMTP connection to a server that is set up to receive it and relay it. smtpserver = 1.2.3.4 copyfolder = sent Is this what you are asking?
Re: [Dovecot] xexec and dovecot 1.1
For the 'Copy to Sent' function... if you sent a message somehow using the IMAP connection, maybe you could save the Client having to upload the same message AGAIN just to copy it to the Sent folder (think 10MB email sent over a 512Kb connection)... No need for a new extension, it's easier to make your MTA deliver a copy of outgoing mail to the 'Sent' folder for those users that want it. OK, I'm game. Design this for me assuming Postfix + Dovecot. Lets assume they are on different servers just to examine the more general situation. We can probably assume an authenticated sasl connection or else it becomes fairly intractable, but we have to assume that customers can choose their FROM address (for many setups the incoming connection might be both unauthenticated AND have random (even forged) FROM addresses...) So what should the config look like? Ed
Re: [Dovecot] xexec and dovecot 1.1
On 3/25/2008 2:20 PM, Marc Perkel wrote: But when I was sitting here watching a large email I had just sent copying to the Sent folder, just minutes after reading your message - it hit me that this would be one very real benefit to it... Yes - my idea isn't for Dovecot to be an SMTP server. As you know IMAP can move messages from the client to the server. My idea is that you add the ability to move it to the server and then hand it off to a real SMTP server for delivery. IMAP is just being used as a transport to upload the message past various port blocks. Does this make sense? Of course... this is the part I saw some value in. But what I meant was, I had seen some messages from you in the past (many months ago) suggesting changes the the IMAP protocol in general that would allow the execution of arbitrary code to do arbitrary things. *This* is what I didn't like. -- Best regards, Charles
Re: [Dovecot] xexec and dovecot 1.1
Charles Marcus escribió: On 3/25/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: What I'm really looking for someone to do is write some kind of SMTP over IMAP plugin so that IMAP can be an authenticated transport that would carry outbound email to Dovecot which would hand it off to an SMTP server or be a conduit to SMTP server. That way email users need not configure outgoing SMTP. It would just send outgoing email over the same connections. I have been a big detractor for any usefulness for this kind of thing, but there is one use that would be a big plus... For the 'Copy to Sent' function... if you sent a message somehow using the IMAP connection, maybe you could save the Client having to upload the same message AGAIN just to copy it to the Sent folder (think 10MB email sent over a 512Kb connection)... No need for a new extension, it's easier to make your MTA deliver a copy of outgoing mail to the 'Sent' folder for those users that want it. -- Angel Marin http://anmar.eu.org/
Re: [Dovecot] xexec and dovecot 1.1
Charles Marcus wrote: On 3/25/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: So Charles - why is it that you've resisted the idea? it just seems so natural to me. I've read your messages calling for much more than just 'smtp over imap' for the imap protocol, and didn't care much for the ideas, because an IMAP/POP server is an IMAP/POP server - not an SMTP server (or a file manager, or anything else). But when I was sitting here watching a large email I had just sent copying to the Sent folder, just minutes after reading your message - it hit me that this would be one very real benefit to it... Yes - my idea isn't for Dovecot to be an SMTP server. As you know IMAP can move messages from the client to the server. My idea is that you add the ability to move it to the server and then hand it off to a real SMTP server for delivery. IMAP is just being used as a transport to upload the message past various port blocks. Does this make sense?
Re: [Dovecot] xexec and dovecot 1.1
On 3/25/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: So Charles - why is it that you've resisted the idea? it just seems so natural to me. I've read your messages calling for much more than just 'smtp over imap' for the imap protocol, and didn't care much for the ideas, because an IMAP/POP server is an IMAP/POP server - not an SMTP server (or a file manager, or anything else). But when I was sitting here watching a large email I had just sent copying to the Sent folder, just minutes after reading your message - it hit me that this would be one very real benefit to it... -- Best regards, Charles
Re: [Dovecot] xexec and dovecot 1.1
I added your idea to my list of reasons for SMTP over IMAP. SMTP over IMAP One of the purposes of developing XEXEC was to lead to SMTP over IMAP. The idea is rather than having a separate configuration for outgoing email that users would use the already authenticated IMAP session to transport outgoing email to an SMTP server which would accept it for outgoing delivery. Such a system would have several advantages. * Simplicity of setup - Outgoing SMTP goes away. * Port Blocking - no port 25 blocks to worry about * Single login - same login for incoming and outgoing email * Authentication - The person sending the email is the person who can read email sent to that address * Single Protocol - Why use both SMTP and IMAP when you can use just one? * Copy to server side sent folder - no need to upload the message twice * Virus Isolation - With port 25 blocked viruses wouldn't be able to send email. SENDER (IMAP) -> DOVECOT (local) -> SMTP-OUT (SMTP) -> SMTP-IN -> RECIPIENT (IMAP) IMAP would be a consumer to server protocol. SMTP would be a server to server protocol.
Re: [Dovecot] xexec and dovecot 1.1
Charles Marcus wrote: On 3/25/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: What I'm really looking for someone to do is write some kind of SMTP over IMAP plugin so that IMAP can be an authenticated transport that would carry outbound email to Dovecot which would hand it off to an SMTP server or be a conduit to SMTP server. That way email users need not configure outgoing SMTP. It would just send outgoing email over the same connections. I have been a big detractor for any usefulness for this kind of thing, but there is one use that would be a big plus... For the 'Copy to Sent' function... if you sent a message somehow using the IMAP connection, maybe you could save the Client having to upload the same message AGAIN just to copy it to the Sent folder (think 10MB email sent over a 512Kb connection)... That's a good point. The operation of copying to a server side sent folder could be done in the same operation. So Charles - why is it that you've resisted the idea? it just seems so natural to me.
Re: [Dovecot] xexec and dovecot 1.1
On Tue, 2008-03-25 at 11:35 -0400, Charles Marcus wrote: > On 3/25/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: > > What I'm really looking for someone to do is write some kind of SMTP > > over IMAP plugin so that IMAP can be an authenticated transport that > > would carry outbound email to Dovecot which would hand it off to an > > SMTP server or be a conduit to SMTP server. That way email users need > > not configure outgoing SMTP. It would just send outgoing email over > > the same connections. > > I have been a big detractor for any usefulness for this kind of thing, > but there is one use that would be a big plus... > > For the 'Copy to Sent' function... if you sent a message somehow using > the IMAP connection, maybe you could save the Client having to upload > the same message AGAIN just to copy it to the Sent folder (think 10MB > email sent over a 512Kb connection)... LEMONADE's URLAUTH + CATENATE extensions will help with this. Everything else is also possible to do in more standard (although maybe more complex) ways except one: Some stupid networks block also submission port, so it's not possible to send outgoing mails with either port smtp/25 or submission/587 (or probably also ssmtp/465). signature.asc Description: This is a digitally signed message part
Re: [Dovecot] xexec and dovecot 1.1
On 3/25/2008, Marc Perkel ([EMAIL PROTECTED]) wrote: What I'm really looking for someone to do is write some kind of SMTP over IMAP plugin so that IMAP can be an authenticated transport that would carry outbound email to Dovecot which would hand it off to an SMTP server or be a conduit to SMTP server. That way email users need not configure outgoing SMTP. It would just send outgoing email over the same connections. I have been a big detractor for any usefulness for this kind of thing, but there is one use that would be a big plus... For the 'Copy to Sent' function... if you sent a message somehow using the IMAP connection, maybe you could save the Client having to upload the same message AGAIN just to copy it to the Sent folder (think 10MB email sent over a 512Kb connection)... -- Best regards, Charles
Re: [Dovecot] xexec and dovecot 1.1
Alex wrote: Patch and prepatched version of xexec module to dovecot v1.1 now available from http://wiki.dovecot.org/Plugins/xexec. Thanks for patch to Stephan Bosch. Thanks Alex. If people like you who are actually using this want to take over the development of it that would be fine with me. I just started it to get the idea going in hopes it would take off and become a standard for nonstandard extensions. I think it has great potential. What I'm really looking for someone to do is write some kind of SMTP over IMAP plugin so that IMAP can be an authenticated transport that would carry outbound email to Dovecot which would hand it off to an SMTP server or be a conduit to SMTP server. That way email users need not configure outgoing SMTP. It would just send outgoing email over the same connections.
Re: [Dovecot] xexec and dovecot 1.1
Stephan Bosch wrote:
Alex wrote:
Stephan Bosch wrote:
[EMAIL PROTECTED] schreef:
[EMAIL PROTECTED] schreef:
Thank you, Stephan, for your help. Patch applies without any problem
and
compilation was successful. According maillog, Dovecot load it without
problems too:
Mar 19 09:06:37 mx3 dovecot: IMAP([EMAIL PROTECTED]): Module loaded:
/usr/lib/dovecot/imap/lib10_xexec_plugin.so
I have activate it in config as for dovecot 1.0. But "sub commands"
does
not started:
...
[pid 4093] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 4093 detached
<... select resumed> ) = 2 (in [8 10], left {2147482,
996000})
--- SIGCHLD (Child exited) @ 0 (0) --
Found it, apparently dovecot-1.1 does not like a NULL parameter to
the array_get function anymore:
-execvp(*(char **)array_idx(&command, 0), array_get(&command,
NULL));
+execvp(*(char **)array_idx(&command, 0), array_idx(&command,
0));
With this additional change, the attached full patch manages to
update the XEXEC plugin to dovecot-1.1. This was tested with the
'average' example and that worked flawlessly.
Regards,
Stephan
Thank you again, Stephan. Now all works perfectly :-) Probably at
http://wiki.dovecot.org/Plugins/xexec it is good to have link on
patch/new version of module, created by you. Or attach to page file. I
can do it, if it's ok. What you think?
Fine with me, but I think you should ask the author of this module. He
can also release a proper new version.
Regards,
Stephan.
Go ahead and post it as a new released version. That's fine with me. I'm
glad someone is using this. What are you all doing with it.
Re: [Dovecot] xexec and dovecot 1.1
Alex wrote:
> Stephan Bosch wrote:
>> [EMAIL PROTECTED] schreef:
>>> [EMAIL PROTECTED] schreef:
>>> Thank you, Stephan, for your help. Patch applies without any problem
>>> and
>>> compilation was successful. According maillog, Dovecot load it without
>>> problems too:
>>>
>>> Mar 19 09:06:37 mx3 dovecot: IMAP([EMAIL PROTECTED]): Module loaded:
>>> /usr/lib/dovecot/imap/lib10_xexec_plugin.so
>>> I have activate it in config as for dovecot 1.0. But "sub commands"
>>> does
>>> not started:
>>>
>>> ...
>>>
>>> [pid 4093] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
>>> Process 4093 detached
>>> <... select resumed> ) = 2 (in [8 10], left {2147482,
>>> 996000})
>>> --- SIGCHLD (Child exited) @ 0 (0) --
>> Found it, apparently dovecot-1.1 does not like a NULL parameter to
>> the array_get function anymore:
>>
>> -execvp(*(char **)array_idx(&command, 0), array_get(&command,
>> NULL));
>> +execvp(*(char **)array_idx(&command, 0), array_idx(&command,
>> 0));
>>
>> With this additional change, the attached full patch manages to
>> update the XEXEC plugin to dovecot-1.1. This was tested with the
>> 'average' example and that worked flawlessly.
>>
>> Regards,
>>
>> Stephan
>>
>>
> Thank you again, Stephan. Now all works perfectly :-) Probably at
> http://wiki.dovecot.org/Plugins/xexec it is good to have link on
> patch/new version of module, created by you. Or attach to page file. I
> can do it, if it's ok. What you think?
Fine with me, but I think you should ask the author of this module. He
can also release a proper new version.
Regards,
Stephan.
Re: [Dovecot] xexec and dovecot 1.1
DOH! Forgot to CC to the mailinglist:
[EMAIL PROTECTED] schreef:[EMAIL PROTECTED] schreef:
> [EMAIL PROTECTED] schreef:
> Thank you, Stephan, for your help. Patch applies without any problem and
> compilation was successful. According maillog, Dovecot load it without
> problems too:
>
> Mar 19 09:06:37 mx3 dovecot: IMAP([EMAIL PROTECTED]): Module loaded:
> /usr/lib/dovecot/imap/lib10_xexec_plugin.so
> I have activate it in config as for dovecot 1.0. But "sub commands" does
> not started:
>
> ...
>
> [pid 4093] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> Process 4093 detached
> <... select resumed> ) = 2 (in [8 10], left {2147482,
> 996000})
> --- SIGCHLD (Child exited) @ 0 (0) --
Found it, apparently dovecot-1.1 does not like a NULL parameter to the
array_get function anymore:
-execvp(*(char **)array_idx(&command, 0), array_get(&command,
NULL));
+execvp(*(char **)array_idx(&command, 0), array_idx(&command, 0));
With this additional change, the attached full patch manages to update
the XEXEC plugin to dovecot-1.1. This was tested with the 'average'
example and that worked flawlessly.
Regards,
Stephan
Updated module to dovecot-1.1
diff -r 7cafabf38524 cmd-xexec.c
--- a/cmd-xexec.c Wed Mar 19 00:58:24 2008 +0100
+++ b/cmd-xexec.c Fri Mar 21 18:12:26 2008 +0100
@@ -128,10 +128,10 @@ static void cmd_xexec_stderr(void *conte
bool cmd_xexec(struct client_command_context *cmd)
{
- struct imap_arg * imap_args;
+ const struct imap_arg *imap_args;
const char *imap_command;
char **backend_command;
- array_t ARRAY_DEFINE(command, char *);
+ ARRAY_DEFINE(command, char *);
pid_t pid;
int status;
int pipe_in[2];
@@ -177,12 +177,13 @@ bool cmd_xexec(struct client_command_con
return FALSE;
}
- ARRAY_CREATE(&command, unsafe_data_stack_pool, char *, 8);
+ t_array_init(&command, 8);
- array_append(&command, backend_command, strarray_length((char const *
const *)backend_command));
+ array_append(&command, backend_command,
+ str_array_length((char const * const *)backend_command));
for (i = 1; imap_args[i].type != IMAP_ARG_EOL; i++) {
- const char *str = imap_arg_string(&imap_args[i]);
+ char *str = p_strdup(cmd->pool, imap_arg_string(&imap_args[i]));
if (str == NULL) {
client_send_command_error(cmd, "Invalid arguments.");
t_pop();
@@ -236,7 +237,7 @@ bool cmd_xexec(struct client_command_con
}
close(pipe_err[1]);
- execvp(*(char **)array_idx(&command, 0), array_get(&command,
NULL));
+ execvp(*(char **)array_idx(&command, 0), array_idx(&command,
0));
exit(1);
}
@@ -246,11 +247,11 @@ bool cmd_xexec(struct client_command_con
close(pipe_out[1]);
close(pipe_err[1]);
- ctx->in = o_stream_create_file(pipe_in[1], default_pool, 0, TRUE);
- ctx->out = i_stream_create_file(pipe_out[0], default_pool, 1024, TRUE);
- ctx->err = i_stream_create_file(pipe_err[0], default_pool, 1024, TRUE);
+ ctx->in = o_stream_create_fd(pipe_in[1], 0, TRUE);
+ ctx->out = i_stream_create_fd(pipe_out[0], 1024, TRUE);
+ ctx->err = i_stream_create_fd(pipe_err[0], 1024, TRUE);
- ctx->loop = io_loop_create(default_pool);
+ ctx->loop = io_loop_create();
ctx->io_out = io_add(i_stream_get_fd(ctx->out), IO_READ,
cmd_xexec_stdout, ctx);
ctx->io_err = io_add(i_stream_get_fd(ctx->err), IO_READ,
diff -r 7cafabf38524 xexec.h
--- a/xexec.h Wed Mar 19 00:58:24 2008 +0100
+++ b/xexec.h Fri Mar 21 18:12:26 2008 +0100
@@ -5,7 +5,7 @@
struct xexec {
- array_t ARRAY_DEFINE(setups, struct xexec_setups *);
+ ARRAY_DEFINE(setups, struct xexec_setup *);
};
struct xexec_setup {
diff -r 7cafabf38524 xexec_plugin.c
--- a/xexec_plugin.cWed Mar 19 00:58:24 2008 +0100
+++ b/xexec_plugin.cFri Mar 21 18:12:26 2008 +0100
@@ -75,7 +75,7 @@ static struct xexec *xexec_init(void)
struct xexec *xexec;
xexec = i_new(struct xexec, 1);
- ARRAY_CREATE(&xexec->setups, default_pool, struct xexec_setup *, 4);
+ i_array_init(&xexec->setups, 4);
return xexec;
}
@@ -122,7 +122,7 @@ void xexec_plugin_init(void)
}
t_pop();
- command_register("XEXEC", cmd_xexec);
+ command_register("XEXEC", cmd_xexec, 0);
str_append(capability_string, " XEXEC");
}
Re: [Dovecot] xexec and dovecot 1.1
[EMAIL PROTECTED] schreef:
I'll test very interesting plugin xexec. It seems very nice and can be
used in many things. It's compiled perfect with dovecot 1.0, but certanly
not with dovecot 1.1. It's stopped with next error:
I did not write that module, but tonight I got a bit bored, so I gave it
a quick try to port it to Dovecot 1.1. The attached patch provides a
compile fix to make it compile without warnings for dovecot-1.1. I only
tested whether the module is successfully loaded by Dovecot and not
whether XEXEC still does what it is supposed to. It does not segfault on
the xexec command, but that is all I tested. I got a backend command
error and now it is bed time for me, but there is a good chance that
this works if you bother to read the wiki page properly ;) So, consider
this to be more like an 'It compiles! Ship it!' kind of fix. But,
anyways, it should help you to get where you want.
Just apply inside the xexec directory using the usual patch -p1. Let me
know what you find out.
Regards,
Stephan.
Updated module to dovecot-1.1
diff -r 521e4f5eb2fe cmd-xexec.c
--- a/cmd-xexec.c Wed Mar 19 00:22:45 2008 +0100
+++ b/cmd-xexec.c Wed Mar 19 00:57:30 2008 +0100
@@ -128,10 +128,10 @@ static void cmd_xexec_stderr(void *conte
bool cmd_xexec(struct client_command_context *cmd)
{
- struct imap_arg * imap_args;
+ const struct imap_arg *imap_args;
const char *imap_command;
char **backend_command;
- array_t ARRAY_DEFINE(command, char *);
+ ARRAY_DEFINE(command, char *);
pid_t pid;
int status;
int pipe_in[2];
@@ -177,12 +177,13 @@ bool cmd_xexec(struct client_command_con
return FALSE;
}
- ARRAY_CREATE(&command, unsafe_data_stack_pool, char *, 8);
+ t_array_init(&command, 8);
- array_append(&command, backend_command, strarray_length((char const *
const *)backend_command));
+ array_append(&command, backend_command,
+ str_array_length((char const * const *)backend_command));
for (i = 1; imap_args[i].type != IMAP_ARG_EOL; i++) {
- const char *str = imap_arg_string(&imap_args[i]);
+ char *str = p_strdup(cmd->pool, imap_arg_string(&imap_args[i]));
if (str == NULL) {
client_send_command_error(cmd, "Invalid arguments.");
t_pop();
@@ -246,11 +247,11 @@ bool cmd_xexec(struct client_command_con
close(pipe_out[1]);
close(pipe_err[1]);
- ctx->in = o_stream_create_file(pipe_in[1], default_pool, 0, TRUE);
- ctx->out = i_stream_create_file(pipe_out[0], default_pool, 1024, TRUE);
- ctx->err = i_stream_create_file(pipe_err[0], default_pool, 1024, TRUE);
+ ctx->in = o_stream_create_fd(pipe_in[1], 0, TRUE);
+ ctx->out = i_stream_create_fd(pipe_out[0], 1024, TRUE);
+ ctx->err = i_stream_create_fd(pipe_err[0], 1024, TRUE);
- ctx->loop = io_loop_create(default_pool);
+ ctx->loop = io_loop_create();
ctx->io_out = io_add(i_stream_get_fd(ctx->out), IO_READ,
cmd_xexec_stdout, ctx);
ctx->io_err = io_add(i_stream_get_fd(ctx->err), IO_READ,
diff -r 521e4f5eb2fe xexec.h
--- a/xexec.h Wed Mar 19 00:22:45 2008 +0100
+++ b/xexec.h Wed Mar 19 00:57:30 2008 +0100
@@ -5,7 +5,7 @@
struct xexec {
- array_t ARRAY_DEFINE(setups, struct xexec_setups *);
+ ARRAY_DEFINE(setups, struct xexec_setup *);
};
struct xexec_setup {
diff -r 521e4f5eb2fe xexec_plugin.c
--- a/xexec_plugin.cWed Mar 19 00:22:45 2008 +0100
+++ b/xexec_plugin.cWed Mar 19 00:57:30 2008 +0100
@@ -75,7 +75,7 @@ static struct xexec *xexec_init(void)
struct xexec *xexec;
xexec = i_new(struct xexec, 1);
- ARRAY_CREATE(&xexec->setups, default_pool, struct xexec_setup *, 4);
+ i_array_init(&xexec->setups, 4);
return xexec;
}
@@ -122,7 +122,7 @@ void xexec_plugin_init(void)
}
t_pop();
- command_register("XEXEC", cmd_xexec);
+ command_register("XEXEC", cmd_xexec, 0);
str_append(capability_string, " XEXEC");
}
