SpamSieve 3.0.4
SpamSieve 3.0.4 is a maintenance release for my Mac e-mail spam filter.
In sending out the update notice to the SpamSieve mailing list, Amazon SES reported a huge number of bounces (almost 10x the normal percentage), primarily from EarthLink/MindSpring addresses. It’s not clear what’s going on here, but I suspect that the addresses are not all suddenly bad. Unfortunately, Sendy seems to want to permanently disable them.
Some interesting bugs were:
Sometimes SpamSieve would send an AppleScript command to Apple Mail but never receive a response. Sampling the process would show that Mail was not busy formulating a reply; it simply seemed to drop the request. I’m not exactly sure what causes this—perhaps Mail being overloaded—but I’ve made lots of changes so that SpamSieve can better handle this situation. We don’t want to just repeatedly wait for a long timeout.
There was a related issue, worked around in a previous version, where Mail could take a really long time to read or download a message, and SpamSieve would try to detect this and throttle requests. However, the workaround had a bug where, if the user put the Mac to sleep in the middle of a request, that would mess up SpamSieve’s estimate of the throughput.
A damaged database may open and fetch without error but then fail to save. SpamSieve tries to handle save errors by either recovering or (as in the case of corruption or a disk error) rolling back. The most important thing is to avoid growing an unbounded graph of objects in memory. This didn’t always work properly because I had failed to account for the fact that Core Data errors may have
NSSQLiteErrorDomain. I had expected that such errors would only occur as underlying errors inside of aCocoaError.Some Apple Mail operations could be unnecessarily slow or even crash because my AppleScript had a typo inside of a
try/endblock. The intent was to just suppress any error (since it was in debug code). Unfortunately, the typo meant that an error was generated every time through this code path. The error was related to referencing a selected message in Mail, so if many messages were selected, AppleScript would generate an error message that included a giant string likeitem 1 of {long list of references to messages, each with the mailbox and account name}even though this was never caught or displayed. This would take a long time and, I think, potentially cause a crash._PFBatchFaultingArrayis a leaky abstraction that will raise an exception (not catchable in Swift) if it’s accessed after the persistent store is shut down. I think I fixed the order of cleanup to prevent this and also made sure that all accesses to such arrays go through an Objective-C category that catches exceptions.I wasn’t able to fully isolate the problem, but
NSRegularExpressionsometimes raises an exception (not catchable in Swift) about an invalid range when using a range created byNSRange(swiftRange, in: swiftString). It works better to to avoid Swift ranges entirely and useNSRangeand the associatedNSStringmethods when using Swift strings withNSRegularExpression.
Previously:
Update (2024-05-22): I found that the bounced addresses were mostly ones that were added a long time ago, and after sending test messages to a sample of them I got no replies and lots of bounces. So I think they really are invalid, though it remains a mystery why they were all reported as such now, rather than with previous messages. Thanks to Ben at Sendy for for explaining that it’s possible to remove the bounce status in Sendy by deleting the addresses and reimporting them. It’s also possible to use Amazon SES’s suppression list to tell it to try certain addresses again, though this can be risky for your account if they really are bad. SES’s SMTP server is, of course, no good for manual testing because it will silently skip sending the message to addresses that are already on its global suppression list.
