master/slave setup via VPN?

[Alain Spineux]

On Sun, Jul 20, 2008 at 8:57 PM, Thorsten Schnebeck
<thorsten.schnebeck at gmx.net> wrote:
> Am Sonntag 20 Juli 2008 schrieb Thorsten Schnebeck:
>> Am Samstag 19 Juli 2008 schrieb Alain Spineux:
>> > On Fri, Jul 18, 2008 at 10:38 PM, Thorsten Schnebeck
>
>> > You can add this entry in /etc/hosts
>> >
>> > 10.10.10.2               slave.domain2.com
>>
>> Hmm, does not work :-(
>> When I ping to slave.domain2.com now it pings to 10.10.10.2
>> but postfix still want to deliver to the real IP. I also insert
>>
>> smtp_host_lookup = native,dns
>>
>> into  /kolab/etc/postfix/main.cf but this somehow does not change anything.
>> Using transport does also not work. Maybe a conflict with Kolabs homeserver
>> ldap settings?
>>
>> Any ideas?
> Ok, seems to work now, but only after one timeout.
> I use
> smtp      unix  -       -       n       -       -       smtp -o
> fallback_relay=10.10.10.2

This is a mistake !!!!
If your server is sending an "autging" mail
and the recipient server is unavailable, your server
will try 10.10.10.2 that should reject the email
and your sender will got a NDR.

>
> in master.cf
>
> now I get
>> connect to slave.domain2.com[4.3.2.1]: Connection timed out (port 25)
>> to=<info at maildomain3.com>, relay=10.10.10.2[10.10.10.2]:25, delay=30,
>> delays=0.03/0.01/30/0.06, dsn=2.0.0, status=sent (250 2.0.0 Ok:
>> queued as 1430A19F97C)
>
> and for some unknown reasons I get on the _slave_ for one of the mail domain
> names a
>
>> : to=<info at maildomain3.com>, relay=none, delay=0.01, delays=0.01/0/0/0,
>> dsn=5.4.6, status=bounced (mail for 10.10.10.2 loops back to myself)
>

Did you set a transport for domain3 ?
If slave share the same ldap data as the master,
maybe it will not understand why you setup a transport to itself.
You should define a transport per mailbox, not for all domain3
or customize your master.cf templates accordingly

> I have no problems with delivering mails to maildomain2.com on the slave.
> Maybe because maildomain2.com==domainname of the slave. But this could be
> solved in using the master as smarthost of the slave.
>
> While now everything seems to work stable, this was a little bit of
> voodoo. :-/ weekend!! :-)
>
> Tips & hints for a better or cleaner solution or a better understanding of
> this stuff are welcome!
>
> Bye
>
>  Thorsten
>
> _______________________________________________
> Kolab-users mailing list
> Kolab-users at kolab.org
> https://kolab.org/mailman/listinfo/kolab-users
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you