This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Email Notifications will not send (Email has been accepted by Device and queued for scanning)

After inital setup I have tried to configured the Email notifications in the firewall. The problem is that I couldn´t send a Testmail, I have tried both ways, the built-in email server and the external email server. When I will send the testmail nothing happens, in the logviewer I see the following entry: Email has been accepted by Device and queued for scanning

Any ideas what could occurs the problem?

Kr Steffen

This thread was automatically locked due to age.

Parents

0 Keyur over 5 years ago

Hi Steffen Trippner

Which Email service are you using to configure email notification?

Could you please let us know the domain name and port number?

If you are using Gmail, please refer to the article- https://community.sophos.com/kb/en-us/124935

How email notification works- https://community.sophos.com/kb/en-us/133616

Configuration- https://community.sophos.com/kb/en-us/131850
Cancel
Vote Up 0 Vote Down

Cancel
0 Steffen Trippner over 5 years ago in reply to Keyur

Hello Keyur I use a customized Email Services. The Domain I tried to send is soundbooking.de and I use the port 587. I think the configuration is not the problem, I habe configured this email service in different other systems and it works fine.

I have also tried to the use built-in email server with the same result, Email has been accepted by device and queued for scanning.
Cancel
Vote Up 0 Vote Down

Cancel
0 Keyur over 5 years ago in reply to Steffen Trippner

Hi Steffen Trippner

Thank you for sharing details, It requires to check the logs of SMTPd service logs to investigate the issue further, I would recommend you to contact technical support and open a service request, please PM us the service request number.
Cancel
Vote Up 0 Vote Down

Cancel
0 rfcat_vk over 5 years ago in reply to Keyur

Hi,

there is a bug that has not been fixed in the notifications, daily reports work, but login errors do not get reported.

Ian
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 rfcat_vk over 5 years ago in reply to Keyur

Hi,

there is a bug that has not been fixed in the notifications, daily reports work, but login errors do not get reported.

Ian
Cancel
Vote Up 0 Vote Down

Cancel

Children

0 LuCar Toni over 5 years ago in reply to rfcat_vk

Hi Ian, i asked in this old thread about this issue, if there somebody could please create a tcpdump with host 0.0.0.0 to verify something. But nobody respond.
Cancel
Vote Up 0 Vote Down

Cancel
0 rfcat_vk over 5 years ago in reply to LuCar Toni

Hi LUCar,

I will try tomorrow when I have better access to the W10 machine, currently has a broken woofer sitting in front of it waiting for repairs.

ian
Cancel
Vote Up 0 Vote Down

Cancel
0 rfcat_vk over 5 years ago in reply to rfcat_vk

Hi folks,

the notification did not work until I disabled MTA. As soon as I disabled MTA the queued message was sent.

So, a fresh installation of mr6 upgraded to mr-8 and notifications are working again.

ian.
Cancel
Vote Up 0 Vote Down

Cancel
0 LuCar Toni over 5 years ago in reply to rfcat_vk

But in case of MTA, did your MTA services tries to connect via 0.0.0.0?
Cancel
Vote Up 0 Vote Down

Cancel
0 rfcat_vk over 5 years ago in reply to LuCar Toni

Hi,

after configuring the test XG in legacy mode, then converting to MTA, the test message - a failed login went out port 465 which is what I set the legacy mode with. The test XG uses the V18 EAP XG as a gateway so I can log the test XG behaviour.

Ian

The tests were all done after the test XG was upgraded to MR-9.

I suspect that MTA has no affect on XG administrative email messages? So, means my testing is invalid.
Cancel
Vote Up 0 Vote Down

Cancel
0 LuCar Toni over 5 years ago in reply to rfcat_vk

Maybe i need to explain in more detail.

MTA is a services to send a mail properly. In Case of some customers, i saw, XG had some issues with some Notifications to send, because the MTA could not get the SNAT (MASQ) properly. You could easily see this in a tcpdump, the XG tried to send certain mails via 0.0.0.0 (So to call: 0.0.0.0:12345 to mail.server:25 ), which the destination server could not answer at all (of course).
Cancel
Vote Up 0 Vote Down

Cancel