Philip Hazel wrote:
>> hostlist relay_from_hosts = host1@??? : host2@??? : host3@???
>
> Really? I presume you really mean host1.foo.bar1 etc...
Sorry, you're right, I meant host1.foo1.bar1 etc ...
>> This problem (bug?) does not appear with exim-4.11.
>
> I'm afraid I do not believe your last statement.
I have tested it on the same machine with the same configure
file and both exim versions. With exim-4.11 there is no error
message and host3 will be accepted, if host2 is not resolveable.
If I delete host3 from the list, exim-4.11 will not accept mails
anymore from host3. So the configuration is right.
If host2 ist resolveable, both exim versions deliver mails from
host3 to anywhere in the world. If host2 ist unresolveable,
exim-4.11 delivers mails from host3 without any error message,
exim-4.30 complains about host2 and will not accept any message
from host3.
Delivery of messages by host1 will always be accepted.
If you want, I can send you the log files of my test.
> It has always been the
> case that if Exim 4 cannot resolve something in a host list, it cannot
> proceed to scan the list further.
exim-4.11 does this job fine ;-)
In my opinion this is the only right behaviour. If any
DNS-server in the world failes to resolve host A, this failure
must not have any effect of the delivery of messages by host B.
> If you have name lookups or wildcarded host names and IP addresses in the same
> host list, you should normally put the IP addresses first. For example, in an
> ACL you could have:
>
> accept hosts = 10.9.8.7 : *.friend.example
In reality my hostlist contains more than 500 hosts - with more
than 200 different 2nd-level domains. The hostlist will be
automatically created by a DynDNS server - written by me.
The DynDNS user has the possibility to delete his host
temporarily from the DynDNS server - before he goes offline.
Should I always generate a new hostlist with only resolveable
hosts and send a SIGHUP to exim? This could happen very often -
more than once a second ;-)
> It then goes on to talk about the reverse lookup case, but the same
> thing applies if a forward lookup fails. I should (and will) make that
> clearer in the documentation.
Reverse lookup doesn't help me, because these names are
identifiers of the dialin ports of the provider.
Regards,
Frank
