von AlexV » 26. Feb 2007, 20:58
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