Bob
12-15-2003, 09:10 PM
FutureQuest has received several support requests from clients in the past two days, stating that they were not receiving any email deliveries to email addresses hosted by FutureQuest.
In each instance, it has turned out that the clients were using EFM as a custom email filter on their email account that was not receiving email, and that the EFM filter was timing out, preventing email from being delivered.
Looking in the file
/big/dom/xdomain/logs_email/filter.log
will reveal if this is the problem.
If you find entries of this type:
[2003-12-15 19:17:46 3493] starting filter: command='/big/dom/xdomain/emailfilter/emailfilter_1.py' sender=<spammer@example.com> recipient=<myemail@mydomain.com> size=3360
[2003-12-15 19:17:46 3493]: /big/dom/xdomain/emailfilter/emailfilter_1.py:151: DeprecationWarning: add_payload() is deprecated, use attach() instead.
[2003-12-15 19:17:46 3493]: container.add_payload(fp.read())
[2003-12-15 19:17:46 3493]: /big/dom/xdomain/emailfilter/emailfilter_1.py:127: DeprecationWarning: add_payload() is deprecated, use attach() instead.
[2003-12-15 19:17:46 3493]: container.add_payload(msgobj)
[2003-12-15 19:18:01 3493] killed!
The killed! entry indicates that the filter program is unable to complete within the 15 seconds of time permitted to email filters.
In such a case, we recommend disabling the email filter to allow the email to be delivered to your account again.
However, it does appear that these recent problems with EFM may be related to the UCE blacklists option. It appears that some of the blacklists are not returning the DNS lookups quickly enough, and that this is causing EFM to be unable to complete within the alotted time.
You might also consider simply turning off the option to use UCE blacklists. If this resolves the situation for you, then you may not need to entirely disable the filter.
Please note that EFM is not directly developed nor supported by FutureQuest. For any further assistance, please contact the developers.
-Bob
In each instance, it has turned out that the clients were using EFM as a custom email filter on their email account that was not receiving email, and that the EFM filter was timing out, preventing email from being delivered.
Looking in the file
/big/dom/xdomain/logs_email/filter.log
will reveal if this is the problem.
If you find entries of this type:
[2003-12-15 19:17:46 3493] starting filter: command='/big/dom/xdomain/emailfilter/emailfilter_1.py' sender=<spammer@example.com> recipient=<myemail@mydomain.com> size=3360
[2003-12-15 19:17:46 3493]: /big/dom/xdomain/emailfilter/emailfilter_1.py:151: DeprecationWarning: add_payload() is deprecated, use attach() instead.
[2003-12-15 19:17:46 3493]: container.add_payload(fp.read())
[2003-12-15 19:17:46 3493]: /big/dom/xdomain/emailfilter/emailfilter_1.py:127: DeprecationWarning: add_payload() is deprecated, use attach() instead.
[2003-12-15 19:17:46 3493]: container.add_payload(msgobj)
[2003-12-15 19:18:01 3493] killed!
The killed! entry indicates that the filter program is unable to complete within the 15 seconds of time permitted to email filters.
In such a case, we recommend disabling the email filter to allow the email to be delivered to your account again.
However, it does appear that these recent problems with EFM may be related to the UCE blacklists option. It appears that some of the blacklists are not returning the DNS lookups quickly enough, and that this is causing EFM to be unable to complete within the alotted time.
You might also consider simply turning off the option to use UCE blacklists. If this resolves the situation for you, then you may not need to entirely disable the filter.
Please note that EFM is not directly developed nor supported by FutureQuest. For any further assistance, please contact the developers.
-Bob