Just one more brief question,
Besides the server that was a subject of previous mails in this thread -
I have two more servers that act as relays (secondary MX)
for the server we were discussing previously.
They have no local deliveries - only relaying.
Essentially everything is fine with them but I would like to ask your
opinion
if the thing I did is right and what the unforeseen consequences might be.
Since the change was implemented in amavis router the secondary servers
started building up queues of messages that were previously,
thanks to lack of checks, delivered straight to primary server.
Now since the messages for non-existent recipients were rejected by
primary -
they got stuck on the secondaries and they attempted to deliver bounce
messages
for them, or freeze them - since bounces didn't go through.
To avoid this - I modified the acl_check_rcpt to read
acl_check_rcpt:
accept hosts = :
deny local_parts = ^.*[@%!/|] : ^\\.
# MODIFIED PART
deny !verify = recipient/callout=2m,defer_ok
# END MODIFIED PART
accept local_parts = postmaster
domains = +local_domains
require verify = sender
accept domains = +local_domains
endpass
message = unknown user
verify = recipient/callout=2m,defer_ok
accept domains = +relay_to_domains
endpass
message = unrouteable address
verify = recipient
accept hosts = +relay_from_hosts
accept authenticated = *
deny message = relay not permitted
The servers behave as I would expect them to do.
The output from exim -d+all -bhc .... looks fine,
but still I would like opinion from somebody with a sharper eye / more
experience.
Thanks
Zlatko
On 2008-02-17 10:31, Graeme Fowler wrote:
> On Sun, 2008-02-17 at 09:37 +0000, Dave Evans wrote:
> > Add "no_verify" to that router. I think that'll fix it.
>
> Aye, it will. Ignore my suggestion, it was far too early on a Sunday for
> mentioning things to do with local parts and domains :)
>
> Much simpler to make the other routers do the verification work, rather
> than over-complicating the amavis router.
>
> I stick by my suggestion of dropping Amavis altogether, though. Fully
> synchronous SMTP-time filtering is far better.
>
> Graeme
>
>
>
--
