EXIM Crashes FIrewall SMTP Stops Authenticating

[BubbaTrading]

Hello, I am running into a problem on the server whereby a developer's phpMailer script is using EXIM to send outbound SMTP bulk messages to an opt-in list.

SMTP Restrictions are on
Added following rule to firewall to enable UID to send mail:

iptables ACCEPT tcp -- 0.0.0.0/0 127.0.0.1 -dport 587 owner UID match MyUID

where MyUID = cPanel account username.

This seems to work as EXIM SMTP authenticates properly with a remote Office 365 Exchange Server, but randomly fails and then all outbound SMTP email requests stop authenticating (504 Gateway timeout)

Simply restarting the firewall resolves the issue and EXIM again properly authenticates with remote Exchange Server, but eventually the cycle repeats usually within the same day perhaps 7 or 8 hours later.


- Allison

 

[BubbaTrading]

Not Sure if Related:
Running exiqgrep from terminal, shows a message from '[email protected]' is frozen in queue.

 

[cPanelLauren]

This sounds more like a firewall issue than anything, especially if restarting the firewall resolves the issue. Are you using anything to configure the firewall (like CSF for instance)

Is anything output to /var/log/messages or /var/log/exim_mainlog when this occurrs?

 

[BubbaTrading]

This sounds more like a firewall issue than anything, especially if restarting the firewall resolves the issue. Are you using anything to configure the firewall (like CSF for instance)

Is anything output to /var/log/messages or /var/log/exim_mainlog when this occurs?

The server utilizes the HG Firewall plugin, which allows open/block port & custom IPTABLE rules, but have been back and forth with their support for two weeks and they still have not even mentioned the firewall being point of origin for failure. :s

There is a massive wall of output from /var/log/exim_mainlog but could not make heads or tail. Was hoping there was a way to "exigrep" for a particular failure, however thus far have not found a way to specifically prune out message pertaining to SMTP Authentication failure.

Running bash$exigrep [email protected] /var/log/messages = No such file or directory.

 

[cPanelLauren]

You could try just exigrep - especially if you've got the message ID from the message where the issue began or even a failed message might give some information. exiqgrep is going to give you exim queue output not necessarily transactional data from the exim logs


If exim isn't actually crashing (meaning it's running normally) and the issue is that mail is being blocked from being delivered/received and restarting the firewall resolves the issue I'd definitely want to look closer into the firewall though it's really difficult for me to do so through the forums.

Feel free to open a ticket using the link in my signature pending you have root access to the system. Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved.


Thanks!

 

[BubbaTrading]

You could try just exigrep - especially if you've got the message ID from the message where the issue began or even a failed message might give some information. exiqgrep is going to give you exim queue output not necessarily transactional data from the exim logs


If exim isn't actually crashing (meaning it's running normally) and the issue is that mail is being blocked from being delivered/received and restarting the firewall resolves the issue I'd definitely want to look closer into the firewall though it's really difficult for me to do so through the forums.

Feel free to open a ticket using the link in my signature pending you have root access to the system. Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved.


Thanks!

Hi cPanelLauren thank you for your assistance. Per your request the Ticket ID is 12586921

 

[cPanelLauren]

Hello @BubbaTrading


I just checked in on this ticket and it appears that our analysts were unable to replicate the issue as of yet, it does look to be awaiting your further response though.