Phishing workflow issue with SIR and Proofpoint PhishAlarm and Analyzer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-21-2022 12:17 PM
Running into an issue with ProofPoint PhishAlarm and Analyzer result enriching the SIR workflow and record. We are seeing in some situations with our config with the SIR flow design creating a PHIS with the SIR (best practice) is "too slow" and the PhishAlarm and PhishAlarm Analyzer results are "beating" or "outrunning" the PHIS/SIR creation. This race condition is causing duplicate records separating the parent SIR/PHIS record with the associated analysis from ProofPoint products.
First, has anyone else run into this situation? Second, if so, what is the common and proven fix to maintain the SIR/PHIS configuration while ingesting the PP Analyzer results to the related record?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-04-2023 07:10 AM
The following KB article might help with the issue first reported back in October. This could be a timing issue described here: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0860057
Description
Emails having attachments sent from custom email account (ProofPoint) are sometimes stuck in a send-retry loop and actually sent many times
One symptom is when we see the following information in a node log when the email is sent:
2020-09-07 07:46:28 (966) worker.7 worker.7 txid=f2294aaadb4f WARNING *** WARNING *** handling smtp exception: javax.mail.MessagingException: Exception reading response; nested exception is: java.net.SocketTimeoutException: Read timed out : Exception reading response 2020-09-07 07:46:28 (973) worker.7 worker.7 txid=f2294aaadb4f WARNING *** WARNING *** EMAIL.b0f70ea6db4f54d09a686b4bd39619c8: send-retry |
This makes the customer believe that the SN instance might not be waiting for a long enough time to receive a response from a mail server.
Release or Environment
All
Cause
The SMTP timeout duration is something that ServiceNow set at code level and we cannot modify it. The default SMTP timeout is 60 seconds and the default SMTP max timeout is 300.
From the ServiceNow side the step to take is to validate if there is any business rule with current.update in the target or sys_email table. The KB0715782 article that discourages the use of current.update is confirmed by the official ServiceNow documentation page that states Avoid using current.update() in a business rule script.
Resolution
Here is a list of external links outside ServiceNow scope that mentions this issue:
https://www.proofpoint.com/sites/default/files/essentials_administrator_guide_for_end-customers_cm.p...
https://mso.harvard.edu/faq/i-have-email-attachment-was-delayed-proofpoint-what-happens-my-email-dur....
https://help.proofpoint.com/Proofpoint_Essentials/Email_Security/Administrator_Topics/110_logs/Troub...
https://www.uml.edu/docs/Secure%20Email%20FAQs_tcm18-237100.pdf
https://help.proofpoint.com/Proofpoint_Essentials/Email_Security/Administrator_Topics/110_logs/Under...