On 9.03.2019 03:50, Viktor Dukhovni wrote:
On Fri, Mar 08, 2019 at 08:00:47PM +0300, sse450 wrote:

Hoping to solve this problem, I wanted to block all the sender emails
not defined in sender_relay table. I will do what you advised here. But,
I know that this will also block apache sender eventually. In this case,
I will have another problem in my lap. Contact forms on my websites and
reporting emails generated by the server will stop working.

I don't know what to do. I would appreciate any advise from you.
Perhaps a classic case of "XY Problem".  Compromised PHP scripts
and the like would typically inject email via local submission, and
it is easier to disallow all local submission by the web server
user (wwwdata or similar) than to make ad-hoc work-arounds in how
you forward to your relay.

Something along the lines of:

     authorized_submit_users = !wwwdata, static:all

And of course you need to check your logs to see how the unauthorized
email messages enter the Postfix queue.  It it via "pickup" (local
submission) or SMTP?  In the latter case you could also deny email
from your own IP addresses, including the loopback address.

Since your problem is not trying to squeeze outbound email out
through an MSA, but is instead an issue of unauthorized submission,
(or perhaps a compromised SASL account, ...).  The solution is to
stop it entering the queue, not ad-hoc kludges in the output
processing.

I found the culprit. The guy who designed one of the websites left his own email as recipient of the contact form. Someone legitimete from the internet who fills the form and sends creates a mess. Destination is an hotmail address, reply-to is the person who fills the form and our domain is something else. Then, smtp relay host complains. Corrected and much relieved now.

Thank you all who helped me and directed to the correct way of problem finding.

All the best.

Reply via email to