That's the 'sorta constrained recipient' option, which will give you headaches when you want to enable a visitor to send a page or announcement of some sort to a buddy who could be at any domain.
There really are two classes of function that you'd be wanting to do with these thingies. 1. You want to keep your email addresses off of web pages and enable structured messages and queries from visitors to get to the right people within your company. That's an any:few kinda thing. The possible recipients are finite and known. 2. Any visitor can trigger a message that goes to anyone in the universe. An any:any function. To prevent nefarious use, you don't allow arbitrary content. These have different logics, but you can easily put them in the same taf as different _functions. #1 is _function=inbound and #2 is _function=outbound The logic for the inbound messages is really simple. Almost freeform. One form field (I use subject) must be from a fixed list; it might be a popup or a hidden field - I don't care. If that argument is missing, the destination ends up being a default mailbox. Everything else, the form designer can make up the fields. They can make up a dozen fields of their own choosing. That's because your taf is going to capture <@ARGNAMES> to figure out what's in the form, and then drop the values of those arguments in the email with some sort of header or footer. Then it sends it to the destination according to your one constrained field (not an email address, please. Never ever put that email in the html unless you just aren't getting enough spam.) The outbound message function is a little trickier, because you want to make this application once and then use it over and over. It's reading a file (a static html page, for instance), hitting a database, or something like that, and placing the sender's message in the message with the designated content. Maybe it's picking up an acrobat file and attaching it. You can create the application such that it has a URL field, which is the content, and if it's empty, then it errors out. If you make sure that the content is mostly yours, then you don't have to worry about controlled lists of domains for recipients. You took the money out of the bank, so there won't be any robbers. -------- Why this is important: We tear our (remaining) hair out constructing big and fancy applications that require logical and technical savvy, but it's the little ones like this that are our Achilles' Heel. It's like placing many deadbolts on the front door and leaving the side door wide open. It takes less time to create a decent formmail function than to write this email, as long as you don't try to do everything in one function. Better to have a couple of tight little functions than one complex and vulnerable one. Lastly, never let down your guard. Because something is lightly visited only by friends and relatives, it doesn't allow you to lighten up your vigilance. Yes, it's improbable that a given bad guy will find and exploit your code, but as they say here in California about earthquakes, "Improbable is inevitable" [Don't ask why I spent so much time ranting on this tiny subject. Something about it compelled me to call attention to the logical blind spot. Many of us do these kinds of things all the time and they're very simple.] On 3/8/05 7:09 AM, "Jason Pamental" <[EMAIL PROTECTED]> wrote: > Roland makes some very important points. You might be able to address > it though by adding a check in the form processing taf that looks at > the referring URL and compares it to a list (one form mailer and you > keep a list in a text file next to the taf that you can update with the > sites you want to allow to use it). You could use <@cgiparam > name=referrer> to get the site or if it's known, the IP address. If the > list is external to the taf, you could update it pretty easily without > having to open and resave the taf. since no-one would have access to > the taf directory directly, they'd never know the list was there. > > Jason > -- > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
