I'm using the mail(); function and it's working but sometimes it returns an error 553. I heard it could be because of:
You are attempting to send email to a domain that is not recognized by this server
You are attempting to relay email through this server, and have not authenticated
(source: http://www.error-553.net/)
Since it is sometimes working I guess the domain is unrecognizable but how do I overcome this error?
EDIT: I think the problem doesn't come from any of this source, first as I said it is sometimes working AND it is also sometimes working with the domain I'm trying to send email to.
Thanks.
Before sending your mail, check that the domain:
Exists
Has an MX record that is valid
Is not blacklisted
And in addition, that your local mailserver allows you to relay emails to the outside.
Points 1 and 2 are solved in an easy fashion: getmxrr("domain.name.com",$arrayOfHosts) will return true if it finds MX records.
Point 3 depends on which blacklist you want to use. I personally like SBL, which just requires a reverse DNS lookup.
Related
This is an issue I've encountered several time and haven't yet found a decent solution for:
Sending an e-mail from a webserver on e.g. "domain.com", to info#domain.com which is hosted on an external mail server e.g. Google Mail
In my case I always send from PHP over Apache and often on shared hosting, but I can imagine this is the same case on other frameworks.
These e-mails always seem to be delivered to the local mail server, even if I set the MX records on that server to point to the right external mail server.
A solution for this is to use an external SMTP server, but this isn't always easy when you're working with clients that either need to set-up a new e-mail account on their server and provide the SMTP details or sign-up for a third-party SMTP server.
What is the solution for this? Is there no way around SMTP?
Most emai/MTA server "autoconfigure" themselves. They guess list of local email domains (doimans with locally hosted mailboxes).
In sendmail case you can turn it off adding the following line in sendmail.mc:
define(`confDONT_PROBE_INTERFACES', `True')
Documentation : cf/README - confDONT_PROBE_INTERFACES
I have had the same issue many many times (in my case using PHP on a LAMP stack).
Try/check the following.
If you are using cPanel or similar, set the MX records to the external mailserver (Google apps etc).
Set up an SPF record to allow your hosting website to send email (this way no need to configure SMTP).
This may not be applicable but if you are using something like phpmailer. Set the property $mail->isMail(); so it tries to use your SPF allowed local mail() function to send the email. Sorry for going off into very specific advice, but might help in your particular situation.
Worth checking there are not similarly named local mailboxes on your hosting box.
Hope this helps!
I have an application hosted on amazon EC2. Now a user can send out invitations to join but on most email clients its showing up in the spam folder. Is there anyway to find out on what criteria it is actually being filtered.
First of all, please check to see if your domain/IP has landed on any blacklists:
https://www.mxtoolbox.com/blacklists.aspx
Second of all, have you set an SPF record? Explanation below:
http://www.openspf.org/Introduction
https://mxtoolbox.com/spf.aspx
This is a way to qualify a particular server/IP as being a valid for relaying/sending mail on behalf of a particular domain. Sendmail - or whatever PHP is configured to use to send mail - can actually send mail for any user on any domain (i.e. "spoofing"). However the server receiving the mail (e.g. a recipients POP3 server where received mail is stored and filtered) is probably going to check whether or not that server is supposed to be sending mail for that domain based on what's in the domain's DNS entries. In particular, it will probably check the SPF record, so you will need to set this. You should consult whichever service manages your DNS (i.e. your nameservers) for how to do this. You can look up where your nameservers are using the whois, dig or nslookup commands (or just use a web based whois service) - look for the "nameserver" entries, often denoted by "ns".
This is one of a number of factors that may be affecting whether or not your mail goes to spam. This subject is something of a "can of worms" and goes way beyond setting up your PHP mail function correctly. Rather than trying to reiterate all of these issues here, I'll direct you to this post on serverfault:
https://serverfault.com/questions/106598/all-my-emails-to-yahoo-hotmail-and-aol-are-going-to-spam-though-ive-implemen
Do you use 5th parameter in mail function?
mail('reciever#address.com', 'the subject', 'the message', null,
'-fyour#address.com');
It helps sometime.
Also maybe your IP was blocked before you start to use it.
I'll try to explain the problem we have at my company the best I can :
So I have several forms across different servers. All are sent up to send emails with the mail() function in PHP to the email address email#ourcompany.fr
Now I've noticed a weird behavior : when the forms are hosted on our server (I'm talking about our apache server, the mails are handled by an exchange server) they arrive fine at the address up there.
But when the forms are hosted anywhere else on the internet, the emails arrive at the address email#ourcompany.es
What could the problem be ? SMTP configuration ? A set of rules at the exchange server ?
I am pretty much a newbie when it comes to emails and how they're handled when they're sent...
Thank you for your help.
EDIT: As per MarcB recommendation I tried the following in the shell :
XXXX:~$ nslookup -type=mx securitasdirect.es
Server: 10.40.144.166
Address: 10.40.144.166#53
securitasdirect.es mail exchanger = 10 smtp.securitasdirect.es.
XXXX:~$ host -t mx securitasdirect.fr
securitasdirect.fr has no MX record
XXXX:~$ host -t mx securitasdirect.es
securitasdirect.es mail is handled by 10 smtp.securitasdirect.es.
Alright so based on your update... and running dig from my local machine to confirm, your securitasdirect.fr domain has no MX records setup on the publicly accessible DNS servers.
Internally in your network, it's possible (likely even) you use different DNS servers which have MX records and hence internally you can deliver email to #fr while externally it's not working.
Update not sure if you're changing things as I write this answer, but it seems like I'm now getting a valid MX return for securitasdirect.fr.
Beyond that, securitasdirect.fr fails the rDNS test (see: http://www.mxtoolbox.com) while securitasdirect.es passes. It's possible this is also interfering with mail delivery.
I have some problems with the email system for CodeIgniter:
First, the emails I send out (registration, confirmations) are getting caught in standard spam filters in gmail and other mail clients. How do I get around this? How do companies like Facebook get their emails through consistently?
Second, the mailer is working locally but once we deploy it it no longer runs (doesn't send emails) but all the other forms run just fine. Anyone ever run into a problem like this?
Thanks for all the help!
I can't really answer your first question - it's not specific to CodeIgniter. You just need to make sure your email doesn't look like spam. In short - there's no way of guaranteeing your e-mail will not end up in a spam filter.
As for the second question, I expect your production server needs to be configured properly for email. You probably need to configure CodeIgniter to send email properly. I would suggest setting up an SMTP server (or using an existing one) rather than using the standard PHP mail which I think CodeIgniter uses by default.
Regarding spam, most organisations are very secretive about how they prevent spam (not wanting to publish information which helps the spammers) and in some cases they don't actually know - an obvious examlpe of this is bayesian filtering - but, for example, hotmail use a completely unaccountable army of volunteers to manually classify emails.
Do and get a copy of spamassassin and try to reverse engineer how the standard rules work. Obvious things to check are:
1) AVOIDING LOTS OF CAPITALS
2) don't mention the 'V' word
3) make sure you've got a current and restrictive SPF 1.0 policy published
4) make sure your sending from an address which has A and PTR DNS records
5) Do provide a reply-to and from email address which use your domain in the address
the mailer is working locally but once we deploy it it no longer runs
doesn't send emails
Which? These are 2 totally seperate things. If the code is falling over (if so why have you not provided the error details) then its likely a PHP version issue or a problem with the connection to the MTA (or the PHP mail config).
The latter is a problem with the MTA itself.
99.9% of problems reported as PHP mail failures have nothing to do with PHP and are problems with the MTA.
Enabled detailled error reporting for your MTA and see where it is failing.
C.
You may have to configure the email on your server differently than your local development environment. I've had to in the past.
There are two basic ways that PHP can send mail:
Via a UNIX program called "sendmail" (only on non-Windows servers and only if it is installed - check with your hosting provider)
Via a SMTP server.
If you've configured CodeIgniter to use SENDMAIL, check to ensure that the Sendmail path is correct. Your hosting provider usually provides this somewhere in their online documentation.
If you're using SMTP, you need to make sure that your server can contact the SMTP server. You can do this by logging into the server via SSH and typing "telnet your.smtpserver.com 25". If you get an error message about not being able to connect, you know you have a problem with your hosting provider connecting to your mail server.
I've been able to diagnose this problem by enabling logging on my production server (http://bit.ly/4pprd6) and adding log_message('error', $this->email->print_debugger()) right after I attempt to send a message.
I have set up an AJAX contact form on a client's website.
The problem is that the email is not getting through to the client's inbox.
I set up the client with Google Apps (in the same way I did for myself).
I used the same contact form with my email address and it works. But with any email addresses on their domain it doesn't!
All members of the domain are receiving 'ordinary' emails.
What could be the difference that's stopping mail() emails getting through?
UPDATE
Ok so I managed to solve it. Turns out that using a CNAME to point the domain to the correct server wasn't enough for sendmail so I had to change it to an A record pointing directly to the server. Strange but true. Thanks for the help folks, you pointed me in the right direction :)
It depends on the both settings on your server and the server on the receiving end.
hotmail for example requires the use of correctly configured SPF records.
many mail-receiving servers (including hotmail) require the email to originate from a Fully Qualified Domain Name. It is very possible that your e-mails send from PHP do not comply with this rule. (there is a good chance they originate from 'apache')
see hotmail self help and hotmail postmaster info
PHP's mail() function does not include a lot of headers with your mail, so you will need to supply them yourself.
The more hops your mail makes on it's way to it destination, the more likely it is to be tagged as spam.
So it might be a better option not to use PHP's mail function and instead use a mail library that connects to an SMTP server just like your desktop mail application does.
All in all, I would place my bets on an external library: Pear::Mail (documentation)
You could also read: how do you make sure email you send programmatically is not automatically marked as spam
UPDATE
Failing the SenderId or SPF check can get your message dropped before it even hits the users inbox. The message will not end up in the users junk folder, it will go directly to /dev/null.
I know this is at least true for hotmail and live mail. I see no reason for other hosts not to have implemented the same policy.
I recommend using PHPMailer (including their SMTP) library instead. It is reliable compared to mail and allows you to create fully customized emails.
http://phpmailer.worxware.com/