I've got everything working adequately, but the perfectionist in me has 
one small niggle.

When receiving SMTP mail from the great wide world. Invalid users in 
valid domains get rejected with 'unrouteable address;'  EVEN WHEN THEY 
SHOULD BE BLOCKED BY SPAMHAUS.

The spamhaus rejection only happens if the recipient is in fact, valid.

Now at one level I don't care. The spam is getting junked.

But is there any way to reverse the check order so that Exim tests spam 
by IP first, before applying the router?

On Tuesday, February 28th, 2012 at 19:58:34h +0000, The Natural Philosopher wrote:

> But is there any way to reverse the check order so that Exim tests spam 
> by IP first, before applying the router?

I have not used spamhaus so do not know the details and can only
suggest the following.

The configuration files in /etc/exim4/conf.d/acl are numbered, so it
should be the case that if you put a rule in a file numbered before
the spamhaus filtering to reject invalid users whether it was spam
or not then that would take care of the problem.

Otherwise if you only want to reject invalid user when it is spam,
you have to let spamhaus do its filtering in order to identify it
as spam and thus rejection of the basis of invalid user would have
to be added to the spamhaus configuration its-self.

If this answer is not satisfactory, then you need to ask your
question on the Exim4 mailing lists (or forum if one exists).

The Natural Philosopher <tnp@invalid.invalid> wrote:
> When receiving SMTP mail from the great wide world. Invalid users in 
> valid domains get rejected with 'unrouteable address;'  EVEN WHEN THEY 
> SHOULD BE BLOCKED BY SPAMHAUS.

Spamhaus doesn't block email. Your configuration appears to do so. I
haven't yet seen an out-of-the-box Debian installation of Exim4 that
blocks email based on DNS BLs.

Here are some suggestions. In the ACLs section you'll find this:

  require
    verify = recipient

This is the bit that bounces unknown users. If you wander down the
file(s) a little more you'll find this section. Or at least you would
in the stock configuration:

  .ifdef CHECK_RCPT_IP_DNSBLS
  warn
    message = X-Warning: $sender_host_address is listed at $dnslist_domain ($dnslist_value: $dnslist_text)
    log_message = ...
    dnslists = ...
  .endif

and another one starting with this:

  .ifdef CHECK_RCPT_DOMAIN_DNSBLS
  warn
    mesasge = X-Warning: ...
    ...
  .endif


If you moved these higher up, you'd get warnings created for deliverable
messages before you determined you were going to reject them. Since you're
not running the standard installation (or at least, not one I've seen)
I cannot help you further without additional information. Hopefully this
will get you started, though.


Oh. You'll have chosen "One big file or many little files" when
configuring Debian's Exim. If the answer was one file, you need to
look in /etc/exim4/exim4.conf.template. Otherwise the files will be
under /etc/exim4/conf.d/acl. If you're not sure, rerun dpkg-reconfigure
exim4-config. When you've edited the ACLs, run update-exim4.conf and
then invoke-rc.d exim4 restart.

Chris

Chris Davies wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> When receiving SMTP mail from the great wide world. Invalid users in 
>> valid domains get rejected with 'unrouteable address;'  EVEN WHEN THEY 
>> SHOULD BE BLOCKED BY SPAMHAUS.
> 
> Spamhaus doesn't block email. Your configuration appears to do so. I
> haven't yet seen an out-of-the-box Debian installation of Exim4 that
> blocks email based on DNS BLs.
> 
> Here are some suggestions. In the ACLs section you'll find this:
> 
>   require
>     verify = recipient
> 
> This is the bit that bounces unknown users. If you wander down the
> file(s) a little more you'll find this section. Or at least you would
> in the stock configuration:
> 
>   .ifdef CHECK_RCPT_IP_DNSBLS
>   warn
>     message = X-Warning: $sender_host_address is listed at $dnslist_domain ($dnslist_value: $dnslist_text)
>     log_message = ...
>     dnslists = ...
>   .endif
> 
> and another one starting with this:
> 
>   .ifdef CHECK_RCPT_DOMAIN_DNSBLS
>   warn
>     mesasge = X-Warning: ...
>     ...
>   .endif
> 
> 
> If you moved these higher up, you'd get warnings created for deliverable
> messages before you determined you were going to reject them.

Ok so the key principle is that exim reads AND EXECUTES THE COMMANDS IN 
the file(s) in ORDER ...

and that verify=recipient is the line to look for.


  Since you're
> not running the standard installation (or at least, not one I've seen)
> I cannot help you further without additional information. Hopefully this
> will get you started, though.
> 
> 

I think it should see me to the end actually

> Oh. You'll have chosen "One big file or many little files" when
> configuring Debian's Exim. If the answer was one file, you need to
> look in /etc/exim4/exim4.conf.template. Otherwise the files will be
> under /etc/exim4/conf.d/acl. If you're not sure, rerun dpkg-reconfigure
> exim4-config. When you've edited the ACLs, run update-exim4.conf and
> then invoke-rc.d exim4 restart.
> 

one big file. No big deal

Except I have to sort out what each section now does to get the order 
right :-)

> Chris

The Natural Philosopher <tnp@invalid.invalid> wrote:
> Chris Davies wrote:
>> Hopefully this will get you started, though.

> I think it should see me to the end actually

Oh good!


> Except I have to sort out what each section now does to get the order 
> right :-)

Do come back here if you get stuck (I'm sure you would!). I'll see what
I can do and maybe others can throw in hints and tips.

Within the ACL section, each "block" is started with a very such as
{ reject, accept, deny, warn } and the following statements get ANDed
together. Some of the statements have side effects - such as the "add
a warning" condition. Mostly, though, I think you'll find it not as
frightening as you might have first thought.

Chris

Chris Davies wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> Chris Davies wrote:
>>> Hopefully this will get you started, though.
> 
>> I think it should see me to the end actually
> 
> Oh good!
> 
> 
>> Except I have to sort out what each section now does to get the order 
>> right :-)
> 
> Do come back here if you get stuck (I'm sure you would!). I'll see what
> I can do and maybe others can throw in hints and tips.
> 
> Within the ACL section, each "block" is started with a very such as
> { reject, accept, deny, warn } and the following statements get ANDed
> together. Some of the statements have side effects - such as the "add
> a warning" condition. Mostly, though, I think you'll find it not as
> frightening as you might have first thought.
> 
> Chris

yes. The thimg is that it seems I may have to move whole blocks around, 
and its now my main mail server...

looks like 4am Sunday to check it out..

The long dark test time of the IT managers soul..


-- 
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

The Natural Philosopher <tnp@invalid.invalid> wrote:
> looks like 4am Sunday to check it out..

One option to mitigate the early start is to change and update the
configuration, but not do the restart. You can then talk SMTP at it
(from the command line) in test mode; this allows you to specify a
particular source IP address and to control the entire conversation. For
example this command will check exim4 accepts email from a client on my
internal network:

  exim4 -bh 192.168.130.96 -C /var/lib/exim4/config.autogenerated

I presume you can "do" SMTP by hand.

Chris
-- 
(Also available for consultancy. Email me)

Chris Davies wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> looks like 4am Sunday to check it out..
> 
> One option to mitigate the early start is to change and update the
> configuration, but not do the restart. You can then talk SMTP at it
> (from the command line) in test mode; this allows you to specify a
> particular source IP address and to control the entire conversation. For
> example this command will check exim4 accepts email from a client on my
> internal network:
> 
>   exim4 -bh 192.168.130.96 -C /var/lib/exim4/config.autogenerated
> 
> I presume you can "do" SMTP by hand.
> 
> Chris

Good call chris. I didn't know you could do that.
SMRP by hand no problem.

-- 
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.