When registering, users get the following error message: "Unable to send e-mail. Please contact the site administrator if the problem persists." This error message comes from the drupal_mail() function, which calls drupal_mail_send(). drupal_mail_send() wraps PHP's mail() function, which appears to be returning false. Unfortunately, the way Drupal does registration, users cannot log in until they receive a one-time login link via email, so until this is resolved, new users cannot register on the site. The Drupal error log doesn't report anything particularly useful: "Error sending e-mail (from email@example.com to ,..)."
Looking into it.
Assignee: server-ops → aravind
Has this worked in the past?
sendmail on the server itself is setup correctly, I was able to send out test mails to myself (on both moco and non-moco addresses). Where is the app configuration for smtp?
The site was recently moved to a new server, but sending mail has been working since the move. I don't think the application has used smtp traditionally and relied instead on the local mta. Here are headers from a previous email sent from that server: Delivered-To: firstname.lastname@example.org Received: by 10.229.106.213 with SMTP id y21cs99921qco; Thu, 17 Jun 2010 11:59:53 -0700 (PDT) X-pstn-nxpr: disp=neutral, email@example.com X-pstn-nxp: bodyHash=c8623de46fc0da86d27e7f2c496149c7e8067917, headerHash=143886aa4c97ec8f0d62cd2824d9797e6f8507bd, keyName=4, rcptHash=37c53cdeea49e2e133086f4def5afd4d21ad7d96, sourceip=126.96.36.199, version=1 Received: by 10.114.249.17 with SMTP id w17mr8616708wah.146.1276801192727; Thu, 17 Jun 2010 11:59:52 -0700 (PDT) Return-Path: <firstname.lastname@example.org> Received: from psmtp.com (na3sys009amx243.postini.com [188.8.131.52]) by mx.google.com with SMTP id u14si19683170wak.120.2010.06.17.11.59.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jun 2010 11:59:52 -0700 (PDT) Received-SPF: neutral (google.com: 184.108.40.206 is neither permitted nor denied by best guess record for domain of email@example.com) client-ip=220.127.116.11; Authentication-Results: mx.google.com; spf=neutral (google.com: 18.104.22.168 is neither permitted nor denied by best guess record for domain of firstname.lastname@example.org) email@example.com Received: from source ([22.214.171.124]) (using TLSv1) by na3sys009amx243.postini.com ([126.96.36.199]) with SMTP; Thu, 17 Jun 2010 11:59:52 PDT Received: from pp-drumbeat01.phx.mozilla.com (unused-10-8-11-82.phx.mozilla.com [127.0.0.1]) by mxout-generic.mozilla.org (8.13.8/8.13.8) with ESMTP id o5HIxo4K012700 for <firstname.lastname@example.org>; Thu, 17 Jun 2010 11:59:50 -0700 Received: (from apache@localhost) by pp-drumbeat01.phx.mozilla.com (8.13.8/8.13.8/Submit) id o5HIxnva012699; Thu, 17 Jun 2010 11:59:49 -0700 Date: Thu, 17 Jun 2010 11:59:49 -0700 Message-Id: <201006171859.o5HIxnva012699@pp-drumbeat01.phx.mozilla.com> To: email@example.com Subject: Welcome to Test Project MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 8Bit X-Mailer: Drupal From: firstname.lastname@example.org Reply-To: email@example.com Errors-To: firstname.lastname@example.org Sender: email@example.com X-pstn-neptune: 0/0/0.00/0 X-pstn-levels: (S: 9.95355/99.90000 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-pstn-settings: 2 (0.5000:0.5000) s cv gt3 gt2 gt1 X-pstn-addresses: from <firstname.lastname@example.org> [202/9]
From the maillogs, it looks like mail from apache is flowing okay. Here is one sample. Jun 16 09:18:57 pm-drumbeat01 sendmail: o5GGIv0F012860: from=<email@example.com>, size=990, class=0, nrcpts=1, msgid=<201006161618.o5GGIvMZ012859@pm-drumbeat01.mozilla.org>, proto=ESMTP, daemon=MTA, relay=dhcp-10-2-11-241.mozilla.org [127.0.0.1] Jun 16 09:18:57 pm-drumbeat01 sendmail: STARTTLS=client, relay=dm-mail01.mozilla.org., field=cn_issuer, status=failed to extract CN Jun 16 09:18:57 pm-drumbeat01 sendmail: STARTTLS=client, relay=dm-mail01.mozilla.org., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256 Jun 16 09:18:58 pm-drumbeat01 sendmail: o5GGIv0F012860: to=<firstname.lastname@example.org>, ctladdr=<email@example.com> (48/48), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=120990, relay=dm-mail01.mozilla.org. [10.2.74.105], dsn=2.0.0, stat=Sent (Ok: queued as 6DC6EB8007)
Mail was being sent from the site on June 16th. Are there more recent examples (i.e. from June 19th?). Are you able to send mail like this? echo "hi" | mail -s"Test Message" firstname.lastname@example.org And have it queued successfully? If so, then clearly it's not a problem with the MTA configuration and I'll have to go back to the drawing board to figure out why the heck Drupal has decided that mail isn't fun anymore :)
(In reply to comment #6) > Mail was being sent from the site on June 16th. Are there more recent examples > (i.e. from June 19th?). Are you able to send mail like this? > echo "hi" | mail -s"Test Message" email@example.com Ah sorry, with all the mercurial stuff going on yesterday, that 16, appeared like a 19 (dyslexic?).. You are right, there are no e-mails in the maillogs after the 16'th. And yes, I am able to send e-mails from the command line (see comment 3). Were there any changes to the setup (drupal) on the 16'th?
Mmmm... this is a problem I encounter often when switching servers for a Drupal site. Can someone confirm the MTA is set up properly in the php.ini file? Look for lines similar to the ones below: SMTP = myserver.localnet.com sendmail_from = firstname.lastname@example.org sendmail_path = /usr/sbin/sendmail Unless these are there and the path is correct, you will keep getting messages like the one listed here. M
(In reply to comment #8) > Can someone confirm the MTA is set up properly in the php.ini file? Look for > lines similar to the ones below: Touching php.ini directly is almost always not the right answer. Each individual app should handle such settings on its own.
Yeah, but if drupal requires changes to php.ini, we have to just do it. Drumbeat.org is the only thing running on this machine and although it isn't ideal, if it fixes the problem, I'm all for it. Can someone check the php.ini file on the server? If php.ini has non-default sendmail configuration (i.e. pointing to a wrong path for a sendmail binary, bad config for smtp server, etc). re: comment #7, The site was moved to a new server on the 15th. I'm not aware of any config changes after that that could have an effect on mail.
Just to follow up, the default php.ini settings (i.e. all commented out) should be sufficient... iirc, php will use /usr/sbin/sendmail and other sensible settings. Hence why I'm wondering if there are some wacky settings in there or if the sendmail binary is in a non-standard location.
(In reply to comment #10) > Yeah, but if drupal requires changes to php.ini, we have to just do it. > Drumbeat.org is the only thing running on this machine and although it isn't > ideal, if it fixes the problem, I'm all for it. Drupal doesn't require changes to the basic php.ini in order to send e-mail. I've CC'd Alex Buchanan of WebDev, MoCo's resident Drupal expert. Maybe he can offer some advice. > Can someone check the php.ini file on the server? If php.ini has non-default > sendmail configuration (i.e. pointing to a wrong path for a sendmail binary, > bad config for smtp server, etc). If somebody has been mucking around in php.ini, then yes, that could be a problem. Just going back to what I said in comment #9, the only time you should be touching php.ini is to edit settings such as the memory limit (for all apps), upload/file-related settings, and a few other minor things.
More info: Just discovered that another script on that webserver is having trouble sending mail and it is using php's mail() function directly, not a drupal function. This tells me it's an issue between php and the systems MTA.
[root@pm-drumbeat01 ~]# ls -l /etc/php.ini -rw-r--r-- 1 root root 44990 Jun 23 2009 /etc/php.ini [root@pm-drumbeat01 ~]# sendmail_path = /usr/sbin/sendmail -t -i [root@pm-drumbeat01 ~]# which sendmail /usr/sbin/sendmail [root@pm-drumbeat01 ~]#
(In reply to comment #12) > If somebody has been mucking around in php.ini, then yes, that could be a > problem. Just going back to what I said in comment #9, the only time you should > be touching php.ini is to edit settings such as the memory limit (for all > apps), upload/file-related settings, and a few other minor things. This has been my experience too. I've never had to muck with php.ini settings to get something like mail working except in rare instances usually involving windows servers.
oremj and I were debugging this for a while over IRC and somehow through unexplained magical wonders it is working again. Did anyone change anything? Closing bug in any case.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.