[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FYI bouncemail complaint
The commentary enclosed below was recently posted to the comp.risks
news group. I thought it might be of interest to those of you
working on bigger and better versins of zmailer.
~Date: Mon, 16 Jan 1995 19:05:36 -0800
~From: Phil Agre <firstname.lastname@example.org>
[Excerpted with permission from Phil's The Network Observer]
Bouncemail top ten.
In running a large mailing list for the past year or so, I
have become acquainted with a depressing variety of dysfunctional
mail handling software. I've gathered here my top ten least
favorite phenomena in hopes that a Universal Union of Large List
Maintainers might spring up to force them to get fixed:
10. Mailers that give intermittent "user unknown" messages
for users who perfectly well exist, perhaps because they
cannot detect transient local network problems well enough
to postpone delivering mail.
9. The confusion over the Errors-To: field, which sure
seems like a good idea to me but which apparently is not
part of the standard. It is supported by most but not
all mailers. If it didn't exist then I'd have to run my
mailing list from a separate account.
8. Mailers that generate messages lacking well-formed
headers, most commonly addresses like "someone@local"
without proper domain information.
7. Mailers that tell me "Press F1 for help with VNM error
codes" even though my function keys are unlikely to be
programmed the same way as they are for users at the
site that generates the bouncemail message. In general,
mailers designed on the assumption that all senders and
recipients of messages would use that same mailer --
particularly when the mailer in question does not think in
terms of standard IP domain formats.
6. Mailers that complain that a certain message could not be
delivered but do not specify who in particular the message
could not be delivered to. Also, mailers that complain
that a forwarded message could not be delivered without
providing any indication of what address(es) the message
was forwarded from.
5. Vacation programs that respond to bulk or mailing-list
mail or that do not keep track of who they've replied to,
with the result that I get batches of spurious vacation
messages (sometimes in German) as each holiday approaches.
4. Mailers that generate mail that cannot be replied to.
Sometimes a message says "From: Fred_Q_Smith@foobar.com",
even though the user's account is actually called "fqs".
Sometimes I have no idea why I cannot reply to a message,
and the mailer offers me no help in figuring it out.
This is particularly annoying when the sender in question
starts sending further messages to the effect of, "you
should reply to my messages, you rude person!" It is
even more annoying when the machine that generated the
bogus message does not have a "postmaster" alias defined.
3. Mailers that take a month before giving up on the delivery
of messages to a missing user, whereupon they initiate
a monthlong stream of error messages, individually, for
every one of the messages I've sent in the last month.
2. Mail-reading programs that automatically generate a little
message to the effect of "so-and-so read your message
about "routine administrative notes" on December 3rd at
08:41" -- even when the message was sent to a mailing list
and not directly to the person reading it. The people
whose mail readers generate these messages are usually not
aware of them, and their site maintainers usually do not
know how to shut them off.
1. The astoundingly baroque and uninformative error messages
that I have gotten from the Novell mailer.
Of course errors happen. The basic point here is that the error
messages are so incomprehensible, so incomplete, so inconsistent,
and so difficult to adjust or control. The right way to do this,
in my view, would be for mailers to be talking to one another and
maintaining updated status tables for the process of delivering
(or not delivering) each message. A reasonable amount of useful
information could travel over these lines of communication, and
my mailer could consequently provide me with some significantly
more useful functionalities. Imagine a GUI interface with a
window showing the messages that got bounced, deferred, and so
forth. And imagine that I could just click on each one to say,
in one nice clean operation, "okay, let's just take this person
off the mailing list, send them a nice explanatory note in case
they're magically back on-line, and expunge from the system all
remaining traces of existing messages from me to them or error
messages from these mailers about them".