Mailing List Archive

On 6 Mar 1997, Russell Nelson wrote:

> Hmmm.... Interesting. I wonder if VERP, in conjunction with a bounce
> manager (never pass up a chance to mention your own software, even if
> it available from http://www.qmail.org for free :), actually *reduces*
> the amount of bandwidth because it greatly lowers the cost of
> eliminating bad addresses promptly.

I think that unless you're bouncing more than you're delivering, qmail
will always take more bandwidth. However, by removing the bounces on a
sendmail system you're significantly reducing the time to deliver and the
time that your system is doing heavy crunching. Remember that while it's
crunching, it is also receiving back all those bounces, which is just
compounding the problem.

qmail doesn't crunch to begin with, it solves the bounce problem, solves
the SPAM relaying problem, doesn't have gaping security holes solves the
mbox-format problem (via Maildir), delivers my 40K user list 3 times
faster than sendmail, is more logical to use and configure, etc., etc.
And for that, its only major "fault" is that it sucks more bandwidth,
roughly equal to a load that websurfers would put on your link.

If your bandwidth is so tight that qmail would cause visible performance
problems, then I would say that qmail isn't the problem to begin with.
Whether or not you're running qmail, you should be sending your mail out
in compressed batches via BSMTP (which, btw, qmail does very nicely).

Evan

Greg Wooledge:
> Greg> Older (vendor, v5) versions of sendmail open parallel
> connections. Greg> Sendmail v8 uses connection caching (with a
> configurable number of Greg> simultaneous outgoing open
> connections). This is extremely useful in Greg> certain special
> situations (e.g., one mail gateway talking to another Greg> mail
> gateway) in which a significant number of messages are delivered
> Greg> to the same host in a short period of time.

David Blacka:
> This is definitely true in my special situation... I am using qmail
> to replace a smap/sendmail configuration (which is does very well)
> and thus, *all* remote deliveries are to the same machine.

Set concurrency-remote to something that machine can reasonably deal
with (e.g. 5).

--
Raul

Russell Nelson <nelson@crynwr.com> writes on 5 March 1997 at 22:15:20 -0000

> The only time single-rcpt matters is on a mailing list. Individual
> messages only ever go to a handful of addresses. VERP requires
> single-rcpt. It's VERP that saves the administrator's time, and it
> saves that time with every bounce message that is handled
> automatically.

Except that most mailing list handlers do automatic bounce handling
without VERP. It's not quite as reliable; I probably see one bounce
message out of each several hundred for manual handling with
SmartList.

The comparison should not be between VERP and completely manual bounce
handling, but between VERP and the level of automatic bounce handling
commonly found in today's mailing list managers.

Evan Champion <evanc@synapse.net> writes on 6 March 1997 at 10:13:37 -0500

> I just want to put in my thumbs-up on VERP. I run a 40K user mailing
> list, and in the first day of running on qmail with VERP I was able to
> remove 2000 dead addresses. With all the bizarre error formats out
> there, I always sent errors to /dev/null; with VERP, I can easily take
> care of them.

Using what mailing list software? And, specifically, does it
implement any non-VERP automation of bounce handling such as SmartList
and Majordomo do? I'm trying to determine if your results indicate
how much better VERP is than *nothing*, or how much better VERP is
than your particular mailing list manager's automatic bounce handling.

> OK, help me understand. What is it exactly that pisses people off?
> That Dan doesn't fall all over himself trying to add every requested
> ``feature'' to qmail? That qmail development isn't democratic? That

That the canonical reaction to a feature request is "no, this will not
be done, kluge up a way around it and leave us alone." For _every_
feature request from the start, see below.

> qmail isn't the best MTA for every situation?

Perhaps the documentation should stop claiming so ;-)

> I don't remember seeing a good description of such a filter. Where
> would it go? How would it be configured?

control/filters:
.brzzl.com:/var/qmail/bin/fixsender

> Fine, it's an issue. What do you think we should do about it:
> 2) Realize that it's inconsistent with qmail's design and philosophy
> and shouldn't be added to qmail.

Document why it's inconsistent with qmail's design and realize why
sonething should be done about it though.

This may sound like a contradiction, but it's just as hard to convince
people who pay their network connection by the byte that they should
accept qmail's behavior like it is to convince Dan that it should be
changed...

> The current approach seems to be (1), which I think has essentially no
> chance of succeeding and is tiresome to long-time members of the list.

The SIGHUP and SIGALRM handlers were added too, after this relatively
small issue had been beaten to death here more than enough...
That such FAQs come up every week shouws just that there is a demand
for it.

olaf

> Given that a number of gateways ignore RFC821, it'll be decades before
> everyone implements RFC1894 (DSN). In the meantime, VERP works, and

...except for the cases of gateways who ignore envelope sender
addresses. There are still enough of them. :-(

olaf

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 7 Mar 1997, Olaf Titz wrote:

> > OK, help me understand. What is it exactly that pisses people off?
> > That Dan doesn't fall all over himself trying to add every requested
> > ``feature'' to qmail? That qmail development isn't democratic? That
>
> That the canonical reaction to a feature request is "no, this will not
> be done, kluge up a way around it and leave us alone." For _every_
> feature request from the start, see below.

my 2p here: look, you have the source, Dan might have a life. one of you
desparately wants the feature, the other might want a night in front of
the tv. One of you has an incentive to add the code, the other has an
incentive to get a beer.

okay, Dan doesn't appear to know the word comment, and some of the
modifications I've tried locally consist of documenting the code, then
figuring out where the patch goes.

write the patch, make it available and if it's good enough dan might deign
to add it

RjL
+----------------------------+
| richard@illuin.demon.co.uk | Aut viam inveniam aut faciam
+----------------------------+

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBMyCP7J6bDk8vHTn1AQEGbAP9HvZm648KT653NKrxeBUehY3Y46wLniNr
Z/+7KYjYZSibR/SXmUYYt/UE4ZEz/BdzIS+vQHlRIX3WqFRYSA7Ww2ZtpqtYYoC4
hzYyqgPHVYZWSq+kH5FsO8XHFZJhJVnY2YrgRJ4eXe3UqK1/ds64zPOAJTLCbcyL
QjM/lKcd+z4=
=6Ekx
-----END PGP SIGNATURE-----

Olaf Titz <olaf@bigred.inka.de> writes:
>
>That the canonical reaction to a feature request is "no, this will not
>be done, kluge up a way around it and leave us alone." For _every_
>feature request from the start, see below.
>

That's not completely true, Olaf. It is true for qmail behavior that
depends on fundamental design decisions, but not to other things.

Back in September or October when Dan first developed the qmail-users
mechanism, I suggested a couple of changes and Dan implemented them
without any argument. I asked for an easy way to add/delete entries
in the assign file that weren't built from /etc/passwd. Dan asked
what I needed it for, and after I explained how I'm running my site's
virtual domains, he created the append file. I mentioned I was
susceptible to typing the wrong thing because of the similarities
between the names of the qmail-pw2users program and the users subdir.
Dan changed the program to qmail-pw2u.

Those items were certainly far more trivial to change than parallel
deliveries, multiple RCPTs, and retry algorithms. I'm not saying
they're equivalent. I'm saying that Dan has implemented changes
without the kind of argument you're complaining about above.

I like to think he was so cooperative because I didn't attempt to
pressure him to make the changes. I simply mentioned my difficulties,
explained my real-life situation when asked, and made it clear in
my responses that I wasn't going to throw a fit if the answer was
"No". That's in stark contrast to most of the other feature requests
I've seen on this list.


I'm not defending the ways qmail proponents respond to requests
for change. I, too, dislike a lot of what I've seen. I'm pointing
out that Dan has not resisted some requests the way you've been
saying he does.

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

> openning multiple
> connections like this is very bad for the core of the network.

Nonsense. The core of the network doesn't take the slightest notice of
your tiny bumps in traffic. You might be able to overload your local
router if you have dozens of mailing list machines running full blast,
but in the real world you would have succumbed to HTTP months earlier.

Practically every outage is caused by the hosts, not by the network.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html