On 23/01/2023 18:36, Johnnie W Adams wrote:
> On Fri, Jan 20, 2023 at 3:12 PM Jeremy Harris via Exim-users <
> exim-users@???> wrote:
>
>> On 20/01/2023 19:50, Johnnie W Adams via Exim-users wrote:
>> An R-verify checks routability, and (with callout) acceptability
>> by the destination. If your intent is to discover nonexistent
>> recipients *during SMTP reception* of a message, so that
>> you can reject at SMTP time and thereby not have to generate
>> a bounce - then yes, it'll do that. But you should be
>> doing this check in your rcpt ACL, and it'll only cover
>> messages *you* receive using SMTP (as opposed to cmdline/stdin).
>>
>
> I'm okay with that limitation.
>
> What I'm unclear on is the full consequences of doing this on our egress
> node rather than our ingress node. It seems to me--but I could be
> wrong!--the worst that can happen is that the mail passes through our
> ingress node, is refused at our egress node, and our ingress node has to
> pass that failure back where it came from. What am I missing?
You're not.
If your overall system, with these two separated nodes. is forwarding
external-source messages out to somewhere else, that's what'll happen
if you R-verify on the last of your nodes.
If there's no other nodes on the path between your "ingress" and
"egress", and if the ingress is Exim, you can do something called
"cutthrough routing" to still avoid the bounce-generation. This
turns your ingress from traditional store-and-forward mode to
a realtime forwarder, and means that a response from the egress
can be passed right back to the message source while the source-ingress
SMTP connection is active.
You can decide when to cutthrough on a per-message basis; it's an ACL
control.
Or, probably at the cost of more knowledge needed there, you could
just arrange this verification in the ingress node.
>> Also, if done for message-submission receptions by you
>> it will upset many MUAs (which have little notion that
>> a message being rejected is a thing, it seems).
>> So if that was your hope, you're onto a loser.
>
>
> Our egress node should Never accept mail from an MUA, so that would not
> worry me in the configuration I'm thinking of, but if the check must be
> made at the ingress node, that would mean (I assume) I'd have to write a
> more complicated ACL, because it does accept mail from MUAs.
Yes. It commonly suffices to condition your ACL paths by $recieved_port -
25 vs. everything else, the latter being your MUA clients. But situations
differ.
> On looking again, I see that I need to put "acl_smtp_vrfy = acl_check_vrfy"
> in my main configuration settings to use acl_check_vrfy in the begin acl:
> section.
Almost certainly not. acl_smtp_vrfy deals with the SMTP VRFY command,
which is not what we're dealing with here despite the naming (it's also
pretty much obsolete. Nobody uses it; most sites refuse to answer it).
You probably want this action being done in your RCPT-time acl. If it's
just a single verb, with a couple of conditions, put it inline.
[ ACL is a programming language. With subroutines. You don't have
to use them, but once you're doing something complicated... ]
--
Cheers,
Jeremy
