Re: [exim] How does exim handle the case of changing smartho…

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Heiko Schlittermann
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: Re: [exim] How does exim handle the case of changing smarthost DNS records?
Heiko Schlittermann <hs@???> (Mo 08 Jan 2007 23:28:17 CET):
> Marc Haber <mh+exim-users@???> (So 07 Jan 2007 23:41:01 CET):
> > On Sun, 7 Jan 2007 23:11:20 +0100, Heiko Schlittermann
> > <hs@???> wrote:
> > >Marc Haber <mh+exim-users@???> (So 07 Jan 2007 22:39:41 CET):
> > >> this message ends with a debug output from exim 4.63 (Debian)
> > >> delivering via a smarthost router (also quoted at the end) to a host
> > >> that requires authentication. Exim is configured to authenticate, and
> > >> does this most of the time. Other times, this is what happens:
> > >>
> > >> routed by smarthost router
> > >> host gmail-smtp.l.google.com [209.85.133.111] port=587
> > >> host gmail-smtp.l.google.com [209.85.133.109] port=587
> > >> <snip>
> > >> remote_smtp_smarthost transport entered
> > >> <snip>
> > >> Connecting to gmail-smtp.l.google.com [209.85.133.111]:587 ... connected
> > >> <snip>
> > >> 209.85.133.111 in hosts_require_auth? no (option unset)
> > >> <snip>
> > >> gethostbyname2 looked up these IP addresses:
> > >> name=gmail-smtp.l.google.com address=64.233.185.111
> > >> name=gmail-smtp.l.google.com address=64.233.185.109
> > >> 209.85.133.111 in hosts_try_auth? no (end of list)
> > >
> > >It tries to find 209.85.133.111 in the hosts_try_auth list,
> > >I suppose there's "smtp.gmail.com:..." (constructed from
> > >passwd.client).
> >
> > It is smtp.gmail.com, constructed from DCsmarthost after cutting off
> > everything behind the first colon. passwd.client is only an "exists"
> > condition which is meant to avoid trying to authenticate when no
> > password is present at all.
> >
> > >If I understand well, then exim does a A lookup for named entries in
> > >the host list (and smtp.gmail.com is currently 64.233.183.109), so the
> > >list looks as follows
> > >
> > >    hosts_try_auth = 64.233.183.109:...

> > >
> > >And this will not match the 209.85.133.111.
> >
> > Yes. Any idea how to fix this?
>
> Not yet.
> Below I'm just writing some thoughts, nothing new.
> (I'll stop here, my wife is about giving a birth and I don't want
> to miss it :-))
>
> > >And some other hint:
> > >--
> > >gethostbyname2(af=inet6) returned 3 (NO_RECOVERY)
> > >fully qualified name = gmail-smtp.l.google.com
> > >gethostbyname2 looked up these IP addresses:
> > > name=gmail-smtp.l.google.com address=209.85.133.111
> > > name=gmail-smtp.l.google.com address=209.85.133.109
> > >--
> > >gethostbyname2(af=inet6) returned 3 (NO_RECOVERY)
> > >gethostbyname2 looked up these IP addresses:
> > > name=gmail-smtp.l.google.com address=64.233.185.111
> > > name=gmail-smtp.l.google.com address=64.233.185.109
> > >
> > >
> > >Appearantly during your debug session the addresses changed.
> >
> > Yes. This happens frequently, according to the bug reporter. So I need
> > to build a way to make authentication work even when the smarthost
> > address changes during the run time of a delivery process.
>
> Hm. From the Spec(V.4.63, 30.2) I understand: the router passes the the
> list of host names and IPs of your smarthost (209.85.133.{111,109}) to
> the transport. During connection $host and $host_address contain the
> data for the current connection, these values are used for
> hosts_try_auth.
>
> "hosts_try_auth" is a host list. After expansion it is:
>
>     hosts_try_auth = smtp.gmail.com

>
> Exim will lookup smtp.gmail.com (and here it gets 64... in your example)
> and then compare the result with the host it's connected to.


Not tested (and modulo syntax errors) *could* do the trick:

    hosts_require_auth = ${if exists{CONFIG_DIR/passwd.client} \
        { ${lookup{$host}lsearch{CONFIG_DIR/passwd.client}{$host_address}} }\
        {} \
        }


(Or use hosts_try_auth because the hosts_require_auth isn't mentioned in
30.2 of the spec.)

*If* this option is evaluated for each transport/delivery attempt in
turn, it could work: if the $host (name) you try to connect to is in the
passwd.client file, than use the $host_address as value for the option.
The $host_address should come from the router (thus avoiding the extra
DNS lookup).


    Best regards from Dresden
    Viele Grüße aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann HS12-RIPE -----------------------------------------
 gnupg encrypted messages are welcome - key ID: 48D0359B ---------------
 gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2  7E92 EE4E AC98 48D0 359B -