Send Email Function

Nice little function for sending mail if you do not want to be bothered with the details about coding the neccesary mail commands. I haven't tested it but it looks clean and tidy.

pzzz tell me about function ??? what is definition ???

Hello Faizan Naqvi. It's not clear what you are asking. If you want to know the name of the function or how to use the function command, it might help to review some basics at http://w3schools.com/php/php_functions.asp

looking nice...

I may be wrong but in line 2 I would think the && would be better the ||.

If to_name is set and to_email is not set, the result would still be true. Meaning one or the other has to be true.. With the && operator, to_name and to_email are required to be true...

Like i said I could be wrong. Just wondering.

Line 2 is supposed to have || because you are basically saying that if any of the variables are blank, return false. If you change it to && all the variables would have to be blank for it to return false. And if any of them are blank, the function can't complete.

Im sorry I believe you are incorrect.. If you leave out $to_name its going to return true.

You want to_name, to_email, from_name, from_email required in order to send emails. So you need to have &&.

Basically you want to_name && to_email && from_name && from_email required in order to send email.

Check again, every variable is preceded by a ! (not). So if any variable is empty then the function is exited.

Doh!!

I'm considering changing the charset value in my send email function to UTF-8 instead of iso-8859-1. Any opinions? UTF-8 sounds like a good idea unless I want to turn all symbols into HTML entities before sending any emails.

That's a nice function. I thought maybe what it's missing is a bit of security checking but why make it bigger? You could have that in other functions before before calling yours. I run this thing below (among others) on user entered emails. I return a general "There was a problem.." if it returns false..

function isEmailOK($email) 
{
    //Remove all characters except letters, digits and !#$%&'*+-/=?^_`{|}~@.[].
    $email = filter_var($email, FILTER_SANITIZE_EMAIL);

    //checks if it's a properly formed email
    if (filter_var($email, FILTER_VALIDATE_EMAIL)) 
    {
        return TRUE;
    } 
    else 
    {
        return FALSE;
    }
}

That is a nice little function to use, I may just go ahead and implement it as part of the send_email function. With user entered emails, I also will usually add the following function to the form:

function form_security() {
    /* Spambot security */
    $string = '<input type="hidden" name="honeypot" id="honeypot" value="http://" />';
    $string .= '<input type="hidden" name="humancheck" id="humancheck" value="" />';
    return $string;
}

Then validate those spambot hidden form fields with the following function in the backend:

function check_form_security($honeypot, $humancheck) {
    $error = false;
    if ($honeypot != 'http://') $error = true;
    if ($humancheck != "") $error = true;
    return $error;
}

Spambots always look for form fields that are blank or can be populated with urls, and since spambots can't tell the difference between hidden and regular form fields, they will naturally fill them. When validated on the backend, if the blank form field isn't blank or if the urls form field doesn't just contain 'http://', the form won't be processed in your backend. Provided you don't allow the form to be processed if the check_form_security function returns 'true'.

One-part emails are pretty simple. To be really useful, this function would simplify the composition of multi-part emails such that you could compose two or more parts (eg plain text and markup) and the function would do the formatting into multi-part.

Another feature would be a mechanism to send drafts to the screen rather than sending an email. This would take some of the pain out of developing dynamically composed emails. I've done enough of this to know how irritating it is to keep switching between editor, browser and email client. If you can eliminate the need for the email client at least some of the time, that would be good.

I like the idea. That would be more than just a PHP function though. Maybe I'll create that as a PHP class.

Nice, short and concise.
Just two minor things with Content-type:

text/html should only be used with HTML emails. If it's text you should be using text/plain

charset=iso-8859-1 is ok but the value would work better as a variable for the user to supply that is set UTF-8 by default (as someone mentioned above).

The text/html content-type is only used for HTML emails. I've been working on some newer and better email functions and classes so maybe I'll add the text/plain for text emails, but I don't believe it's a requirement.

It's some time since I did any emaill stuff but IIRC, modern email clients are pretty good at detecting the mime type of one-part emails, but only in the absence of a defined type. If you go for my multipart idea, then it is essential to define the correct mime type for each part (eg text/plain followed by text/html).

If I find time, I'll see if I can dig out my multipart code. It was written for a particular purpose but I think the heart of it was pretty well generic.

Mmm, I found it but it's an old phpBB2 emailer class, which I modded back in 2007. I can't really post the whole thing here but you may like to be aware of "Content-type: multipart/alternative; ...;".

As far as I can tell, the definitive standard on this and related issues is RFQ 2046. It's a good bedtime read.