03-02-2022 06:13 AM
Dear experts,
on our cluster of two ESA
(C100V - 11.1.0-131)
SBRS stopped working suddenly (March 1st ~20:35 UTC+1)
Since then, all incoming connections show
"SBRS None country None" and are not filtered by senderbase reputation.
Some debug output:
senderbasestatus SenderBase Host Status Status as of: Wed Mar 02 15:07:28 2022 CET Host success/fail: success SBRS Status Status as of: Wed Mar 02 15:07:28 2022 CET Host success/fail: success SenderBase Network Participation Status Time of last SenderBase upload: never
repengstatus Component Last Update Version Reputation Engine Never updated 1.2.0-079 Reputation Engine Tools Never updated 1.2.0-079
After
repengupdate force:
repengstatus Component Last Update Version Reputation Engine 02 Mar 2022 13:23 (GMT +00:00) 1.2.0-079 Reputation Engine Tools 02 Mar 2022 13:23 (GMT +00:00) 1.2.0-079
Also restarted the service via
DIAGNOSTIC SERVICES SBRS RESTART
status of service is now:
[]> sbrs Choose the operation you want to perform: - RESTART - Restart the service - STATUS - View status of the service []> status Reputation Engine has been up for 2h 17m 56s.
What else could I try to debug or revive SBRS?
Thank you very much.
Solved! Go to Solution.
03-15-2022 08:43 AM
Replying to self as problem was solved with help of TAC.
It was a DNS problem. Resolving 'senderbase.org' worked. But the special queries that are generated to check incoming connections suddenly stopped being handled by our ISPs DNS.
They are TXT-queries, asking for
1-12341234123412341234123412341234.200.200.200.200.v1x2s.rf-xyzxyzxyz.senderbase.org
("200.200.200.200" would be the IP of the server trying to send mails.
"1234..." and "xyz..." are some random looking numbers which I don't now the meaning of, so I've masked them for this post).
Reply by server was "NXDOMAIN".
The secondary and tertiary servers (lower priority) were basically never triggered. After changing the priority and now mainly using the DNS of another vendor, SBRS started working immediately.
TAC connected remotely to the appliance, collected network-dumps and recognized the DNS problems in the dumped replies.
03-02-2022 06:32 PM
I dont see any ongoing issues with our global system that is meant for processing SBRS requests - https://urgentnotices.statuspage.io/
This does look like a local problem. If there were connectivity issues, message tracking would logically return "unable to retrieve".
If you are instead seeing none for all senders. Would be a good idea to contact TAC and get their feedback.
03-03-2022 12:00 AM
Thank you for your message and the link to the status page, didn't know that one.
TAC ticket is opened.
03-03-2022 08:12 AM
Hi, we are having the same issue: we was forced to improve the rate for envelope senders limits.
Are you sure is a local problem? Can you suggest some troubleshooting?
regards
03-15-2022 08:43 AM
Replying to self as problem was solved with help of TAC.
It was a DNS problem. Resolving 'senderbase.org' worked. But the special queries that are generated to check incoming connections suddenly stopped being handled by our ISPs DNS.
They are TXT-queries, asking for
1-12341234123412341234123412341234.200.200.200.200.v1x2s.rf-xyzxyzxyz.senderbase.org
("200.200.200.200" would be the IP of the server trying to send mails.
"1234..." and "xyz..." are some random looking numbers which I don't now the meaning of, so I've masked them for this post).
Reply by server was "NXDOMAIN".
The secondary and tertiary servers (lower priority) were basically never triggered. After changing the priority and now mainly using the DNS of another vendor, SBRS started working immediately.
TAC connected remotely to the appliance, collected network-dumps and recognized the DNS problems in the dumped replies.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide