Arthur Fuller
artful at rogers.com
Sun Dec 12 18:36:57 CST 2004
Food for thought, to be sure. But here is the scenario, so feel free to refute/revise/shoot me. Customer wants two tickets to U2 East Rutherford 2005/##/##. Tickets available? Yes = book them. No = Waiting List (we may get more). Yes -> credit card authentication etc. all of which is nailed down. Important part is to be able to stay in touch with said customer. We ask for phone numbers as well as email addy's but our preference is certainly to communicate via e-addys, and we want to know asap if we have a problem reaching you this way. For example, we're sold out but then U2 decides to add an extra night in East Rutherford, so we want to hit you asap with a note that we can take you off the waiting list and sell you the tickets you're craving. In the ideal world I would like to verify your e-addy a few moments after you type it in. I realize that outfits such as hotmail take a while to post new mail, and also that some (perhaps most) users have spam-blockers, and also that some ISPs have blockers that will reject everything sent to you that you have not specifically authorized. My real question is, what's a graceful and efficient way to step aside these problems? Assuming that you HAVE purchased, I need to be able to get in touch asap (Cher has a cold and the concert is postponed until the next night). I don't want to wait until I need to send you such a message to discover that the e-addy you supplied is bad, or that my sends will get bounced due to your spam-filter etc. I want to be a good vendor and get gracefully past all these impediments asap, without subverting your spam-filters, ISP-bouncers etc. I just want to be a good reliable honest vendor and be able to stay in touch with you as things change -- which, in the rock & roll biz, they do, frequently. So perhaps I was all wrong in my spec. Wouldn't be the first time! But the above describes my intent. We want to keep all the communication net-oriented if possible. 90%+ of our clients will have reached us via the net. I have a pair of queries to list those with e-addy's and those with phone numbers only, and our intent is to hit all the U2 East Rutherford clients with a note that the date has changed (etc.) the moment we know it.... so I want to know if I can hit your e-addy asap and offer you the opportunity to correct it in case you mispelled it, and also to let you know that your spam-filter rules bounced me, asap. You are proposing to give me money. I wish to guarantee that I can get in touch. That's all. There are no hidden motives. We won't overload your mailbox with junk. All we are interested in is staying in touch with news about your tickets, and getting the changes to you asap. So I thought that some method of guaranteeing that I can hit your supplied e-addy would be good. I'm not wedded to this notion. I just thought it might be a good way of doing it. If you have a better method -- excluding phone calls -- I would love to read about it. A. Stuart McLachlan wrote: >On 12 Dec 2004 at 12:58, Arthur Fuller wrote: > > > >>I have a web page upon which I request the user's email address. >> >> > >The important qestion here is: Why? > > > >>What I >>have in mind is that the moment the user tabs out of this textbox, I >>immediately send a test message to said address to see if it's at least >>real. (It may be real but inaccurate and there's not much I can think of >>to get around that problem, so let's just deal with the "real" problem.) >> >> >> > >Email is not an instance messaging medium. There can be all sorts of >delays in message delivery for any number of reasons,. The minimum >recommended timeouts for the various transactions in a mail delivery vary >between 2 and 10 minutes including a 5 minute timeout on the initial >connection. In other words, a single mail transaction can take up to an >hour to complete Most SMTP servers will retry for several daya to deliver >a message if they receive a 400 series delivery failure. > > > >>3. Is there any way to detect whether the bounce was caused by a bad >>address or alternatively by a spam-blocker etc.? >> >> > >If the email address is to a vaild SMTP server, the receiving SMTP server >will return a numeric code to the originating SMTP server (not to your ASP >page) > > > >>And supposing that I >>could detect the latter, what sort of advice could I offer the visitor >>to allow my mail in? I guess I would have to know the particular blocker >>in use, etc., which is a nested can of worms I don't really want to get >>into. >> >>Any advice? >> >> > >Rethink the whole concept. Unless you are going to email instructions to >the viewer (such as a password to proceed further) you are wasting your >time. Unless there is a valid reason for supplying a true email address , >you will find that most of your logins are from wgates at microsoft.com :-) > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.0 - Release Date: 12/9/2004