Hi,
host-blacklist file with these two entries:
insidersavings.com
*.abo.wanadoo.fr
with this acl line:
deny hosts = +ignore_unknown :
results in:
<much snippage>
no IP address found for host insidersavings.com (during SMTP
connection from (taken.nl)
[86.195.96.128])
insidersavings.com in dns_again_means_nonexist? no (option unset)
host in "+ignore_unknown :
/"? list match
deferred for /
deny: condition test deferred
451 Temporary local problem - please try later
LG: (taken.nl)
[86.195.96.128] F=<demaa (AT) taken (DOT) nltemporarily rejected RCPT
<dlugo (AT) cluestick (DOT) org>
removing insidersavings.com allows the hosts to match, correctly
rejecting the connection from the wanadoo ip.
Spec.txt says for +ignore_unknown: " If any item that follows
"+ignore_unknown" requires information that cannot be found, Exim
ignores that item and proceeds to the rest of the list."
Is this a bug in exim?

Dave Lugo wrote:
Hi,

host-blacklist file with these two entries:

insidersavings.com
*.abo.wanadoo.fr

with this acl line:

deny hosts = +ignore_unknown :

results in:

<much snippage>

no IP address found for host insidersavings.com (during SMTP
connection from (taken.nl)
[86.195.96.128])
insidersavings.com in dns_again_means_nonexist? no (option unset)
host in "+ignore_unknown :
/"? list match
deferred for /
deny: condition test deferred
451 Temporary local problem - please try later
LG: (taken.nl)
[86.195.96.128] F=<demaa (AT) taken (DOT) nltemporarily rejected RCPT
<dlugo (AT) cluestick (DOT) org>

removing insidersavings.com allows the hosts to match, correctly
rejecting the connection from the wanadoo ip.

Spec.txt says for +ignore_unknown: " If any item that follows
"+ignore_unknown" requires information that cannot be found, Exim
ignores that item and proceeds to the rest of the list."

Is this a bug in exim?

I read that section as being applicable to either pre-defined or inlined Exim
'hostlist' structures (only) - as:

' (at top level - they are not recognized in an indirected file)'

So, IMH, not a bug - just a limitation.

Bill

Mon, 29 Jan 2007, W B Hacker wrote:

I read that section as being applicable to either pre-defined or inlined Exim
'hostlist' structures (only) - as:

' (at top level - they are not recognized in an indirected file)'

So, IMH, not a bug - just a limitation.

I don't think so. Spec.txt also includes this example as legit:

accept hosts = +ignore_unknown : friend.example : \
192.168.4.5

So, I suspect that "indirected file", means something
like this:

accept hosts = some-file

where some-file looks like:

+ignore.unknown
1.2.3.0/24
*.example.com

Dave Lugo wrote:
Mon, 29 Jan 2007, W B Hacker wrote:
>I read that section as being applicable to either pre-defined or inlined Exim
>'hostlist' structures (only) - as:
>>
>' (at top level - they are not recognized in an indirected file)'
>>
>So, IMH, not a bug - just a limitation.
>>

I don't think so. Spec.txt also includes this example as legit:

accept hosts = +ignore_unknown : friend.example : \
192.168.4.5

ACK - but that's a 'continuation - not a file-name \192.168.4.5

Ergo an 'in place' hostlist structure (as opposed to a separately-defined
'named' hostlist.)

So, I suspect that "indirected file", means something
like this:

accept hosts = some-file

where some-file looks like:

+ignore.unknown
1.2.3.0/24
*.example.com

Probably so. But (at top level) may (also) take in the case where hte terms
precede the file.

In any case, it is easy enough to test.
Temporarily change your code to:

deny
hosts = +ignore_unknown : insidersavings.com : *.abo.wanadoo.fr
- and see if it makes the expected difference.

Bill

Mon, 29 Jan 2007, W B Hacker wrote:

deny
hosts = +ignore_unknown : insidersavings.com : *.abo.wanadoo.fr

- and see if it makes the expected difference.

It makes no difference. Whether +ignore_unknown is there, it fails
with insidersavings.com as part of the hostlist. +ignore_unknown
doesn't seem to have any effect.

I'm concerned, as this seems to imply that I can't reliably use
hostname patterns in reject list, without worrying about some dns
issue (either accidental or not) with a spammer's domain affecting
mail that has nothing to do with said spammer.

(this is with exim 4.63, by the way. I haven't yet checked newer
versions. May as well do that.)

Dave Lugo wrote:
Mon, 29 Jan 2007, W B Hacker wrote:
>deny
>hosts = +ignore_unknown : insidersavings.com : *.abo.wanadoo.fr
>>
>- and see if it makes the expected difference.
>>

It makes no difference. Whether +ignore_unknown is there, it fails
with insidersavings.com as part of the hostlist.

JFWIW, I get 'manual' (host -v) failure on *both* 'insidersavings.com' AND
'abo.wanadoo.fr' (haven't tried any further prefixes)

+ignore_unknown
doesn't seem to have any effect.

Per above, one may need an entry for each (beware MUA line-wrap):

hosts = +ignore_unknown : insidersavings.com : +ignore_unknown : *.abo.wanadoo.fr

I'm concerned, as this seems to imply that I can't reliably use
hostname patterns in reject list, without worrying about some dns
issue (either accidental or not) with a spammer's domain affecting
mail that has nothing to do with said spammer.

While further research seems appropriate w/r that feature, I have long used a
different approach entirely [1] so haven't needed it.

(this is with exim 4.63, by the way. I haven't yet checked newer
versions. May as well do that.)

Mix of 4.63, 4.65 here. But haven't tried the code in question yet on either.

Bill

[1] We structure block lists to NT D DNS or any other off-box callouts, i.e.
we don't use the 'hosts' structure for those at all - just an on-box search of
the most appropriate of Exim's available lookup types.

Why do a callout on 'known bad' entities?

Mon, 29 Jan 2007, W B Hacker wrote:

JFWIW, I get 'manual' (host -v) failure on *both* 'insidersavings.com'
AND 'abo.wanadoo.fr' (haven't tried any further prefixes)

abo.wanadoo.fr looks fine, it just doesn't itself have an IP, nor
does it appear to be a delegated subdomain.

+ignore_unknown
doesn't seem to have any effect.

Per above, one may need an entry for each (beware MUA line-wrap):

hosts = +ignore_unknown : insidersavings.com : +ignore_unknown : *.abo.wanadoo.fr

The docs are quite clear that once the option is specified, it remains
in force:

"Both "+include_unknown" and "+ignore_unknown" may appear in the same
list. The effect of each one lasts until the next, or until the end of the
list."

Why do a callout on 'known bad' entities?

Huh? I have a list of IPs and rDNS patterns I don't want to
accept mail from. It seems pretty normal that folks would want
to do that.

Dave Lugo wrote:
Mon, 29 Jan 2007, W B Hacker wrote:

>JFWIW, I get 'manual' (host -v) failure on *both* 'insidersavings.com'
>AND 'abo.wanadoo.fr' (haven't tried any further prefixes)

abo.wanadoo.fr looks fine, it just doesn't itself have an IP, nor
does it appear to be a delegated subdomain.

+ignore_unknown
doesn't seem to have any effect.
>Per above, one may need an entry for each (beware MUA line-wrap):
>>
>hosts = +ignore_unknown : insidersavings.com : +ignore_unknown : *.abo.wanadoo.fr
>>

The docs are quite clear that once the option is specified, it remains
in force:

No argument.

But *something* ain't right - or you would not be having the results you are.

More testing is needed - and/or PH pitching in with what the code expects to
happen. not.

Then perhaps some changes to the doc

IW - I am not (yet) clear as to whether it is 'bug' or spec anomaly.

"Both "+include_unknown" and "+ignore_unknown" may appear in the same
list. The effect of each one lasts until the next, or until the end of the
list."

>Why do a callout on 'known bad' entities?
>>

Huh? I have a list of IPs and rDNS patterns I don't want to
accept mail from. It seems pretty normal that folks would want
to do that.

Absolutely!

What I mean is - once they are known and stable - why take the time and
resources to check them, again, every time they arrive (or have expired from the
lookups cached) by DNS or RBL callout at all?

A simple match against a local list may not take all that much less in the way
of CPU cycles, but at least removes the external link delay and b/w consumption
of a callout. I suspect it keeps caches/hints DB a wee bit 'leaner' as well.

JM2CW,

Bill

We have a set of primary mail servers, let's call it A. We also have two
backup mail servers B and C (which should operate on the same MX
priority but a slightly different problem occurs even if they wouldn't).

Figure the case where a mail is to be delivered to a particular mail
server in the set A but that server is down so it is delivered to B
instead. B then tries to deliver to the primary server but it's still
down so it goes on in the MX priority and sends the mail to C insteads.
And here's where the loop begins I think, because C will then re-send it
to B won't it?

I haven't really seen this in action because our second backup mail
server isn't active yet. How do I configure the backup mail server to
only deliver mail to the end destination (which could be defined as the
highest MX priority (lowest MX value) for that domain).

Note that A isn't well-defined, it's a set of several primary mail
servers. Actually it's the set of every mail server that is defined as
the highest MX priority for every domain in relay_domains.

I'm sure there's a nice way to tackle this problem, I just don't know how.

Thanks,
Patrik

Hello,

Wed, Jan 31, 2007 at 09:25:52AM +0100, Patrik Jansson wrote:
We have a set of primary mail servers, let's call it A. We also have two
backup mail servers B and C (which should operate on the same MX
priority but a slightly different problem occurs even if they wouldn't).

Figure the case where a mail is to be delivered to a particular mail
server in the set A but that server is down so it is delivered to B
instead. B then tries to deliver to the primary server but it's still
down so it goes on in the MX priority and sends the mail to C insteads.
And here's where the loop begins I think, because C will then re-send it
to B won't it?

No, it won't, if the priorities are equal.

This behaviour is documented in chapter 17 of the fine manual:

<quote>
MX records that point to the local host, or to any host name that
matches hosts_treat_as_local, are discarded, together with any other
MX records of equal or lower priority.
</quote>

And please, don't steal threads.

Matthias Waffenschmidt wrote:
No, it won't, if the priorities are equal.

This behaviour is documented in chapter 17 of the fine manual:

<quote>
MX records that point to the local host, or to any host name that
matches hosts_treat_as_local, are discarded, together with any other
MX records of equal or lower priority.
</quote>

Thanks for the answer.

And please, don't steal threads.

Sorry, that wasn't my intention.

Best regards,
Patrik Jansson