Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I wrote 2 routers to take care of forwarding in one of my mail server:

virtual_aliases_nostar:
  driver = redirect
  allow_defer
  allow_fail
  require_files = "+/var/auth/valiases/$domain"
  data = ${lookup{$local_part@$domain}lsearch{/var/auth/valiases/$domain}}
  file_transport = address_file
  group = mail
  pipe_transport = virtual_address_pipe
  retry_use_local_part
  unseen

virtual_aliases:
    driver = redirect
    allow_defer
    allow_fail
    require_files = "+/var/auth/valiases/$domain"
    data = ${lookup{*}lsearch{/var/auth/valiases/$domain}}
    file_transport = address_file
    group = mail
    pipe_transport = virtual_address_pipe
    unseen

Which call for this transport:

virtual_address_pipe:
  driver = pipe
  group = some_user
  return_output          
  user = some_user

In case there is a valiases/somedomain.com file like the one below, it will resolve the first email and forward it but will stop there.

user1@domain.com: user1@forwardomain.com
user1@domain.com: user3@forwardomain.com
user1@domain.com: user4@forwardomain.com
user1@domain.com: user9@forwardomain.com
user1@domain.com: user111@forwardomain.com
user1@domain.com: user12@forwardomain.com
user1@domain.com: user11@forwardomain.com

Basically user1@domain.com will be forwarded to user1@forwardomain.com only and stop there. Any idea why it happens? thanks.

share|improve this question

1 Answer 1

up vote 3 down vote accepted

What are you expecting it to do? You seem to expect the virtual_address_pipe transport to be called, but the aliasfile example you give doesn't have any pipe aliases in them...

omigosh... I just reread your question for the 20th time. I got distracted by the fact that what you are describing doesn't quite gel with your example, since a redirect to another email address wouldn't trigger a pipe_transport. I'm going to assume your real alias file redirects to actual pipes and it got lost in translation when you tried to clean up for an example instead of posting the real config and alias file you are having problems with.

Anyway, ignoring that, I think the answer to your question is as simple as putting all the targets on a single line:

user1@domain.com: user1@forwardomain.com, user3@forwardomain.com, user4@forwardomain.com, user9@forwardomain.com, user111@forwardomain.com, user12@forwardomain.com, user11@forwardomain.com

You only ever do one lookup per local_part in a router like that. Pu all the targets on a single line and Exim will handle re-routing/transporting/etc all the targets that are looked up. This works for email address, files, and pipes:

 user1@domain.com: /path/to/file, |/path/to/pipe, user1@forwardomain.com

Hope that helps.

share|improve this answer
    
${lookup{$local_part@$domain}lsearch{/var/auth/valiases/$domain}} mean it look up for user1@domain.com (when user1@domain.com arrives) and take the email after the : and trigger the pipe_transport (virtual_pipe_address) Basically it does work for the first email, the other aren't triggered, what I am looking for are ways to tell the router to run multiple time as long as it matches. –  Adam Benayoun Aug 17 '09 at 15:15
    
what version of exim are you running? 3 or 4? That require_files makes me fear you are running 3... –  jj33 Aug 17 '09 at 15:23
    
im running exim 4.63 - and by the way I've done the changes you wrote here and now it is working perfectly. thanks a lot! –  Adam Benayoun Aug 17 '09 at 20:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.