Force php mail() through postfix + auth

[smurffit]

Hi,

I'm a bit lost with the PHP/Sendmail configuration, maybe somebody could help me getting back on the right track.

Following situation:

Postfix:
* accepts smtp on port 25 but from his own domains. Some policy and spamchecks through amavisd are made.

* accepts submission on port 587 and 465 from authenticated users only. Quota and spamchecks prevent outgoing spam.

So I'm enforcing a very strong outgoing spam-policy but the users are still able to use the php mail() function to send spam through the /usr/sbin/sendmail command.
My users have access to their own php.ini so my idea was to somehow enforce the delivery through the local postfix on port 587 or 465 and just let them enter their user/pass in their php.ini. (I suppose, their might be a cleaner-solution ).

Unfortunately, my configurations like smtp_host, port, user etc. are getting ignored if the sendmail_path line is active. But if I comment this line out, php just uses the default, which is the same as configured in the sendmail_path line - so it's active whether i use the line or not (setting it to an invalid command breaks the mail() function completely).

So my question is basically: how can I enforce my anti-spam policy on the php mail() command?
For my ssh users I just blocked the outgoing connection to localhost on port 25 which seems to work so far, but somehow the postfix-sendmail-wrapper just ignores this.

I appreciate any suggestions and hints.
Thank you in advance.

[jpollard]

If a user wants to send spam via php, then they will always be able to send spam.

Trying to block/control the mail function will just cause them to open sockets directly. The mail function is just a convenience.

That said- the php.ini file defines what is going to be interpreted as the binary to invoke for the MTA ("sendmail_path"). As long as this accepts the parameters used by the mail function, it can do anything it likes.

[smurffit]

Thank you for your reply jpollard.

Originally Posted by jpollard

If a user wants to send spam via php, then they will always be able to send spam.

Of course, there is always a way for messing around. But I want to make it at least as hard as possible.

Originally Posted by jpollard

Trying to block/control the mail function will just cause them to open sockets directly. The mail function is just a convenience.

Well, I highly doubt that a correct configured mail server would accept incoming mail from a non-privileged port. Also, I have a opt-in firewall configuration, so I suppose that might be less a problem. Additionally, php is executed via suEXEC and fcgi which should also add some restrictions. (SSH is jailed and unprivileged ofc).

Originally Posted by jpollard

That said- the php.ini file defines what is going to be interpreted as the binary to invoke for the MTA ("sendmail_path"). As long as this accepts the parameters used by the mail function, it can do anything it likes.

As far as I understood it's also possible to force sendmail to use smtp auth. But unfortunately I'm not familiar with sendmail, neither the postfix.sendmail binary. I'm just very surprised that their seems no simple solution (or I just haven't found it yet) for this issue, which looks like a big trouble-ahead for me.

To bring another point in this discussion: I'm signing all outgoing mail with DKIM and I have plans to migrate to the strict-variant which advices the recipient to drop unsigned-mails. In that case it would be necessary to route all php-mails through postfix - at least through amavisd.

[jpollard]

Originally Posted by smurffit

Thank you for your reply jpollard.
...
Well, I highly doubt that a correct configured mail server would accept incoming mail from a non-privileged port. Also, I have a opt-in firewall configuration, so I suppose that might be less a problem. Additionally, php is executed via suEXEC and fcgi which should also add some restrictions. (SSH is jailed and unprivileged ofc).

Apparently you don't realize it, but that is how mail IS done.
Any user can open a socket and bind it to a SMTP server. The source socket is arbitrary.

As far as suEXEC/fcgi - It depends entirely on who provides the php. If it is a user owned file, then suEXEC will not add any security whatsoever. If it is a system owned file, then there is no need to do anything about the mail function. If the php script allows unvalidated data, then the script has a bug.

As far as I understood it's also possible to force sendmail to use smtp auth. But unfortunately I'm not familiar with sendmail, neither the postfix.sendmail binary. I'm just very surprised that their seems no simple solution (or I just haven't found it yet) for this issue, which looks like a big trouble-ahead for me.

Requiring SMTP auth is completely up to the server, not the client. If the server requires it, then the client must respond or it will get a connection closed error.

BTW, sendmail supports both MUA (mail user agent) or MTA (mail transfer agent) operation. MUA is client to a server. MTA is server to server. As far as I know postfix only supports MTA.
Current sendmail utilities use a different configuration file to support this.

To bring another point in this discussion: I'm signing all outgoing mail with DKIM and I have plans to migrate to the strict-variant which advices the recipient to drop unsigned-mails. In that case it would be necessary to route all php-mails through postfix - at least through amavisd.

Again, DKIM requirements are completely up to the server, not the client. The client only has to support the servers requirements or be rejected.

Anything can be used in place of sendmail. If you only want to allow local delivery, use procmail.