thr3ads.net - Pkg exim4 users - [Pkg-exim4-users] Secondary MX with virtual domain config [Jan 2011]

If this information is useful, please help other people find it:
Share via:

x_debian-exim4-users_x at nospam.pz.podzone.net

2011-Jan-29 16:31 UTC

[Pkg-exim4-users] Secondary MX with virtual domain config

Hi,

I am trying to configure exim for so called ''virtual'' domains,
but
with a primary/secondary MX scenario.  In fact I''m not so sure this is
strictly correct usage of primary/secondary terminolgy but I hope it''s
clear.

The stock solution appears to be the "vdom_aliases" router (below), as
variously quoted in howto''s and internet postings.  However afaict,
this only caters for single server operation and my attempts to morph
this to work satisfactorilly on a secondary MX have failed so far.

I have previously used the hubbed_hosts router (below) on the
secondary MX, together with callout to the primary to check for valid
recipient.  This doesn''t work so well I think if the primary MX is
down.

So I think the solution is to modify the hubbed_hosts router so that
it will consult a local configuration (as the vdom_aliases router
does) to validate the recipient addr.

The primary MX would then run the vdom_aliases router as per normal,
with it''s local configuration of /etc/exim4/virtual/... files.

My efforts to figure this out have so far not come to much.  I''m
hoping someone can point me in the right direction please?

I''m happy if the solution requires files to be synched between MXs, or
a hybrid solution where /etc/exim4/virtual/... is first used for
vaildation and /etc/exim4/hubbed_hosts is then used for routing.

-- 150_exim4-config_hubbed_hosts --

hubbed_hosts:
  debug_print = "R: hubbed_hosts for $domain"
  driver = manualroute
  domains = "${if exists{CONFDIR/hubbed_hosts}\
                   {partial-lsearch;CONFDIR/hubbed_hosts}\
              fail}"
  same_domain_copy_routing = yes
  route_data = ${lookup{$domain}partial-lsearch{CONFDIR/hubbed_hosts}}
  transport = remote_smtp

-- 350_local-config_vdom_aliases --

vdom_aliases:
      driver = redirect
      allow_defer
      allow_fail
      domains = dsearch;/etc/exim4/virtual
      data =
${expand:${lookup{$local_part}lsearch*@{/etc/exim4/virtual/$domain}}}
      retry_use_local_part
      pipe_transport   = address_pipe
      file_transport   = address_file
      no_more

My references on this have so far been the (Red) Exim book, and -

http://www.debian-administration.org/articles/140

http://wiki.nerdylorrin.net/wiki/Wiki.jsp?page=EximVirtualDomains

Thanks in advance for any help or advice received.

Charlie

Jonathan Plews

2011-Jan-31 00:22 UTC

head link

[Pkg-exim4-users] Secondary MX with virtual domain config

My server does just that, the following lines are in  
exim4.conf.localmacros (but you could use debconf too)

MAIN_LOCAL_DOMAINS = @:localhost:dsearch;/srv/conf/vmail
MAIN_RELAY_TO_DOMAINS = dsearch;/srv/conf/dns


/srv/conf/vmail is just the same as /etc/exim4/virtual in examples

/srv/conf/dns works the same way as alias files for the virtual  
domains - but they''re tinydns files

I''d expect ''lsearch:/etc/exim4/local_relay_domains''
or similar would
work too if it contained:


example.co.uk
etc.org
...


Seems to work well for me, no problems so far.

-- 
Jonathan Plews



Quoting x_debian-exim4-users_x at nospam.pz.podzone.net:
> Hi,
>
> I am trying to configure exim for so called ''virtual''
domains, but
> with a primary/secondary MX scenario.  In fact I''m not so sure
this is
> strictly correct usage of primary/secondary terminolgy but I hope
it''s
> clear.
>
> The stock solution appears to be the "vdom_aliases" router
(below), as
> variously quoted in howto''s and internet postings.  However
afaict,
> this only caters for single server operation and my attempts to morph
> this to work satisfactorilly on a secondary MX have failed so far.
>
> I have previously used the hubbed_hosts router (below) on the
> secondary MX, together with callout to the primary to check for valid
> recipient.  This doesn''t work so well I think if the primary MX is
> down.
>
> So I think the solution is to modify the hubbed_hosts router so that
> it will consult a local configuration (as the vdom_aliases router
> does) to validate the recipient addr.
>
> The primary MX would then run the vdom_aliases router as per normal,
> with it''s local configuration of /etc/exim4/virtual/... files.
>
> My efforts to figure this out have so far not come to much.  I''m
> hoping someone can point me in the right direction please?
>
> I''m happy if the solution requires files to be synched between
MXs, or
> a hybrid solution where /etc/exim4/virtual/... is first used for
> vaildation and /etc/exim4/hubbed_hosts is then used for routing.
>
> -- 150_exim4-config_hubbed_hosts --
>
> hubbed_hosts:
>   debug_print = "R: hubbed_hosts for $domain"
>   driver = manualroute
>   domains = "${if exists{CONFDIR/hubbed_hosts}
>                    {partial-lsearch;CONFDIR/hubbed_hosts}
>               fail}"
>   same_domain_copy_routing = yes
>   route_data = ${lookup{$domain}partial-lsearch{CONFDIR/hubbed_hosts}}
>   transport = remote_smtp
>
> -- 350_local-config_vdom_aliases --
>
> vdom_aliases:
>       driver = redirect
>       allow_defer
>       allow_fail
>       domains = dsearch;/etc/exim4/virtual
>       data =  
> ${expand:${lookup{$local_part}lsearch*@{/etc/exim4/virtual/$domain}}}
>       retry_use_local_part
>       pipe_transport   = address_pipe
>       file_transport   = address_file
>       no_more
>
> My references on this have so far been the (Red) Exim book, and -
>
> http://www.debian-administration.org/articles/140
>
> http://wiki.nerdylorrin.net/wiki/Wiki.jsp?page=EximVirtualDomains
>
> Thanks in advance for any help or advice received.
>
> Charlie
>
> _______________________________________________
> Pkg-exim4-users mailing list
> Pkg-exim4-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users
>
>


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: PGP Digital Signature
URL:
<http://lists.alioth.debian.org/pipermail/pkg-exim4-users/attachments/20110131/11437bee/attachment.pgp>

x_debian-exim4-users_x at nospam.pz.podzone.net

2011-Jan-31 10:33 UTC

head link

[Pkg-exim4-users] Secondary MX with virtual domain config

Hi,

Thanks for that.

If I understand it right you also have vdom_aliases (or similar)
router installed on the secondary mx.

Does Envelope-To: header correctly show the address the mail was
originally sent to?  If so then I''d like to understand how that is
acheived because it has different behaviour here.

The mail headers that the user ends up seeing have Envelope-To:
user at finalhost, rather than user at realdomain.  Which is not so easy for
the recipient when it comes to local sorting of mail.  I assume this
is because it is the final host (what I called the primary mx) that
adds Envelope-To: and by that point the secondary vdom_aliases router
has already re-routed the mail to user at finalhost.

This is why I wondered about using hubbed_hosts, in my OP.

With the vdom_aliases instead configured to run on the primary (or
final) mx, and hubbed_hosts configured to run on the secondary, the
Envelope-To: header will correctly show the address the mail was
originally sent to.  However the downside in this case is that the
secondary MX will not reject reject mail for invalid recipients.

Charlie


On Mon, Jan 31, 2011 at 12:22:56AM +0000, Jonathan Plews
wrote:> My server does just that, the following lines are in  
> exim4.conf.localmacros (but you could use debconf too)
> 
> MAIN_LOCAL_DOMAINS = @:localhost:dsearch;/srv/conf/vmail
> MAIN_RELAY_TO_DOMAINS = dsearch;/srv/conf/dns
> 
> 
> /srv/conf/vmail is just the same as /etc/exim4/virtual in examples
> 
> /srv/conf/dns works the same way as alias files for the virtual  
> domains - but they''re tinydns files
> 
> I''d expect
''lsearch:/etc/exim4/local_relay_domains'' or similar would
> work too if it contained:
> 
> 
> example.co.uk
> etc.org
> ...
> 
> 
> Seems to work well for me, no problems so far.
> 
> -- 
> Jonathan Plews
> 
> 
> 
> Quoting x_debian-exim4-users_x at nospam.pz.podzone.net:
> 
> >Hi,
> >
> >I am trying to configure exim for so called ''virtual''
domains, but
> >with a primary/secondary MX scenario.  In fact I''m not so sure
this is
> >strictly correct usage of primary/secondary terminolgy but I hope
it''s
> >clear.
> >
> >The stock solution appears to be the "vdom_aliases" router
(below), as
> >variously quoted in howto''s and internet postings.  However
afaict,
> >this only caters for single server operation and my attempts to morph
> >this to work satisfactorilly on a secondary MX have failed so far.
> >
> >I have previously used the hubbed_hosts router (below) on the
> >secondary MX, together with callout to the primary to check for valid
> >recipient.  This doesn''t work so well I think if the primary
MX is
> >down.
> >
> >So I think the solution is to modify the hubbed_hosts router so that
> >it will consult a local configuration (as the vdom_aliases router
> >does) to validate the recipient addr.
> >
> >The primary MX would then run the vdom_aliases router as per normal,
> >with it''s local configuration of /etc/exim4/virtual/... files.
> >
> >My efforts to figure this out have so far not come to much. 
I''m
> >hoping someone can point me in the right direction please?
> >
> >I''m happy if the solution requires files to be synched between
MXs, or
> >a hybrid solution where /etc/exim4/virtual/... is first used for
> >vaildation and /etc/exim4/hubbed_hosts is then used for routing.
> >
> >-- 150_exim4-config_hubbed_hosts --
> >
> >hubbed_hosts:
> >  debug_print = "R: hubbed_hosts for $domain"
> >  driver = manualroute
> >  domains = "${if exists{CONFDIR/hubbed_hosts}
> >                   {partial-lsearch;CONFDIR/hubbed_hosts}
> >              fail}"
> >  same_domain_copy_routing = yes
> >  route_data = ${lookup{$domain}partial-lsearch{CONFDIR/hubbed_hosts}}
> >  transport = remote_smtp
> >
> >-- 350_local-config_vdom_aliases --
> >
> >vdom_aliases:
> >      driver = redirect
> >      allow_defer
> >      allow_fail
> >      domains = dsearch;/etc/exim4/virtual
> >      data =  
> >${expand:${lookup{$local_part}lsearch*@{/etc/exim4/virtual/$domain}}}
> >      retry_use_local_part
> >      pipe_transport   = address_pipe
> >      file_transport   = address_file
> >      no_more
> >
> >My references on this have so far been the (Red) Exim book, and -
> >
> >http://www.debian-administration.org/articles/140
> >
> >http://wiki.nerdylorrin.net/wiki/Wiki.jsp?page=EximVirtualDomains
> >
> >Thanks in advance for any help or advice received.
> >
> >Charlie
> >
> >_______________________________________________
> >Pkg-exim4-users mailing list
> >Pkg-exim4-users at lists.alioth.debian.org
> >http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users
> >
> >
> 
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 

> _______________________________________________
> Pkg-exim4-users mailing list
> Pkg-exim4-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users

Jonathan Plews

2011-Feb-01 02:30 UTC

head link

[Pkg-exim4-users] Secondary MX with virtual domain config

That''s correct, I have a mail server, primary for myself and other  
virtual domains that is also a backup MX for other servers.

The backup MX for my own primary uses rsync to pull updates to the  
virtual domain alias files but it only uses the file names to check  
the domains it should be taking messages for, not user accounts. The  
backup still checks blacklists and rejects high spam scores (but  
doesn''t add headers)

Have you tried anything like this:

vdom_relay:
       driver = dnslookup
       transport = remote_smtp
       domains = (dsearch for domains)
??    condition = if{$local_part} lsearch *@{/etc/exim4/virtual/$domain}
       (maybe some other stuff)
       no more

The condition is not valid syntax, and the whole idea could be flawed,  
I don''t have anything to test with at the moment.

Regards

-- 
Jonathan Plews



Quoting x_debian-exim4-users_x at nospam.pz.podzone.net:
> Hi,
>
> Thanks for that.
>
> If I understand it right you also have vdom_aliases (or similar)
> router installed on the secondary mx.
>
> Does Envelope-To: header correctly show the address the mail was
> originally sent to?  If so then I''d like to understand how that is
> acheived because it has different behaviour here.
>
> The mail headers that the user ends up seeing have Envelope-To:
> user at finalhost, rather than user at realdomain.  Which is not so easy
for
> the recipient when it comes to local sorting of mail.  I assume this
> is because it is the final host (what I called the primary mx) that
> adds Envelope-To: and by that point the secondary vdom_aliases router
> has already re-routed the mail to user at finalhost.
>
> This is why I wondered about using hubbed_hosts, in my OP.
>
> With the vdom_aliases instead configured to run on the primary (or
> final) mx, and hubbed_hosts configured to run on the secondary, the
> Envelope-To: header will correctly show the address the mail was
> originally sent to.  However the downside in this case is that the
> secondary MX will not reject reject mail for invalid recipients.
>
> Charlie
>
>
> On Mon, Jan 31, 2011 at 12:22:56AM +0000, Jonathan Plews wrote:
>> My server does just that, the following lines are in
>> exim4.conf.localmacros (but you could use debconf too)
>>
>> MAIN_LOCAL_DOMAINS = @:localhost:dsearch;/srv/conf/vmail
>> MAIN_RELAY_TO_DOMAINS = dsearch;/srv/conf/dns
>>
>>
>> /srv/conf/vmail is just the same as /etc/exim4/virtual in examples
>>
>> /srv/conf/dns works the same way as alias files for the virtual
>> domains - but they''re tinydns files
>>
>> I''d expect
''lsearch:/etc/exim4/local_relay_domains'' or similar would
>> work too if it contained:
>>
>>
>> example.co.uk
>> etc.org
>> ...
>>
>>
>> Seems to work well for me, no problems so far.
>>
>> --
>> Jonathan Plews
>>
>>
>>
>> Quoting x_debian-exim4-users_x at nospam.pz.podzone.net:
>>
>> >Hi,
>> >
>> >I am trying to configure exim for so called
''virtual'' domains, but
>> >with a primary/secondary MX scenario.  In fact I''m not so
sure this is
>> >strictly correct usage of primary/secondary terminolgy but I hope
it''s
>> >clear.
>> >
>> >The stock solution appears to be the "vdom_aliases"
router (below), as
>> >variously quoted in howto''s and internet postings. 
However afaict,
>> >this only caters for single server operation and my attempts to
morph
>> >this to work satisfactorilly on a secondary MX have failed so far.
>> >
>> >I have previously used the hubbed_hosts router (below) on the
>> >secondary MX, together with callout to the primary to check for
valid
>> >recipient.  This doesn''t work so well I think if the
primary MX is
>> >down.
>> >
>> >So I think the solution is to modify the hubbed_hosts router so
that
>> >it will consult a local configuration (as the vdom_aliases router
>> >does) to validate the recipient addr.
>> >
>> >The primary MX would then run the vdom_aliases router as per
normal,
>> >with it''s local configuration of /etc/exim4/virtual/...
files.
>> >
>> >My efforts to figure this out have so far not come to much. 
I''m
>> >hoping someone can point me in the right direction please?
>> >
>> >I''m happy if the solution requires files to be synched
between MXs, or
>> >a hybrid solution where /etc/exim4/virtual/... is first used for
>> >vaildation and /etc/exim4/hubbed_hosts is then used for routing.
>> >
>> >-- 150_exim4-config_hubbed_hosts --
>> >
>> >hubbed_hosts:
>> >  debug_print = "R: hubbed_hosts for $domain"
>> >  driver = manualroute
>> >  domains = "${if exists{CONFDIR/hubbed_hosts}
>> >                   {partial-lsearch;CONFDIR/hubbed_hosts}
>> >              fail}"
>> >  same_domain_copy_routing = yes
>> >  route_data =
${lookup{$domain}partial-lsearch{CONFDIR/hubbed_hosts}}
>> >  transport = remote_smtp
>> >
>> >-- 350_local-config_vdom_aliases --
>> >
>> >vdom_aliases:
>> >      driver = redirect
>> >      allow_defer
>> >      allow_fail
>> >      domains = dsearch;/etc/exim4/virtual
>> >      data >>
>${expand:${lookup{$local_part}lsearch*@{/etc/exim4/virtual/$domain}}}
>> >      retry_use_local_part
>> >      pipe_transport   = address_pipe
>> >      file_transport   = address_file
>> >      no_more
>> >
>> >My references on this have so far been the (Red) Exim book, and -
>> >
>> >http://www.debian-administration.org/articles/140
>> >
>> >http://wiki.nerdylorrin.net/wiki/Wiki.jsp?page=EximVirtualDomains
>> >
>> >Thanks in advance for any help or advice received.
>> >
>> >Charlie
>> >
>> >_______________________________________________
>> >Pkg-exim4-users mailing list
>> >Pkg-exim4-users at lists.alioth.debian.org
>> >http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users
>> >
>> >
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>
>
>
>> _______________________________________________
>> Pkg-exim4-users mailing list
>> Pkg-exim4-users at lists.alioth.debian.org
>> http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users
>
> _______________________________________________
> Pkg-exim4-users mailing list
> Pkg-exim4-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users
>
>


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: PGP Digital Signature
URL:
<http://lists.alioth.debian.org/pipermail/pkg-exim4-users/attachments/20110201/5c20af08/attachment.pgp>

x_debian-exim4-users_x at nospam.pz.podzone.net

2011-Feb-05 19:29 UTC

head link

[Pkg-exim4-users] Secondary MX with virtual domain config

Hi,

Thanks.  That gave me enough pointers to finally figure it out.

I found exactly the desired behaviour with the following ACL added to
the secondary MX:

  deny
    message = User not known at this domain
    !acl = acl_local_deny_exceptions
    domains = dsearch;CONFDIR/virtual
    !condition =
${lookup{$local_part}lsearch*@{CONFDIR/virtual/$domain}{yes}{no}}

Debian allows this addition to acl_check_rcpt with the use of a local
file ''CHECK_RCPT_LOCAL_ACL_FILE''.

This allows the secondary to verify the recipient address (without
callout to the primary) by lookup under /etc/exim4/virtual/... file.

If the recipient is invalid then it will be rejected at smtp stage by
the secondary with 550.

The mail is then relayed from secondary to primary according to MX
records as usual.

The primary MX also has the /etc/exim4/virtual/... files, but in this
case the vdom_aliases router mentioned in the OP is used to deliver
mail to the appropriate accounts locally.

Cheers!


On Tue, Feb 01, 2011 at 02:30:17AM +0000, Jonathan Plews
wrote:> That''s correct, I have a mail server, primary for myself and other
> virtual domains that is also a backup MX for other servers.
> 
> The backup MX for my own primary uses rsync to pull updates to the  
> virtual domain alias files but it only uses the file names to check  
> the domains it should be taking messages for, not user accounts. The  
> backup still checks blacklists and rejects high spam scores (but  
> doesn''t add headers)
> 
> Have you tried anything like this:
> 
> vdom_relay:
>       driver = dnslookup
>       transport = remote_smtp
>       domains = (dsearch for domains)
> ??    condition = if{$local_part} lsearch *@{/etc/exim4/virtual/$domain}
>       (maybe some other stuff)
>       no more
> 
> The condition is not valid syntax, and the whole idea could be flawed,  
> I don''t have anything to test with at the moment.
> 
> Regards
> 
> -- 
> Jonathan Plews
> 
> 
> 
> Quoting x_debian-exim4-users_x at nospam.pz.podzone.net:
> 
> >Hi,
> >
> >Thanks for that.
> >
> >If I understand it right you also have vdom_aliases (or similar)
> >router installed on the secondary mx.
> >
> >Does Envelope-To: header correctly show the address the mail was
> >originally sent to?  If so then I''d like to understand how
that is
> >acheived because it has different behaviour here.
> >
> >The mail headers that the user ends up seeing have Envelope-To:
> >user at finalhost, rather than user at realdomain.  Which is not so
easy for
> >the recipient when it comes to local sorting of mail.  I assume this
> >is because it is the final host (what I called the primary mx) that
> >adds Envelope-To: and by that point the secondary vdom_aliases router
> >has already re-routed the mail to user at finalhost.
> >
> >This is why I wondered about using hubbed_hosts, in my OP.
> >
> >With the vdom_aliases instead configured to run on the primary (or
> >final) mx, and hubbed_hosts configured to run on the secondary, the
> >Envelope-To: header will correctly show the address the mail was
> >originally sent to.  However the downside in this case is that the
> >secondary MX will not reject reject mail for invalid recipients.
> >
> >Charlie
> >
> >
> >On Mon, Jan 31, 2011 at 12:22:56AM +0000, Jonathan Plews wrote:
> >>My server does just that, the following lines are in
> >>exim4.conf.localmacros (but you could use debconf too)
> >>
> >>MAIN_LOCAL_DOMAINS = @:localhost:dsearch;/srv/conf/vmail
> >>MAIN_RELAY_TO_DOMAINS = dsearch;/srv/conf/dns
> >>
> >>
> >>/srv/conf/vmail is just the same as /etc/exim4/virtual in examples
> >>
> >>/srv/conf/dns works the same way as alias files for the virtual
> >>domains - but they''re tinydns files
> >>
> >>I''d expect
''lsearch:/etc/exim4/local_relay_domains'' or similar would
> >>work too if it contained:
> >>
> >>
> >>example.co.uk
> >>etc.org
> >>...
> >>
> >>
> >>Seems to work well for me, no problems so far.
> >>
> >>--
> >>Jonathan Plews
> >>
> >>
> >>
> >>Quoting x_debian-exim4-users_x at nospam.pz.podzone.net:
> >>
> >>>Hi,
> >>>
> >>>I am trying to configure exim for so called
''virtual'' domains, but
> >>>with a primary/secondary MX scenario.  In fact I''m not
so sure this is
> >>>strictly correct usage of primary/secondary terminolgy but I
hope it''s
> >>>clear.
> >>>
> >>>The stock solution appears to be the "vdom_aliases"
router (below), as
> >>>variously quoted in howto''s and internet postings. 
However afaict,
> >>>this only caters for single server operation and my attempts to
morph
> >>>this to work satisfactorilly on a secondary MX have failed so
far.
> >>>
> >>>I have previously used the hubbed_hosts router (below) on the
> >>>secondary MX, together with callout to the primary to check for
valid
> >>>recipient.  This doesn''t work so well I think if the
primary MX is
> >>>down.
> >>>
> >>>So I think the solution is to modify the hubbed_hosts router so
that
> >>>it will consult a local configuration (as the vdom_aliases
router
> >>>does) to validate the recipient addr.
> >>>
> >>>The primary MX would then run the vdom_aliases router as per
normal,
> >>>with it''s local configuration of
/etc/exim4/virtual/... files.
> >>>
> >>>My efforts to figure this out have so far not come to much. 
I''m
> >>>hoping someone can point me in the right direction please?
> >>>
> >>>I''m happy if the solution requires files to be synched
between MXs, or
> >>>a hybrid solution where /etc/exim4/virtual/... is first used
for
> >>>vaildation and /etc/exim4/hubbed_hosts is then used for
routing.
> >>>
> >>>-- 150_exim4-config_hubbed_hosts --
> >>>
> >>>hubbed_hosts:
> >>>  debug_print = "R: hubbed_hosts for $domain"
> >>>  driver = manualroute
> >>>  domains = "${if exists{CONFDIR/hubbed_hosts}
> >>>                   {partial-lsearch;CONFDIR/hubbed_hosts}
> >>>              fail}"
> >>>  same_domain_copy_routing = yes
> >>>  route_data =
${lookup{$domain}partial-lsearch{CONFDIR/hubbed_hosts}}
> >>>  transport = remote_smtp
> >>>
> >>>-- 350_local-config_vdom_aliases --
> >>>
> >>>vdom_aliases:
> >>>      driver = redirect
> >>>      allow_defer
> >>>      allow_fail
> >>>      domains = dsearch;/etc/exim4/virtual
> >>>      data >
>>>${expand:${lookup{$local_part}lsearch*@{/etc/exim4/virtual/$domain}}}
> >>>      retry_use_local_part
> >>>      pipe_transport   = address_pipe
> >>>      file_transport   = address_file
> >>>      no_more
> >>>
> >>>My references on this have so far been the (Red) Exim book, and
-
> >>>
> >>>http://www.debian-administration.org/articles/140
> >>>
>
>>>http://wiki.nerdylorrin.net/wiki/Wiki.jsp?page=EximVirtualDomains
> >>>
> >>>Thanks in advance for any help or advice received.
> >>>
> >>>Charlie
> >>>
> >>>_______________________________________________
> >>>Pkg-exim4-users mailing list
> >>>Pkg-exim4-users at lists.alioth.debian.org
> >>>http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users
> >>>
> >>>
> >>
> >>
> >>
> >>----------------------------------------------------------------
> >>This message was sent using IMP, the Internet Messaging Program.
> >>
> >
> >
> >
> >>_______________________________________________
> >>Pkg-exim4-users mailing list
> >>Pkg-exim4-users at lists.alioth.debian.org
> >>http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users
> >
> >_______________________________________________
> >Pkg-exim4-users mailing list
> >Pkg-exim4-users at lists.alioth.debian.org
> >http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users
> >
> >
> 
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 

> _______________________________________________
> Pkg-exim4-users mailing list
> Pkg-exim4-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users

Pkg exim4 users - Jan 2011 - Secondary MX with virtual domain config

[Pkg-exim4-users] Secondary MX with virtual domain config

[Pkg-exim4-users] Secondary MX with virtual domain config

[Pkg-exim4-users] Secondary MX with virtual domain config

[Pkg-exim4-users] Secondary MX with virtual domain config

[Pkg-exim4-users] Secondary MX with virtual domain config