On 11/30/01 9:06 AM, "John R Levine" <[EMAIL PROTECTED]> wrote:

> It turns out that individual deliveries take more bits but paradoxically
> are actually faster on all but the most overloaded networks due to the
> increased parallelism.  That's not an important consideration unless
> you're running a huge list on a 28.8K modem which I hope nobody does any
> more.

I actually sat down and built a mathematical model of this once, since we're
planning on upgrading our systems to do just this. Basically, you (at the
minimum) double your network bandwidth usage. Depending on how you had your
list server configured before, you could double it again.

As John says, unless your list server is already heavily optimized for
parallel delivery or your network pipes are full, it'll mostly come out in
the wash. 

When you do this, if you do this, you'll put a higher load on your network,
and a significantly higher load on your disk -- I keep finding that disk I/O
is a much bigger issue for fast mail delivery than anything, even after I
"fix" it. It seems to be THE bottleneck unless you've written a  no-disk MTA
(and if you have, I bow to you..).

These imply that you'll need to more carefully tune your system to handle
the load. And if you stress your disks, it'll slow down more than you'd
expect. Those are the mines out in the minefield.

> Nonetheless, I think that putting the individual recipient's address in
> the To: line is a pretty bad idea.

And I disagree, strongly. With the growing population base of technically
na�ve internet people, combined with the proliferation of people having
multiple e-mail addresses (or owning entire domain names where all addresses
are valid), combined with a continuing wave of mass domain-name renamings
(like uswest.net -> qwest.net, and the slow train-accident known as home.com
that's going on right now), the issue of subscribers who simply have no clue
what address is subscribed is becoming more and more of a problem. And these
are users who don't know about the techie details, don't care, and just want
stuff fixed. 

Disk is pretty cheap, network is pretty cheap, good user experiences are
really important. By moving the subscribed address into the "To:" line, you
clean up a huge percentage of these problems, and make life a lot easier for
both the subscribers and admins, because everyone can stop guessing.

>  Many PC mail programs have weak
> filtering features and can't filter on arbitrary headers,

Which is exactly why the answer isn't "put a X-subscribed-address" header
into it at the MTA level, too.

I think there are times when I'm right, and times when John's right. Smaller
lists, more technical/experienced subscriber populations, don't need this as
much. If (like mailman does) you send out monthly subscriber-status notices,
it's less of an issue (but still an issue). But as your lists get larger, as
you move from discussion to announce to enewsletter to e-marketing type
mailings, and as your population gets less technical -- I think this stuff
becomes more crucial. The lack of having that "to" line filled out is the
cause of the vast majority of our support interventions these days, and most
of them are because you have a user who used to be [EMAIL PROTECTED] who didn't
realize he's now [EMAIL PROTECTED], or he signed up as [EMAIL PROTECTED] and is
trying to unsubscribe as [EMAIL PROTECTED], or they subscribed via some
hotlink address that forwards to their yahoo.com address that forwards to
their college address, which they forgot still forwards to their home.com
address, because it was supposed to go away six months ago (but didn't).

And in their eyes, these technical details aren't things they ought to have
to worry about. And frankly, I tend (most of the time) to agree with them.
So I see it as crucial to clean stuff up so they don't have to. It'll cost
programmer time, network bandwidth, and I'll have to worry about the I/O
issues, at least until I decide to write that "from my database to your MTA"
direct delivery tool, but for me, making it easy for the user is a lot more
important than making it easier for me or my computers....

FWIW.

Chuq



Reply via email to