On 23/01/2023 18:36, Johnnie W Adams wrote:
On Fri, Jan 20, 2023 at 3:12 PM Jeremy Harris via Exim-users <
[email protected]> 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
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
