Joshua Alexander <[EMAIL PROTECTED]> writes:
> Hi folks,
>
> > > tmda_virtual_pipe:
> >> driver = pipe
> >> command = /usr/bin/python2 /usr/local/tmda/bin/tmda-filter
> >> return_path_add
> >> delivery_date_add
> >> envelope_to_add
> >> user = "${lookup{$domain}lsearch* {/etc/userdomains}{$value}}"
> >> group = mail
> >> environment = EXTENSION=${substr_1:$local_part_suffix}:\
> >> [EMAIL PROTECTED]
> >
> >First thing I see is that the -S switch will only call the script if
> >an environment variable named EXT (not EXTENSION) exists. This is
> >qmail-specific. That doesn't appear to be the cause of your problem,
> >though. You could add an EXT (same contents as EXTENSION)
> >but... there may be an easier way.
>
> I'm not sure what you mean, but that environment line was taken from
> exim-specific configuration instructions. Also, I believe it does set
> environment variables, not check for them, because this is a
> transport, not a router. But, that's just my understanding of it, I
> could be way off base.
Exim sets those variables (EXTENSION, RECIPIENT) because your
transport tells it to. qmail sets EXT instead of EXTENSION. The
basic tmda-filter supports both. The problem is that the code for the
-S switch was put in place to support qmail's virtual domains only and
thus doesn't look at EXTENSION, but only EXT.
> >You mention in a later message that you could set $HOME in the
> >environment before tmda-filter is called. Actually, you said $home
> >but I'm hoping that equates to $HOME.
>
> I said:
>
> Is there a way for me to set $home and override DELIVERY in the exim
> transport itself?
>
>
> Yes, I meant $HOME. Sorry, didn't know there was a difference :-) In
> any case, I don't know if I can or not! It certainly would be easier
> if I could, like tmda-filter -h /path/to/home.
Adding something like this is a possibility, but it wouldn't work well
for qmail. Most of the problems with virtual domains have to do with
the fact that they are implemented so wildly differently in the
various MTAs.
With qmail virtual domains, the virtual user's home directory isn't
known at the time qmail runs tmda-filter; thus, I added support by
running a script from within tmda-filter. With Exim, it looks like
you could figure out the virtual home directory before running
tmda-filter and so passing it as a parameter makes sense.
On the other hand, if you can figure out the virtual home directory in
the transport before calling tmda-filter (in other words, if you could
figure out the correct directory to pass to a '-h' switch), you should
just as easily be able to set the $HOME variable using that directory.
> I'm finding that using a vuserinfo-style script is a little more
> complicated than I thought.
Because it's qmail-specific. :)
> TMDA wants to pass it the user and domain according to the
> docs. Well in the case of mydomain.com with unix account me, and
> virtual email [EMAIL PROTECTED], exim will set the user to "me",
> which is good because the mail files are owned by me:mail, and the
> local_part to "test". So now what does TMDA pass to the -S script?
> "me" or "test"? I'm guessing the former, which won't work for me.
tmda-filter will call it like this:
<vdir-script> "test" "mydomain.com"
In other words, it uses the text from $EXT as the username.
> Perhaps I can set $HOME in
> /home/me/mail/mydomain.com/test/.tmda/config, and then use -c with
> tmda-filter?
But how will you know the path to the config file, which is different
for each user, just like $HOME is different for each user? And if you
have separate config files for each user, you could just hardcode the
paths instead of using '~' to mean $HOME. Then you wouldn't care what
$HOME is set to.
Anyhow, it seems to me that if you can figure out the path in the
transport, setting $HOME and using TMDA's defaults would be simpler.
If you decide to use the above technique (with '-c'), be sure to set
$HOME before setting any TMDA configuration variables that use '~'.
os.environ['HOME'] = "/home/me/mail/mydomain.com/test"
> Anyway, these days my exim_mainlog is showing:
>
> Child process of tmda_virtual_pipe transport returned 1 from command:
> /usr/bin/python2
>
>
> I wish someone could tell me what these return codes (75 and 1 so far)
> might indicate.
Return code 1 can be either an error from the Python interpreter or a
problem with the command line arguments passsed to tmda-filter. I see
below that your argument to the '-c' flag is enclosed in quotes. Does
Exim do the processing that you want when the commands are in quotes?
Or does it pass '/home/${lookup{$domain}lsearch*...' directly to
tmda-filter? If it passes everything in the quotes directly, that
could be causing the error code 1.
Return code 75 occurs when tmda-filter encounters an unrecoverable
error and, rather than losing the mail, it returns the 75 to tell Exim
(or any MTA) that delivery temporarily failed and that it should
preserve the message and retry delivery later.
> Here is output from exim -d -bs:
>
> set_process_info: 11183 reading output from |/usr/bin/python2
> /usr/local/tmda/bin/tmda-filter -c "/home/${lookup{$domain}lsearch*
> {/etc/userdomains}{$value}}/mail/$domain/$local_part/.tmda/config"
>
> writing data block fd=11 size=44 timeout=3600
> writing data block fd=11 size=433 timeout=3600
> writing data block fd=11 size=1 timeout=3600
> tmda_virtual_pipe transport yielded 2
> search_tidyup called
> tmda_virtual_pipe transport returned FAIL for [EMAIL PROTECTED]
> post-process [EMAIL PROTECTED] (2)
> LOG: MAIN
> ** [EMAIL PROTECTED] R=tmda_virtual T=tmda_virtual_pipe:
> ** Child process of tmda_virtual_pipe transport returned 1 from
> ** command: /usr/bin/python2
>
>
> What it means for the command to "yield 2" and "return 1" is beyond
> me. I have no idea what either of those mean. Anybody else?
The 2 comes from the Exim transport code and has meaning to Exim. The
1 is from either Python or tmda-filter (when it has an error parsing
options).
Tim
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
