[exim] received_protocol during sender verification

Top Pagina
Delete this message
Reply to this message
Auteur: Phil Pennock
Datum:  
Aan: exim-users
Onderwerp: [exim] received_protocol during sender verification
Hi,

I have a gross workaround for the problem here, but I think that there
is a minor buglet in Exim not changing $received_protocol during the
routing test of sender verification.

We have some customers who, for reasons of heavy abuse, have bounces
rejected. We explain to them how bad this is. There aren't many such
customers and we're always very reluctant to add another.

We have a RCPT ACL with a clause "require verify = sender".

I strongly suspect, but am not going to go chasing, that in the Exim3
days the base sender_verify would only verify the domain. The problem
here is that verify=sender without callout _will_ verify the LHS if the
domain is local.

Whilst such customers will always have problems mailing to most places
using sender verification with callout, we don't want to be effectively
doing a callout for them. The neat solution would be to allow the
bounce if it's happening during callback verification but not during
normal address verification (so as to keep the rejection of bounces,
rather than blackholing -- I really do not want to ever blackhole what
can be rejected).

So conceptually, we want:
   condition = ${if and {{eq {$sender_address}{}}\
                   {!eq{$received_protocol}{local}}} {yes}{no}}


The problem here is that $received_protocol is not changed during
sender verification. I believe that since the message being routed
would have been generated locally, a proper routing test would set
$received_protocol, and perhaps the other flags too. Alternatively,
a global variable such as $verifying_sender which is only true during
such a test.

I do accept that this is a strange corner case, that anyone rejecting
bounces deserves problems and that there might be no desire to change
the current behaviour.

As a gross workaround, we just won't reject bounces if the connection
comes from our own smarthosts ...

Am I missing a cleaner way to do this?

And anyone saying "don't ever reject bounces" should propose an
alternative for cases where joe-jobs and the like cause hundreds of
thousands of inbound bounces per day.

Thanks,
-- 
Phil Pennock,       Senior Systems Administrator,      Demon Netherlands
NL Sales: +31 20 422 20 00      Thus Plc      NL Support: 0800 33 6666 8