Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs

[Klaus Weide]

On Fri, 14 Jul 2000, Vlad Harchev wrote:
> On Thu, 13 Jul 2000, Klaus Weide wrote:
> > On Thu, 13 Jul 2000, Vlad Harchev wrote:
> > > On Thu, 13 Jul 2000, Klaus Weide wrote:
> > > > On Thu, 13 Jul 2000, Vlad Harchev wrote:
> > > > > On Wed, 12 Jul 2000, Klaus Weide wrote:
> > > > > > On Mon, 10 Jul 2000, Vlad Harchev wrote:
> > > > > > > On Sun, 9 Jul 2000, Klaus Weide wrote:
> 
>  Isn't this stack beatiful?

It would be nices if somebody else popped in once in a while...

> > > > > > Realize that any of the recently discussed "solutions" don't apply
> > > > > > to mail that is sent when a FORM with ACTION="mailto:..."; is 
> > > > > > submitted.
> > > > > 
> > > > >    It shouldn't be invoked, of course.
> > > > 
> > > > Are you sure?
> > > 
> > >   This is the same case as with "Mail this file" - user i snot expected to
> > > type anything - so using MUA is not necessary.
> > 
> > Not strictly true that the user is not expected to type anything.
> 
>  Are you sure? If I press 'p', "mail this file", then I'm only prompted for
> email address - no editing of cc:, subject:. So it looks like you are missing
> something.

That was in reference to FORM ACTION="mailto:..."; - you said that it is
"the same case" as with "Mail this file", and I said no it's not.


> > > > That's a first draft for a definition of the problem, but it still needs
> > > > some work.  What exactly is 'going to'?  Obviously you don't mean just
> > > 
> > >   I meant 'x','g','G','E' and ACTIVATE commands (probably I missed some 
> > > other 
> > > exotic comand, but unlikely).
> > 
> > HEAD?  'd'ownload?  or
> 
>   As currently, not supported for mailto: URLs.
>  
> >   HTTP/1.0 301 Moved Temporarily
> >   Location: mailto:address@hidden ,
> 
>   MUA should be invoked in this case since user will have to type message of
> the body.

Well, probably.  It's a weird case anyway (but this kind of redirection is
normally only blocked if no_goto_mailto is set).

> > or
> > 
> >   RULE:Redirect mailto:address@hidden  mailto:address@hidden ,
> 
>   Don't get why you give this item - it has nothing to do with mailto:
> handling.

Maybe I should have written
    RULE:Redirect http://somewhere/somepath/*  mailto:address@hidden ...

> Also, CERN rules for mailto: are yet not supported by lynx.

Mailto on the right side works...  (assuming the left side isn't lynxexec
or something similar, or mailto itself).

Anyway, *you* asked for (or at least mentioned) "exotic" commands...
My question is, is this 'going to'?  I am trying to get you to
find a better formulation than 'going to'.


>  As for FORM mailto: action - since user is not expected to type anything
> (subject field, body, etc), external MUA shouldn't be invoked. 

As above - the user *is* expected to type something in the FORM mailto action 
case.  Namely, subject and (unless disabled) cc.

Try it.
   <TITLE>Test of form with mailto action</TITLE>
   <FORM ACTION="mailto:address@hidden";>
   <INPUT type=text name=i1 value=foo>
   <INPUT TYPE=submit name=sn value=sv>
   </FORM>


> > The problem is how to describe exactly when your proposed MUA replacement
> > feature applies and when it doesn't, for documentation in lynx.cfg and
> > maybe Lynx_users_guide.  (Also, how to call the feature/option.)  If it
> > can't be described simply and accurately, then maybe it's too complex
> > or not well designed.  If it's easier to say "this option applies to all
> > mailto URLs" rather than "this option applies to all mailto URLs except
> > for [long explanation]", then maybe "applies to all mailto URLs" _is_ the
> > more logical behavior.
> 
>   It looks like the rule of thumb is: if user is expected to type message body
> or edit subject and cc: in given situatiuon, then external MUA will be
> invoked (if enabled).

According to *that* rule of thumb, the external MUA would have to be
invoked for a FORM mailto action.

I guess I also want to re-open the question whether lynx's built-in
handling of FORM mailto actions is right.  I just read RFC 2368,
which defines "The mailto URL scheme".  It says:

7. Security Considerations

   ....

   A mailto URL gives a template for a message that can be sent by mail
   client software. The contents of that template may be opaque or
   difficult to read by the user at the time of specifying the URL.
   Thus, a mail client should never send a message based on a mailto URL
         ===============================================================
   without first showing the user the full message that will be sent
   =================================================================
   (including all headers that were specified by the mailto URL), fully
   =============================================================
   decoded, and asking the user for approval to send the message as
                ============================
   electronic mail. The mail client should also make it clear that the
                                    ==================================
   user is about to send an electronic mail message, since the user may
   ================================================
   not be aware that this is the result of a mailto URL.

   A mail client should never send anything without complete disclosure
   to the user of what is will be sent; it should disclose not only the
                                           ============================
   message destination, but also any headers. Unrecognized headers, or
   =========================================
   headers with values inconsistent with those the mail client would
   normally send should be especially suspect. MIME headers (MIME-
   Version, Content-*) are most likely inappropriate, as are those
   relating to routing (From, Bcc, Apparently-To, etc.)

   ....

   Examples of problems with sending unapproved mail include:

     * mail that breaks laws upon delivery, such as making illegal
       threats;

     * mail that identifies the sender as someone interested in breaking
       laws;

     * mail that identifies the sender to an unwanted third party;

     * mail that causes a financial charge to be incurred on the sender;

     * mail that causes an action on the recipient machine that causes
       damage that might be attributed to the sender.


Lynx's handling of FORM mailto actions doesn't do what the RFC says.
There is prompting for some headers, and at that point the user
has a chance to cancel the submission with ^G, but that's it.  The
prompts look like "Subject: ..." and "Cc: ", I am not sure that that
is even enough to "make clear that the user is about to send an
electronic mail".

(Whether lynx handles mailto in other contexts according to the
specs is another question.)

Using mailto as a FORM action is non-standard and discouraged:

   HTML 4.01:
   <http://www.w3.org/TR/html4/interact/forms.html#h-17.13.3>
   "For any other value of action [than HTTP URL] or method [than "get",
   "post"], behavior is unspecified."

   Web Authoring FAQ (WDG):
   <http://www.htmlhelp.com/faq/html/forms.html#mailto-form>
  8.2. How do I get form data emailed to me?

   The only reliable mechanism for processing form submissions is with a
   server-side (e.g., CGI) program. To send form data to yourself via
   email, you should use a server-side program that processes the form
   [...]
   Forms that use ACTION="mailto:..."; are unreliable. They may work for
   some of your users, but they will fail for others who have different
   software configurations.

Still, since lynx chooses to support it, it should do it right.
At least, there should be an option to select between current behavior
and full editing access to the message that is about to be sent
(probably just using lynx's normal reply_by_mail that is used for normal
non-FORM mailto URLs, with some modifications - don't use "original
message" prefixed with '>', use form data instead to pre-fill the
message; do something about content-type).  While we're at it, an
option to turn mailto FORM actions completely off without having
to disable all mail sending.

Vlad, I'm not saying that you should "fix" this for lynx's built-in
mail handling (would be nices though), but you should keep this in
mind when thinking about external MUA invocation.  Basically, don't
assume that just because lynx currently doesn't allow to edit an
outgoing FORM mailto message, that's the way it should be when using
an external MUA.

  Klaus



; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden