Harald(_dot_)T(_dot_)Alvestrand(_at_)uninett(_dot_)no wrote:
Note also that if you revise Mailto:, the ADs will want to have answered
the questions that were raised on Mailserver:, including:
- How to ensure a proper From: address
(this is about THE most common question from mail admins these days;
the keyword is Netscape 2.0)
I think the keyword you're thinking of is Netscape 1.1; in 2.0, we
complain if the user's return address doesn't contain an "@" followed
by at least one ".". Which I think is the best we can do and have it
still work on systems that do address resolution in funny ways (for
example, on YP/NIS systems, or heavily firewalled systems, where you
don't have access to MX records at all.)
- How to (request to) apply signature functions to the message
- How to make sure the user is aware of what he is doing
(or is getting done in his name)
In the case of mailto: URLs opened with GET, this is no problem, since
all this does is bring up a message composition window, with certain
fields initialized; the user then has the ability to edit and review
what's going to happen, and any pre-delivery processing that would
normally occur would occur in this case as well.
In the case of mailto: URLs opened with POST (which sends the message
directly), perhaps there should be some confirmation before sending the
mail; I think there is only one difference between this type of POST and
POSTs to all other URLs, and that is the inclusion of the "From:"
header.
See http://domen.uninett.no/~hta/ietf/http-traps.html for some
examples of how to get mail sent from unsuspecting clients.
I'm happy to report that none of these seemed to work on Netscape 2.0
(running on Linux 1.2.13, at least.) I don't particularly understand
why the SMTP tricks didn't work, however; I assume it's because our
HTTP headers are confusing the mail server...
--
Jamie Zawinski jwz(_at_)netscape(_dot_)com
http://www.netscape.com/people/jwz/