|I figure that each list owner can absorb the tasks as part of his/her
|routine workload, but that a new position of "postmaster" might be required
|to manage the software (list creation, archiving, etc.). With those figures,
|how many hours *per week* would be needed for postmaster duties in 1998,
|1999, and 2000?
Don't confuse LISTSERV administrator with POSTMASTER. They can (and
sometimes should) be separate and distinct tasks.
POSTMASTER tasks relate to the operation of SMTP Servers and clients,
possibly regardless of what cient generated the mail e.g., LISTSERV.
Your answer is "it depends"
You aren't really going to get your "answers," just other people's
additional questions and their particular answers which is a function of
unquantifiable results.
Here is some other info that relates to proper mail delivery.
Date: Sun, 19 Feb 1995 09:47:00 EST
From: "Peter M. Weiss +1 814 863 1843" <[log in to unmask]>
Subject: Re: How to test if a server is down?
In-Reply-To: NATHAN AT LSOFT.COM -- Sat, 18 Feb 1995 16:20:06 EST
>On Sat, 18 Feb 1995 14:10:08 -0600 Natalie Maynor said:
>>> I'd like to learn how to checkout what is and isn't down so I can
>>> intelligently answer the queries I am getting.
When you ask about the "server being down" I believe you are really
asking about end-to-end transmission. What constitutes E-2-E xmission?
Here's a first pass (in no particular order):
telecom links (usually provisioned by the telephone company incl.
long distance (IXC) and local operating companies (LEC) (and
of course overseas circuits)
routers that xmit IP packets (the atomic unit of the Internet)
store-and-forward hosts such as those commonly found on bitnet
e.g., UGA, PSUVM, SEARN (they need not be listserv hosts)
availability of authoritative hosts for the domain name system
(these guys translate host names to IP address or to other
mail exchangers (MX) e.g., NETCOM.COM has 16 MX hosts that
can exchange i.e., receive mail
mail exchangers (MX) on the Internet
correctly configured RSCS (NJE), MAILER, LISTSERV, SENDMAIL software
correctly configured mail file systems with sufficient disk-space
for the user
sufficient bandwidth of telecom links
sufficient horsepower (CPU and disk) of sending/intermediate/receiving
sites
Sometimes in trouble shooting, we find that the current configuration is
NOW correct, but in the recent past there was a problem or change and
that residual obsolete info STILL exists at intermediate sites pending a
"timeout" of the cached info.
There are plenty of samples of trouble shooting that have been
broadcasted to LSTOWN-L and NODEINFO from such experts as Melvin Klassen
(from whom I've learned alot).
Tools such and various inquiries of RSCS, MAILER, SMTP, DNS (DiG or
NSLOOKUP), LISTSERV (DISTRIBUTE MAIL DEBUG=YES wrt REVIEW list) are
used. Sometimes they require you to be on that network: it might be
impossible to inquiry of an RSCS Q from an Internet host.
IMO, understanding "all" of this forms a career path.
-- co-owner INFOSYS, TQM-L, CPARK-L, ERAPPA-L, JANITORS, LDBASE-L, et -L
[log in to unmask] "Hot MIPS sink CHIPS" +1 814 863 1843
31 Shields Bldg. -- Penn State Univ -- University Park, PA 16802-1202 USA
Date: Mon, 19 Jun 1995 16:09:00 EDT
x-Reply-To: LISTSERV list owners' forum <[log in to unmask]>
x-Sender: LISTSERV list owners' forum <[log in to unmask]>
From: "Peter M. Weiss +1 814 863 1843" <[log in to unmask]>
Subject: Overview: Electronic Mail Delivery
Comments: To: [log in to unmask]
(Permission granted to reprint, though you might want
to edit for your specific installation. PMW1)
Determining failure locations in electronic mail requires
an understanding of numerous network functions and layers.
Often times, that is the work of an e-mail postmaster.
Most e-mail sites support a generic e-mail address of
[log in to unmask] The job of postmaster is often done
as an 'other duty as assigned' or in rare instances,
not at all.
As you will see, e-mail just doesn't "happen" but is the
result of a complex interaction of computer processes.
In general, the ability to successfully transmit electronic
mail (e-mail) from a LAN-based system is due to the proper
administrating and functioning of:
1) the client software -- typically a package like Eudora
installed on a workstation
2) your office/department LAN as operated by your system
administrator
3) a mail gateway/server such as that operated by the
Center for Academic Computing
4) a data backbone such as that operated by the Office
of Telecommunications, and those of external service
providors
5) the Domain Name System such as operated by a number of
inter-dependent host sites including the Office of
Telecommunications, many times in conjunction with other
departments and/or external institutions or individuals
6) the proper operation of telecommunication circuits
usually operated by local exchange and long distance
carriers
7) the proper administration of any name (userid) lookup
schemes which is controlled by both system administrators
and mail users such as operated on PSU.EDU (PH) facilities
8) the proper operation of the receiving mail server
such as that operated by the Office of Administrative
Systems aka oas.psu.edu
9) the proper administration of the receiver's mail
box, as impacted by various security software, as
well as the receiver him/herself (not allowing the
mail-box to overflow)
(When e-mail is sent to a LISTSERV-based list, the
delivery mechanisms are even more complex. Fortunately,
there are personnel at Penn State who can help trace
that flow.)
/Pete Weiss,
[log in to unmask]
-- co-owner INFOSYS, TQM-L, CPARK-L, ERAPPA-L, JANITORS, LDBASE-L, et -L
[log in to unmask] "I get paid by the Byte" +1 814 863 1843
31 Shields Bldg. -- Penn State -- University Park, PA 16802-1202 USA
-----
Date: Wed, 4 Jan 1995 09:27:00 EST
x-Reply-To: LISTSERV list owners' forum <[log in to unmask]>
x-Sender: LISTSERV list owners' forum <[log in to unmask]>
From: "Peter M. Weiss +1 814 863 1843" <[log in to unmask]>
Subject: fwd: Bouncemail top ten.
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.
--------------------------------------------------------------------
|
