The difference between defer and deny in Exim

That sounds a bit "impolite" to "legitimate" invalid recipient deliveries (old addresses, typos, etc). But that's not the biggest problem, in my opinion.

You're really doing yourself a disservice by dropping those connections -- now, rather than just having the sending MTA (legitimate or otherwise) fire all it's addresses at you in one hit and get a Yay/Nay on each quickly, you're going to have it connect, get a bunch of Yays, then when it gets a Nay it'll have to reconnect, HELO/FROM/etc, go through all the Yays it did last time, get to the next Nay, get dropped... basically, for a recipient list with N failed recipients, you're going to get N+1 connections rather than 1. For a legitimate server, not such a big deal, but for a spammer with a large number of invalid recipients... ugh.

If you think that a spammer will give up if it gets an invalid address, you're in for a big shock. They're the most persistent buggers out there, hammering away incessantly regardless of how many times they get dropped.

Of course, neither dropping or denying will work for spammers who retry on 5xx errors... for them, a tarpit or detect the source IP and 3xx the initial connection are the only options. Or shooting. I prefer shooting.

From the bat book:

In a non-set-user-id root world, sendmail runs under two guises. In one guise, it is run by root to function as a listening daemon. This listening daemon is just like the listening daemon of earlier versions, except that, instead of running as root no matter who ran it, it now runs as root only if root runs it.

In its second guise, sendmail runs as an ordinary user to collect locally submitted messages. In this mode of operation, sendmail is set-group-id to a special group, so it runs in that group no matter who runs it. That group owns and has write permission to a separate queue into which locally submitted deferred messages are placed.