New plugin: Misnamed Filter

[AlexV]

Again, apologies for not writing in German here.

I've got another plugin ready for you to try, called Misnamed Filter. Its purpose is to detect spam emails which have been sent to valid email addresses, but using the wrong display names. For example, if an email is addressed to "Richard Meyer" <example@gmail.com> then it is very likely to be spam (unless your name is Richard Meyer, of course!).

This filter is capable of learning the valid display names for addresses, based on the non-spam emails learnt through the training area, and can also be manually configured using regular expressions to exactly specify your email addresses and valid display names for them.

This filter is provided in an installer, which will place Misnamed Filter.dll in your Spamihilator plugins folder, and supporting files such as the uninstaller, configuration component and settings file in a "Misnamed Filter" subfolder of the plugins folder.

All incoming mail will have the To:, CC: and BCC: headers scanned for email addresses with display names. The presence of any known email address with a display name that is not known as valid for that address will cause the email to be marked as spam. This filter will never mark an email as non-spam.

I would recommend positioning this filter just above the learning filter in the priorities list, below any filter which may perform any sort of whitelisting.

This filter requires the .net CLR runtimes, which the installer will check for and install if you don't already have them. The source is also provided in the installer, with the plugin dll written in C++ (ugh) and the configurator in C#. The installer is NSIS.

I hope you find this useful, and comments and suggestions are always welcome.

MisnamedFilter-0.7.exe

Alex

[anbuva]

Hallo AlexV!

Thank you for your cooperation and a new great PlugIn.
Unfortunately, Spami cannot load this Plugin at start ("a PlugIn couldn't be loaded") . I don't know whether the problem is due to Spami or the PlugIn.

Regards
anbuva

[AlexV]

Hello anbuva,

I'm sorry that this plugin is not loading for you. I'm not sure why that would be, perhaps you could tell me what version of Spamihilator you are using? I am using 0.9.9.21, and of course it loads fine for me!

When it says a plugin could not be loaded, does it give the name of the plugin that can't be loaded, and is it "Misnamed Filter.dll"?

Thanks,

Alex

[anbuva]

Hallo AlexV!

Yes, that is right. This is the name of the plugin . Im also use the .21 version. The same error with the .10.

Regards
anbuva

[AlexV]

The only thing I can think of then, is maybe you have a different version of the .net runtimes installed, or not installed at all, and the plugin installer didn't detect it for some reason... Did you try my other plugin, the TrustSpamAssassinHeaders.zip one? If that one produces the same error then it must be something .net related...

[anbuva]

Hallo AlexV!

With the other PlugIn from you, the same "problem"!
I have the framework 2.0.50727 on my computer.
The required version is the 2.0; isn't it?

Regards
anbuva

[AlexV]

OK, I've done a bit more research into this. It looks like C++ apps also require MSVCR80.DLL, which I'm guessing you don't have. I've updated the installer so that it includes that, now. It puts it in a sub-folder of plugins, so it should be available to any plugin that requires it, and shared among them.

I don't know if this actually works or not, it is according to instructions I've found on Microsoft's site and others, but on my PC it was working before, so the fact that it is working now doesn't give me any more information!

Oh well, another 300k on to the download size, and more dll files splattered about the place. Yet another reason to dislike C++

[anbuva]

Hallo AlexV!

Great! WOW! That was it! Thank you very much!
Now i will try the new filter for the next (and hopefully every) time.......

Regards
anbuva

[Chactory]

Hallo AlexV!

Thank you for the new plugin. This is a good idea, and I will try it out.

Regards, Chactory

[anbuva]

Hallo AlexV!

The first results were positive. I can issue a good testimonial to this filter at the moment!

Regards
anbuva

[AlexV]

Hallo anbuva!

Thanks, that is good to know. I have noticed a couple of people gave it 2/5 stars on the plugins database, but as no-one has commented what they don't like about it, I will leave it as it is. It works well for me!

Regards,

Alex

[anbuva]

Hallo AlexV!

Good that you have said it. With the assessment system something doesn't seem to be correct.The result should look different . I will take care of it....

Regards
anbuva

http://www.spamihilator.com/forum/viewt ... highlight=

[Burkart]

Hi, Alex!

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

[AlexV]

Hello Burkart,

Thank you for your long and detailed post:

As far as I can tell, neither GCC nor Dev-CPP support C++ CLI (C++ .net). OK, it would be technically possible to rewrite this plugin in pure C++ without using .net, but I know .net well, and I don't know C++ well, so I'm not going to do that.

I'm sorry you don't like .net 2.0. I'm not sure I can help you with the installation error, it is a standard script supposed to just download the official installer from Microsoft and run it. It is understandable that the plugin would not be loaded if .net 2 was not installed, though.

I understand the confusion about regular expressions, there is much which may not be obvious about their use. That is why I added the Learning function to produce them automatically, and figured editing them manually would be an advanced task. If I can figure out a good UI for specifying whether an entered name or address should be treated as plain-text and auto-converted to a regex, I could add that to the configuration dialog.

I chose to make the checks case-insensitive deliberately, as I could not think of a reason they should be case-sensitive. If "Alex Vallat" is right, then surely "alex vallat" doesn't indicate spam?

Emails as regexes make sense to me, as I have several addresses on a domain which are valid, and I would not want to lose that functionality, or specify them all individually. Again, a way of auto-converting to a regex in the configuration UI might address this issue for you.

Good call on that quote from the readme, I'll fix that. It was, of course, supposed to read: "The presence of any known email address with a display name that is not known as valid for that address will cause the email to be marked as spam."

I'm not convinced about the Similar Names idea. If I've manually entered a regex, I want it to match those exactly, if I wanted a fuzzier match, I'd have written a fuzzier regex pattern. For the Learning function, I have followed the same principle of the learning filter. Make a best guess, and improve on it by learning from mistakes. If, in your example, you get "Surname, Firstname" marked as spam, then mark it as Non Spam and learn from it, then "Surname, Firstname" will be added to the pattern and not marked as spam in the future. Thank you for the suggestion, though.

Thanks also for the idea for explaining about using the same name for different addresses in the readme, I'll add that in.

I'm not sure what it is you don't like about the current UI. You click Add, and you type the name. Like if you choose "New Folder" in Explorer, for example. Anyway, if it is against your intuition, and you found it awkward to use, then that is good for me to know, in case I come up with a better idea.

The rationale behind the behaviour for when an email contains both good and bad display names is that this plugin doesn't mark things as non-spam. I thought that having a good display name wasn't a strong enough indicator to indicate non-spam, so left it as making no decision. Having a bad display name is a good indicator for spam, though.

If I added functionality to consider good addresses as non-spam, then if there was both good and bad, they should cancel out to undecided, though. I'd be interested, in your experience, would a good display name be a strong enough indicator of non-spam to be worthwhile?

I see what you are saying about folding headers, I'll check it out. The regex is correct as is, as it should not have to be aware of the underlying format of the header. The header should be unfolded before being matched against, but it might not be currently. If it isn't, I'll fix it so that it is.
edit: Just checked, headers are unfolded by Spamihilator before being passed to plugins, so this works fine.

Thanks for pointing out the comma bug. This is simply a bug with the internal regex I am using for parsing email addresses not supporting commas inside the display name. I'll fix this.

So, in conclusion, thank you for your suggestions and bug reports, and yes, there will be a version 0.2 coming soon.

Regards,

Alex

[anbuva]

Hallo AlexV, hallo Burkart!

@Burkart:

Thank you, for this very interesting statement !

@AlexV:

Everything worked fine; till now
I already look forward to the new version.

Gruß
anbuva