Steve Keith <[EMAIL PROTECTED]> writes: > I have had some problems with file permissions or file absence that > causes TMDA to generate a message similar to: > > Uncaught Python 2.1.1 Exception (Thu Jan 1 22:11:02 2004): > ----------------------------------------------------------- > Traceback (most recent call last): > File "/usr/bin/tmda-filter", line 53, in ? > execfile(os.path.join(execdir, 'tmda-rfilter')) > File "/usr/bin/tmda-rfilter", line 891, in ? > main() > File "/usr/bin/tmda-rfilter", line 830, in main > orig_msgin_size) > File "/usr/lib/python2.1/site-packages/TMDA/FilterParser.py", line 913, in > firstmatch > Util.build_dbm, self.__search_dbm, optional) > File "/usr/lib/python2.1/site-packages/TMDA/FilterParser.py", line 770, in > __autobuild_db > txt_mtime = os.path.getmtime(basename) > File "/usr/src/build/221901-i386/install/usr/lib/python2.1/posixpath.py", line > 144, in getmtime > st = os.stat(filename) > OSError: [Errno 2] No such file or directory: '/home/tina/.tmda/filters/blacklist' > > In this case the error is corrected by adding the blacklist file; > however, the message that generated this error is lost... whether it > was "good" or "bad."
When TMDA gets an error such as this it defers the message, meaning that the message is left in the MTA's queue and delivery will be re-attempted later. TMDA does this by returning the exit code EX_TEMPFAIL, which all supported MTAs understand to mean a temporary failure. If a message is lost, it is because of an intermediate program (such as procmail) that doesn't understand exit codes from programs it runs. In our Sendmail instructions (the only MTA requiring the use of procmail), we explicitly set procmail's EXITCODE variable from tmda-filter's exit code so that procmail *will* successfully return the temporary failure notice to Sendmail. If that is not done, all bets are off, but this really can't be considered a TMDA problem, as TMDA does does behave correctly. Procmail, on the other hand, happily ignores delivery problems and must be coerced into doing the right thing. > The real problem is a lack of attention to detail... I failed to > create a file, or I created it as root and didn't have proper > permissions. Are you saying that TMDA's inability to access a file that you explicity created with permissions that deny it access is TMDA's lack of attention to detail, or your's? (Email sucks as a communication medium. My question is serious, not sarcastic. I can't tell from your sentence which you mean and I need to know before attempting any sort of reasonable answer.) > Another exists due to the mailman config.db file being regenerated > periodically with permissions that don't allow all users to read the > file. That mailman creates files with permissions that deny regular users access is obviously not TMDA's fault, but perhaps there are some Mailman admins who have run into this problem and figured out how to solve it, or at least a reasonable workaround? > Is there a way to make this more friendly for admin error? Is there > a way to prevent the loss of the message when a similar Python error > occurs? Messages shouldn't be lost and aren't, with the correct MTA/delivery agent configuration. This is perhaps the most important design criteria both Jason and I adhere to with TMDA. Regardless of how nice a feature would be or how difficult it would be to implement correctly, mail must not be lost! Tim _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
