[nycbug-talk] Curious about everyones thoughts on NDRs....
schmonz at schmonz.com
Wed Aug 29 13:36:00 EDT 2007
Miles Nordin wrote:
> (apparently Qmail's bloody-minded absolutist disregard for the ``rough
> consensus and working code'' model is causing a sizeable chunk of the
> backscatter problem. It has to be patched to not backscatter. Can
> you even distribute pre-patched binaries with that man's weird
This stuff is commonly misunderstood. qmail has no license. DJB's
thoughts on licenses:
There are restrictions on redistribution:
In short, no, you can't distribute patched binaries. But even if you
could, it'd be difficult to choose one SMTP-recipient-verification patch
that'd work for everyone. Most of the options are described here:
Sysadmins managing real-world mail installations are using packaging
systems anyway (or really, really ought to be). For qmail, pkgsrc
provides the badrcptto, qregex, and realrcptto patches as PKG_OPTIONS.
In my scenario, realrcptto keeps a whole lot of crap out of my system,
and a badrcptto clone blocks much of the rest.
> In my opinion, you should do all your spam checks, both
> list-of-recipient checks and even lengthy checks like spamassassin,
> while the remote MTA is still connected, and send a 5xx error if you
> think the mail is spam.
I send 5xx if the mail is "really really spammy" (above a certain
SpamAssassin score), otherwise it goes into the queue for local
delivery. My users and I still get messages that score somewhere between
"not spam" and "really really spammy", but not too many, and almost all
of it goes into Spam folders which are small enough to easily eyeball
Note that it's impossible to prevent all backscatter, because it's
impossible to know for sure whether an arbitrary local delivery is
supposed to succeed, because local delivery instructions are allowed to
be complex and unverifiable. But it's very possible to get backscatter
under control, and that's certainly a highly worthwhile goal for mail
administrators to pursue.
More information about the talk