X-PHP-Originating-Scrip header contains some text that trigger spam filters

[phiw13]

Sample: X-PHP-Originating-Script: 72467:txplib_misc.php(1826) : eval()'d code

(from an email send with TXP 4.7 dev + com_connect latest)

See this thread: https://forum.textpattern.io/viewtopic.php?pid=311516#p311516

[Bloke]

I've no idea how to get round this in the code, nor if it's even possible. That specific header is added by the mail() function based on settings in php.ini. As far as I know, to silence this you need to edit that file on your server and comment out the relevant directive.

There are lots of (old) references on the web to simply overwriting the PHP superglobals (such as PHP_SELF) with other values prior to calling mail() but in all my tests so far it makes zero difference: the same X-PHP-Originating-Script is sent. Perhaps MTAs are no longer using such user-supplied and easily tamperable info (which makes sense from a spam prevention stance).

If anyone knows if it's possible to set or unset anything prior to calling mail that will allow us to set the originating source to something less annoying (even if it's something fake like /textpattern/com_connect.php), please comment.

[vanmelick]

On 30/04/18 12:42, Stef Dawson wrote:

I've no idea how to get round this in the code, nor if it's even possible. That specific header is added by the |mail()| function based on settings in |php.ini|. As far as I know, to silence this you need to edit that file on your server and comment out the relevant directive.

SMTP relay services like mailchannels.com recommend/require enabling that header to allow them to identify which script is sending spam and specifically block spam coming from that source as opposed to blocking everything coming from that IPnr. I suspect the problem isn't the header itself, but the fact that it contains "|eval()'d code", which is what a lot of spam scripts use as well (I've seen quite a lot of them on hacked websites in recent years). In that case the solution would be not to use eval() anymore, which currently means not installing plugins via the backend but uploading them as PHP files in a plugin directory (unless something changed recentely in TXP).

Perhaps it's possible to eval the plugin code only during installation and after the plugin code has been edited via TXP. If that succeeds (no parse errors), store the plugin code in the file system and include it instead of using eval during normal page requests. | Regards, --Ruud

[Bloke]

I like the idea of eval()ing the code once and then including it. Probably faster too but will need to consider DB vs filesystem access. Will slate this for investigation next release, thanks.

[phiw13]

With TXP 4.8.0 beta2, the plugin now sends the following:

X-PHP-Originating-Script: 72467:com_connect.php

That is already much saner, I guess, and fixes the issue, mostly?

[Bloke]

Yep, since plugins are stored on disk in Textpattern 4.8+ and not run through eval() this issue is hopefully moot.