Ryan Whalen wrote:
> I am a bit of a Greenhorn with EXIM, but am hoping to grasp an issue I'm
> having:
>
> We have a server that has a site running a support software. The software
> has been installed on a subdomain. IE: xxxxxxx.domain.com *not*
> www.domain.com. We're trying to setup piping through cPanel, but the piping
> doesn't work for the subdomain because it doesn't technically have
> permission to access the script that is run to fulfill the piping
> execution. I read the following which explains that in order for the
> subdomain to have permissions to access the script, you have to set certain
> directives inside "exim.conf" . Well, I have no clue how this can be
> achieved (after hours upon hours of Googling), so I turn to you guys.
>
> Here is what I read:
>
>
>
>>CPanel has a restriction on piping of emails between two seperate accounts
>>owned by different users. For Example, If you have eSupport installed at
>>support.domain.com and are piping support@??? (Notice that it has
>>no subdomain) to eSupport, CPanel will reject the email with "Local Delivery
>>Failed" error.
>>
>>The following is the fix as described by the CPanel Staff themself.
>>
>>-- Snip --
>>Yes the /etc/exim.conf file has this:
>>
>># This director handles aliasing using a traditional /etc/aliases file.
>># If any of your aliases expand to pipes or files, you will need to set #
>>up a user and a group for these deliveries to run under. You can do # this
>>by uncommenting the "user" option below (changing the user name # as
>>appropriate) and adding a "group" option if necessary. Alternatively, you #
>>can specify "user" on the transports that are used. Note that those # listed
>>below are the same as are used for .forward files; you might want # to set
>>up different ones for pipe and file deliveries from aliases.
>>
>>...
>>
>>central_filter:
>>#!!# filter renamed allow_filter
>>driver = redirect
>>allow_filter
>>no_check_local_user
>>file = /etc/vfilters/${domain}
>>file_transport = address_file
>>pipe_transport = virtual_address_pipe
>>reply_transport = address_reply
>>retry_use_local_part
>>user = "${lookup{$domain}lsearch* {/etc/userdomains}{$value}}"
>>no_verify
>>
>>So any pipes or files must have permissions to use it from the owner via
>>exim.conf (IE the 'user =' directive above)(which is why even the sample
>>perl test failed since the /home/63723 file wasn't owned by the user or
>>group of the domain the email address had). Otherwise you could have a
>>security risk.
>>
>>To get around this you will have to modify your exim.conf to allow all
>>users to use the file not owned by the user and group.
>>
>>http://www.exim.org/ will have more information on specific directives you
>>can set up to allow this.
>>
>>If I run across any specific directives that will allow this I will let
>>you know.
>>
>>You may also want to ask the exim users mailing list how to do that
>>
>>HTH
>>--
>>Daniel Muey
>>Technical Support
>>cPanel Inc
>>
>
>
> Any ideas as to how I would go about editing exim.conf to achieve this? The
> commenting in exim.conf is rather vague. Thanks in advance!!
>
> - Gabe
First - thanks for researching and taking the issue up with CPanel first.
The next stop should probably be the Debian/Linux parallel to this list.
From what you were given / have researched, I *think* there is some
less-than-entirely-accurate - or at least incomplete advice in the above chain.
Exim is able to su to other UID:GID for delivery - which is the phase where your
pipes 'live' - but the setup of users, groups, memberships, and privilege levels
*AFAIK* need to be addressed external to Exim before you start.
I suspect that is more basic Linux admin than either CPanel (alone) or Exim
(alone) - and that you are more likely to find folks who understand those
Debian-unique or CPanel tools and the relationship to their specialized Exim
configuration system on the Debian/Exim list than here.
HTH,
Bill
