Comment 6 for bug 1842005

From a coding perspective you're absolutely right, not to mention that trying to catch all possible exceptions is time consuming. pyspf needs to be fixed, no argument here.
But from a user & sysadmin perspective, all that's visible is a "451 4.3.5 Server configuration problem; [...]" translated at the other end to a nearly useless bounce message *only* after the queue lifetime of the message expires on the remote MTA. No hint in that bounce on what the actual problem might be. On the server running python-spf the sysadmin sees the stacktrace, yet this still isn't sufficient.
Regardless of where the issue is, the filter must NOT crash under any circumstance. There's of course the discussion on what should the filter return? Perhaps "dunno" or "reject"? If choosing "reject" the exception message can be customized so that the sender, when receiving the bounce, will be able to contact their service (DNS/email/etc) provider and offer them *some* useful information.
Currently the crash causes the MTA to return 451, which is probably the worst option in this particular case.