Re: operator-visible goals?

----- Original Message ----- 
From: "Keith Moore" <[email protected]>

> - mail system operators want the mail system to be easy to configure

Good.

Two comments:

There might be a tendency to fall trap to a "particular" methodology based
of the core audience.  Unix people are comfortable with files,  Windows
people want interactive configuration.

So from a "open-ended functional specification" standpoint,  I would
rephrase this to:

- system should offer a well defined "set of configuration variables"

This allows the vendors to offer the easy configuration for the standard
mail-ng variables in the manner the vendor or software chooses to do so,
manual files or GUI.

However, in keeping inline with other operator/network concepts that might
facilitate a "mail-ng network",  I suggest this to be restated as two
requirements:

- system should offer a well defined "set of local configuration variables"
- system should offer a well defined "set of network configuration
variables"

The local is specific to the local basic requirement for mail-ng operation.

The network is specific to a network related concept, including the
"sharing" of network information with other compliant systems.   Network
variables should also include server attributes.   This will also help the
next item of "testing" and your next, next item of "performance
considerations."

> - mail system operators want a way to verify and test configurations
> before making them "live"

Good.  Something that is missing today.  My only question here is should the
word "compliance" be added or did is this implied?

I think this is important, could be "sensitive topic," but I personally
think, based on what I see this is headed, that ultimately some "new
registry/database" system, centralized, distributed or mixed will be
required.  So a vendor will most definitely (I know we will) use this to:

    o Help with local configuration,
    o Help with network configuration,
    o Help with testing/verifying,
    o Help with "registration" with the new "mail-ng" network.

For example,  the last one is something we have plans to add to support  the
new DMP, SPF implementation.   It will deployed faster when we help the
sysop setup his DNS records.

There is no doubt in my mind, this part alone will add "points" or weight to
helping acceptability and deployment.  DNS setup remains the hardest thing
to explain to new customers.

> - mail system operators want the mail system to run efficiently and
> economically, without requiring substantial CPU resources, network
> bandwidth, etc. for the number of users served or messages handled

Absolutely!

This will help refine the ultimate streaming format, network server
attributes in the 'mail-ng network registry."

> - mail system operators want the mail system to be secure, in that they
> can control access to it and that attempts at unauthorized use (a) fail
> and (b) do not significantly impact operation of the mail system or
> supporting infrastructure

Yes, we want the "Spirit" that made the SMTP/Internet so successful, but
with one key difference: that the functional specification is written very
clear with no loopholes and no mis-interpretations. In other words, we don't
want a repeat of concepts that suggest:

        "System must accept or continue with the session even if  XYZ
validation fails."

We want a tight definition, with the options for strict compliance.

Now on a related note, someone pointed out to me that historistically the
reason the above HELO?EHLO client-domains validation failures exception was
allowed was to allow a  minimum contact for "system operation error"
reporting (not bounces) but related to inform a system of a problem:

         "Hey something is not right with our setup or interface with you."

I agree. So we need something that is related to a "minimim SYSOP TO SYSOP
notification" that may not have strong authentication/trusting.  Lets state
this as follows:

- system should offer a 'sysop to sysop only direct notification contact'
(mail or IM based?) for the purpose of reporting system operation
information, including "compliancy or testing" information which a hub or
host may may perform on the system.

> - mail system operators want reliable fault detection
> - mail system operators want the ability to continue operating the mail
>    system in the presence of various failures

hmmmmm,  implementation related?

Do you mean "availability detection?"

Don't get me wrong. I don't want to jump the gun, but I am thinking in terms
of an "open-ended" functional specification, how would the "protocol" state
this so implementators will have a guide to design it without the
implication that a "minimum availability requirement" is necessary.

We might want to state this like so:

- system should offer a well defined "set of operation variables"
- system should offer an autheticated "watch-dog" feature that monitor
operation variables.

Implementators can now have a good idea for design and do it they want to
want to do this.  For example,  some traditional systems may want to use a
file-semphore design,  others like in Win32 developers may want to use Named
Kernel objects.

System variables could include informations that might allow a "tester" to
work well.

In our SMTP server, we have proprietary commands to display system state and
operation variables, i.e., SHOW xxxx".  So for mail-ng,  maybe a command
"STATUS [Verbose]" would allow a 3rd party developers to write mail-ng
watchdog applications.

So basically stated the operation requirements thinking in terms of "what
are the system variables" helps the specs, the protocol writers and the
vendor will need all the help in the world to redesign a new system like
this.

> - mail system operators want effective tracing and logging to aid in
>   problem diagnosis

Good.

> - mail system operators want a uniform and effective interface for
> problem reporting by users

Good.   Falls in line with the "sysop-to-sysop minimum contact." I guess
that should say,  "user-sysop minimum contact"

> - network operators want a mail system that uses their networks
> efficiently

> - network operators want a mail system that doesn't compromise the
> security or operational integrity of their networks

Topology considerations? Routing Restrictions?

I guess, in terms of generic terminology, you covered a good bit that I see
important from my standpoint.  Here are others (my input above repeated for
consolidation).

Networking/Communications, Operations

- Sysops want to create private networks only.
- Sysops want to be part of open network and also private networks.
- System should have a 'sysop/local user  to sysop'  notification contact
method (mail or IM based?)
- System should offer both full time and part time operations.
- System should offer schedule events concepts.

Variables

- System should offer a well defined "set of configuration variables"
- System should offer a well defined "set of local configuration variables"
- System should offer a well defined "set of network configuration
variables"
- System should offer a well defined "set of system operation variables"

Configuration

- System should offer remote configuration
- System should offer automatic/assistance "Network Registry" registration

Availability, Fault, Error Detection, Signaling

- System should offer a watch-dog feature that monitor system
status/variables.
- System should offer a shutdown signaling feature (internal/external
command)
- System should offer a re-load signaling feature (internal/external
command)
- System should offer an abort process
- System should offer backup

Monitoring

- System should offer a watch-dog feature that monitor system
status/variables.
- System should offer transaction summary information
- System should offer load/performance information (i.e,  Win32 offers
method to register performance variables for the Win32 Performane Monitor
utility)

Queuing,  Backend Interfacing

- System should offer queue management
- System should offer server-side backend interface queue

well, I just grab a good bit what we have today on our system. :-)

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com