gnus-parameters

gnus-parameters

[reader]

I don't know if `gnus-visible-headers' is something that can even be
delt with in `gnus-parameters' but what I have below is definitely NOT
the way to do it.  Since I don't understand/know the basic principles
of elisp... I'm just monkeying around with the parens hoping to get it
right. 

The forumulation below can be evaluated without error but gnus cannot
function with that evaluated...  Basic things like opening/closing a
group are broken by it... and give errors like (wrapped for mail):

   gnus-group-fast-parameter: Wrong type argument: \
      stringp, gnus-visible-headers


 (setq gnus-parameters
       '(("[Ss]pam[0-9]*$\\|_ex$"
          (total-expire . t)
          (expiry-wait . 18))
         (gnus-visible-headers
           ("\.bk$"
            ("^X-Spam-Report:.*_FARAWAY_")))))

Can someone tell me first off if `gnus-visible-headers' is something
that can be handled in `gnus-parameters'.  

The manual talks about it and mentions that `visible' doesn't work.
So I wasn't sure if that would include `gnus-VISIBLE-headers'.

From gnus manual:
 
     Group parameters can be set via the `gnus-parameters' variable
     too.  But some variables, such as `visible', have no effect (For
     this case see `gnus-permanently-visible-groups' as an
     alternative.). [...]

Just scanning thru various related things in the manual I couldn't
tell if `gnus-visible-headers' should work in a gnus-parameters
setting. But just going by the name of it `gnus-visible-headers' seems
like it would be considered a `gnus-parameter'

If `gnus-visible-headers' can be set for a list of groups matching a
regex in gnus-parameters maybe someone can show an example of what the
syntax would look like.

I do have `gnus-visible-headers' set globally and not sure if that
would somehow interfere. (Wrapped for mail)

(setq gnus-visible-headers 
         "^From:\\|
         ^Subject:\\|
         ^To:\\|
         ^Date:\\|
         ^Message-ID:\\|
         ^X-Spam-Status:\\|
         ^X-HP[rm].*:\\|
         ^Newsgroups:\\|
         ^Keywords:\\|
         ^Gnus-Warning:")

Re: gnus-parameters

[Reiner Steib]

On Sun, Dec 16 2007, reader@newsguy.com wrote:

>  (setq gnus-parameters
>        '(("[Ss]pam[0-9]*$\\|_ex$"
>           (total-expire . t)
>           (expiry-wait . 18))
>          (gnus-visible-headers
>            ("\.bk$"
>             ("^X-Spam-Report:.*_FARAWAY_")))))

Please describe *what* you are trying to achieve.

My best guess is that you'd like to _add_ X-Spam-Report in all groups
matching "\.bk$".  This would be...

(setq gnus-parameters
      '(("[Ss]pam[0-9]*$\\|_ex$"
	 (total-expire . t)
	 (expiry-wait . 18))
	("\\.bk$"
	 (gnus-visible-headers
	  (concat gnus-visible-headers "\\|^X-Spam-Report:")))))

> Can someone tell me first off if `gnus-visible-headers' is something
> that can be handled in `gnus-parameters'.  

It can.

> The manual talks about it and mentions that `visible' doesn't work.
> So I wasn't sure if that would include `gnus-VISIBLE-headers'.

No.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: gnus-parameters

[reader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Sun, Dec 16 2007, reader@newsguy.com wrote:
>
>>  (setq gnus-parameters
>>        '(("[Ss]pam[0-9]*$\\|_ex$"
>>           (total-expire . t)
>>           (expiry-wait . 18))
>>          (gnus-visible-headers
>>            ("\.bk$"
>>             ("^X-Spam-Report:.*_FARAWAY_")))))
>
> Please describe *what* you are trying to achieve.

I guess I thought since I was attempting to add gnus-visible-headers
to gnus-parameters it would be kind of clear I wanted to make a header
visible by way of gnus parameters which is largely based on regex.

But I can see now since I had it completely inside out and backwards how
it would be pretty confusing.

But anyway, you made a good and accurate guess ... thanks.
I only wanted the X-Spam-Reports that contain hits on _FARAWAY_ but that
is an easy refinement now you've showed the main code.  And thanks again.

Since there is little traffic on this sunday afternoon (here) I guess
I will bore you to death with some commentary about _FARAWAY_

PS -

_FARAWAY_ is part of the string spamassassin inserts if one tells it
to look for messages not in their native language (in my case
english).

I've wondered from time to time how spamassassin accomplishes that.
Charset declarations headers or `Received' headers with addresses
ending in non-english speaking country designations like \.kr \.cn
etc.  Is how most of it gets done but I've noticed that not all
messages have those things in them.  Yet spamassassin still mostly
gets it right.

I've found quite a few messages with the _FARAWAY_ tag but I could
find no evidence to base it on... but it was correct.  Or at least was
in a non-english language.

The reason I'm curious is that at one time I spent a few days trying
to create procmail recipes that did that very thing.  The one that was
most reliable (below wrapped for mail) gets very few if any false
positives:

* ^(Subject|Message-ID|From|Received):.*(@|\.)[a-z0-9][a-z0-9]*\.
     (ar|br|cl|ch|cn|co|cz|de|hu|it|jp|kr|mx|pe|pl|ro|ru|th|tr|tw|ua|uk|
     [a-z][a-z])[^a-z0-9.@]

I add a new country every once in a while.  But like I said, not all
non-english mail has that kind of handy string or a non-enghish
character set header in it.

For those, I tried to create a few Subject based regular expression
character sets that included common letters in some non-english
language that never occur in english, but finding common letters when
you know nothing at all about a language is very time consuming.

Now I happily let spamassassin do the chore... but I doubt it uses
that method.

I still do the heavy lifting with that regex based on country
designation trying to keep down the high cpu cost of spamassassin by
handling most of the non-english stuff before it gets that far.

If I knew more about how SA does it, I might try to get still more of
it with procmail.  I asked on the SA list twice but was shunned both
times.. Apparently they felt it was either obvious or well documented.

Neither seemed true to me.

Re: gnus-parameters

[Adam Sjøgren]

On Sun, 16 Dec 2007 16:40:50 -0600, reader@newsguy.com wrote:

[...]

> Now I happily let spamassassin do the chore... but I doubt it uses
> that method.

Why not just look at the SpamAssassin code? It is Free after all, right?

Looking at the 20_body_tests.cf rule-file:

  http://svn.apache.org/viewvc/spamassassin/trunk/rules/20_body_tests.cf?view=markup

reveals a method called check_for_faraway_charset() in the module
Mail::SpamAssassin::Plugin::MIMEEval:

  http://search.cpan.org/src/JMASON/Mail-SpamAssassin-3.2.3/lib/Mail/SpamAssassin/Plugin/MIMEEval.pm

Reading that code reveals that your system locale is considered, for
instance.

You can do similar "detective work" for the other rules that involve
FARAWAY (20_head_tests.cf --> Mail::SpamAssassin::Plugin::HeaderEval
check_for_faraway_charset_in_headers) - then you needn't speculate nor
guess :-)


  Best regards,

    Adam

-- 
 "I myself have spent many an enjoyable hour in my            Adam Sjøgren
  spare time not collecting stamps."                     asjo@koldfront.dk

gnus-parameters

[Boris Daix]

Hi all and thanks for reading...

   I use Gnus coming from CVS snapshots for Debian -- I've put this in
my .gnus.el file : 

,----[ from .gnus.el ]
| [...]
| (setq gnus-parameters
|      '(
|        ("mail\\.cron" (total-expire t)
| 	              (expiry-wait 3))
|        ("mail\\.spam" (total-expire t)
| 	              (expiry-wait 3))
|        ("list\\..*" (total-expire t)
| 	            (expiry-wait 15))
|       )
| )
| [...]
`----

   I hoped it would delete spam after three days and mailing-lists
stuff after 15, but id doesn't... I have to say that I have different
kind of sources : /var/spool/mail/me and ~/spool/*.spool that are
re-splitted so that all go in place according to my fancy-splitting,
anyway, I think this shouldn't be a problem. The variable
documentation didn't help me -- any idea ?

-- 
Boris Daix

	"Feel free to be Free, or not to be..."