It's just my good friend's birthday. I encourage everyone to wish him a happy birthday!
Happy Birthday!
Friday, October 31, 2008
Thursday, October 30, 2008
Welcome!
Welcome, rencalago. As my first follower, I wish to welcome you to my blog. Hopefully you find my code pondering useful and informative. I spend much of my programming life designing, documenting, coding, debugging, maintaining, talking, and all the fun little tasks and trials in between, so I figured I would just share a little of my knowledge with you and the rest of who cares here, in this blog.
So, welcome again. Look forward to having you read my ponderings.
So, welcome again. Look forward to having you read my ponderings.
Hiding Email Addresses
With a business or informational site, your contact information is power. It dictates the accessibility of your clients, friends, or fans, to you. However the more and more I play this game called web development, the more and more I find the uselessness of providing an email address (actually ANY email address) to the user. Any system that can handle a web site will typically have some manner of mailing functionality available. If your site doesn't offer this functionality, ignore what I say and risk keeping your email addresses on your site. But if you are one of the majority, bear with me.
The sad truth of this world is that people are out there digging out email addresses posted on web sites on these site's forums, articles, and yes, their contact sections. They will either use these email addresses to send emails TO, or worse, use these email addresses to send emails FROM your addresses.
If SPAM is sent to your address, this can be annoying, unproductive, as well as embarrassing. There are many SPAM blocking programs available nowadays, but the best defense is a preemptive one and not a reactionary one. In other words, you address the reason for the problem and not the effect of it. And mail is dumb, as is the case for the more black-hatted of the black hats or script kiddies who use your email address to send out emails. Some of you may must be wondering how this could happen. Well, again, mail is dumb. Mail servers care more about who it's going to, and not who it's coming from. You'll notice this happening when you receive a NDR (non-delivery response). What this means is that someone sent an email to a nonexistent recipient with your email address as the sender. The mail server will send you the response of this transaction. NDRs are common occurrences (I've noticed it a lot in my clients newsletters), but if you never sent an email to the nonexistent recipient defined in the NDR, you may have been victim to this problem. Soon NDRs aren't the worse of this. Mail servers will get wiser to the spamming and blacklist your email address. It DOES happen.
Ouch.
For these reasons, I move that email addresses be hidden from web sites. If people must send you emails, I suggest provide a form, process the form with a script, and mail the message on their behalf.
This has many advantages. Firstly, it hides the email address from the site. My reasons are the reasons I mentioned above. Second, it allows you more control over the email people send you in the form of validation, verification, and cleaning. You will get more organized and less frivolous emails sent to you this way which will help your respond time to these emails. Third, it will make email easier. Everyone submits a form and the recipient and any other static fields will be entered for them. This will streamline the process.
I could go on, but these pros should provide you enough to make your own decision about my suggestion.
The sad truth of this world is that people are out there digging out email addresses posted on web sites on these site's forums, articles, and yes, their contact sections. They will either use these email addresses to send emails TO, or worse, use these email addresses to send emails FROM your addresses.
If SPAM is sent to your address, this can be annoying, unproductive, as well as embarrassing. There are many SPAM blocking programs available nowadays, but the best defense is a preemptive one and not a reactionary one. In other words, you address the reason for the problem and not the effect of it. And mail is dumb, as is the case for the more black-hatted of the black hats or script kiddies who use your email address to send out emails. Some of you may must be wondering how this could happen. Well, again, mail is dumb. Mail servers care more about who it's going to, and not who it's coming from. You'll notice this happening when you receive a NDR (non-delivery response). What this means is that someone sent an email to a nonexistent recipient with your email address as the sender. The mail server will send you the response of this transaction. NDRs are common occurrences (I've noticed it a lot in my clients newsletters), but if you never sent an email to the nonexistent recipient defined in the NDR, you may have been victim to this problem. Soon NDRs aren't the worse of this. Mail servers will get wiser to the spamming and blacklist your email address. It DOES happen.
Ouch.
For these reasons, I move that email addresses be hidden from web sites. If people must send you emails, I suggest provide a form, process the form with a script, and mail the message on their behalf.
This has many advantages. Firstly, it hides the email address from the site. My reasons are the reasons I mentioned above. Second, it allows you more control over the email people send you in the form of validation, verification, and cleaning. You will get more organized and less frivolous emails sent to you this way which will help your respond time to these emails. Third, it will make email easier. Everyone submits a form and the recipient and any other static fields will be entered for them. This will streamline the process.
I could go on, but these pros should provide you enough to make your own decision about my suggestion.
Monday, October 27, 2008
Form Field Naming
It's fairly easy to do and yet SO useful. When working with forms, I like to use arrays for all my fields. All data retrieved in the form is put into a values array. A parameters array informs the form's action what to do with that values array.
Observe the following. It's purpose is to submit an email (although that code is not shown here):
<form action="email.php">
<input name="parameters[mode]" value="send" type="hidden">
<input name="parameters[redirect]" value="http://www.foobar.com" type="hidden">
<input name="values[subject]">
<textarea name="values[body]"></textarea>
</form>
It's a simple enough form, but makes it easier to handle in the form's action. PHP and other server side languages champion great array functions that make your life easier through organization, data manipulation, verifying, validation, and other neat little tricks. Try it out and see exactly how useful it can be.
Observe the following. It's purpose is to submit an email (although that code is not shown here):
<form action="email.php">
<input name="parameters[mode]" value="send" type="hidden">
<input name="parameters[redirect]" value="http://www.foobar.com" type="hidden">
<input name="values[subject]">
<textarea name="values[body]"></textarea>
</form>
It's a simple enough form, but makes it easier to handle in the form's action. PHP and other server side languages champion great array functions that make your life easier through organization, data manipulation, verifying, validation, and other neat little tricks. Try it out and see exactly how useful it can be.
Subscribe to:
Posts (Atom)
Posts
