a client asked me about a little form for his website, from which it would be possible to mail the URL to someone. Something like "Hey check this out".
Since he was not happy with mailto:, I want to use PHP mail() function, but i wonder if it is smart to let users define a sender of the email. I am worried about the form being abused for spam/phishing.
Is that a reason to worry? Is it even legal?
It's legal to send e-mail. It's not legal (everywhere) to send spam. But you are just providing a share link, not a relay server, so I wouldn't worry about that. If you limit the amount of control over the content of the message, and limit the number of people to send it to, it won't be too interesting for spammers.
Letting the user choose a sender is not a very good idea. Some mail relay servers check if the originating server is allowed to send e-mails for the domain specified in the address, so the mails might never arrive. You can safely set the sender name, though.
Apart from that, if the receivers of the message consider it as spam and report it, your domain might become blacklisted, and your mails will be sent to junk mail in many cases, so you want to make sure no (or little) spam is sent through your form.
Those bots try every form automatically just to see what happens, so you'll need to make some effort. You could add a captcha, which is an obstacle for humans too, although Google is going to put an end to that. Or you could protect it through other means, like a honeypot. Maybe you can just generate the form through JavaScript, which is a big obstacle for most spam bots.
Setting the From on an email in php mail isn't the cause for concern. The problem is that you'll be sending emails from your server. The mail headers will have your server information embedded - so any issues will tie back to you.
As long as you can safeguard your own server from allowing these spam/phishing attacks, then there's nothing wrong with it.
Just limit the number of people this mail function can send to - and make sure it can't be called multiple times in succession -- like with a script.
This way, the spammers wouldn't benefit from using your page to try to send spam. They'll go elsewhere.
There's much more to do to work with sending email, but this will at least get you started.
"Is it legal" depends upon the country you are in.
I don't think you need to worry about spam if you set up a login.
Or you could limit the number of emails by IP address. This can be spoofed, however, so it may not be the best option.
There are other control options you could do; limit number of emails by User Agent/IP combination, etc.
Aside from the reasons pointed out by others who have answered this question, I would advise against doing this because these messages will likely be marked as spam by spam filters, due to SPF and DMARC records.
For example, is someone sends a message through your system from a yahoo.com address, most spam filters will treat the message as spam, because os Yahoo's DMARC record, which basically says, 'any message sent from a yahoo.com email address that did not originate from a mail server on yahoo's network is spam'. See https://help.yahoo.com/kb/mail/SLN24016.html?impressions=true for more info.
All my emails I am sending in local WAMP or on server, with PHP mail() function, goes to SPAM folder always.
While looking for the issue, I found we've to set headers like from id, reply to, return path, mime version, char type and charset.. I have set all of them, but still email goes to SPAM folder into my Gmail / Yahoo id, any clue?
All email addresses, which I am using in from/to/replyto/return path existing in real and still it goes to SPAM, very strange !
What i've found locally that sendmail_from was not set into my WAMP, and once i used,
ini_set('sendmail_from', 'some_valid_email_address'); it gets to Inbox !
Wohaaa... and working into live as well..
Take a close look at the SMTP headers from the messages that are getting flagged as possible spam. Many spam filters will add a few lines listing the reasons a message was flagged; for example, if the sending IP address is blacklisted for some reason, there might be a header describing which blacklists you're listed in.
That is one of the issues with mail function. The better solution is to go for either of these:
Swift Mailer
PHPMailer
One thing to do is to make sure that your HTML validates. It turns out that spammers are generally incapable of writing validating HTML and so this a huge tip off.
Another possibility is that you're on a shared host with another user that's a spammer. In this case, the whole IP range may have been banned.
Also, using red in your CSS and spammy words (think "free", "viagra", "act now", "sale", etc) are tip offs that some spam filters use.
The biggest thing that you can do to keep your emails out of spam folders is to only send emails to people that request them. This will keep people from reporting you as spam. If a lot of your emails get reported as spam, then your emails will get put in spam folders.
try not including the "From: " this which might let the server think that you're spoofing.
I had the same problem and nothing worked.
I found out, that no line in the message is allowed to have more than 70 characters.
Solution is to add wordwrap after the message.
$message= wordwrap($message, 70, "\r\n");
Let me explain what I mean in my title. Let's say, that for example I'm creating a small e-commerce system for one web shop/catalog. There's a possibility for customers to choose, do they wish to receive newsletters or not. If they do, then logically thinking the newsletters should be send immediately as the newsletter is formed and ready.
Of course it can be done simple by fetching all specified user e-mails from database and using for cycle to send mail via mail function in loop, but problem is that I was told, that this is bad practice. The simple and not cheap way would be purchasing internet service for sending newsletters, but what for the php programmer is needed, then?
So I ask you humble comrades, what from your point of view might be a solution?
NB! You probably won't believe me, but it is not for spamming.
UPD: I might have explained myself wrong, but I would like to hear a solution not only about the correct way to send mail, but also about the correct delivery. Since not every mail send is always delivered.
Of course there are some reasons, which are unpredictable. For example someplace along the way something broke and mail was lost (if such thing is possible), but there are also other reasons which are influenced maybe from server or elsewhere. Maybe there is need to talk with hoster about it?
There is no reason why you couldn't write it in PHP, although I would not make it a part of a webrequest / HTTP process. I've successfully implemented for give or take 500,000 subscribers per mailing (depending on local data available, as this was a location-specific project). It was an in-house project, so unfortunately no code/package for you, but some pointers I came across:
Setting up delivery
Started out with phpmailer itself, to take care of formatting, encoding of contents and headers, adding of attachments etc. That portion of it works well, and I wouldn't want to write that from scratch.
The 'sending' of an email itself is just setting some flag in a database whether / how / what should be sent to (a portion of) the subscribers.
After this flag is set, it will automatically be picked up by a cronjob, no more webserver involved.
I started out with a heavily polluted database with millions of email addresses, of which a lot were obvious not valid, so first thing was to validate all email addresses for format, then for host:
filter_var($email, FILTER_VALIDATE_EMAIL); over the subscribers (and storing the result obviously) got rid of the first few hundred thousand invalid emails.
Splitting out the host (and storing the host name) from the emails, and validating that (does it have an MX or at least an A record in DNS, but keep in mind: you can send email to an IP-address foo#[255.255.255.255], so do keep those valid)) got rid of a good portion more. The emailaddresses here are not permanently disabled, but with a status flag that indicates they're disabled because of the domain name / ip.
Scripts were changed to require valid emailaddresses on subscription / before insertion, this nonsense of 'you aint gonna get it#anywhere' subscription-pollution in the database was just ridiculous.
Now I ended up with a list of email addresses that had the potential of being valid. There are in essence 3 ways to detect invalid addresses (keep in mind, the all can be temporary):
They are denied immediately by the server.
The earlier determined server just doesn't listen to traffic.
They are bounced long after you thought you delivered them.
Strange thing, the bounces, which every emailserver seems to have another format forand were a hell to parse at first, ended up actually pretty easy to capture using VERP. Rather then parsing whole emails, a dedicated email address (let's call it mailer#example.com) was configured to rather then deliver to mailbox, to pipe it through a command, and if we sent email to user#server.tld, the Return-Path was set for mailer+user=server.tld#example.com. Easily parsed on receipt, and after how many bounces (mailbox could not exist, mailbox may be full (yes, still!), etc.) you declare an emailaddress unusable is up to you.
Now, the direct denial by the server. Probably we could have gone with properly configuring some MTA and/or writing plugins for those, but as the emails were time-sensitive, and we had to have absolute configurable control per mailing over last usable delivery time (after which the email was not longer of interest to the user), throttling per receiving server, and generally everything, it would take about the same time writing a mailer in PHP which we knew better, that used the SMTP protocol directly to socket 25 on receiving servers. With a minimum amount of effort the possibility of another transport then the default choices in PHPMailer was built-in. The SMTP protocol is actually quite simple, but there are some caveats:
A lot of receiving server apply Grey Listing: most spambots will not really care if a specific mail arrives, they just churn them out. So, if an unknown / not yet trusted sender send mail, it will be temporarily rejected. Catch that (usually code 451), and place the email in the queue for later retry.
A mailserver, especially of the larger ISP's and free services (gmail, hotmail/msn/live, etc.) will not stand for a torrent of mail without fighting back: after the first couple of hundred / thousand, they start rejecting you. More about that later.
Getting speed
Now, we had a delivery system that worked, but it needed to be fast. Sending a 10,000 emails in an hour is all fine if you only have 10,000 addresses to send to, but the minimum we required was about 200,000 per hour. Start of it was a dedicated server (which can actually be pretty low powered, no matter what you do, most of time taken in delivery of email is in the network, not on your server).
Caching of IP's: remember all those IP's we requested from hostnames in email addresses? We stored those obviously, and looking up their IP's again and again causes considerable lag. However, IPs may change: a DNS record there, another MX at another place... the data gets stale fast. Most of the time the server isn't actually sending anything (subscription newslettters come in bursts obviously), a low-priority cronjob is running checking all hostnames with a stale IP (we chose older then 1 day as being stale) for an IP address, including those which previously had none (new domains get registered all the time, so why shouldn't a domain become available the day after someone already enthusiastically subscribed with his/her brand new email address? Or server problems with some domain are solved, etc.). Actually sending the emails now required no more domain lookups.
Reuse of the SMTP connection: setting up a connection to a server takes relatively a large portion of the time to deliver an email when you're talking directly to port 25. You don't have to setup a new connection for every email, you can just send the next over the same connection. A bit of trail-and-error has resulted in setting the default here to about 50 emails per connection (assuming you have that many or more for the domain). However, on failure of an emailaddress closing and reopening the connection for a retry sometimes helped. All in all, this really helped to speed things along.
Some obvious one, so obvious I almost forgot to mention it: it would be a waste to have to create the body of the email on the spot: if it's a general mail, have the body ready (I altered PHPMailer somewhat to be able to use a cached email), possibly days before (if you know you're going to send a mail on Friday, and your server is idling, why not prepare them on Wednesday already? If it's personalized, you could still prepare it beforehand given enough time, if not, at least have the non-personalized portions waiting to go.
Multiple processes. Did I mention much of the time it takes to deliver email is spend on the network? One mailing process is not nearly getting the most from your emailserver, barely noticable load and the mails are trickling out. Play around with a number of processes mailing different portions of the queue to see what's right for your server/connection, but remember 2 very important things:
Different processes make you very vulnerable to race conditions: be freaking absolutely sure you have a fullproof system that will never send the same mail twice (thrice, of even more). Not only does it seriously annoy users, your spamrating goes up a notch.
Keep domains together where possible: randomly picking from the queue you will lose the advantage of keeping an open connection to the server receiving email for the domain.
Avoiding rejects
You're going to send a lot of mail. That's exactly what spammers do. However, you don't want to be seen as a spammer (after all, you aren't, are you)? There are a number of mechanisms in place which will thoroughly increase your trustworthiness to receiving servers:
Have a proper reverse DNS: processes checking the DNS belonging to the IP that is sending the email like it very much if the second level domains match: are you sending mail on behalf of example.com? Make sure your server's reverse DNS is something like somename.example.com.
Publish SPF records for your domain: explicitly indicate the machine used to send your bulk email is allowed & expected to send mail with that From / Return-Path headers.
remember rejects: servers don't like it to tell you again and again that different email addresses don't exist. Either automated mechanisms, and even human admins, blocked our server while we worked through all non-validated email addresses that did (no longer) exist. We didn't employ a double opt-in until later, so the database was polluted with typos, people switching IPs and thereby email address, prank email addresses and so on. Be sure to capture those invalids, and given enough or sever enough failures, unsubscribe them. They're doing you no good, they're hogging resources, and if they really want you mail and the mailbox becomes available later, they'll just have to resubscribe.
DKIM is another mechanism that may increase your trustworthiness, but as we haven't implemented it (yet), I cannot tell you much about that.
MX records: some servers still like it if your sending server is also the receiving server for the domain. As it was at the time, we had only 1 MX, and as the mailing server was still not that very busy, we dubbed it the fallback MX server for the domain. The normal MX server was not the server sending the subscriptions, as it is very irritating to be temporarily blocked by a server you're trying to send an important email to (clients etc.) because you already sent a load of less important mail. It does have the highest preference as receiving MX, but in the event it would fail we had the nice bonus that our subscription sending server would still be fallback for delivery, so in crisis we could still get to it, preventing awkward bounces to customers trying to reach us.
Tell them about you. Seriously. A lot of major players in free email addresses like live.com offer you the opportunity to sign up in some way, or have some point of contact to go to for help & support if your emails get rejected. I you have a legitimate reason to send so many emails, and it is believable you have that many subscribers, chances are they seriously up the number of emails you can send to their server per hour. A meager 1,000 may become somewhere in the ten-thousands or even higher if you are persuasive and honest enough. There may be contracts, requirements you have to fulfill, and promises you must make (and keep) to be allowed this. ISP's are a brand apart, and every other player is different. Don't bother calling them usually, because 99% of the time the only numbers you can find will only have people willing to troubleshoot your internet connection, which understand (or are allowed) little else. An abuse# email address is a good place to start, but see if you can delve up a more to-the-point email address up from somewhere. Be precise, honest and complete: roughly how many subscribers of you have an emailaddress with that ISP, how often are you trying to mail them, what are the errors or denials you receive, how is the subscribe & unscubscribe process like, and what is the service you actually provide to their customers. Also, be nice: how vital sending those mails may be to your business, panicking about it and claiming terrible losses does not concern them. A polite statement of facts and wishes, and asking whether they can help rather then demanding a solution goes a very long way.
Throttling: as much as you tried, some server will accept only a certain amount of mail per hour and/or day from you. Learn those numbers (we're logging successes & failures anyway), set them to a reasonable default for the normal domains, set them to agreed upon limits for bigger players.
Avoiding being tagged as spam
First rule: don't spam!
Second rule: ever! Not a 'once off', not a 'they haven't subscribed but this may be the deal of a lifetime to them', not with the best intentions, people have had to ask for your emails.
Obviously set up a correct double opt-in subscription mechanism.
PHPMailer does set proper headers on its own,
Set up an easy unsubscribe mechanism, by web (include a link to it in every mail), possibly also email and customerservice if you have it. Make sure the customerservice can unsubscribe people directly.
As said earlier: unsubscribe (excessive) fails & bounces.
Avoid spammy 'deal of a lifetime' wordings.
Use url's in your emails sparingly.
Avoid adding links to domains outside your control, unless you are absolutely sure you can trust them not to spam, if even then...
Provide value to the user: being tagged as spam by user-interaction in google/yahoo/live webmail clients seriously hurts future successes (on a site note: if you sign up for it, live/msn/hotmail will forward all mail to you send by your domain which is tagged as spam by users. Learn to love it, and as always: unsubscribe them, they clearly don't want your mall and are hurting your spam rating).
Monitor blacklists for your IP. If you appear on one of those, it's bye bye, so immidiate action in both clearing your name and determining the case is required.
Measuring success rate
With the whole process under your control, you are reasonably sure the email ended up somewhere (although it could be the MX's bitbucket or a spam folder), or you have logged a failure & the reason why. That takes care of the 'actually delivered' numbers.
Some people will try to convince you to add links to online images to your emails (either real or the famous 1x1 transparent gif) to measure how many people actually read your email. As a high percentage blocks those images, these numbers are shaky at best, and our believe is we just shouldn't bother with them, their numbers are utterly unreliable.
Your best bet for measuring actual success rate are a lot easier if you want the users to do something. Add parameters to links in the mail, so you can measure how many users arrive at the site you linked, whether they performed desired actions (watched a video, left a comment, purchased goods).
All in all, with all the logging, the user-interface, configurable settings per domain / email / user etc. It took us about 1,5 man-month to build & iron out the quirks. That may be quite an investment compared to outsourcing the emails, it may be not, it all depends on the volume & business itself.
Now, let the flaming begin that I was a fool to write an MTA in PHP, I for one thoroughly enjoyed it (which is one reason I wrote this huge amount of text), and the extremely versatile logging & settings capabilities, per-host alerts based on failure percentage etc. are making live oh so easy ;)
Using something like Swiftmailer, PHPmailer or Zend_mail are much better alternatives to using the simple mail() function as it can be easily marked as spam. There are simply too many issues with mailing that need to be considered - most of these are solved by using pre-existing libraries.
Just a few problems that need to be addressed when sending mass emails manually:
Using incorrect headers.
Processing bounced messages
Timing out of script due to an influx of emails.
Edit:
Probably not the answer you're looking for. But, I would strongly suggest you invest in something like Campaign Monitor or Mail Chimp. Since this process is not for educational purposes, but commercial, I would strongly suggest the above services.
I got your question, but before replying, let's me go to usual considerations. First, I strongly recommend using a service like Mail Chimp. It's kinda free for small jobs, and has many cool features, like tracking back how many emails were open, how many were clicked, how many failed on deliver... Think about make a favor to yourself and don't reinvent the wheel.
Now, for getting to know purpose, let's go to the reply to your question.
First thing to have in mind is to enforce your list to be a good one. How to do that? Well, for a good list, I mean a valid email addresses list. Simple put a newsletter form on your page, with just one field (maybe a captcha, but I don't think it is necessary).
Save all input to a database table, with a field "isValid" set as false by default, and any kind of unique hash. Then you send a confirmation email, with a link (with the hash generated) for confimation which when clicked will make the "isValid" flag true, and a link for cancelation (ALWAYS send this cancelation link within all your emails).
This is what stores and serious sites do. Anything that force your customers/visitors to receive is a bad moral practice (ie, spam).
Second thing, use a good hosting service. Too cheap services usually are used by spammers, and major email services blacklist everything coming from those addresses.
I know, you should be asking yourself if I get your question wrong. No, I don't, technical stuff comes now.
Why is a bad practice put a mail function inside a for loop? Simple. Because function mail do several operations everytime it is called. PHP, will open a connection to mail server, send data to be parsed, ask for sending, register mail server status, close connection, bubble up status to finish the mail function you called and clean up the memory mess.
This connection overhead is the problem people state as bad practice from programming point of view. Using a SMTP/IMAP solution is better because it optimizes this process.
A little bit down on tech stuff I see your questions about delivery. Well, as I said, you have some ways to ensure you emails list is good enough. But what if another exception occurs, like having a blackout + no-break failures on customer server?
Well, PHP keeps the status of "asking mail server to send, mail server sent". If the mail server sent your message, PHP will return true. Period.
If client was unable to receive, or reject, you should check email headers and email status. These are on email server. Once again, these informations can be accessed with SMTP/POP/IMAP extensions, not with mail function.
If you wanna go further, read IMAP docs, search for email classes (phpclasses.org, pear and pecl are best places to look into).
Extra tip: RFCs can be useful, as you can understand better what email servers really talks to each other.
Extra tip 2: Access you gmail or ymail and check for your sent/received messages for their "full version" and read its headers. You can learn a lot with them.
Via SMTP Authentication: http://www.cyberciti.biz/tips/howto-php-send-email-via-smtp-authentication.html
Just use PHP Mail and study IMF and how to build custom headers you can attach the fourth parameter, exmaple follows
<?php
// multiple recipients
$to = 'aidan#example.com' . ', '; // note the comma
$to .= 'wez#example.com';
// subject
$subject = 'Birthday Reminders for August';
// message
$message = '
<html>
...
</html>
';
// To send HTML mail, the Content-type header must be set
$headers = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
// Additional headers
$headers .= 'To: Mary <mary#example.com>, Kelly <kelly#example.com>' . "\r\n";
$headers .= 'From: Birthday Reminder <birthday#example.com>' . "\r\n";
$headers .= 'Cc: birthdayarchive#example.com' . "\r\n";
$headers .= 'Bcc: birthdaycheck#example.com' . "\r\n";
// Mail it
mail($to, $subject, $message, $headers);
?>
Source: http://php.net/manual/en/function.mail.php
create a mail queue subsystem which might include tables such as mail_queue, mail_status, mail_attachments, mail_recipients and mail_templates etc...
You might consider PHPMailer
http://phpmailer.worxware.com/index.php?pg=exampleasendmail
You can add multiple recipients and a special callback function for handling the returning messages for every single mail sent. (for an example visit the link)
I Don't think that catching a "mail delivery failed" error mail is possible via php except that you are using PHPMailer via SMTP and once in a while watch for any returning message form any recipient in from your outgoing email collection.
this is my first question on StackOverflow, but I think that we'll both come to the happy end. :) The problem is: I've got newsletter script written in PHP and when I send those emails to the various accounts they are put in the spam folder. Here is what I get in mail headers:
X-Spam-status: Yes, score=5.01 tagged_above=1 required=4.5
tests=[HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001,
HTML_TAG_BALANCE_BODY=0.712, MIME_HTML_ONLY=1.105, MISSING_DATE=1.396,
MISSING_MID=0.14, RCVD_IN_BRBL_LASTEXT=1.644,TO_EQ_FM_DOM_HTML_ONLY=0.001,
T_FRT_CONTACT=0.01] autolearn=no
And here are my questions:
What is that and how to fix status RCVD_IN_BRBL_LASTEXT? I haven't found anything informative googling that phrase.
How to fix MISSING_DATE status? I've put in the code generating whole email:
$mailHeaders[] = "Date: ".date('Y-m-d H:i:s', time());
but with no success. "Date" fields comes only as H:i (13:45, for example) - Thunderbird 3.1.3 FYI. Searching on SO didn't help me. I have also tried adding Delivery-Date status - still nothing.
RCVD_IN_BRBL_LASTEXT indicates that your email has been flagged by the Baracuda RBL, which is a service which tracks IP addresses that have been known to send spam.
Possibly your newsletter has been flagged up as spam in the past? or possibly its the ISP you're using to route your email which has been responsible for some spam. Either way, this particular point isn't an issue with your mail headers.
The missing date is the important one which will bring your points below the threshold.
The date format you need looks like this: Date: Wed, 15 SEP 2010 14:12:27 +0100
Most of that is self explanatory (the last bit is the time zone), and it looks like you know your way around the PHP date function, so hopefully that should sort you out. But I found this page helpful as a walk-through of a legitimate email header format.
The challenge with bulk email sending is that there's so many different factors that could throw you off and get you blocked as spam. Headers tell you what's going on, but in the grand scheme of things they're not one of the biggest challenges.
My company sends 50000+ emails per week, sometimes that many per day. Here's what we've learned:
1) If your server hasn't established "reputation" with email hosts, you're more likely to get flagged. There's no great way to establish it, though sites like Socket Labs simply throttle down new clients in the beginning and after 60-90 days release that throttle to allow more email to go through. As many emails as Socket Labs processes, it tells me it's a valid practice.
1a) Monitor the RBL list to ensure you're not on it. If you do get flagged (happens to just about everyone at some time or another) aggressively work to get yourself off ASAP. Contact the RBL in question and work with them to quickly right the situation.
2) The "big guys" including Gmail, Yahoo, AOL, and MSN are sensitive to being rapidly hit by the same host in succession. My company has chosen to overcome this by keeping track of who our email processes are sending to via a "log" If the next email has the same domain as the previous sent, we wait a period of time. If not, we fire at will. It prevents our system from sending more than 1 email per X seconds to the same host, and has meant our emails are getting through at a very high rate.
3) AOL mail is borderline worthless. I saw a stat once that someone had proven something like 20% of email sent to AOL just "disappears" I'm not sure if it's that high, but I know we have nothing but problems with getting AOL email through...it's the nature of the beast. The good news is that AOL is on its way out, so we shouldn't have to deal with it on this level too much longer.
4) The obvious step is to ensure that you're doing the best you can to stay CAN-Spam compliant. Include a real-time opt-out, company information in the footer, and don't try to deceive with your message.
5) Finally, don't send email to people who haven't requested it. It seems like a silly easy step, but it's abused SO much. You won't be flagged as spam if you send to people who want your email...it's that easy. If you get a bounce, process it out of your list immediately so that you're not trying to resend to a bad account.
Good luck.
The X-Spam-Status header is being added by a Barracuda spam filter, and what you're seeing is diagnostic information it attaches to explain why it marked the message as spam.
Barracuda is a rules-based engine, and as you guessed, the score you're getting (5.01 in the example above, though you say you fixed the date so your score may be lower) is above the allowed threshold.
Since the highest-weighted signal is the RCVD_IN_BRBL_LASTEXT field, you're likely getting dinged primarily because your IP address is in their Real-time Block List (RBL). It's possible you can find the data source that hates your IP -- check http://www.spamhaus.org/lookup.lasso to see if it's Spamhaus that has tagged you -- and convince them to remove you, but more likely the best path is to use an IP that's already been groomed to have a good reputation. Two providers you may wish to check out are http://sendgrid.com and http://authsmtp.com, both of whom will allow you to proxy your traffic through their servers (assuming your content isn't likely to be voted as spam).
Hope that is helpful.
I have been trying to get PEAR::mail to successfully deliver emails to hotmail users without being flagged as SPAM and ending up in the junk folder, i have no problems with yahoo/gmail only with hotmail.
google suggested that this is a common problem with hotmail and that possible causes can include
incorrect reverse DNS for main IP of the server
lack of SenderId/SPF records
being blacklisted
having checked all of the above i can only think of one other reason - incorrectly formatted headers ?
to test this theory i set up outlook to send email via the same address that PEAR::mail uses and sent a quick test - it delivered straight to my inbox
so i compared the headers from the email sent from PEAR::mail against the headers sent by Outlook and there are only a few differences - i have only listed the differences to save space (and peoples eyes)
PEAR::mail headers (not in outlook headers)
X-PHP-Script: www.example.com/register.php for [users ip address]
Outlook headers (not in PEAR::mail headers)
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Ack6CWSQlgV8s6+6SWyifka2NNpB7g==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
the only other differences that i can see are
the order of the From: and To: headers are reversed
and in the Received: section of the headers
Outlook
Received: from myhomehostname.com ([ip address] helo=simber)
by mywebhostname.com with local (Exim 4.67)
PEAR::mail
Received: from apache by mywebhostname.com with local (Exim 4.67)
could these small differences in the headers be the cause or am i looking in the wrong place ? i knew this might be problematic hence why i chose to use the PEAR::mail class rather than rolling my own but now i really have no idea where to go with this, any help would be greatly appreciated.
Update: as per changelog's suggestion i have tried adding the MS headers to the PEAR::mail class and i have tried replacing PEAR::mail with PHPMailer (with & without the extra headers) - they all end up in the junk folder.
I am starting to believe that it may not be the headers afterall.
Update 2: i should have mentioned that the emails are just a registration confirmation to validate the email address the user signed up with - no mailshots etc so our volume is extremely low.
I have considered warning users who provide a #hotmail/live email address to add us to their address book or check their junk folder - but this just seems unprofessional to me - it may be that i have to resort to this.
As for becoming Sender Score Certified - its very unlikely that i can justify the cost of this when considering the low volume and purpose of these emails.
My company does professional e-mail marketting campaigns (through strongmail servers) we send thousands of (sollicited) emails a day to all kinds of addresses.
The problem you are facing is that you have no authority. You could just be some spammer trying to send loads of spam.
The thing you need to do is:
Add unsubscribe links
Apply for hotmail's Junkmail reporting program (JMRP) and MAKE SURE people that press the 'this is junk' button do not get mailed again. This will up your 'sender score; # hotmail and allow you messages to get through.
Add SPF and other antispam solutions.
Do not send more than 50 e-mails per minute to #hotmail.com (other domains have other limits)
B.t.w we use PHPMailer to compose our messages, no problem at all with that :-)
The problem nowadays really is the restricting receiving mailservers.
Email Deliverability is closer to an art than a science. I can pretty much guarantee that it has nothing to do with your headers. Trying to spoof headers is likely the worst thing you can do. The received: header is added by the mail servers as they receive the messages: spoofing this will cause your email to get flagged as spam: one of the spam filters commonly used is to count then number of relays (ie received: headers). If there's too many you get a higher spam score.
Reverse DNS and SPF are the minimum entry barriers. For hotmail in particular, there are three other very important factors AFTER you get your SPF and DNS records in line:
IP/Domain Reputation
Volume
Being in the Address Book
Reputation isn't the same as being blacklisted. You need to build trust with hotmail. Hotmail uses Sender Score Certified as their main reputation broker -- you can check your reputation with them if you want, but it may cost you.
If you're on a shared host or an IP address that has a checkered past, you won't have much luck with hotmail.
You build reputation by having a consistent volume with low spam complaints. You can send 1M messages an hour all day long, as long as you do it every day. If you're sending less than 10,000 messages a day, you likely won't be able to build up a decent reputation. You can get a report on your volume at Sender Base.
Finally, the best way to make sure you end up in the inbox is to get your users to add the sending email address to their address book. Hotmail uses this as a safe sender list. In fact, I think there's an additional trusted sender option in Hotmail now too (it's been awhile since I've been in the delivery game and I don't use hotmail).
Here are some other best practices for sending email:
ALWAYS use the same IP address
ALWAYS use the same FROM address
if you have a large list that you send newsletters to, make sure you retire old addresses (ie, check open rates)
if you have a large list, try segmenting it and sending from different IP addresses based on risk (ie, newer addresses may mark the message as spam)
I have always used PHPMailer in my projects, and what I did to avoid Hotmail's junk folder was to call a method they had that added MS Headers to the message.
Take a look at the source, and add those headers yourself.
Also, I recommend including a text-version if you're sending HTML e-mail.
I'd suggest modifying the headers you send to match 100% what outlook sends, and see if that solves the problem. Really it's a tough one though, hotmail is known for having a super crappy spam filter, sending lots of legit email to junk, and lots of spam to your inbox.