exim -bP log_file_path to get a templated log-file path; replace
main, and use that as the logfile to look at. (also
%D for date, etc). If that really points to the same
main.log file which you looked at, then use
lsof, see if you have broken log-file rotation or something. If the file is the current log-file, the filesystem is not full, messages are flowing but the log is empty, then you have a compromised system.
Look to see where the messages came from. If they came from a local user, then that user is injecting mail; if that's a web-hosting user, then you need to figure out which PHP application is out-of-date and letting spammers abuse you. Commercial abuse of PHP apps has been happening for at least 12 years. There are various options you can apply to your webserver and PHP configs to lock down sender addresses, if you have a lot of vhosts and can't identify the source.
If the messages are coming from remote IP addresses, figure out what you did to turn yourself into an open relay.
If there is an authenticated user showing up, then they had a weak password: don't allow user-chosen passwords for SMTP. Use strong passwords which you generate, tell users that they're allowed to write them down. Consider looking over the Exim wiki at rate-limiting examples, to rate-limit abusive SMTP AUTH attempts.
If the connections are not authenticated, and are just remote open relay, then the issue depends upon how much you've customized your Exim configure file (run
exim -bV to find the path to the active config file). If it's fairly close to stock, then you have a
relay_from_hosts and you might have rather too many hosts in that. Lock it down.