Pkg exim4 users - Dec 2005 - pipe aliases and permissions

Hi,

I did a search in gmane for exim mailing lists. It was a nice surprise to 
find a Debian-specific one.

I''ve been trying to configure the email gateway for roundup 
(http://roundup.sourceforge.net).

In the section on configuring an email interface,

http://roundup.sourceforge.net/doc-0.8/installation.html#configure-an-email-interface

there are instructions about setting up a mail alias pipe process.

However, this does not work out of the box, at least on Debian''s exim, 
since the pipe transport is unset, and also there is a permissions issue, 
as described at

http://www.exim.org/exim-html-4.50/doc/html/FAQ.html#TOC198

I''m not completely sure what acutually happens here. Apparently Exim
runs
as different users depending on what it is doing, and in the case it is 
piped to a process you have to tell it because it doesn''t know what
user
it should run as, or something?

However, surely it must be running under some default permissions in that 
case? What are those?

Anyway, in the case of roundup the pipe looks like

newtracker: "|/usr/bin/python /usr/bin/roundup-mailgw 
/var/lib/roundup/trackers/newtracker/"

This needs to write to a directory 
(/var/lib/roundup/trackers/newtracker/db), which I''ve set the gid bit
on,
and also set it to be owned by the group roundup. I added Debian-exim to 
the ''roundup'' group.

So, if exim was to write to the directory with owner:group 
Debian-exim:roundup, it would be Ok, but i was getting permission errors. 
Funnily enough, when I set that directory (db) to be writable by anyone, 
the owner:group that I saw for the file created by Exim were in fact 
Debian-exim:roundup.

Can anyone explain to me what is going on here?

Anyway, I''m using the monolithic config file for exim4, 
/etc/exim4/exim4.conf.template, and added the following lines at the 
beginning to fix this.

SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe
SYSTEM_ALIASES_USER = Debian-exim
SYSTEM_ALIASES_GROUP = roundup

The section that uses these variables is the exim4-config_system_aliases 
section.

***********************************************************
system_aliases:
   debug_print = "R: system_aliases for $local_part@$domain"
   driver = redirect
   domains = +local_domains
   allow_fail
   allow_defer
   data = ${lookup{$local_part}lsearch{/etc/aliases}}
   .ifdef SYSTEM_ALIASES_USER
   user = SYSTEM_ALIASES_USER
   .endif
   .ifdef SYSTEM_ALIASES_GROUP
   group = SYSTEM_ALIASES_GROUP
   .endif
   .ifdef SYSTEM_ALIASES_FILE_TRANSPORT
   file_transport = SYSTEM_ALIASES_FILE_TRANSPORT
   .endif
   .ifdef SYSTEM_ALIASES_PIPE_TRANSPORT
   pipe_transport = SYSTEM_ALIASES_PIPE_TRANSPORT
   .endif
   .ifdef SYSTEM_ALIASES_DIRECTORY_TRANSPORT
   directory_transport = SYSTEM_ALIASES_DIRECTORY_TRANSPORT
   .endif
********************************************************

My understanding of what is going on here is currently minimal. If anyone 
could recommend good reading about this, I''d be happy to understand it 
better.

However, my immediate question is whether this will break anything. I have 
an /etc/aliases as per usual on Debian, but have not done anything to it 
except the Roundup line quoted above.

Secondly, is this is a reasonable thing to do, and if not, what are the 
alternatives?

Apparently the Debian Exim maintainers consider pipe transports for 
aliases deprecated, and prefer a dedicated router/transport instead. 
However, at the moment I''ve no idea how to do this.

It is also possible that to do so would require specific knowledge of 
Roundup.

If someone would explain to me how to set this up, I''ll submit a
wishlist
bug against the Debian roundup package so other people know what to do.

BTW, has anyone read The Exim SMTP Mail Server Official Guide for Release 
4 (http://www.uit.co.uk/exim-book/)? If so, what did you think of it?

Thanks in advance.                                          Faheem.

On Fri, Dec 09, 2005 at 03:21:51PM -0500, Faheem Mitha
wrote:
> I did a search in gmane for exim mailing lists. It was a nice surprise to 
> find a Debian-specific one.
It is also prominently mentioned in the Debian package.
> I''ve been trying to configure the email gateway for roundup 
> (http://roundup.sourceforge.net).
> 
> In the section on configuring an email interface,
> 
>
http://roundup.sourceforge.net/doc-0.8/installation.html#configure-an-email-interface
> 
> there are instructions about setting up a mail alias pipe process.
> 
> However, this does not work out of the box, at least on Debian''s
exim,
> since the pipe transport is unset,
That is documented in the configuration file right next to the
system_ailases router, and it is also mentioned in the README.
> and also there is a permissions issue, 
> as described at
> 
> http://www.exim.org/exim-html-4.50/doc/html/FAQ.html#TOC198
That''s not a permissions issue. You just need to tell exim which user
to run as when invoking the pipe.
> I''m not completely sure what acutually happens here. Apparently
Exim runs
> as different users depending on what it is doing, and in the case it is 
> piped to a process you have to tell it because it doesn''t know
what user
> it should run as, or something?
Yes, right.
> However, surely it must be running under some default permissions in that 
> case? What are those?
It runs as the user Debian-exim, which has write access to the mail
logs, and to the mail spool. I hope that it is clear that running user
processes with these set of privileges is almost as bad an idea as
root is.
> Anyway, in the case of roundup the pipe looks like
> 
> newtracker: "|/usr/bin/python /usr/bin/roundup-mailgw 
> /var/lib/roundup/trackers/newtracker/"
> 
> This needs to write to a directory 
> (/var/lib/roundup/trackers/newtracker/db), which I''ve set the gid
bit on,
> and also set it to be owned by the group roundup. I added Debian-exim to 
> the ''roundup'' group.
Exim does not assume the privileges of any additional groups that the
Exim user might be in for local deliveries. This is discussed in
spec.txt, chapter 23. But that''s irrelevant here since you set a group
on the router.
> So, if exim was to write to the directory with owner:group 
> Debian-exim:roundup, it would be Ok, but i was getting permission errors. 
Because it was trying to write as Debian-exim:Debian-exim, as watching
a delivery process with -d clearly shows:
changed uid/gid: local delivery to |/tmp/mailpipe <|/tmp/mailpipe>
transport=address_pipe
  uid=105 gid=105 pid=5378
  auxiliary group list: <none>
  home=NULL current=/
      
> Funnily enough, when I set that directory (db) to be writable by anyone, 
> the owner:group that I saw for the file created by Exim were in fact 
> Debian-exim:roundup.
That is the result of the gid bit on the directory.
> Can anyone explain to me what is going on here?
See any explanation of UNIX file mode semantics.
> Anyway, I''m using the monolithic config file for exim4, 
> /etc/exim4/exim4.conf.template, and added the following lines at the 
> beginning to fix this.
> 
> SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe
> SYSTEM_ALIASES_USER = Debian-exim
> SYSTEM_ALIASES_GROUP = roundup
> 
> The section that uses these variables is the exim4-config_system_aliases 
> section.
Setting the group on the transfer seems to work on my system. Now we
need to find out why it doesn''t work when setting the group on the
router. I''m going to ask exim-users about this.
> However, my immediate question is whether this will break anything. I have 
> an /etc/aliases as per usual on Debian, but have not done anything to it 
> except the Roundup line quoted above.
All pipe deliveries are done with group roundup, which I consider
unelegant. And it might be a surprise for your successors when they
take over the system from you.
> Apparently the Debian Exim maintainers consider pipe transports for 
> aliases deprecated, and prefer a dedicated router/transport instead. 
> However, at the moment I''ve no idea how to do this.
Did you take a look at /usr/share/doc/mailman/README.EXIM on a system
with mailman installed as suggested in exim''s README?

The following should be a start:

  roundup_router:
    driver = accept
    require_files = /usr/bin/roundup-mailgw
    local_parts = newtracker
    transport = mailman_transport

  roundup_transport:
    driver = pipe
    command = /usr/bin/python /usr/bin/roundup-mailgw
/var/lib/roundup/trackers/newtracker/
    current_directory = 
    home_directory = 
    user = 
    group = 

This can possibly be gold-plated by having the router or transport
look in the roundup config to see wheter a local_part should be
handled by roundup.
> BTW, has anyone read The Exim SMTP Mail Server Official Guide for Release 
> 4 (http://www.uit.co.uk/exim-book/)? If so, what did you think of it?
It is an excellent book, straight from "the horses mouth", and much
better as a tutorial as the spec.txt file which is more a reference
than a tutorial.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Hi Marc,

Thanks for the super helpful reply, and sorry for being so clueless.

On Sat, 10 Dec 2005, Marc Haber wrote:
> On Fri, Dec 09, 2005 at 03:21:51PM -0500, Faheem Mitha wrote:
>> I did a search in gmane for exim mailing lists. It was a nice surprise
to
>> find a Debian-specific one.
>
> It is also prominently mentioned in the Debian package.
Easy to miss the obvious, sorry.
>> However, surely it must be running under some default permissions in
that
>> case? What are those?
>
> It runs as the user Debian-exim, which has write access to the mail
> logs, and to the mail spool. I hope that it is clear that running user
> processes with these set of privileges is almost as bad an idea as
> root is.
True.
> Exim does not assume the privileges of any additional groups that the
> Exim user might be in for local deliveries. This is discussed in
> spec.txt, chapter 23. But that''s irrelevant here since you set a
group
> on the router.
Ah, I see. Not really irrelevant, because I only set the group after 
running into this problem.
>> So, if exim was to write to the directory with owner:group
>> Debian-exim:roundup, it would be Ok, but i was getting permission
errors.
>
> Because it was trying to write as Debian-exim:Debian-exim, as watching
> a delivery process with -d clearly shows:
> changed uid/gid: local delivery to |/tmp/mailpipe <|/tmp/mailpipe>
transport=address_pipe
>  uid=105 gid=105 pid=5378
>  auxiliary group list: <none>
>  home=NULL current=/
What is the best way to turn on debugging?
>> Funnily enough, when I set that directory (db) to be writable by
anyone,
>> the owner:group that I saw for the file created by Exim were in fact
>> Debian-exim:roundup.
>
> That is the result of the gid bit on the directory.
>
>> Can anyone explain to me what is going on here?
>
> See any explanation of UNIX file mode semantics.
Hmm. the info I can find says things like"the setgid bits causes the 
effective group ID of the process to be set to the group of the file", 
which is unclear. I wonder what they mean by effective group ID?

Does the exim process actually switch group IDs or not?

If it does not, then the exim process is still running as 
Debian-exim:Debian-exim. So does this mean that the permissions of the 
file written to the disk is not actually what the process was running as?

If it does, then why does it not have permission to write to the 
directory?
>> Anyway, I''m using the monolithic config file for exim4,
>> /etc/exim4/exim4.conf.template, and added the following lines at the
>> beginning to fix this.
>>
>> SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe
>> SYSTEM_ALIASES_USER = Debian-exim
>> SYSTEM_ALIASES_GROUP = roundup
>>
>> The section that uses these variables is the
exim4-config_system_aliases
>> section.
>
> Setting the group on the transfer seems to work on my system. Now we
> need to find out why it doesn''t work when setting the group on the
> router. I''m going to ask exim-users about this.
''transfer''? Sorry, I don''t follow. I thought that
I''m setting the user and
group on the system_aliases router using the SYSTEM_ALIASES_*, which works 
for me.

What does not work exactly?
>> However, my immediate question is whether this will break anything. I
have
>> an /etc/aliases as per usual on Debian, but have not done anything to
it
>> except the Roundup line quoted above.
>
> All pipe deliveries are done with group roundup, which I consider
> unelegant. And it might be a surprise for your successors when they
> take over the system from you.
Yes, I didn''t think this was the best idea.
>> Apparently the Debian Exim maintainers consider pipe transports for
>> aliases deprecated, and prefer a dedicated router/transport instead.
>> However, at the moment I''ve no idea how to do this.
>
> Did you take a look at /usr/share/doc/mailman/README.EXIM on a system
> with mailman installed as suggested in exim''s README?
Yes. That was one of the few things I could find that seemed relevant, 
though I did find similar info for debbugs. I think you had written a 
router/transport pair for that too.

However, I couldn''t understand what needed to be done well enough to do
it
for Roundup.
> The following should be a start:
>
>  roundup_router:
>    driver = accept
>    require_files = /usr/bin/roundup-mailgw
>    local_parts = newtracker
>    transport = mailman_transport
Do you mean roundup_transport?
>  roundup_transport:
>    driver = pipe
>    command = /usr/bin/python /usr/bin/roundup-mailgw
/var/lib/roundup/trackers/newtracker/
>    current_directory >    home_directory >    user >    group 
Hmm. Perhaps I should have a system user called ''roundup'', and
have exim
run as the user/group roundup. Perhaps that would be good?

I don''t need to set current_directory/home_directory, correct?

I wonder if one can get Apache to run as a specific user. Probably.

In any case, with your permission, once I get this config a little firmed 
up and make sure it works, I''d like to submit it as a wishlist bug
against
the README.Debian in the Roundup Debian package.

(I assume that the config for the split config would be identical, with 
one file for the router subdirectory and one for transport.)

I''ll also possibly suggest to the Roundup maintainers that they make
some
exim-specific comments in their installation guide.
> This can possibly be gold-plated by having the router or transport
> look in the roundup config to see wheter a local_part should be
> handled by roundup.
Sorry, I''m not sure what you mean. Isn''t specifying the local
part (which
seems from context to be the bit before the @), sufficient? What is the 
advantage in having exim look at the roundup config? I''m not even sure
how
this could be done.
>> BTW, has anyone read The Exim SMTP Mail Server Official Guide for
Release
>> 4 (http://www.uit.co.uk/exim-book/)? If so, what did you think of it?
>
> It is an excellent book, straight from "the horses mouth", and
much
> better as a tutorial as the spec.txt file which is more a reference
> than a tutorial.
Thanks. I''ll try to get hold of a copy.

                                                               Faheem.

On Sat, Dec 10, 2005 at 03:15:13PM -0500, Faheem Mitha
wrote:
> On Sat, 10 Dec 2005, Marc Haber wrote:
> >Because it was trying to write as Debian-exim:Debian-exim, as watching
> >a delivery process with -d clearly shows:
> >changed uid/gid: local delivery to |/tmp/mailpipe
<|/tmp/mailpipe>
> >transport=address_pipe
> > uid=105 gid=105 pid=5378
> > auxiliary group list: <none>
> > home=NULL current=/
> 
> What is the best way to turn on debugging?
cat some_message | exim -d target.address@domain.example
> >>Funnily enough, when I set that directory (db) to be writable by
anyone,
> >>the owner:group that I saw for the file created by Exim were in
fact
> >>Debian-exim:roundup.
> >
> >That is the result of the gid bit on the directory.
> >
> >>Can anyone explain to me what is going on here?
> >
> >See any explanation of UNIX file mode semantics.
> 
> Hmm. the info I can find says things like"the setgid bits causes the 
> effective group ID of the process to be set to the group of the file",
> which is unclear. I wonder what they mean by effective group ID?
That''s the semantics for _files_. You are looking for the semantics of
the sgid bit on directories. When the sgid bit is set on a directory,
all files created within that directory will have the same group
ownership as the directory itself.
> Does the exim process actually switch group IDs or not?
It should, but it only seems to actually do it when the group is set
on the transport.
> >>Anyway, I''m using the monolithic config file for exim4,
> >>/etc/exim4/exim4.conf.template, and added the following lines at
the
> >>beginning to fix this.
> >>
> >>SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe
> >>SYSTEM_ALIASES_USER = Debian-exim
> >>SYSTEM_ALIASES_GROUP = roundup
> >>
> >>The section that uses these variables is the
exim4-config_system_aliases
> >>section.
> >
> >Setting the group on the transfer seems to work on my system. Now we
> >need to find out why it doesn''t work when setting the group on
the
> >router. I''m going to ask exim-users about this.
> 
> ''transfer''?
transport. Sorry, a typo.
> Sorry, I don''t follow. I thought that I''m setting the
user and
> group on the system_aliases router using the SYSTEM_ALIASES_*, which works 
> for me.
> 
> What does not work exactly?
Setting the group on the router does not seem to work, it needs to be
set on the transport.
> >>However, my immediate question is whether this will break anything.
I have
> >>an /etc/aliases as per usual on Debian, but have not done anything
to it
> >>except the Roundup line quoted above.
> >
> >All pipe deliveries are done with group roundup, which I consider
> >unelegant. And it might be a surprise for your successors when they
> >take over the system from you.
> 
> Yes, I didn''t think this was the best idea.
It has the advantage of working with all MTAs, which is why program
authors like to take that approach in their docs.
> >>Apparently the Debian Exim maintainers consider pipe transports for
> >>aliases deprecated, and prefer a dedicated router/transport
instead.
> >>However, at the moment I''ve no idea how to do this.
> >
> >Did you take a look at /usr/share/doc/mailman/README.EXIM on a system
> >with mailman installed as suggested in exim''s README?
> 
> Yes. That was one of the few things I could find that seemed relevant, 
> though I did find similar info for debbugs. I think you had written a 
> router/transport pair for that too.
afaik, router/transport pairs exist for debbugs, mailman and
request-tracker.
> >The following should be a start:
> >
> > roundup_router:
> >   driver = accept
> >   require_files = /usr/bin/roundup-mailgw
> >   local_parts = newtracker
> >   transport = mailman_transport
> 
> Do you mean roundup_transport?
Yes, of course.
> > roundup_transport:
> >   driver = pipe
> >   command = /usr/bin/python /usr/bin/roundup-mailgw 
> >   /var/lib/roundup/trackers/newtracker/
> >   current_directory > >   home_directory > >   user >
>   group >
> Hmm. Perhaps I should have a system user called
''roundup'', and have exim
> run as the user/group roundup. Perhaps that would be good?
Depends on what roundup expects. I don''t have a clue about roundup, so
I cannot comment about that. I am a big fan of having separate
accounts for different tasks.
> I don''t need to set current_directory/home_directory, correct?
> 
> I wonder if one can get Apache to run as a specific user. Probably.
That''s quite hard to do. Look for suexec and/or suphp.
> In any case, with your permission, once I get this config a little firmed 
> up and make sure it works, I''d like to submit it as a wishlist bug
against
> the README.Debian in the Roundup Debian package.
Of course, go ahead.
> (I assume that the config for the split config would be identical, with 
> one file for the router subdirectory and one for transport.)
Yes, right.
> I''ll also possibly suggest to the Roundup maintainers that they
make some
> exim-specific comments in their installation guide.
Even better.
> >This can possibly be gold-plated by having the router or transport
> >look in the roundup config to see wheter a local_part should be
> >handled by roundup.
> 
> Sorry, I''m not sure what you mean. Isn''t specifying the
local part (which
> seems from context to be the bit before the @), sufficient? What is the 
> advantage in having exim look at the roundup config? I''m not even
sure how
> this could be done.
I don''t know about roundup. the mailman example given above does not
need any exim configuration when new lists are generated: exim looks
in mailman''s directory structure whether configuration exists to learn
whether a lists exists or not, and then picks mail addresses belonging
to the mailing list automatically. So, you don''t need to touch exim if
you create a new mailman list. If roundup has a concept like a list,
or a queue, that mechanism can be used to avoid exim configuration.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

On Sat, 10 Dec 2005, Marc Haber wrote:
> On Sat, Dec 10, 2005 at 03:15:13PM -0500, Faheem Mitha wrote:
>> On Sat, 10 Dec 2005, Marc Haber wrote:
>> Hmm. the info I can find says things like"the setgid bits causes
the
>> effective group ID of the process to be set to the group of the
file",
>> which is unclear. I wonder what they mean by effective group ID?
>
> That''s the semantics for _files_. You are looking for the
semantics of
> the sgid bit on directories. When the sgid bit is set on a directory,
> all files created within that directory will have the same group
> ownership as the directory itself.
>
>> Does the exim process actually switch group IDs or not?
>
> It should, but it only seems to actually do it when the group is set
> on the transport.
No, my question was referring to the situation when there is no 
router/transport, the default behavior where there is a permission 
problem.

For example, if just

SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe

was set.
>>>> Anyway, I''m using the monolithic config file for
exim4,
>>>> /etc/exim4/exim4.conf.template, and added the following lines
at the
>>>> beginning to fix this.
>>>>
>>>> SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe
>>>> SYSTEM_ALIASES_USER = Debian-exim
>>>> SYSTEM_ALIASES_GROUP = roundup
>>>>
>>>> The section that uses these variables is the
exim4-config_system_aliases
>>>> section.
>>>
>>> Setting the group on the transfer seems to work on my system. Now
we
>>> need to find out why it doesn''t work when setting the
group on the
>>> router. I''m going to ask exim-users about this.
>>
>> ''transfer''?
>
> transport. Sorry, a typo.
>
>> Sorry, I don''t follow. I thought that I''m setting the
user and
>> group on the system_aliases router using the SYSTEM_ALIASES_*, which
works
>> for me.
>>
>> What does not work exactly?
>
> Setting the group on the router does not seem to work, it needs to be
> set on the transport.
It works for me with the system_aliases router that exists in the 
/etc/exim4/exim4.conf.template, as I have already said.

I think you are talking about the custom roundup_router & 
coundup_transport that you wrote. Is my understanding correct?
> afaik, router/transport pairs exist for debbugs, mailman and
> request-tracker.
I''m not aware of one for RT, and I just looked at the docs for the
Debian
unstable package the other day.
>> Hmm. Perhaps I should have a system user called
''roundup'', and have exim
>> run as the user/group roundup. Perhaps that would be good?
> Depends on what roundup expects. I don''t have a clue about
roundup, so I
> cannot comment about that. I am a big fan of having separate accounts 
> for different tasks.
I don''t think that roundup is fussy about how permissions are set up in
the db directory in the tracker instance. It just needs the MTA process 
and the web server process to be able to write to it.
>> I don''t need to set current_directory/home_directory, correct?
>>
>> I wonder if one can get Apache to run as a specific user. Probably.
>
> That''s quite hard to do. Look for suexec and/or suphp.
Thanks for the tip.
>>> This can possibly be gold-plated by having the router or transport
>>> look in the roundup config to see wheter a local_part should be
>>> handled by roundup.
>>
>> Sorry, I''m not sure what you mean. Isn''t specifying
the local part (which
>> seems from context to be the bit before the @), sufficient? What is the
>> advantage in having exim look at the roundup config? I''m not
even sure how
>> this could be done.
>
> I don''t know about roundup. the mailman example given above does
not
> need any exim configuration when new lists are generated: exim looks
> in mailman''s directory structure whether configuration exists to
learn
> whether a lists exists or not, and then picks mail addresses belonging
> to the mailing list automatically. So, you don''t need to touch
exim if
> you create a new mailman list. If roundup has a concept like a list,
> or a queue, that mechanism can be used to avoid exim configuration.
Ah, I see. Yes, roundup has a tracker instance, which is what newtracker 
is in my example.

Eg. each directory in /var/lib/roundup/trackers belongs to a tracker 
instance.

I think it would suffice to configure an mail address (or whatever it is 
called) corresponding to each local instance.

So if there were directories /var/lib/roundup/trackers/track1 and 
/var/lib/roundup/trackers/track2, then configure mail addresses track1 and 
track2. Presumably one should do this in the router.

I see that the mailman router/transport for Exim 4 is

******************************************************************
   mailman_router:
     driver = accept
     require_files = MAILMAN_HOME/lists/$local_part/config.pck
     local_part_suffix_optional
     local_part_suffix = -bounces : -bounces+* : \
                         -confirm+* : -join : -leave : \
                         -owner : -request : -admin
     transport = mailman_transport

  mailman_transport:
     driver = pipe
     command = MAILMAN_WRAP \
               ''${if def:local_part_suffix \
                     {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
                     {post}}'' \
               $local_part
     current_directory = MAILMAN_HOME
     home_directory = MAILMAN_HOME
     user = MAILMAN_USER
     group = MAILMAN_GROUP
******************************************************************

Would something like the following work for Roundup? It looks like 
$local_part is extracted by matching require_files, correct?

******************************************************************
   # Home dir for your Roundup installation
   ROUNDUP_HOME=/var/lib/roundup/trackers

   # User and group for Roundup.
   ROUNDUP_USER=roundup
   ROUNDUP_GROUP=roundup

   roundup_router:
     driver = accept
     # The config file config.ini seems like a more natural choice, but the
     # file config.py was replaced by config.ini in 0.8, and schema.py needs to
be
     # present too.
     require_files = /usr/bin/roundup-mailgw, ROUNDUP_HOME/$local_part/schema.py
     transport = roundup_transport

   roundup_transport:
     driver = pipe
     command = /usr/bin/python /usr/bin/roundup-mailgw ROUNDUP_HOME/$local_part/
     current_directory      home_directory      user = ROUNDUP_USER
     group = ROUNDUP_GROUP
***************************************************************

Thanks.                                                          Faheem.

On Sat, Dec 10, 2005 at 04:25:06PM -0500, Faheem Mitha
wrote:
> On Sat, 10 Dec 2005, Marc Haber wrote:
> >It should, but it only seems to actually do it when the group is set
> >on the transport.
> 
> No, my question was referring to the situation when there is no 
> router/transport, the default behavior where there is a permission 
> problem.
> 
> For example, if just
> 
> SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe
> 
> was set.
I''d expect it to stay at Debian-exim.
> >>Sorry, I don''t follow. I thought that I''m setting
the user and
> >>group on the system_aliases router using the SYSTEM_ALIASES_*,
which works
> >>for me.
> >>
> >>What does not work exactly?
> >
> >Setting the group on the router does not seem to work, it needs to be
> >set on the transport.
> 
> It works for me with the system_aliases router that exists in the 
> /etc/exim4/exim4.conf.template, as I have already said.
> 
> I think you are talking about the custom roundup_router & 
> coundup_transport that you wrote. Is my understanding correct?
No. I tried replicating with an alias and kept ending up running the
script as Debian-exim.
> >afaik, router/transport pairs exist for debbugs, mailman and
> >request-tracker.
> 
> I''m not aware of one for RT, and I just looked at the docs for the
Debian
> unstable package the other day.
The rt maintainer didn''t incorporate it yet. it''s in the
Debian BTS as
#229052, and in the exim wiki on
http://www.exim.org/eximwiki/RequestTrackerConfiguration
> Eg. each directory in /var/lib/roundup/trackers belongs to a tracker 
> instance.
> 
> I think it would suffice to configure an mail address (or whatever it is 
> called) corresponding to each local instance.
> 
> So if there were directories /var/lib/roundup/trackers/track1 and 
> /var/lib/roundup/trackers/track2, then configure mail addresses track1 and 
> track2. Presumably one should do this in the router.
> 
> I see that the mailman router/transport for Exim 4 is
> 
> ******************************************************************
>   mailman_router:
>     driver = accept
>     require_files = MAILMAN_HOME/lists/$local_part/config.pck
>     local_part_suffix_optional
>     local_part_suffix = -bounces : -bounces+* : \
>                         -confirm+* : -join : -leave : \
>                         -owner : -request : -admin
>     transport = mailman_transport
> 
>  mailman_transport:
>     driver = pipe
>     command = MAILMAN_WRAP \
>               ''${if def:local_part_suffix \
>                     {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
>                     {post}}'' \
>               $local_part
>     current_directory = MAILMAN_HOME
>     home_directory = MAILMAN_HOME
>     user = MAILMAN_USER
>     group = MAILMAN_GROUP
> ******************************************************************
Yes, with the magic being the require_files directive.
> 
> Would something like the following work for Roundup? It looks like 
> $local_part is extracted by matching require_files, correct?
> 
> ******************************************************************
>   # Home dir for your Roundup installation
>   ROUNDUP_HOME=/var/lib/roundup/trackers
> 
>   # User and group for Roundup.
>   ROUNDUP_USER=roundup
>   ROUNDUP_GROUP=roundup
> 
>   roundup_router:
>     driver = accept
>     # The config file config.ini seems like a more natural choice, but the
>     # file config.py was replaced by config.ini in 0.8, and schema.py needs
>     to be
>     # present too.
>     require_files = /usr/bin/roundup-mailgw, 
>     ROUNDUP_HOME/$local_part/schema.py
>     transport = roundup_transport
> 
>   roundup_transport:
>     driver = pipe
>     command = /usr/bin/python /usr/bin/roundup-mailgw 
>     ROUNDUP_HOME/$local_part/
>     current_directory >     home_directory >     user = ROUNDUP_USER
>     group = ROUNDUP_GROUP
> ***************************************************************
Looks good.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

On Sat, 10 Dec 2005, Marc Haber wrote:
>> Would something like the following work for Roundup? It looks like
>> $local_part is extracted by matching require_files, correct?
>>
>> ******************************************************************
>>   # Home dir for your Roundup installation
>>   ROUNDUP_HOME=/var/lib/roundup/trackers
>>
>>   # User and group for Roundup.
>>   ROUNDUP_USER=roundup
>>   ROUNDUP_GROUP=roundup
>>
>>   roundup_router:
>>     driver = accept
>>     # The config file config.ini seems like a more natural choice, but
the
>>     # file config.py was replaced by config.ini in 0.8, and schema.py
needs
>>     to be
>>     # present too.
>>     require_files = /usr/bin/roundup-mailgw,
>>     ROUNDUP_HOME/$local_part/schema.py
>>     transport = roundup_transport
>>
>>   roundup_transport:
>>     driver = pipe
>>     command = /usr/bin/python /usr/bin/roundup-mailgw
>>     ROUNDUP_HOME/$local_part/
>>     current_directory >>     home_directory >>     user =
ROUNDUP_USER
>>     group = ROUNDUP_GROUP
>> ***************************************************************
>
> Looks good.
Ok, I now have a working configuration.

Please comment on proposed addition to Roundup README.Debian.

Note I''ve made a few minor modifications. In particular, I''ve
removed
current_directory and home_directory since they don''t do anything and
Exim
does not like them unset.

Thanks.                                                       Faheem.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Hi,

In the Roundup installation documentation 
(http://roundup.sourceforge.net/doc-0.8/installation.html#configure-an-email-interface),
it says

*******************************************************************
As a mail alias pipe process

Set up a mail alias called "issue_tracker" as (include the quote
marks):
"|/usr/bin/python /usr/local/bin/roundup-mailgw <tracker_home>"
*******************************************************************

However, this does not work out the box on Debian, using Debian Exim4. 
Instead. I propose using a custom router & transport as per Debian Exim 
preferences.

The following configuration has been tested on Debian Sarge with Exim4.

The following three config files, when dropped into /etc/exim4/,
should do what it necessary. Note that as per directions in the Debian
Exim README.Debian, the monolithic file (unsplit configuration)
/etc/exim4/exim4.conf.template can be rebuilt from the conf.d files by
running ''update-exim4.conf.template -r''.

This configuration is largely due to Marc Haber, the Debian Exim
maintainer, and has been lightly edited by me.

This config makes a few assumptions:

1) That the mail address corresponding to the tracker instance has the 
same name, ie. the mail address corresponding to a Roundup instance called 
mytracker is mytracker@...

2) That all the tracker instances are owned by the same user, in this 
case, ''roundup''.

3) That if the schema.py file exists, then the tracker is ''ready to
go''. I''m not sure if it would be better to use the config.ini
file.

However, it has the advantage that modulo these assumptions no further 
configuration will need to be made, when new tracker instances are added.

NB. The roundup_router needs to come before system_aliases, otherwise Exim 
will complain that '' pipe_transport unset in system_aliases
router'', and
defer the message. Using 050 ensures that it is included before 
system_aliases, which is 
/etc/exim4/conf.d/router/400_exim4-config_system_aliases.

************************************************************************
/etc/exim4/conf.d/main/000_localmacros
************************************************************************
# Home dir for your Roundup installation
ROUNDUP_HOME=/var/lib/roundup/trackers

# User and group for Roundup.
ROUNDUP_USER=roundup
ROUNDUP_GROUP=roundup
************************************************************************
/etc/exim4/conf.d/router/050_exim4-config_roundup
************************************************************************
roundup_router:
   driver = accept
   # The config file config.ini seems like a more natural choice, but the
   # file config.py was replaced by config.ini in 0.8, and schema.py needs
   # to be present too.
   require_files = /usr/bin/roundup-mailgw:ROUNDUP_HOME/$local_part/schema.py
   transport = roundup_transport
************************************************************************
/etc/exim4/conf.d/transport/050_exim4-config_roundup
************************************************************************
roundup_transport:
   driver = pipe
   command = /usr/bin/python /usr/bin/roundup-mailgw ROUNDUP_HOME/$local_part/
   user = ROUNDUP_USER
   group = ROUNDUP_GROUP
************************************************************************

If you have followup questions, I suggest you talk to (in addition to 
myself), the people on pkg-exim4-users@lists.alioth.debian.org, who 
certainly know much more about all this stuff than I do.

Thanks.                                                          Faheem.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

On Sat, Dec 10, 2005 at 08:09:49PM -0500, Faheem Mitha
wrote:
> Note I''ve made a few minor modifications. In particular,
I''ve removed
> current_directory and home_directory since they don''t do anything
and Exim
> does not like them unset.
I''d set them to some roundup-related directory just in case that the
script or a program called from there dumps core.
> *******************************************************************
> As a mail alias pipe process
> 
> Set up a mail alias called "issue_tracker" as (include the quote
marks):
> "|/usr/bin/python /usr/local/bin/roundup-mailgw
<tracker_home>"
> *******************************************************************
> 
> However, this does not work out the box on Debian, using Debian Exim4. 
This suggests that Debian''s exim packages are flawed. Your upstream
author is not going to like this.

I''d suggest something like "However, the Debian Exim4 packages
don''t
allow pipes in alias files by default, and the maintainers have a
point in suggesting a different way to accomplish delivery to
roundup-mailgw".
> This configuration is largely due to Marc Haber, the Debian Exim
> maintainer, and has been lightly edited by me.
Actually Debian Exim4 is maintained by a Team, and I am only a member.
> NB. The roundup_router needs to come before system_aliases, otherwise Exim 
> will complain that '' pipe_transport unset in system_aliases
router'', and
> defer the message.
That will only happen if the alias is still in place, which is not
necessary any more. If you remove the alias, the system_aliases router
will decline and anything will be fine.
> ************************************************************************
> /etc/exim4/conf.d/main/000_localmacros
> ************************************************************************
> # Home dir for your Roundup installation
> ROUNDUP_HOME=/var/lib/roundup/trackers
> 
> # User and group for Roundup.
> ROUNDUP_USER=roundup
> ROUNDUP_GROUP=roundup
I''d call that 010_roundup_macros
> ************************************************************************
> /etc/exim4/conf.d/router/050_exim4-config_roundup
> ************************************************************************
I''d call that 050_roundup (exim4-config is the custom for a file
belonging to the exim4-config package, which your file isn''t)
> roundup_router:
>   driver = accept
>   # The config file config.ini seems like a more natural choice, but the
>   # file config.py was replaced by config.ini in 0.8, and schema.py needs
>   # to be present too.
>   require_files =
/usr/bin/roundup-mailgw:ROUNDUP_HOME/$local_part/schema.py
>   transport = roundup_transport
> ************************************************************************
> /etc/exim4/conf.d/transport/050_exim4-config_roundup
> ************************************************************************
Same thing here.
> roundup_transport:
>   driver = pipe
>   command = /usr/bin/python /usr/bin/roundup-mailgw 
>   ROUNDUP_HOME/$local_part/
>   user = ROUNDUP_USER
>   group = ROUNDUP_GROUP
> ************************************************************************
> 
> If you have followup questions, I suggest you talk to (in addition to 
> myself), the people on pkg-exim4-users@lists.alioth.debian.org, who 
> certainly know much more about all this stuff than I do.
> 
> Thanks.                                                          Faheem.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The list is only open to subscribers, so a link to the subscribe web
page would be a good idea.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

On Sat, Dec 10, 2005 at 11:32:32AM +0100, Marc Haber
wrote:
> Setting the group on the transfer seems to work on my system. Now we
> need to find out why it doesn''t work when setting the group on the
> router. I''m going to ask exim-users about this.
Upstream confirms this as a bug. A patch will be made available, but
won''t make its way into sarge.

Workaround is, as expected, to set the group on the transport.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

On Sun, 11 Dec 2005, Marc Haber wrote:
> On Sat, Dec 10, 2005 at 08:09:49PM -0500, Faheem Mitha wrote:
>> Note I''ve made a few minor modifications. In particular,
I''ve removed
>> current_directory and home_directory since they don''t do
anything and Exim
>> does not like them unset.
>
> I''d set them to some roundup-related directory just in case that
the
> script or a program called from there dumps core.
It''s a Python script, so I would not have thought core dumps would be
an
issue. But Ok.

Setting home_directory and current_directory to ROUNDUP_HOME.
>> *******************************************************************
>> As a mail alias pipe process
>>
>> Set up a mail alias called "issue_tracker" as (include the
quote marks):
>> "|/usr/bin/python /usr/local/bin/roundup-mailgw
<tracker_home>"
>> *******************************************************************
>>
>> However, this does not work out the box on Debian, using Debian Exim4.
>
> This suggests that Debian''s exim packages are flawed. Your
upstream
> author is not going to like this.
I''m not sure which upstream author you are referring to.
> I''d suggest something like "However, the Debian Exim4
packages don''t
> allow pipes in alias files by default, and the maintainers have a
> point in suggesting a different way to accomplish delivery to
> roundup-mailgw".
Ok. Changed to something similar.
>> This configuration is largely due to Marc Haber, the Debian Exim
>> maintainer, and has been lightly edited by me.
>
> Actually Debian Exim4 is maintained by a Team, and I am only a member.
Ok, changed to say "one of the Debian Exim maintainers".
>> NB. The roundup_router needs to come before system_aliases, otherwise
Exim
>> will complain that '' pipe_transport unset in system_aliases
router'', and
>> defer the message.
>
> That will only happen if the alias is still in place, which is not
> necessary any more. If you remove the alias, the system_aliases router
> will decline and anything will be fine.
Sorry. I''ve no idea what you mean. I got the behaviour described when I
dropped the files described here into a vanilla Debian Exim4 config. There 
were no modifications to the system_aliases router still present at that 
point.

Can you be more explicit? What alias are you referring to?
>>
************************************************************************
>> /etc/exim4/conf.d/main/000_localmacros
>>
************************************************************************
>> # Home dir for your Roundup installation
>> ROUNDUP_HOME=/var/lib/roundup/trackers
>>
>> # User and group for Roundup.
>> ROUNDUP_USER=roundup
>> ROUNDUP_GROUP=roundup
>
> I''d call that 010_roundup_macros
Done.
>>
************************************************************************
>> /etc/exim4/conf.d/router/050_exim4-config_roundup
>>
************************************************************************
>
> I''d call that 050_roundup (exim4-config is the custom for a file
> belonging to the exim4-config package, which your file isn''t)
Done.
>> roundup_router:
>>   driver = accept
>>   # The config file config.ini seems like a more natural choice, but
the
>>   # file config.py was replaced by config.ini in 0.8, and schema.py
needs
>>   # to be present too.
>>   require_files =
/usr/bin/roundup-mailgw:ROUNDUP_HOME/$local_part/schema.py
>>   transport = roundup_transport
>>
************************************************************************
>> /etc/exim4/conf.d/transport/050_exim4-config_roundup
>>
************************************************************************
>
> Same thing here.
Done.
>> roundup_transport:
>>   driver = pipe
>>   command = /usr/bin/python /usr/bin/roundup-mailgw
>>   ROUNDUP_HOME/$local_part/
>>   user = ROUNDUP_USER
>>   group = ROUNDUP_GROUP
>>
************************************************************************
>>
>> If you have followup questions, I suggest you talk to (in addition to
>> myself), the people on pkg-exim4-users@lists.alioth.debian.org, who
>> certainly know much more about all this stuff than I do.
>>
>> Thanks.                                                         
Faheem.
>>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> The list is only open to subscribers, so a link to the subscribe web
> page would be a good idea.
Done.

Modified message follows.

###############################################################################
Hi,

In the Roundup installation documentation
(http://roundup.sourceforge.net/doc-0.8/installation.html#configure-an-email-interface),
it says

*******************************************************************
As a mail alias pipe process

Set up a mail alias called "issue_tracker" as (include the quote
marks):
"|/usr/bin/python /usr/local/bin/roundup-mailgw <tracker_home>"
*******************************************************************

However, the Debian Exim4 packages don''t allow pipes in alias files by
default, and I propose using a custom router & transport to accomplish
delivery to roundup-mailgw as per the recommendations of the Debian
Exim maintainers.

Please consider appending this information to README.Debian, along
with the other Debian-specific configuration information.

@@@@@@@@@@@@@@@@ BEGIN PROPOSED ADDITION TO README.DEBIAN @@@@@@@@@@@@

The following configuration files for Exim 4 implement a custom router
& transport to accomplish delivery to roundup-mailgw as per the
recommendations of the Debian Exim maintainers.

This configuration replaces the instructions in the Roundup
installation documentation
(http://roundup.sourceforge.net/doc-0.8/installation.html#configure-an-email-interface),
for configuring the mail gateway, which says

*******************************************************************
As a mail alias pipe process

Set up a mail alias called "issue_tracker" as (include the quote
marks):
"|/usr/bin/python /usr/local/bin/roundup-mailgw <tracker_home>"
*******************************************************************

The following configuration has been tested on Debian Sarge with Exim4.

The following three config files, when dropped into
/etc/exim4/conf.d/, should do what it necessary. Note that as per
directions in the Debian Exim README.Debian, the monolithic file
(unsplit configuration) /etc/exim4/exim4.conf.template can be rebuilt
from the conf.d files by running ''update-exim4.conf.template
-r''.

This configuration is largely due to Marc Haber, one of the Debian
Exim maintainers, but has been modified by me.

This config makes a few assumptions:

1) That the mail address corresponding to the tracker instance has the
same name as the directory of the tracker instance, ie. the mail
address corresponding to a Roundup instance called
/var/lib/roundup/trackers/mytracker is mytracker@...

2) That (at least) all the db subdirectories of all the tracker
instances (ie. /var/lib/roundup/trackers/*/db) are owned by the same
user, in this case, ''roundup''.

3) That if the schema.py file exists, then the tracker is ''ready to
go''. I''m not sure if it would be better to use the config.ini
file.

However, it has the advantage that modulo these assumptions no further 
configuration will need to be made when new tracker instances are added.

NB. The roundup_router needs to come before system_aliases, otherwise Exim 
will complain that ''pipe_transport unset in system_aliases
router'', and
defer the message. Using 050 ensures that it is included before 
system_aliases, which is 
/etc/exim4/conf.d/router/400_exim4-config_system_aliases.

************************************************************************
/etc/exim4/conf.d/main/010_roundup_macros
************************************************************************
# Home dir for your Roundup installation
ROUNDUP_HOME=/var/lib/roundup/trackers

# User and group for Roundup.
ROUNDUP_USER=roundup
ROUNDUP_GROUP=roundup
************************************************************************
/etc/exim4/conf.d/router/050_roundup
************************************************************************
roundup_router:
    driver = accept
    # The config file config.ini seems like a more natural choice, but the
    # file config.py was replaced by config.ini in 0.8, and schema.py needs
    # to be present too.
    require_files = /usr/bin/roundup-mailgw:ROUNDUP_HOME/$local_part/schema.py
    transport = roundup_transport
************************************************************************
/etc/exim4/conf.d/transport/050_roundup
************************************************************************
roundup_transport:
    driver = pipe
    command = /usr/bin/python /usr/bin/roundup-mailgw ROUNDUP_HOME/$local_part/
    current_directory = ROUNDUP_HOME
    home_directory = ROUNDUP_HOME
    user = ROUNDUP_USER
    group = ROUNDUP_GROUP
************************************************************************

@@@@@@@@@@@@@@@@ END PROPOSED ADDITION TO README.DEBIAN @@@@@@@@@@@@@@@@@@@@

If you have followup questions, I suggest you talk to (in addition to
myself), the people on
http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users, who
certainly know much more about all this stuff than I do.

Thanks.                                                          Faheem.

On Mon, 12 Dec 2005, Marc Haber wrote:
> On Sat, Dec 10, 2005 at 11:32:32AM +0100, Marc Haber wrote:
>> Setting the group on the transfer seems to work on my system. Now we
>> need to find out why it doesn''t work when setting the group on
the
>> router. I''m going to ask exim-users about this.
>
> Upstream confirms this as a bug. A patch will be made available, but
> won''t make its way into sarge.
>
> Workaround is, as expected, to set the group on the transport.
Hi Marc,

As before, apologies in advance for my cluelessnes.

However, I''m still not clear about this issue.

As I said earlier, I can set the group on the router system_aliases, in 
400_exim4-config_system_aliases, and this works, while not setting the 
group fails. I tried it both ways.

I set the macros

SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe
SYSTEM_ALIASES_USER = Debian-exim
SYSTEM_ALIASES_GROUP = roundup

as I described earlier, and this works.

Are you talking about this router, or are you talking about the custom 
router/transport we were discussing for roundup?

Please be as explicit as possible. I''m really not very familiar with
the
issues or the terminology.

Thanks.                                                        Faheem.

On Mon, Dec 12, 2005 at 08:37:09PM -0500, Faheem Mitha
wrote:
> On Sun, 11 Dec 2005, Marc Haber wrote:
> >On Sat, Dec 10, 2005 at 08:09:49PM -0500, Faheem Mitha wrote:
> >>Note I''ve made a few minor modifications. In particular,
I''ve removed
> >>current_directory and home_directory since they don''t do
anything and Exim
> >>does not like them unset.
> >
> >I''d set them to some roundup-related directory just in case
that the
> >script or a program called from there dumps core.
> 
> It''s a Python script, so I would not have thought core dumps would
be an
> issue. But Ok.
Dumping core is always a possible issue. Even the python interpreter
is a binary.
> >>*******************************************************************
> >>As a mail alias pipe process
> >>
> >>Set up a mail alias called "issue_tracker" as (include
the quote marks):
> >>"|/usr/bin/python /usr/local/bin/roundup-mailgw
<tracker_home>"
> >>*******************************************************************
> >>
> >>However, this does not work out the box on Debian, using Debian
Exim4.
> >
> >This suggests that Debian''s exim packages are flawed. Your
upstream
> >author is not going to like this.
> 
> I''m not sure which upstream author you are referring to.
I''m refering to roundup''s author here.
> >>NB. The roundup_router needs to come before system_aliases,
otherwise Exim
> >>will complain that '' pipe_transport unset in
system_aliases router'', and
> >>defer the message.
> >
> >That will only happen if the alias is still in place, which is not
> >necessary any more. If you remove the alias, the system_aliases router
> >will decline and anything will be fine.
> 
> Sorry. I''ve no idea what you mean. I got the behaviour described
when I
> dropped the files described here into a vanilla Debian Exim4 config. There 
> were no modifications to the system_aliases router still present at that 
> point.
Was the alias entry with the roundup pipe still present in
/etc/aliases when you tried?
> Can you be more explicit? What alias are you referring to?
newtracker: "|/usr/bin/python /usr/bin/roundup-mailgw
/var/lib/roundup/trackers/newtracker/"
>
###############################################################################
> Hi,
> 
> In the Roundup installation documentation
>
(http://roundup.sourceforge.net/doc-0.8/installation.html#configure-an-email-interface),
> it says
> 
> *******************************************************************
> As a mail alias pipe process
> 
> Set up a mail alias called "issue_tracker" as (include the quote
marks):
> "|/usr/bin/python /usr/local/bin/roundup-mailgw
<tracker_home>"
> *******************************************************************
> 
> However, the Debian Exim4 packages don''t allow pipes in alias
files by
> default, and I propose using a custom router & transport to accomplish
> delivery to roundup-mailgw as per the recommendations of the Debian
> Exim maintainers.
> 
> Please consider appending this information to README.Debian, along
> with the other Debian-specific configuration information.
> 
> @@@@@@@@@@@@@@@@ BEGIN PROPOSED ADDITION TO README.DEBIAN @@@@@@@@@@@@
> 
> The following configuration files for Exim 4 implement a custom router
> & transport to accomplish delivery to roundup-mailgw as per the
> recommendations of the Debian Exim maintainers.
> 
> This configuration replaces the instructions in the Roundup
> installation documentation
>
(http://roundup.sourceforge.net/doc-0.8/installation.html#configure-an-email-interface),
> for configuring the mail gateway, which says
> 
> *******************************************************************
> As a mail alias pipe process
> 
> Set up a mail alias called "issue_tracker" as (include the quote
marks):
> "|/usr/bin/python /usr/local/bin/roundup-mailgw
<tracker_home>"
> *******************************************************************
> 
> The following configuration has been tested on Debian Sarge with Exim4.
> 
> The following three config files, when dropped into
> /etc/exim4/conf.d/, should do what it necessary. Note that as per
> directions in the Debian Exim README.Debian, the monolithic file
> (unsplit configuration) /etc/exim4/exim4.conf.template can be rebuilt
> from the conf.d files by running ''update-exim4.conf.template
-r''.
This will overwrite any local changes to update-exim4.conf.template.
Users should be warned.

In the README, I''d refer to the exim4 README.
> This configuration is largely due to Marc Haber, one of the Debian
> Exim maintainers, but has been modified by me.
> 
> This config makes a few assumptions:
> 
> 1) That the mail address corresponding to the tracker instance has the
> same name as the directory of the tracker instance, ie. the mail
> address corresponding to a Roundup instance called
> /var/lib/roundup/trackers/mytracker is mytracker@...
> 
> 2) That (at least) all the db subdirectories of all the tracker
> instances (ie. /var/lib/roundup/trackers/*/db) are owned by the same
> user, in this case, ''roundup''.
> 
> 3) That if the schema.py file exists, then the tracker is ''ready
to
> go''. I''m not sure if it would be better to use the
config.ini file.
> 
> However, it has the advantage that modulo these assumptions no further 
> configuration will need to be made when new tracker instances are added.
> 
> NB. The roundup_router needs to come before system_aliases, otherwise Exim 
> will complain that ''pipe_transport unset in system_aliases
router'', and
> defer the message. Using 050 ensures that it is included before 
> system_aliases, which is 
> /etc/exim4/conf.d/router/400_exim4-config_system_aliases.
Again, I do not think that this paragraph is necessary and that you
are suffering from the remnants of your experiments with the alias file.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

On Tue, 13 Dec 2005, Marc Haber wrote:
> On Mon, Dec 12, 2005 at 08:37:09PM -0500, Faheem Mitha wrote:
>> On Sun, 11 Dec 2005, Marc Haber wrote:
>>> On Sat, Dec 10, 2005 at 08:09:49PM -0500, Faheem Mitha wrote:
> Was the alias entry with the roundup pipe still present in
> /etc/aliases when you tried?
Oh, right. I forgot all about that. Yes, it is still there, in fact. 
Sorry. Ok, I''ll take out that para,
>> Can you be more explicit? What alias are you referring to?
>
> newtracker: "|/usr/bin/python /usr/bin/roundup-mailgw
/var/lib/roundup/trackers/newtracker/"
Right,
>> The following configuration has been tested on Debian Sarge with Exim4.
>>
>> The following three config files, when dropped into
>> /etc/exim4/conf.d/, should do what it necessary. Note that as per
>> directions in the Debian Exim README.Debian, the monolithic file
>> (unsplit configuration) /etc/exim4/exim4.conf.template can be rebuilt
>> from the conf.d files by running ''update-exim4.conf.template
-r''.
>
> This will overwrite any local changes to update-exim4.conf.template.
> Users should be warned.
Ok.
> In the README, I''d refer to the exim4 README.
Ok.
>> NB. The roundup_router needs to come before system_aliases, otherwise
Exim
>> will complain that ''pipe_transport unset in system_aliases
router'', and
>> defer the message. Using 050 ensures that it is included before
>> system_aliases, which is
>> /etc/exim4/conf.d/router/400_exim4-config_system_aliases.
>
> Again, I do not think that this paragraph is necessary and that you
> are suffering from the remnants of your experiments with the alias file.
Agreed. Paragraph will be removed.

I''ll go ahead and file a wishlist bug report against the Debian Roundup
package, and copy the link here.

Thanks.                                                         Faheem.

On Mon, Dec 12, 2005 at 10:20:51PM -0500, Faheem Mitha
wrote:
> However, I''m still not clear about this issue.
> 
> As I said earlier, I can set the group on the router system_aliases, in 
> 400_exim4-config_system_aliases, and this works, while not setting the 
> group fails. I tried it both ways.
> 
> I set the macros
> 
> SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe
> SYSTEM_ALIASES_USER = Debian-exim
> SYSTEM_ALIASES_GROUP = roundup
> 
> as I described earlier, and this works.
> 
> Are you talking about this router, or are you talking about the custom 
> router/transport we were discussing for roundup?
I am talking about a system_aliases router:

|begin routers

|system_aliases:
|  debug_print = "R: system_aliases for $local_part@$domain"
|  driver = redirect
|  allow_fail
|  allow_defer
|  data = ${lookup{$local_part}lsearch{/etc/aliases}}
|  group = roundup
|  pipe_transport = address_pipe
|
|begin transports
|
|address_pipe:
|  debug_print = "T: address_pipe for $local_part@$domain"
|  driver = pipe
|  return_fail_output
|
|the pipe process runs as Debian-exim:Debian-exim (105/105) instead of
|Debian-exim:roundup (105/116). I need to add a group directive to the
|transport for actually having the delivery run with group roundup.

I can confirm that this happens on any current exim (I didn''t try with
the exim from Debian sarge as I couldn''t report a bug against 4.50-8
upstream anyway).

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

On Tue, 13 Dec 2005, Marc Haber wrote:
> On Mon, Dec 12, 2005 at 08:37:09PM -0500, Faheem Mitha wrote:
>> On Sun, 11 Dec 2005, Marc Haber wrote:
>> The following configuration has been tested on Debian Sarge with Exim4.
>> The following three config files, when dropped into /etc/exim4/conf.d/,
>> should do what it necessary. Note that as per directions in the Debian 
>> Exim README.Debian, the monolithic file (unsplit configuration) 
>> /etc/exim4/exim4.conf.template can be rebuilt from the conf.d files by 
>> running ''update-exim4.conf.template -r''.
> This will overwrite any local changes to update-exim4.conf.template. 
> Users should be warned.
> In the README, I''d refer to the exim4 README.
Have reread this, I realise that I have no idea what you mean by the last 
sentence. What README are you referring to, and which exim4 README should 
I refer to and why? Can you clarify?

If you reply before I submit the bug, I''ll include what changes you
want,
otherwise you can amend the bug report as you see fit.

                                                                Faheem.

On Tue, 13 Dec 2005, Faheem Mitha wrote:
> I''ll go ahead and file a wishlist bug report against the Debian
Roundup
> package, and copy the link here.
Link to Debian bug report is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343283

Maybe I should add a link to the discussion here for completeness. If I 
can summon up the energy, I''ll also send a message to roundup-users.

                                                                Faheem.

On Wed, Dec 14, 2005 at 01:44:28AM -0500, Faheem Mitha
wrote:
> Have reread this, I realise that I have no idea what you mean by the last 
> sentence. What README are you referring to, and which exim4 README should 
> I refer to and why? Can you clarify?
the README in the roundup Debian package should refer users to
/usr/share/doc/exim4-base/README.Debian.gz for more information about
Debian exim works.

Greeetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

On Wed, 14 Dec 2005, Faheem Mitha wrote:
>
>
> On Tue, 13 Dec 2005, Faheem Mitha wrote:
>
>> I''ll go ahead and file a wishlist bug report against the
Debian Roundup
>> package, and copy the link here.
>
> Link to Debian bug report is
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343283
>
> Maybe I should add a link to the discussion here for completeness. If I can
> summon up the energy, I''ll also send a message to roundup-users.
I checked with roundup-devel, and Richard Jones says he would be willing 
to include a patch against the current installation document.

My question here is whether the proposed addition to README.Debian for 
roundup requires drastic changes to make it into something suitable for a 
generic Exim user.

Could I just say something like the enclosed snippets should be put in the 
sections for (correspondingly) macros, router, transport?

I don''t think there is anything Debian specific about the snippets 
themselves, just about the way they are included in the config, right?

Thanks.                                                         Faheem,

********************************************************************************
On 15/12/2005, at 6:34 PM, Faheem Mitha wrote:
> 1) Is a patch against installation.txt Ok?
>
> 2) Would you be willing to include Exim 4 specific information in 
installation.txt?

Yes and yes.

> 3) If there a length restriction on such information? If so, how much?
If it''s "too long" we can split it out into a separate file.
Too long
would be > a couple of hundred lines, I
suppose. There''s no hard rule.


      Richard

On Mon, Dec 26, 2005 at 08:06:00PM -0500, Faheem Mitha
wrote:
> On Wed, 14 Dec 2005, Faheem Mitha wrote:
> >Maybe I should add a link to the discussion here for completeness. If I
> >can summon up the energy, I''ll also send a message to
roundup-users.
> 
> I checked with roundup-devel, and Richard Jones says he would be willing 
> to include a patch against the current installation document.
> 
> My question here is whether the proposed addition to README.Debian for 
> roundup requires drastic changes to make it into something suitable for a 
> generic Exim user.
I don''t think so.
> Could I just say something like the enclosed snippets should be put in the 
> sections for (correspondingly) macros, router, transport?
Yes, that should work. Of course, there needs to be considerable clue
in the target admin when it comes to placing the router, and there are
ways of configuring exim that would make using the routers hard or
impossible.
> I don''t think there is anything Debian specific about the snippets
> themselves, just about the way they are included in the config, right?
Right.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

On Tue, 27 Dec 2005, Marc Haber wrote:
> On Mon, Dec 26, 2005 at 08:06:00PM -0500, Faheem Mitha wrote:
>> On Wed, 14 Dec 2005, Faheem Mitha wrote:
>>> Maybe I should add a link to the discussion here for completeness.
If I
>>> can summon up the energy, I''ll also send a message to
roundup-users.
>>
>> I checked with roundup-devel, and Richard Jones says he would be
willing
>> to include a patch against the current installation document.
>>
>> My question here is whether the proposed addition to README.Debian for
>> roundup requires drastic changes to make it into something suitable for
a
>> generic Exim user.
>
> I don''t think so.
>
>> Could I just say something like the enclosed snippets should be put in
the
>> sections for (correspondingly) macros, router, transport?
>
> Yes, that should work. Of course, there needs to be considerable clue
> in the target admin when it comes to placing the router, and there are
> ways of configuring exim that would make using the routers hard or
> impossible.
>
>> I don''t think there is anything Debian specific about the
snippets
>> themselves, just about the way they are included in the config, right?
>
> Right.
Ok, Thanks for the comments.

Since you have been so helpful, I''m taking the liberty of including
the diff to Roundup''s installation.txt before sending it upstream.

Comments/corrections would be appreciated.

Thanks.                                                       Faheem.

**********************************************************************

diff -r 293f0a353096 installation.txt
--- a/installation.txt	Tue Dec 27 22:47:45 2005
+++ b/installation.txt	Tue Dec 27 19:27:33 2005
@@ -522,6 +522,98 @@

      echo test |mail -s ''[issue] test''
support@YOUR_DOMAIN_HERE

+As a custom router transport using a pipe process (Exim 4 specific)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following configuration snippets for Exim 4 configuration
+implement a custom router & transport to accomplish mail delivery to
+roundup-mailgw. A configuration for Exim 3 is similar but not
+included, since Exim 3 is considered obsolete.
+
+This configuration is similar to the previous section, in that it uses
+a pipe process. However, there are advantages to using a custom
+router/transport process, if you are using Exim.
+
+* This avoids privilege escalation, since otherwise the pipe process
+will run as the mail user, typically mail. The transport can be
+configured to run as the user appropriate for the task at hand.
+
+* Separate configuration is not required for each tracker
+instance. When a email arrives at the server, Exim looks for a match
+to one of the routers. The roundup_router looks for a match with one
+of the roundup directories, and if there is one it is passed to the
+roundup_transport, which uses the pipe process in the previous
+section.
+
+The matching is done in the line
+
+require_files = /usr/bin/roundup-mailgw:ROUNDUP_HOME/$local_part/schema.py
+
+The following configuration has been tested on Debian Sarge with
+Exim4. 
+
+Note that the Debian Exim4 packages don''t allow pipes in alias files
+by default, so this method will not work with the default
+configuration. See the discussion in
+/usr/share/doc/exim4-config/README.system_aliases on any Debian system
+with Exim 4 installed.
+
+For more Debian-specific information, see suggested addition to
+README.Debian in
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343283, which will
+hopefully be merged into the Debian package eventually.
+
+This config makes a few assumptions:
+
+* That the mail address corresponding to the tracker instance has the
+same name as the directory of the tracker instance, ie. the mail
+address corresponding to a Roundup instance called
+/var/lib/roundup/trackers/mytracker is mytracker@...
+
+* That (at least) all the db subdirectories of all the tracker
+instances (ie. /var/lib/roundup/trackers/*/db) are owned by the same
+user, in this case, ''roundup''.
+
+* That if the schema.py file exists, then the tracker is ''ready to
+go''. I''m not sure if it would be better to use the config.ini
file.
+
+However, it has the advantage that modulo these assumptions no further 
+configuration will need to be made when new tracker instances are added.
+
+************************************************************************
+Macros for Roundup router/transport. Should be placed in the macros
+section of the Exim 4 config.
+************************************************************************
+# Home dir for your Roundup installation
+ROUNDUP_HOME=/var/lib/roundup/trackers
+
+# User and group for Roundup.
+ROUNDUP_USER=roundup
+ROUNDUP_GROUP=roundup
+************************************************************************
+Custom router for Roundup. This should work if placed at the beginning
+of the router section of the Exim 4 config.
+************************************************************************
+roundup_router:
+    driver = accept
+    # The config file config.ini seems like a more natural choice, but the
+    # file config.py was replaced by config.ini in 0.8, and schema.py needs
+    # to be present too.
+    require_files = /usr/bin/roundup-mailgw:ROUNDUP_HOME/$local_part/schema.py
+    transport = roundup_transport
+************************************************************************
+Custom transport for Roundup. This should work if placed at the
+beginning of the router section of the Exim 4 config.
+************************************************************************
+roundup_transport:
+    driver = pipe
+    command = /usr/bin/python /usr/bin/roundup-mailgw ROUNDUP_HOME/$local_part/
+    current_directory = ROUNDUP_HOME
+    home_directory = ROUNDUP_HOME
+    user = ROUNDUP_USER
+    group = ROUNDUP_GROUP
+************************************************************************
+
  As a regular job using a mailbox source
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~