spam.el whitelist and blacklist contents and syntax

spam.el whitelist and blacklist contents and syntax

[lanz]

Two questions/feature requests concerning spam-whitelist and
spam-blacklist filtering with the Spam Elisp Package provided with
Gnus v5.10.3 (CVS).

- I think new sender addresses should only be added to the whitelist
  (or blacklist) file if not already present in the file. At the
  moment these files are unnecessarily growing with identical entries
  for mail addresses I frequently exchange mail messages with (I get
  frequently spam from).

- I think the whitelist and blacklist entries as generated through
  gnus-group-ham-exit-processor-whitelist and
  gnus-group-ham-exit-processor-blacklist do not use Emacs regular
  expression syntax as stated in the documantation? I am not shure
  about this, but they produce entries like `Peter Pan
  <peter.pan@somewhere.com>' instead of `Peter Pan
  <peter\.pan@somewhere\.com>' or `Peter Pan
  <peter\\.pan@somewhere\\.com>'? I'm confused, is the documentation
  clear enough?  gnus-group-ham-exit-processor-blacklist and
  gnus-group-ham-exit-processor-whitelist also enters the `Peter Pan'
  part into the list, i.e. the mail address label. Therefore, I get
  many unreadable charcters stemming from Korean and similar spam in
  the blacklist file (I use an unibyte (latin1) emacs). Any problem?
  Maybe not, but it might be safer to register only the
  email-addresses without labels?

Re: spam.el whitelist and blacklist contents and syntax

[Adrian Lanz]

On 24 Jun 2003, tzz@lifelogs.com wrote:

> On Tue, 24 Jun 2003, lanz@fowi.ethz.ch wrote:
>> A typical korean spam message with a from: field of the form
>> 'DISPLAY-NAME <MAILBOX>' now splits into the bogus group (Error in
>> `nnmail-split-methods'). I use an unibyte (Latin1) emacs and
>> DISPLAY-NAME is shown like in '³ª¿ä<koogi888@hanmail.net>' (don't
>> know how this comes out in your emacs, for me the DISPLAY-NAME part
>> is a superscripted 3, a superscripted a a spanish question mark and
>> an a with two dots over it). mail-header-parse-addresses, which
>> should probabely be implemented but is at the moment the same as
>> ietf-drums-parse-addresses, tested with
>> '(mail-header-parse-addresses "³ª¿ä<koogi888@hanmail.net>")'
>> returns nil.
>
> gnus-extract-address-components seems to work OK with this address,
> I use it instead of ietf-drums-parse-addresses now, see CVS.

That's right, but with the CVS version of today all incoming mail
messages get split into the spam group! Something wrong in the logic
of the spam-check-blacklist function?

Thanks, Adrian