«invalid characters»

[Olivier Hammam]

As a french user I receive some mails with accented chars in the sender's alias; also, I receive, as anybody, spams from countries that don't use the common characters sets (China, Japan, Russia, etc.). And I can't add these adresses to friends or blocked senders because of the «invalid characters» filter. I saw that some users asked for an unicode support, but there is another way: no need to «understand» (recognize) the extended characters to handle these adresses, I think that there is no reason to consider these characters as «invalid».

For example, there is a sender that appears as «NewsLetter Libération» in my mail software and as «NewsLetter Libération» through Spamihilator. As it seems to me, «Ã©» are «valid characters» as long as the sender's name «NewsLetter Libération» appears each time in the same form, and this is.

I suggest to allow « strange » characters in the sender's alias.

[michel]

Hello Olivier,

thank you for your contribution. The characters are considered invalid because the senders are saved in a .ini file where they might cause problems. In the future they will be saved in a SQLite database. This should solve this issue. I added this feature to my TODO list.

Sincerely,
Michel

[Olivier Hammam]

Hi michel!

Thanks a lot for your answer.

Regards,
Olivier Hammam

[RetiredFed]

Hallo michel!
I assume that the SQL database was added to v1.0.
My problem adding friends who have accented characters in their names remains since I had to uninstall v1.0 when it seemed to mis-function and I had to re-install v0.9.9.44 that I had running previously.
Would any of the Beta's contain the sql version?

I am running Spami on an XP SP3 on a Thinkpad T60.

Gruß
RetiredFed

[Chactory]

Hello RetiredFed!

I'm going to alert Michel about your question, for I can't answer it for him.

Regards,
Chactory

[Quellcore]

Hello RetiredFed!

0.9.9.54: Michel Krämer (07/08/10)
- improved storage of senders: they will be saved in a Sqlite
database now

http://www.filefactory.com/file/5obu7uxn006r/n/Spamihilator-win32-0_9_9_54_exe

Regards,
Quellcore

[Quellcore]

Hello RetiredFed!

...I had to uninstall v1.0 when it seemed to mis-function...

May i ask for more details about "mis-function"
Sounds mysterious, but could most likely be solved easily.

Regards,
Quellcore

[michel]

Hi!

Yes, that would also be interesting for me. RetiredFed, can you give us more information please? Thanks.

Michel

[RetiredFed]

Hallo michel!
Eventually, I will try to reinstall the newer version of Spami...later...maybe 1.x.
So, for now, I will not try to duplicate the problem that I encountered. Sorry.

For the moment, I am content to stay with 9.9.44 because it works ok for me.

Am I correct to assume that Spami only needs a Name associated with the emailaddress. It is the emailaddress that gets filtered, not the name associated with it. The DisplayName does not have to exactly duplicate the Name received.

My work-around that seems to resolve the accented character problem is to delete the part of the name that contains such accented characters.

The actual username@ispdomain.com never, contains accented characters. IAW RFC5322. So the Spami INI file in this 9.9.44 version of Spami will contain, e.g. the DisplayFirstname only and the email-username@isp.com with the DisplayLastname deleted if it contained the accented character:"Jose" instead of "Jose García" or "Jose Peña".

So, as long as the email address is compliant with RFC5322, Spami 9.9.44 should be ok?
If RFC6530 ever gets implemented, then I will need an update Spami version. The SQLLite will work with RFC6530?

http://en.wikipedia.org/wiki/Email_addr ... n_Examples


Gruß
RetiredFed

[RetiredFed]

I guess it is your implementation of UTF8 that will allow the international character set?
I was not familiar with UTF8. At first I thought it dealt with MIME issues.
But, how many mailservers in the US and Europe can deal with UTF8?

Your user base probably has a need for UTF8, but I doubt I will have any correspondents with UTF8 addresses in the near future.