Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Toni Mueller <toni@debian.org>]

Hi,

On Mon, 24.12.2007 at 07:29:58 +0100, Turbo Fredriksson <turbo@debian.org> wrote:
> - all that send receipt on acceptance/delivery, reject at SMTP etc (and
> claims that this makes Qmail wide open for spams is rubish - it's only
> if/when configured incorrectly that this becomes a problem) shouldn't

this I can't agree with. Stock qmail (which I don't advocate) accepts
all mails sent to one of the domains it is configured to accept mails
for ("locals" etc), and decides to bounce mails it can't deliver later.
This causes significant backscatter for the typical

random1@debian.org -> blurqwoeiuy@bayour.com

junk mail that imho accounts for well over 50% of all spam. This can,
and is (was) used to send spam in the past, albeit in the form of
bounce messages, and when I was running stock qmail this way, I had
hundreds of undeliverable mails sitting in my queue because of that.
After I switched to qmail-ldap and turning RCPTCHECK on (a few years
ago), this wave was extinguished because I now don't accept mails that
are undeliverable.

> be done by an MTA (it isn't in the SMTP RFC that I know of).

What has this to do with RFCs? I didn't see any particular statement
demanding that mails to unknown recipients have to be accepted or
rejected.

> > featureless, and trivially replaced with things
> > that do respect the FHS are IMHO more important.

That's quite untrue, imho. It's not trivial to replace qmail, imho, and
while we are at it, I also consider the slashpackage a much better
"standard" than the FHS anyway (although qmail doesn't follow it,
either). And then qmail-ldap imho at least used to have a better
feature set and better documentation than Postfix (didn't check
recently), or otherwise I'd probably switched.


Best,
--Toni++