Re: user-visible goals

Doug Royer wrote:

> And it sounds like it would be spammers heaven to test email addresses
> before sending.
> That is why most of us turn off SMTP's VRFY and EXPN.

I'm not so sure about that. Spammers don't seem to care whether would-be
recipient
addresses are valid or not.  They forge the sender envelope address with
the result
being that joe-job victims get all of the bounces.   From the user's
point of view, it
would be better if VRFY worked.  I.e.

- users do not want to be bothered by administrivia (mailbox full,
invalid address,
  we think maybe it might contain a virus, etc.) related to messages
which they did
  not send.

A related one:

- users do not want to be annoyed by messages complaining about the lack of
  non-standard cruft (e.g. "You didn't use Mail-Followup-To").

and

- users do not want to be bothered by challenge-response systems.

Others:

- users would like to be able to exchange forms (receive blank form, fill it
  out and send it).

- users do not want to have to pay royalties on each message (message format
  should not be encumbered by patents, etc.)

The last one segues into a discussion of issues related to a particular
subset of
users of the protocols, namely software developers.  We should keep in mind
the excellent suggestions in RFC 1958. As this relates to user-visible
goals:

- users do not want to have to change their habits often (if ever). Ideally,
  existing email programs should continue to work.  Changes in number of
  hosts, processor speed, available memory, etc. should not require
scrapping
  existing software or hardware.

- (at least some) senders would prefer to see a "recipient is not currently
  accepting messages - try again later" rather than one or more delayed
  notices from intermediate systems saying "message not yet delivered -
  will keep trying".  This is an instance of end-to-end responsibility for
  the integrity of communication.  Other senders might wish to offload
  their part of that responsibility.

- developers would prefer a standardized method of implementing features
  rather than having to support multiple means of achieving the same or
  similar functionality (e.g. MIME vs in-line uuencoding).

- users want a solution today, even if it is incomplete.

- (many) users would prefer not to have to specify options (e.g. message
  composition format) -- options should be automatically negotiated by
  the software whenever possible.

- (in conjunction with privacy/security) users don't want to have to
manually
  keep track of security/privacy keys etc.

Another (based on RFC 2277):

- some users want language of text to be clearly indicated, in a manner that
  can be used for machine processing (e.g. text-to-speech conversion).  It
  should be possible to change language frequently in running text.