On 2023-09-25, Greg Wooledge <g...@wooledge.org> wrote: > > The preferred policy nowadays is to perform all possible checks *during* > the initial SMTP conversation. If a message fails to meet acceptance > criteria for any reason, it should be rejected during that initial > conversation. Generating a bounce message almost always ends up sending > spam to an innocent third party address, which the malicious sender has > forged. > > How this relates to fetchmail and exim, specifically, I can't say. These > aren't tools I'm deeply familiar with. But if you can do it, try to > arrange it so that any message that can't be accepted gets dropped into > a black hole, rather than generating a bounce message. > >
I guess this is what you're alluding to? https://starcat.dp.ua/doc/exim4/FAQ-html/FAQ_7.html 7. POLICY CONTROLS Q0701: How do I block unwanted messages from outside my host? A0701: Exim uses Access Control Lists (ACLs) for controlling incoming mail from other hosts. A whole chapter in the reference manual is devoted to describing how they work. A wide variety of conditions can be imposed on incoming messages. The default Exim run time configuration contains an example of an ACL which blocks all relaying, and messages whose senders cannot be verified. This example is heavily commented and worth studying. Q0702: I don't want to block spam entirely; how can I inspect each message before deciding whether or not to deliver it? A0702: Wherever possible, inspection and rejection is best done automatically in an ACL, that is, before the message is accepted. If you want to verify manually each message that is classified as spam by an automatic check, you can arrange for a system filter to freeze such messages after they have been accepted. If, after inspection, you decide not to deliver the message, it is safest to discard it, using the -Mrm option. Use of the -Mg option to force a bounce carries the risk of “collateral spam” if the sender address is faked (as it usually is in spam).
