Elgg email header mismatch, not showing dedicated IP

Outgoing msgs from within my Elgg app are not showing my dedicated IP and "proper" info in the headers, while outgoing msgs from my domain's ordinary mail account look fine. Both Activation Emails and Member Messages are wrong. 

Not sure if I should post headers here. Would that be a security risk for my domain? Are they too bulky and lengthy?

The header in the email from the ordinary mail account showed my current dedicated IP,

Received-SPF: pass (google.com: domain of sslego@brickcollections.com designates 216.119.131.174 as permitted sender) client-ip=216.119.131.174;
DomainKey-Status: good
Authentication-Results: etc. etc. as above
DomainKey-Signature: xxx - lotsa good stuff

The headers in both Elgg-generated emails showed my prior, shared IP:

Received: from a2s57.a2hosting.com ([216.119.132.66])
and nothing about SPF, Authentication, nor DomainKey. Specifically it did not include the "
designates 216.119.131.174 as permitted sender" phrase.

I changed to a dedicated IP on Tuesday. The DomainKey automatically showed the new IP and I promptly revised the SPF.

Not sure where to look in Elgg. Or is there the equivalent of a re-boot for my Elgg's mail function?

Thanks,

Stephen

When I first opened my account with A2 Hosting, my chosen name was "sslego." That name persists across various functions.
Then, when I set up Elgg on the domain, the default name was admin@brickcollections.com. A couple weeks in, I thought it
would be more personal if that was changed to stephen@brickcollections.com



  • Also, if you press your provider on this, they may respond eventually.

    I had one case where a client's provider refused to fix a PHP mail problem. The provider had specific local rules and had not configured their PHP/MTA interface to handle this.

    They argued that another Drupal user had embedded the local rules in their Drupal application and that we should do the same for Elgg.

    I pointed out to my client that if we accepted the responsibility for email configuration, then that would establish a precedent which could lead to no end of problems.  Email rules often change and we might end up having to keep tinkering with the Elgg application to implement rules that that were really part of the basic server email infrastructure.

    Together the client and I succeeded in pressuring the provider into properly configuring the rules at the MTA end instead.

    Kevin

  • @Kevin, @Cash, @DDS,

    Thanks for your help. I appreciate your bearing with me, as opposed to just saying "RTFM." (I once installed Arch Linux distro on my home PC; those guys were brutal.)

    The last 3 posts blur the line a bit between PHP and MTA (I think my host is using Exim). Do PHP scripts specify the MTA configuration? 

    Does the phpmailer plugin constitute "tinkering with the Elgg app?" My thought was to enable it strictly for learning & diagnostic purposes. Or do you guys mean that by using the phpmailer plugin, I should be able to fix/override this particular problem myself?

    Lastly, I am at A2 Hosting, a host recommended (I believe) by the Elgg community. So far, they are roughly as good as my other host Lunarpages. (My theory is that all webmasters hate their hosts, but that most of them are pretty decent, and mostly all about the same quality of support.) So, changing hosts is one of the last things I'd do.

    I also went back to A2 again, with a posting from an Exim Forum, that spoke to the variation allowed by Exim, when it comes to defining the sending IP. While the first level tech support has a knee-jerk response of "that's an application-specific problem," I am hopeful that some persistent & persuasive discussion pointing out that Elgg simply does not define sending IPs will bear fruit.

  • Some progress with phpmailer plugin.

    Using SMTP, and SMTP authorization (both with and without SSL), I sent out an Activation Email, whose header showed the correct IP address (...174) and the DomainKey. But did NOT show the SPF, nor the important "designates 216.119.131.174 as permitted sender."

    Can I use phpmailer to add this info to my outgoing email headers?

  • PHP has no control over the set up of the MTA.

    Here is a short discussion on StackOverflow that is related to this thread: http://stackoverflow.com/questions/3392195

     

  • On A2's Knowledge Base, they say:

    The last two parameters to mail(), which are optional, are "additional_headers" and "additional_parameters". They can both be used to ensure a properly set 'From' address.

    Example:

    mail("target@address.com", 
    "subject",
    "message",
    "From: your@address.com",
    "-fyour@address.com"
    );

    Replace "your@address.com" with something appropriate, but ensure that the "-f" is maintained.

    I don't see -f anywhere in start.php and I do see:

    array $params = NULL

    Can I modify the plugin to define the additional parameter -f? Would that help?

     

  • Cash and Stephen,

    My point was that PHP interacts with the MTA and that this interaction can be controlled on the PHP side (usually bad in my view) or on the MTA side (much cleaner as it avoids making server-specific hacks to your PHP apps).

    Stephen, if you are forced to fiddle with the way Elgg handles email to meet some local server requirement, you are headed for trouble in my view.

  • In particular, the MTA can and should be configured to set any additional required headers. Elgg should not need to do that.

  • In conversations with my host, would the proper terminology be "mail sent from my smtp server" versus "mail sent from php?"

     

  • My host sez: If you send email from one of your mail accounts the dedicated IP address will be shown.
    If you send using the mail function that mail will be sent from the servers main shared IP address.

     the mail() function does not send from your account but rather from a shared account on the server so it will not originate from your IP address but instead will originate from the main shared IP.

    To be clear, I have a dedicated IP address, on a shared server.

    He sez I gotta go to VPS.

  • @cash, @kevin,

    Thx for your help. I need to move forward on this; it's been a week now that I've been fighting with this issue.

    Tech support at the host says that the "-f" parameter added to the plugin should work.

    But I'm very wary of that. We gotta figure out a hack to a plugin. We gotta hope it works. And I'm still on a shared server, with a workaround solving this week's problem.

    I'm paying $8 per month for my present set-up. I can get a VPS for about $16. If that would solve this the right way, and maybe avoid a few similar problems in the futuer, that's my inclination.

    Thoughts?