Hi, Alex!
AlexV hat geschrieben:It looks like C++ apps also require MSVCR80.DLL
Actually it's binaries created by Microsoft Visual C++ that requires this runtime DLL. You might consider using GCC or another compiler to avoid this. Personally I like Dev-CPP.
And now to your Plugin. I think it uses a clever idea so of course I've tried it out. It's running since a couple of days which unfortunately were pretty short of spam

so I did some manual testing. Generally speaking it does work, however there are some bugs and inconveniences I discovered.
It starts with the forced installation of .net 2.0 which I don't like very much. I had version 1.x installed and since I wanted to try your plugin I swallowed the bitter pill and allowed the setup program to download and install the .net framework 2.0. The download worked but the installation failed (sorry I didn't note the error message). Therefore restarting Spami resulted in an error message, "a PlugIn couldn't be loaded." After manual installation of .net 2.0 everything worked fine so far. I configured my primary e-mail address manually: "firstname.surname@example.com" with display names "Firstname" and "Firstname Surname".
After a while it turned out that a spam mail with
- Code: Alles auswählen
To: "Firstname.surname" <firstname.surname@gmx.de>
was not detected as spam. I looked deeper into it and found out that this misnomer was detected after I changed "Firstname" to "^Firstname$". After all it's a regular expression, right? The problem is that probably noone will intuitively add ^ and $. So I think it's worth considering to have the plugin automatically add these commands or something of that sort. In any case this should be noted in the readme. BTW, I think the readme is hidden quite deep within the file system. Hadn't I been curious about the new plugin I guess I wouldn't have found it. Maybe you could add a link in the settings dialog. Oh, and also I should mention that later on I found out that whenever the Misnamed Filter learns a new address automatically it adds ^ and $.
Another thing about the RegExes: Shouldn't they be case-sensitive? Right now they are case-insensitive.
And another one: E-mail addresses are also treated as RegExes. Does this make sense to anybody? While it is there's a pitfall about dots in e-mail addresses. I entered my address as "firstname.surname@example.com" and it did work so far. As the dot in a RegEx means "any character" I unconsciously also added addresses "firstnameXsurname@example.com" etc. as well. The correct entry would have been "firstname\.surname@example.com" or better yet "^firstname\.surname@example.com$". I know, I know, this is mentioned in the readme so it's kind of my own fault. Yet I think that regular expressions are not required at that spot and that I won't be the only user to fall into that trap.
The readme says that
"The presence of any known email address without a valid display name will cause the email to be marked as spam."
This is not true as far as my experience with the filter is concerned. And you know what - I'm glad it isn't. In order to be consistent the readme should be changed in that regard. And of course, if there are people who would like to see that behavior, an option would be great.
The following one isn't a bug but something which might be worth thinking about to improve the filter. Let's say I have "^Firstname Surname$" as my name pattern. Now if someone sends me an e-mail with "Firstname", "Surname", "F. Surname", "Surname, Firstname", "Firstname TopSecret Lastname" or the likes, it will be considered spam according to the filter's rules. Sooner or later this will trigger a couple of false positives and if there's one thing the forum members don't like, that's it

Maybe the filter could be modified so as to detect "similar" display names. So far just some food for thought.
I think the readme could be improved when it comes to address sets. The explanation is perfect for different persons, subsequently having different e-mail addresses AND names. It might be added that it makes sense to merge peter@mydomain and peter@otherdomain if both addresses belong to the display names "Peter", "Peter W.", "Peter Whatsoever" and so on.
When it comes to editing the matching email/name patterns I dislike the current user interface. One has to click "add" and afterwards change the added "<new name pattern>" into something real. Also if "add" is clicked repeatedly there are a lot of new patterns...

It's no big deal, I just mentioned it as it's against my personal intuition.
What happens if one e-mail contains both a good and a bad display name? During my testing I found out that your plugin flags this mail as spam. Personally I think that non-spam or rather undecided would be the right choice here. Again an option would be the crème de la crème.
When the filter automatically adds an e-mail address and display name, it changes spaces to "\ " which is perfect in the sense of RegEx. However does it then handle folding white spaces in the mail header? This is one thing I didn't investigate any further, but it might be error-prone.
While testing I used
- Code: Alles auswählen
To: "Alter Kollege" <alterkollege@bollchen.de>
which was learned correctly. Changing it to
- Code: Alles auswählen
To: "Alter! Ey, Kollege!" <alterkollege@bollchen.de>
showed a bug. The automatically learned display name was "^Kollege!$" which of course is incorrect. I assumed the comma to be the source of the bug and trying
- Code: Alles auswählen
To: "Alter! Ey Kollege!" <alterkollege@bollchen.de>
which was learned correctly as "^Alter!\ Ey\ Kollege!$" proved that point. It only got really peculiar as I manually added "^Alter!\ Ey,\ Kollege!$":
- Code: Alles auswählen
To: "Alter! Ey, Kollege!" <alterkollege@bollchen.de>
is still erroneously detected as spam; reason for filtering:
- Code: Alles auswählen
, Kollege!" <alterkollege@bollchen.de>
The test tool however works fine and interprets "alter! ey, kollege!" as non-spam.
Well... that was quite a bit. I would like to hear what you and others think about my suggestions. Better yet I'd really appreciate a version 0.2.0
Um... and yes, to those who are eagerly waiting for an updated Bad Recipient Filter... I'll work on it... soon
Bye, Burkart