Since many of these same issues have been discussed at one-time or other on LSTOWN-L, I thought that you would enjoy this compilation. Phil Agre is the author (see end for contact info). abstracted from T H E N E T W O R K O B S E R V E R VOLUME 2, NUMBER 1 JANUARY 1995 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: [log in to unmask]", 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". -------------------------------------------------------------------- Phil Agre, editor [log in to unmask] Department of Communication University of California, San Diego +1 (619) 534-6328 La Jolla, California 92093-0503 FAX 534-7315 USA -------------------------------------------------------------------- The Network Observer is distributed through the Red Rock Eater News Service. To subscribe to RRE, send a message to the RRE server, [log in to unmask], whose subject line reads "subscribe firstname lastname", for example "Subject: subscribe Jane Doe". For more information about the Red Rock Eater, send a message to that same address with a subject line of "help". For back issues etc, use a subject line of "archive send index". TNO is also on WWW at http://communication.ucsd.edu/pagre/tno.html -------------------------------------------------------------------- Copyright 1995 by the editor. You may forward this issue of The Network Observer electronically to anyone for any non-commercial purpose. Comments and suggestions are always appreciated. --------------------------------------------------------------------