Re: [Exim] ACL verify=sender

On Mon, 2004-01-05 at 17:35 +0000, Tony Finch wrote:
> However the feature is troublesome from an architectural point of view
> (Philip wants to keep reception and delivery more separate than this)

That I can understand :)

> and w.r.t. how it fits in with local_scan() and the system filter

'Another tricky aspect of this feature is that an early delivery happens
before the local_scan() function and the system filter are run.'

Why so? I was thinking of doing it after DATA...\r\n.\r\n is received by
the relaying host, but before returning a response to the DATA command.
That's when local_scan() is run already, isn't it? Not sure about the
system filter.

> wary to use it between systems that aren't tightly
> coupled (such as a departmental email server and our central email
> relays).

Indeed. But that's part of why I want suggesting it -- so that
_differences_ in content checking policies don't cause double-bounces.
In my case, the machines _are_ tightly coupled. Everything runs exactly
the same config, even my home dialup machine (at least the real Exim on
IPv6, not the one which accepts incoming mail from Demon on IPv4). For
the majority of my users, their mailboxes reside on an ancient dual-P200
machine and I keep its SpamAssassin load down just by making its primary
MX record IPv6-only, and letting it trust the IPv4 MX backups to have
already done the SpamAssassin checks. So all I actually need is the
recipient verification callouts.

I can certainly see some justification for the kind of setup you've
documented in the case of a relay which permanently sits in front of
another mail host, though.

Just how difficult _is_ this to achieve, architecturally? That's a
genuine question not a rhetorical one -- my knowledge of the internals
of Exim isn't that great.

We already put the mail into the spool file before returning OK to the
DATA command, and we fork a process to deliver it.... how hard to sleep
and delay the final ACK until the delivery has been attempted?

--
dwmw2