[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 <pagre@weber.ucsd.edu>
~Subject: Bouncemail

     [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".