Re: [exim] [Debian normal bug #296492] exim4: remote_smtp tr…

Hi,

* David Woodhouse [2005-02-27]:
> On Sun, 2005-02-27 at 00:06 +0100, Marc Haber wrote:
> >this is Debian Bug #296492, which I consider a bug with normal
> >severity from a Debian point of view.
> >
> >----- Forwarded message from Laurent Fousse <laurent@???> -----
> >
> >> When sending to a remote host that has both an ipv6 and ipv4 RR, exim
> >> falls back immediately to ipv4 when ipv6 connectivity is not present.
> >> I noticed however that exim is stuck to ipv6 when it's trying to send
> >> to a "fallback_host".
>
> Pleae define 'stuck to' in this context.

Subsequent retries do not seem to use the other RR (A record) for the
hosts, but are given up immediatly with "Network is unreachable". I
have the following example in my logfile (email addresses that are not
mine changed to protect the innocent) :

2005-01-31 18:48:16 1Cvfeq-0001dL-3J <= laurent@??? U=laurent P=local S=1675 id=20050131174815.GA6274@???
2005-01-31 18:48:25 1Cvfeq-0001dL-3J => foo@??? R=dnslookup T=remote_smtp H=cirse.extra.cea.fr [132.166.172.102]
2005-01-31 18:48:25 1Cvfeq-0001dL-3J nowwhat.lateralis.org [2001:838:300:2ab::2] : Network is unreachable
2005-01-31 18:48:25 1Cvfeq-0001dL-3J silence.lateralis.org [2001:960:2:452::2]: Network is unreachable
2005-01-31 18:48:25 1Cvfeq-0001dL-3J == bar@??? R=dnslookup T=remote_smtp defer (101): Network is unreachable
[...]
2005-01-31 19:15:38 1Cvfeq-0001dL-3J => bar@??? R=dnslookup T=remote_smtp H=macker.loria.fr [152.81.1.70]


The context is the following:

- I (laurent@???) am sending an email with two recipients
(foo@??? and bar@???). The first recipient gets the email
fine, but I get greylisted for the second. This information does
not appear in the logfile (I didn't cut anything from the log) but
you can trust me on this. I don't think the first successful
delivery is relevant as I've had the same problem with only one
recipient.
- line 3 and 4, you can see my exim trying to use my two
fallback_hosts (nowwhat.l.o and silence.l.o) which have both an A
and an AAAA record, failing on the AAAA record for lack of IPv6
connectivity. At this point, exim does not use the A record for any
of my fallback_host and delivery is deferred.
- Unfortunately, you don't see subsequent queue runs "stuck" on this
particular example because of the way greylisting works (the remote
smtp server accepts the next attempt) but I have seen it already. I
could dig my logfile to find an example, or try to recreate it
manually, but IIRC there's nothing more in the log than line 3 and
4 repeated for each queue run.

> Surely Exim should attempt to use all addresses in the RR set for the
> named fallback_host? Does it try only the first and then give up?

Exactly.

> If the first address returned from getaddrinfo() is the IPv6 address and
> you don't have a global IPv6 address of your own, then your resolver
> isn't conforming to RFC3484.

Although my laptop is on a LAN with private IPv4 address and no IPv6
address when the problem occurs, the dns server it uses is running on
another host on the LAN which has a global IPv6 address.

> Nevertheless, the failure to connect to the IPv6 address(es) should be
> fairly much instant, and we should fall back to the other address(es).
> Please could you describe the problem in more detail?

I'll try to provide more details if needed. I'll need to setup an
email address to always return a temporary failure to help testing, do
you have a simple way to do that? Maybe some procmail failure?

Laurent.