Photocon <[EMAIL PROTECTED]> writes: > from ~vpopmail/domain/user/tmda/log/tmda_debug.log: > ------------------------------ > Uncaught Python 2.2 Exception (Mon Dec 16 22:57:14 2002): > --------------------------------------------------------- > Traceback (most recent call last): > File "/usr/bin/tmda-filter", line 50, in ? > execfile(os.path.join(execdir, 'tmda-rfilter')) > File "/usr/bin/tmda-rfilter", line 780, in ? > main() > File "/usr/bin/tmda-rfilter", line 728, in main > message_size) > File "./TMDA/FilterParser.py", line 930, in firstmatch > File "/usr/src/build/87651-i386/install/usr/lib/python2.2/sre.py", > line 137, in search > > return _compile(pattern, flags).search(string) > File "/usr/src/build/87651-i386/install/usr/lib/python2.2/sre.py", > line 228, in _compile > > raise error, v # invalid expression > error: nothing to repeat > ------------------------------- > > In previous posts Tim has mentioned looking for "*" and"+" in all > files in the lists dir, and making sure they are correct. Ive checked > the syntax in the whitelist for *@=domain.com, and all is > correct.
Just a clarification that might help you a little. In email addresses, whether they appear in your incoming filter or in text list files (white/black), the '*' works like it does at the shell. It means zero or more characters, *not* zero or more of the preceding character. The only time TMDA uses real regular expressions, where '*' means zero or more of the preceding character, is in the 'body', 'body-file', 'header' and 'header-file' rules. So the error above is occuring in one of those four rules. You'll only need to look at those rules or the files reference by either of the two body/header-file rules. > There were a couple of instances of "*" being in the blacklist in a > supposed user's name multiple times, so I removed those entries (or > shortened them to "*@evildomain.com". Changing this did not seem to > help. The contents of that file are not interpreted as regular expressions, so the problem can't be there. > Im really confused why it is looking for file > "/usr/src/build/87651-i386/install/usr/lib/python2.2/sre.py". I don't know why this happens, but it seems common on RedHat systems and regardless of the wacky file names that get compiled in, the Python system seems to work. At a guess, that's the location where the binaries were built and so bears no relation to where the installation actually is. > At first that file didn't even exist on my system. However, I > symlinked "/usr/src/build/87651-i386/install/" to "/usr" so now the > file negotiation is correct. This did not seem to have any effect. Yeah, you can undo that. It doesn't have anything to do with the problem. > This was a keyworded to field that is causing the problems. It's not the address that caused the problem. It's your filter. Most mail probably gets either whitelisted or blacklisted before it reaches the problem line, which is why you don't see the problem most of the time. > I added "to [EMAIL PROTECTED] ok" (actual email > address changed to protect the innocent) to the incoming filter at > the top. This seemed to have no effect. This should have had an effect. Perhaps you have a typo? Try something like to user-keyword-*@hosted.net ok if you want to test that. But the real solution is to find the problem regular expression. If you can't find it, feel free to send me your incoming filter directly. Tim _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
