exim4

exim4

[Jakob Hirsch]

Hi,

I have mlmmj 1.2.4 with exim4 running. For the archives, if somebody 
runs into the same problems as me: return_path_add is needed in the 
transport calling mlmmj-recieve. I had a hard time finding that out, 
that should really be in the README.

Anyway, I chose to use my own router and transport for mlmmj:

# main config

MLMMJ_HOME=/var/spool/mlmmj
domainlist ml_domains = my.list.domain


domainlist relay_to_domains = +ml_domains


begin routers

mlmmj_router:
   driver = accept
   domains = +ml_domains
   require_files = MLMMJ_HOME/$local_part/index
   local_part_suffix = +*
   local_part_suffix_optional
   transport = mlmmj_transport


begin transports

mlmmj_transport:
   driver = pipe
   return_path_add
   user = mlmmj
   group = mlmmj
   home_directory = MLMMJ_HOME
   current_directory = MLMMJ_HOME
   command = /usr/local/bin/mlmmj-recieve -F -L MLMMJ_HOME/$local_part




Next thing to look for is VERP, but it works right now and I have only a 
low volume list.


btw, why is it needed to run the mlmmj-tools always with full path? It's 
a little annoying.

Re: exim4

[Mads Martin Joergensen]

* Jakob Hirsch <jh@plonk.de> [Mar 12. 2005 03:51]:
> Hi,
> 
> I have mlmmj 1.2.4 with exim4 running. For the archives, if somebody 
> runs into the same problems as me: return_path_add is needed in the 
> transport calling mlmmj-recieve. I had a hard time finding that out, 
> that should really be in the README.

Could you maybe write it into README.exim and send it to me, then I'll
include it.

> Anyway, I chose to use my own router and transport for mlmmj:
> 
> # main config
> 
> MLMMJ_HOME=/var/spool/mlmmj
> domainlist ml_domains = my.list.domain
> 
> 
> domainlist relay_to_domains = +ml_domains
> 
> 
> begin routers
> 
> mlmmj_router:
>   driver = accept
>   domains = +ml_domains
>   require_files = MLMMJ_HOME/$local_part/index
>   local_part_suffix = +*
>   local_part_suffix_optional
>   transport = mlmmj_transport
> 
> 
> begin transports
> 
> mlmmj_transport:
>   driver = pipe
>   return_path_add
>   user = mlmmj
>   group = mlmmj
>   home_directory = MLMMJ_HOME
>   current_directory = MLMMJ_HOME
>   command = /usr/local/bin/mlmmj-recieve -F -L MLMMJ_HOME/$local_part
> 
> 
> 
> 
> Next thing to look for is VERP, but it works right now and I have only a 
> low volume list.
> 
> 
> btw, why is it needed to run the mlmmj-tools always with full path? It's 
> a little annoying.

It's needed to figure out where the other mlmmj binaries are located.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: exim4

[Drake Wyrm]

At 2005-03-12T14:42:22+0100, Mads Martin Joergensen <mmj@mmj.dk> wrote:
> * Jakob Hirsch <jh@plonk.de> [Mar 12. 2005 03:51]:
> > btw, why is it needed to run the mlmmj-tools always with full path? It's 
> > a little annoying.
> 
> It's needed to figure out where the other mlmmj binaries are located.

I've wondered about that myself. If the binaries are installed somewhere
in $PATH, wouldn't that provide sufficient method for finding them?

-- 
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
  --Ghost in the Shell

Re: exim4

[Mads Martin Joergensen]

* Drake Wyrm <wyrm@haell.com> [Mar 12. 2005 15:36]:
> > > btw, why is it needed to run the mlmmj-tools always with full path? It's 
> > > a little annoying.
> > 
> > It's needed to figure out where the other mlmmj binaries are located.
> 
> I've wondered about that myself. If the binaries are installed somewhere
> in $PATH, wouldn't that provide sufficient method for finding them?

I would prefer for security reasons not to start parsing environment
variables. Besides, with this method, you can have many mlmmj
installations in parallel.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: exim4

[Jakob Hirsch]

Mads Martin Joergensen wrote:

>>runs into the same problems as me: return_path_add is needed in the 
>>transport calling mlmmj-recieve. I had a hard time finding that out, 
> Could you maybe write it into README.exim and send it to me, then I'll
> include it.

Sure, in the next days.

btw, after I had it running, I saw a post in the archive about just this 
subject (http://mlmmj.mmj.dk/archive/0154.html). Should have checked the 
archives a little more thoroughly...

Re: exim4

[Jakob Hirsch]

Mads Martin Joergensen wrote:

>>I've wondered about that myself. If the binaries are installed somewhere
>>in $PATH, wouldn't that provide sufficient method for finding them?
> I would prefer for security reasons not to start parsing environment
> variables. 

Sounds sensible, but mlmmj uses execvp, which uses PATH itself, so why 
should you have to parse that yourself?
Another possibility would be to use a hard coded path from configure or 
some header file.

 > Besides, with this method, you can have many mlmmj
> installations in parallel.

mlmmj uses no config file, so what's the use? Having different versions 
of mlmmj running? That should be done with configure's --program-suffix. 
Otherwise you end up having a directory for every mlmmj installation.

Re: exim4

[Mads Martin Joergensen]

* Jakob Hirsch <jh@plonk.de> [Mar 14. 2005 00:55]:
> Mads Martin Joergensen wrote:
> 
> >>I've wondered about that myself. If the binaries are installed somewhere
> >>in $PATH, wouldn't that provide sufficient method for finding them?
> >I would prefer for security reasons not to start parsing environment
> >variables. 
> 
> Sounds sensible, but mlmmj uses execvp, which uses PATH itself, so why 
> should you have to parse that yourself?

This assumes that mlmmj is installed in the PATH, which very often is
not the case. mlmmj binaries are run by some unpriviliged user, which
often doesn't have a path. That would lead to execlp searching in /bin
and /usr/bin for binaries, but all the BSDs for one have it installed in
/usr/local/bin.

> Another possibility would be to use a hard coded path from configure or 
> some header file.
> 
> > Besides, with this method, you can have many mlmmj installations in
> > parallel.
> 
> mlmmj uses no config file, so what's the use? Having different versions 
> of mlmmj running? That should be done with configure's --program-suffix. 
> Otherwise you end up having a directory for every mlmmj installation.

But then you couldn't move the binaries around, and it would add
constraints. If it's so bad for you, just create a small shell wrapper
which solves it all for you?

The use for several installations is needed for people running
production systems.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: exim4

[Mads Martin Joergensen]

* Jakob Hirsch <jh@plonk.de> [Mar 14. 2005 00:48]:
> >>runs into the same problems as me: return_path_add is needed in the 
> >>transport calling mlmmj-recieve. I had a hard time finding that out, 
> >Could you maybe write it into README.exim and send it to me, then I'll
> >include it.
> 
> Sure, in the next days.

Nice.

> btw, after I had it running, I saw a post in the archive about just this 
> subject (http://mlmmj.mmj.dk/archive/0154.html). Should have checked the 
> archives a little more thoroughly...

The README also has this: "Also make sure that exim will add the
envelope from in the Return-Path: header."

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: exim4

[Christian Laursen]

Jakob Hirsch <jh@plonk.de> writes:

> Mads Martin Joergensen wrote:
> 
> >>I've wondered about that myself. If the binaries are installed somewhere
> >>in $PATH, wouldn't that provide sufficient method for finding them?
> > I would prefer for security reasons not to start parsing environment
> > variables.
> 
> Sounds sensible, but mlmmj uses execvp, which uses PATH itself, so why
> should you have to parse that yourself?
> Another possibility would be to use a hard coded path from configure
> or some header file.

The currently implemented approach works very well. I for one don't like
it when things have to change for no good reason.

If it is so annoying to use the full path, write a wrapper.

>  > Besides, with this method, you can have many mlmmj
> > installations in parallel.
> 
> mlmmj uses no config file, so what's the use? Having different
> versions of mlmmj running? That should be done with configure's
> --program-suffix. Otherwise you end up having a directory for every
> mlmmj installation.

A directory for every installation seems far less confusing than one
directory clobbered with mulitple version from my point of view.

-- 
Christian Laursen

Re: exim4

[Morten K. Poulsen]

On Mon, Mar 14, 2005 at 12:55:30AM +0100, Jakob Hirsch wrote:
> >I would prefer for security reasons not to start parsing environment
> >variables. 
> 
> Sounds sensible, but mlmmj uses execvp, which uses PATH itself, so why should
> you have to parse that yourself?

It only uses $PATH if the given argument does not contain a slash. We might as
well use execl() instead of execlp(). I may patch that.

> Another possibility would be to use a hard coded path from configure or some
> header file.

Configure it at build time? Yikes.

> > Besides, with this method, you can have many mlmmj installations in
> > parallel.
> 
> mlmmj uses no config file, so what's the use? Having different versions of
> mlmmj running? That should be done with configure's --program-suffix.
> Otherwise you end up having a directory for every mlmmj installation.

Exactly! I want to use two different versions of mlmmj for the same list, when
testing a new patch. One set of binaries in one directory, the other set in
another directory, and two different aliases. Therefore I _need_ the full path,
and it can not be in the configuration file, as the two versions share it.

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: exim4

[Jakob Hirsch]

Mads Martin Joergensen wrote:

>>>>runs into the same problems as me: return_path_add is needed in the 
>>>>transport calling mlmmj-recieve. I had a hard time finding that out, 
>>>Could you maybe write it into README.exim and send it to me, then I'll
>>>include it.

I put that in http://plonk.de/sw/mlmmj/README.exim4

>>btw, after I had it running, I saw a post in the archive about just this 
>>subject (http://mlmmj.mmj.dk/archive/0154.html). Should have checked the 
>>archives a little more thoroughly...
> The README also has this: "Also make sure that exim will add the
> envelope from in the Return-Path: header."

errr... ok, will go and hit myself with my LART...

Re: exim4

[Jakob Hirsch]

Morten K. Poulsen wrote:

>>Sounds sensible, but mlmmj uses execvp, which uses PATH itself, so why should
>>you have to parse that yourself?
> It only uses $PATH if the given argument does not contain a slash. We might as
> well use execl() instead of execlp(). I may patch that.

Oh, I thought you used execlp() by intention.

>>Another possibility would be to use a hard coded path from configure or some
>>header file.
> Configure it at build time? Yikes.

Why not? Most poeple use make install and never move around any binaries.

>>mlmmj uses no config file, so what's the use? Having different versions of
>>mlmmj running? That should be done with configure's --program-suffix.
>>Otherwise you end up having a directory for every mlmmj installation.
> Exactly! I want to use two different versions of mlmmj for the same list, when
> testing a new patch. One set of binaries in one directory, the other set in
> another directory, and two different aliases. Therefore I _need_ the full path,
> and it can not be in the configuration file, as the two versions share it.

You mean configuration of a particular mailing list? I agree that 
putting the binaries' path there is senseless.
But what about using --program-suffix? I always thought that's the 
perfect way to have multiple versions of the same software on your system.

Anyway, I think I will code myself a shell script to have something like 
a frontend to the usual functions (sub, unsub, list). That also saves me 
from entering the mlmmj spool directory every time :)

Another possibility would be to use default values for these things 
(taken at configure time). Would you accept a patch for that?

Re: exim4

[Mads Martin Joergensen]

* Jakob Hirsch <jh@plonk.de> [Mar 16. 2005 12:55]:
> Anyway, I think I will code myself a shell script to have something like 
> a frontend to the usual functions (sub, unsub, list). That also saves me 
> from entering the mlmmj spool directory every time :)

Actually mlmmj-list doesn't invoke any other binaries, so I'll remove
the check in that one for the next version.

> Another possibility would be to use default values for these things 
> (taken at configure time). Would you accept a patch for that?

Not likely. But I would love to put your wrapper scripts in contrib/

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: exim4

[Jakob Hirsch]

Mads Martin Joergensen wrote:

> Actually mlmmj-list doesn't invoke any other binaries, so I'll remove
> the check in that one for the next version.

I did not look there, but it runs already fine without full path.

>>Another possibility would be to use default values for these things 
>>(taken at configure time). Would you accept a patch for that?
> Not likely. But I would love to put your wrapper scripts in contrib/

ok, will be happy to send it when it's ready.

Re: exim4

[Mads Martin Joergensen]

* Jakob Hirsch <jh@plonk.de> [Mar 16. 2005 12:42]:
> 
> I put that in http://plonk.de/sw/mlmmj/README.exim4

Thanks! I've committed to CVS, so it'll be part of next release.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.