I was having a problem with some (not all) invitation emails not being sent, or not reaching their destination. I think the problem may lie within the _invite_send_invite function, specifically in the following line of code...

if ($success = user_mail($email, $subject, wordwrap($body, 72), "From: $from\r\nReply-To: $replyto")) {

My webserver is on a linux box, and I have read in the user_mail api documentation that on linux carriage returns should be "\n" and not "\r\n" or else problems may occur with email not reaching its destination. The user_mail function called in the above code is itself set to strip off any "\r", but it looks like it only strips them from the message body, and not from the header. Could this be the problem? As it is the header which is being set in the above code where \r\n appears, I tried removing the \r from the code, and I think the mails are all being received properly now, though it is hard for me to be sure. Can anyone confirm this for me? Thanks in advance for your help.

Comments

Nick Wilson’s picture

Nick Wilson commented
Priority: Critical » Minor

Actually, the api doc says this:

"$header String to be inserted at the end of the email header. This is typically used to add extra headers (From, Cc, and Bcc). Multiple extra headers should be separated with a CRLF (\r\n). When sending mail, the mail must contain a From header."

which would suggest something else is the cause of your issue i thnk.

sja1’s picture

sja1 commented

Hi, thanks for taking a look at this. I went back and looked at the api doc and you're right, it does say \r\n should be used in the header. So then I went to the php documentation of the mail() command, which is the command invoked by the user_mail function, and found the following documentation (http://es.php.net/manual/en/function.mail.php). The last "Note:" suggests that the \r\n could indeed be causing problems.

This is typically used to add extra headers (From, Cc, and Bcc). Multiple extra headers should be separated with a CRLF (\r\n).

Note: When sending mail, the mail must contain a From header. This can be set with the additional_headers parameter, or a default can be set in php.ini.

Failing to do this will result in an error message similar to Warning: mail(): "sendmail_from" not set in php.ini or custom "From:" header missing. The From header sets also Return-Path under Windows.

Note: If messages are not received, try using a LF (\n) only. Some poor quality Unix mail transfer agents replace LF by CRLF automatically (which leads to doubling CR if CRLF is used). This should be a last resort, as it does not comply with RFC 2822.

I also found this note googling for answers...

This is causing mail generated by PHP to be BLOCKED as being potentially a virus by some anti-virus SMTP servers. The presence of "\r\n" in headers is typically a sign of a virus trying to reach Outlook. Some antivirus products now totally block MIME mail containing "\r\n". This means all mail generated by PHP programs...

Nick Wilson’s picture

Nick Wilson commented

Can you tell us what MTA your system uses, and if using just \r is working for you?

sja1’s picture

sja1 commented

Hi, it looks like my server is running qmail. I have modified my version of invite.module to use just \n, and mail is going out (put myself on BCC for a while to make sure). It seems like that has alleviated the problem of invitations not being received, because I haven't received any more complaints since making the change. But I can't be 100% sure as users don't always talk with the person they are inviting to ensure that their invitation has been received.

AjK’s picture

AjK commented
Status: Active » Closed (won't fix)

Personally I would mark this "won't fix". The reason, you identified the fault and it's not Drupal which is RFC complient in this case. It's been identified that the MTA is the culpret not being RFC complient.

The work around you did worked for you but it's not a solution for Drupal. The real soution is "use a proper MTA that is complient". All I can suggest is a note in the README file about it. But we shouldn't remove the \r just bacause one MTA doesn't like it ;)