Re: Bug#457318: qmail and related packages in NEW
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 <pape@smarden.org> 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.
Reply to: