E-mail Validations not Arriving

Some (many) users trying to sign up to my site aren't getting their validation e-mails.  I tried with a Yahoo account and never got anything in the inbox or junk folder.

I tried resending to no avail.

How can I figure this problem out? Is there a way to send a test e-mail to one of the accounts that worked?

Is there logging information for the plug-in?

  • oh right, I forgot about that... yeah we discovered PHP's 80 char limit not long ago.  Docs say it's "suggested" but it appears to be more than suggested.

  • No offense intended here towards women / wives. It's like when a wife suggests something to her husband, it isn't really a suggestion. It's more this is the way it's going to be.

    @Cim, It wasn't the plan to have more than 80 characters, it is just the way it worked out. The validation by email script uses their name plus the name of the Community in the subject line when generating and sending the email.

    Here is an example of the subject line. "We Connect please confirm your email address for Hello World!" (63 characters, no problem email sent.) Even with a longer name it isn't an issue because of the short community name.

    Versus this line. "Steve Cunningham please confirm your email address for the Retiree's of Ontario Community!" which is 91 characters and fails while "John please confirm your email address for the Retiree's of Ontario Community!" (78 characters gets sent because it is less than 80).

    Even with the first example if the site name is "Retiree's of California" the subject line becomes "Steve Cunningham please confirm your email address for the Retiree's of California!" which is 83 characters and fails.


  • You should change the en.php file and take off the %s from the email subject line or reword it.

  • That is what I ended up doing which solved the problem.

  • It's gotten through to a couple of people but 9/10 of them fail. I just tried from three e-mail addresses and none of them worked.

    Rohit Gupta: I'm using the default setup. I can try disabling some plug-ins but I'd expect this to work out-of-the-box.

    Dan: I don't know why the subject would be 80 chars. That can't be what the code intends but I can have a look.

  • Oh! I'll have a look at that file.

    What line is it in en.php, please?

  • Okay I changed mod/uservalidationbyemail/languages/en.php

    5: 'email:validate:subject' => "Please confirm your email address!",

    But it still isn't working...

  • I just verified again that simple script Rohit Gupta.  It works so there must be something wrong in the Elgg mailer :/


  • Hmm, I think it might actually have something to do with the $body.

    I had to hack up my own function to get it to work and re-do the $body part.


  • I think the problem isn't caused by Elgg because if this would be the case there be no emails sent at all. If some emails arrive and others do not the more likely reason is credibility of the server as such, i.e. some email providers just block the routing of the emails coming from your server. The validation emails are likely candidates for blocking because they are quite similar in content obviously. But this shouldn't matter nevertheless, if the mail server has been configured to use some proper mechanism to allow for verification of the origin of the emails. I would suggest:

    • checking if the server's IP is already included in some blacklist (eg. at http://www.spamhaus.org/ and http://www.senderbase.org). If they are listed, you can request for removal.
    • removal from blacklists is only a temporary solution if you don't also use some mechanism to allow for email providers to verify the validity of the email origin. Use SPF and/or DomainKeys for that. You should also have a valid PTR record on your server to allow for reverse DNS lookups. You might need to ask the support of your webhoster to configure these methods for your (specifically the PTR record).
    • if you are not already using a site email with the same domain as your Elgg site, it might also help to increase credibility.

    It might also help to check for bouncing emails in the inbox of your server's admin account (in CPanel or what's used for server administration). Normally, there's kind of a default email account configured where non-delivery notices for all bouncing emails end. These emails often contain some explanation why the emails were not delivered and fixing the problems mentioned there can also help a lot.