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.