Re: [MacPerl-WebCGI] Can SMTP collect and transfer CGI <form> data ??

[email protected] (Jeff Lowrey) Fri, 21 Sep 2001 21:07:51 -0500
Newsgroups perl.macperl.webcgi
Message-ID <p05010400b7d1a032f071@[192.168.136.5]> 
At 2:56 AM +0200 9/22/01, Detlef Lindenthal wrote:
>I never saw such a thing, but it would be very comfortable
>for quick and specific answers to e-mails:
>
>If I have a web page starting and ending with <html> and
></html>,
>this can have a <form> section and some <input ..."text">
>lines and
>an <input   .. "submit"> button. Then my browser and the
>HTTP
>can take care that those CGI data are transmitted, so a Perl
>script can
>utilize them.
>
>Am I right if I suppose that if I manage to equip the HTML
>partition of an e-mail with form, input and submit elements,
>then
>the mainly used e-mail programs do *not* have an
>opportunity  to
>transfer the content of such elements to a perl script,
>because SMTP
>is not designed for that, nor are the browsers?
>
>Or is there a direct way (other than attaching a file or
>adding
>a clickkable link to a web page form) to directly adding and
>
>transferring fill-in-elements?
>
>Detlef

I won't go on at all about how much this idea disturbs me.  That's 
not relevant to the forum nor the subject.

Let's pause for a second and remember what SMTP means.. Simple Mail 
Transport Protocol.

SMTP has nothing to do with the contents or the presentation of said 
contents of email.  It's all about the Transport.  The other usual 
"half" of email is POP3 - which is Post Office Protocol, version 3. 
That's also all about transport.

I do not believe there is anything resembling a standard for email 
presentation - i.e. nothing resembling a standard for how email would 
be "browsed".  The closest you might come is reviewing the MIME 
standards.  There should be some rules in there about how some 
particular MIME piece might be presented.

When you say "HTML partition" what you really mean is "MIME part that 
contains HTML text".  There's no guarantee that a particular email 
client will do *anything* with that MIME part, including even 
*keeping* it, much less "display it to the user as if it were in a 
web browser".  My email client, for instance, displays all HTML MIME 
parts as raw text.

In addition, CGI works because there is a point-to-point connection 
between a server and a client - and the server has a program 
configured to respond to aspects of that connection.  There is no 
point-to-point connection between an email sender and an email reader.

However, perl is perfectly capable of parsing the contents of an 
email message, and as such there's no reason you can't extract data 
from email messages.

Now, your original idea *might* be possible, if you could guarantee 
that all your mail recipients were using clients that would 
"properly" display HTML - and in addition, support something like an 
in-line frame or a redirect that would establish a point-to-point 
connection between the email client and your webserver.  But it's 
those kind of email clients that allow things like Nimda to  be 
created and propogated.

What?  You can tell my day job involves building automated systems to 
process email?  I'm shocked!

-Jeff Lowrey