Russell Nelson writes:
> Sam writes:
> > Are you really saying that it is now necessary to jump through hoops in
> > order to support Qmail on the back-end? Why should I figure out anything,
> > just for the sake of switching to Qmail? There's no need for me to figure
> > out how to make it easy. It's already easy: sendmail takes care of those
> > things for me, automatically.
>
> Nonsense. Sendmail makes a "90%" attempt at the job. When it expands
> aliases, it eliminates any duplicates it can detect. However, it can
> only detect alias expansions on the same host. Once you leave that
> host (for example when moving from the department workgroup server and
> going to the enterprise server), no attempt is made to suppress
> duplicate alias expansions.
Well, that's still 90% better than what Qmail does. And, with mailing
lists being managed in one place, that goes up to 100%. There is no
concept of a "workgroup" versus "enterprise" server. There are just a
bunch of honking servers, who all have the access to the same exact set of
monster alias files. I'm not sure, but the actual aliases may actually be
kept in NIS or LDAP, or they may be periodically updated from a central
server, but the point is that whichever server gets the mail, the server
has complete access to all mailing list aliases, and can completely expand
the recipient list all by itself.
Furthermore, the PHBs don't exactly have access to a shell server, where
they can install procmail recipes or forwarding. Even nobody in IT does
that because, frankly, there's no need to. Mail gets delivered to a
central IMAP server, and anyone can access their mailbox from any office,
so there's very little need for any forwarding.
> Sendmail also makes no attempt to delete duplicates caused by multiple
> SMTP deliveries. There is a small but nonzero period of time when a
> connection failure must result in a second delivery even though the
> first was successful. This is a well-known (although infrequent)
> problem which sendmail makes no attempt to solve.
>
> Eliminate-dups solves both of those problems.
Eliminate-dups is a solution in search of a problem. Duplicates due to
SMTP window failures are mostly theoretical than anything else. If you
have a flaky connection, you are likely to fail long before you get to this
point. I do not ever recall receiving a duplicate message that was traced
to this problem. The actual window of vulnerability is as small as you can
possibly get. Then, with your internal network having a pretty good track
record of stability, to calculate the actual probability of a duplicated
message, you'd have to go pretty far past the decimal point.
If anyone has ever logged a dupe, and confirmed that this was the reason
for it, please raise your hand.
I'm not comfortable with the notion that the way to eliminate duplicates
with 100% certainty is, first, to generate a whole bunch of them, and then
to eliminate them on the delivery end. Seems to be a bit wasteful to me.
eliminate-dups can also be argued to be a useful tool to eliminate
duplicate copies of reply-to-alls from your mailing list manages.
Yet, in actual practice, I found that to be a non-issue as well, as long as
you are already filtering your mailing list mail. It seems to me that when
you develop a need for something like that, you are probably already
filtering your mailing lists, and may not end up reading all of it.
I doubt I'm the only one who reads every message in every mailing list. I
usually flush 90% of everything straight into the trash. I actually
welcome a carbon copy that goes straight into my INBOX, instead of being
shuffled aside into the mailing list folder. If I feel the need to
respond, it helps me to go in and fish out the mailing list copy, and reply
to that too.
Yet, actually I tend to avoid doing that myself, when I reply. I think I'm
in the minority here, as far as that's concerned.
--
Sam
