I'm trying to set up a web presence for a client, and just tried setting up an HTML form using post to subscribe people to a Smartlist mailing list. (I didn't see it mentioned as working, but I thought I'd try. It does get emailed.) It almost worked perfectly: it uses the address posted in the form, but the form puts a '=' in front of the address. Can anyone point me to a good way to strip that out? (Sorry, don't know shell code yet.)
Daniel T. Staal
p.s. Here's a copy of what gets sent to Smartlist, in case you need it:
Return-Path: countrynews-request@strictly-country.com Delivered-To: daniel@gandolf.magehandbook.net Received: by gandolf.magehandbook.net (Postfix, from userid 1004) id DDEC616D; Wed, 31 Jul 2002 14:26:24 -0500 (CDT) X-From_:DStaal@usa.net Wed Jul 31 14:26:18 2002 Delivered-To: countrynews-request@gandolf.magehandbook.net Received: from [192.168.1.10] (mac.magehandbook.net [192.168.1.10]) by gandolf.magehandbook.net (Postfix) with ESMTP id AAFFD161 for countrynews-request@strictly-country.com; Wed, 31 Jul 2002 14:26:10 -0500 (CDT) To: countrynews-request@strictly-country.com subject:subscribe X-Mailer: Mozilla/4.0 (compatible; MSIE 5.15; Mac_PowerPC) MIME-Version: 1.0 Content-type: text/plain Message-Id: 20020731192611.AAFFD161@gandolf.magehandbook.net Old-Date: Wed, 31 Jul 2002 14:26:11 -0500 (CDT) From: DStaal@usa.net X-Diagnostic: Sent confirmation instructions X-Envelope-To: countrynews-request Date: Wed, 31 Jul 2002 14:26:24 -0500 (CDT)
E-mail Address:=DStaal@usa.net
At 3:56 PM -0400 7/31/02, Daniel Staal is rumored to have typed:
It almost worked perfectly: it uses the address posted in the form, but the form puts a '=' in front of the address.
Program it not to do that.
Can anyone point me to a good way to strip that out? (Sorry, don't know shell code yet.)
Honestly, I wouldn't bother stripping it out; I'd remove the body completely from what the form mails. The From: header field seems fine (although it's possible that that's an artifact of the way you're doing things), so drop the email address in the body. (I'd also fix the Subject: header field and make other changes, but they aren't SmartList-related, and are a function of whatever you're using to program the CGI.) Remember that SmartList doesn't _need_ a body; it'll cheerfully use the From: header field for the subscribing address. (Naturally, you ARE using one of the confirm routines, right?)
p.s. Here's a copy of what gets sent to Smartlist, in case you need it:
Are you sure? Why in the world would your web-based form be adding an X-Mailer: Mozilla/4.0 header field? (Are you using a Frontier script to generate AppleEvents to Communicator? If so, there are MUCH easier ways...even 5.x has the NetEvents applet.)
Basically, I'm telling you your CGI is wrong, and needs to be reworked. The problem isn't SmartList, and shouldn't be FIXED by SmartList, it should be fixed at the CGI.
Charlie
--On Wednesday, July 31, 2002 16:58 -0400 Charlie Summers charlie@lofcom.com wrote:
<snip>
Basically, I'm telling you your CGI is wrong, and needs to be reworked. The problem isn't SmartList, and shouldn't be FIXED by SmartList, it should be fixed at the CGI.
I'd agree, except I'm not using a CGI. This is a HTML form with the action set to post to the -request address of the list. What I was actually expecting was SmartList to ignore the body, and I'd manually double check the address against the body. (This in addition to the confirm package.) My current plan is to re-work the form so it doesn't actually post anything, but that is dangerous in that the only way I'm getting any info then is from the user's browser, which could be completely wrong. (And I'd have thrown away the way to check it.)
Sorry this wasn't clear in the original email; to recap here's what I've got: The user opens a page in their web browser (in my test IE5/Mac, therefore "Mozilla/4.0 (compatible; MSIE 5.15; Mac_PowerPC)"), enters their email address in a field and clicks submit. Their browser sends the form as a text/plain email to countrynews-request with a subject of subscribe. The '=' is part of the standard for how the browser is supposed to send 'post' forms (at least as I understand it). There is _no_ scripting involved, besides SmartList's internal scripts. Just pure, valid, html.
I'm aware I'm trying to be to clever for my own good, but it almost worked...
Daniel T. Staal
------------------------------------------------------------------------ This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ------------------------------------------------------------------------
In article <856544.1028132815@[192.168.1.10]>, Daniel Staal DStaal@usa.net wrote:
I'd agree, except I'm not using a CGI. This is a HTML form with the action set to post to the -request address of the list. What I was actually expecting was SmartList to ignore the body, and I'd manually double check the address against the body. (This in addition to the confirm package.) My current plan is to re-work the form so it doesn't actually post anything, but that is dangerous in that the only way I'm getting any info then is from the user's browser, which could be completely wrong. (And I'd have thrown away the way to check it.)
So you're using something like this?
<form method=post action="mailto:country-news-request@example.com?subject=subscribe">
That's pretty clever indeed. :-) If I were doing this I'd probably skip having them enter their e-mail address in a box at all. If they're submitting a mailto: URL, their browser will automatically put their return address (or whatever it thinks is their return address) in the From: header and probably the SMTP envelope too. SmartList should be able to get it from there.
--On Thursday, August 1, 2002 17:15 +0000 Tim Pierce twp@rootsweb.com wrote:
So you're using something like this?
<form method=post action="mailto:country-news-request@example.com?subject=subscribe">
Bingo! Well, there's a enctype="text/plain" in there too. ;)
That's pretty clever indeed. :-) If I were doing this I'd probably skip having them enter their e-mail address in a box at all. If they're submitting a mailto: URL, their browser will automatically put their return address (or whatever it thinks is their return address) in the From: header and probably the SMTP envelope too. SmartList should be able to get it from there.
Yes, but... That assumes several things. First of all, it assumes the browser puts a real return address in there. (Opera for instance has the option of obscuring your return address.) Secound, it assumes they are doing this from their own computer, not a computer at a library or something. Thirdly, it assumes they want to subscribe with whatever the browser assumes to be their 'default' address, and not some secondary address on their computer. Overall, those are probably good assumptions 90 percent of the time, but I'd like to at least be able to check them. If SmartList totally ignored the address from the box (but left it in the email), that would be a good secondary solution. (Checks are manual.) If SmartList could _correctly_ parse the email the browser is sending then the checks are automatic.
Daniel T. Staal
------------------------------------------------------------------------ This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ------------------------------------------------------------------------
In article <1179475.1028212096@[192.168.1.10]>, Daniel Staal DStaal@usa.net wrote:
--On Thursday, August 1, 2002 17:15 +0000 Tim Pierce twp@rootsweb.com wrote:
If I were doing this I'd probably skip having them enter their e-mail address in a box at all.
Yes, but... That assumes several things. First of all, it assumes the browser puts a real return address in there. (Opera for instance has the option of obscuring your return address.) Secound, it assumes they are doing this from their own computer, not a computer at a library or something. Thirdly, it assumes they want to subscribe with whatever the browser assumes to be their 'default' address, and not some secondary address on their computer. Overall, those are probably good assumptions 90 percent of the time, but I'd like to at least be able to check them.
Sure, but asking people to type their e-mail address into a form is not without its own risks. A depressingly high percentage of people are going to get their own e-mail addresses wrong. They'll use "earthlink.con" instead of "earthlink.com", # instead of @, their full name instead of their userid ("Joe.Schmoe@example.com" instead of "jschmo@example.com"), and so on. The return address in their e-mail program is likely to have been debugged already.
It's not clear to me which is the more fail-safe solution. Letting people subscribe by just hitting a button is nice, but I would say on the web page that the preferred method is to send mail from their favorite mailer program to listname-request. :-)
At 5:26 PM -0400 7/31/02, Daniel Staal is rumored to have typed:
This is a HTML form with the action set to post to the -request address of the list.
Er...not to sound confused or anything, but instead of creating a form why don't you just make a simple link something like:
<A HREF="mailto:mylist-request@mydomain.tld?subject=SUBSCRIBE">
...and be done with it? Since you don't _need_ any other information other than the subscriber's email address, why bother with a form at all? With a form you're depending on how the browser deals with your code (and every one will be slightly different), where with a mailto: URL, it's all pretty standard.
(Of course, if you _are_ planning on capturing additional information at a future date, this obviously won't work.)
Charlie
--On Thursday, August 1, 2002 13:59 -0400 Charlie Summers charlie@lofcom.com wrote:
Er...not to sound confused or anything, but instead of creating a form why don't you just make a simple link something like:
<A HREF="mailto:mylist-request@mydomain.tld?subject=SUBSCRIBE">
...and be done with it? Since you don't _need_ any other information other than the subscriber's email address, why bother with a form at all? With a form you're depending on how the browser deals with your code (and every one will be slightly different), where with a mailto: URL, it's all pretty standard.
Well, that was my first choice too. Client deemed it to confusing, since it opens up their email program to send it. How this is handled is actually fairly bug-free in my tests.
(Of course, if you _are_ planning on capturing additional information at a future date, this obviously won't work.)
Charlie
Actually, they just asked me to set up another list where they do collect additional info at signup. If I can get this working, I'll use the same system.
Daniel T. Staal
------------------------------------------------------------------------ This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ------------------------------------------------------------------------
At 3:36 PM -0400 8/1/02, Daniel Staal is rumored to have typed:
Actually, they just asked me to set up another list where they do collect additional info at signup. If I can get this working, I'll use the same system.
(*sigh*) Then spend a few minutes and either pull one of the gadzillion subscribe-o-matic CGIs available on the web (just avoid formmail.pl), or write one yourself in whatever system you like. It's obviuos this "method" doesn't work (since you can't control the browser), so use a CGI and be done with it.
(Honest...about two minutes in PHP and you're done. Less than that, actually, unless you're holding more info in MySQL. But a sub mail? Two lines for the form, one line for the mail, done.)
And since this is NOT really a SmartList issue (the same rules/problems apply to any mailing list software, or any forms handling in general), it should be taken to a different mailing list.
Charlie
smartlist@lists.rwth-aachen.de
-
Charlie Summers -
Daniel Staal -
Tim Pierce