Hi, On Thu, Dec 04, 2008 at 11:05:31AM +0100, Florian Weimer wrote: > Out of curiosity, does netqmail fix at least the delayed bounce > problem?
no, or maybe: not yet; they gave notice of including that, but nothing happened yet http://marc.info/?l=qmail&m=120275739720434&w=2 On Thu, Dec 04, 2008 at 11:44:41AM +0200, Kalle Kivimaa wrote: > Gerrit Pape <[EMAIL PROTECTED]> writes: > > I've yet to be pointed to a grave or serious bug in the packages pending > > in NEW, otherwise I see no reason why they shouldn't be processed and > > pass NEW. I completely agree with this well written post > > Does the package in NEW fix the well known backscatter spam issue? I > tried searching for the fix in the package but unfortunately failed. Not the default install. The package includes a patch though, and builds and provides additional smtpd and qmtpd replacements that reject unknown addresses in the SMTP connection, they're trivial to enable. I personally use mailfront instead of qmail-smtpd. mailfront, already available in Debian/main, has this functionality and can also act perfectly as a replacement. > If it doesn't, then IMO, at this day and age, a MTA sending > backscatter spam doesn't belong to Debian. I understand that opinion, and almost share it, after all I've configured my servers that way too. I'd prefer to have that changed upstream in netqmail, but am not strictly opposed to making that change for Debian explicitly. Why 'almost share it'? Rejecting in the SMTP connection also plays into the hands of spammers. They have some resources available to blast out data of unsolicited mails. Once an SMTP server rejects a recipient before DATA, the SMTP client doesn't need to transmit the data, and can immediately switch to another recipient, using the resources more efficiently. The more SMTP servers reject on RCPT, the more moves the load to other SMTP servers. So it might well be that those SMTP servers, that accept mail regardless of the existence of the recipient mailbox, take load off your server's spam processing, because they eat spammer's resources. Concerning the delayed delivery notifications, there's an efficient way to immediately reject those in the SMTP connection, see http://lists.debian.org/debian-isp/2004/09/msg00080.html Finally, just as not supporting VRFY, not rejecting in the SMTP conversation makes it harder for the spammers to sort out bad recipient addresses, and so to use their resources even more efficiently. That not necessarily needs to be true; it's theory, but in my opinion it's worth thinking about. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
