A light has come on in my brain. Is this as simple as going into my ingress
node and adding "require verify = recipient/callout" somewhere sensible,
like right after "require verify = sender"?
On Mon, Jan 23, 2023 at 1:14 PM Jeremy Harris <jgh@???> wrote:
> 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
>
>
--
John Adams
Senior Linux/Middleware Administrator | Information Technology Services
+1-501-916-3010 | jxadams@??? |
http://ualr.edu/itservices
*UA Little Rock*
Reminder: IT Services will never ask for your password over the phone or
in an email. Always be suspicious of requests for personal information that
come via email, even from known contacts. For more information or to
report suspicious email, visit IT Security
<
http://ualr.edu/itservices/security/>.
