On 2014-09-03 at 23:44 +0300, Lena@??? wrote:
> Web scripts can submit mail via SMTP to localhost or not via SMTP
> (via pipe to "sendmail" binary which calls exim).
> I was told that PHP's mail() function submits not via SMTP, at least usually.
In `php.ini`:
----------------------------8< cut here >8------------------------------
[mail function]
mail.force_extra_parameters = -fthe-sender@???
mail.add_x_header = On
----------------------------8< cut here >8------------------------------
The `add_x_header` is useful for anti-abuse, as it adds a header
identifying the actual script triggering the email.
With something like Apache, use:
php_admin_value mail.force_extra_parameters -fthe-sender@???
(and for anti-abuse, learn when to use `php_admin_value` so that the
customer can't override it!)
When I last ran PHP stuff, using Apache, I actually used mod_macro which
made it easy to scale up; one of the macro parameters was `%admin` so I
could just use `-f%admin` in the above.
This way, you don't need to enable SMTP and you don't need to risk that
a broken script has let an attacker inject arbitrary SMTP with fake
senders. The non-SMTP sendmail interface is more controllable here.
If you *must* enable SMTP, then:
(1) make sure each PHP site is running under a separate uid (suphp or
its like)
(2) run identd, allowing connections only from the mail-server
(3) Use Exim's `rfc1413_hosts` option and ensure that
`rfc1413_query_timeout` is not `0s`.
This is the sort of scenario for which RFC1413 ident is ideal -- you
trust the source host to provide identity, you don't trust the users.
Since you only expose identd to the mail-server, you don't need to use a
token-issuing identd which can only correlate to real user accounts via
the logs -- expose the actual user account and use it as a rate-limit
key.
Consider also using `mail.log` in `php.ini`.
I last was a postmaster for an ISP with PHP hosting in 2006. The horror
in my recollection still lingers, but at least it is no longer a
visceral horror.
-Phil
