Newsgroup: it.comp.software.newsreader
Titolo: [Hamster] mailfilt.hst: filtrare i post in html

(con o senza asterisco prima di Content-Type)
Decisamente *con*.
Ho provato: non pare filtrare per nulla il Content-Type...
Mi sono chiesto se fosse rilevante che, nei msg multipart, alcuni
header seguano parte del body (se cosě vogliam dire). Ma il mancato
filtraggio avviene anche quando Content-Type si trova nel primo gruppo
di header. Non so che dire...
-- 
Bye.
       Lem
--------------- 'CLOCK is what you make of it' ---------------
Nuovi numeri primi, con Prime95: 
www.mersenne.org/freesoft.htm

di header. Non so che dire...
Dall'help di Hamster:
The scoreable fields depend on the overview-information returned by
the newsserver ("XOVER")[*]. In most cases, the following fields are
available for scoring: Subject, From, Date, Age, Message-ID,
References, Bytes, Lines, Xref, Xpost:
[*] Note: Hamster does not support additional fields returned by the
server yet.
Probabilmente Content-Type non viene filtrato.
-- 
DGP85
http://daps.cjb.net/
Don't change the address.
No Binaries or HTML at this address.

Il protocollo POP3/IMAP è un po' diverso da quello NNRP :-)
Ma va'? Non lo sapevo ;)
Ma sulla sezione su mailfilt parla che gli header sono simili a quelli
di scores.


quelli di scores.
Allora mi è sfuggito.

di scores.
Simile č la syntax overview, ed il linguaggio perl per le regular 
expression... ma si legge distintamente che si dovrebbe poter filtrare
*qualsiasi* header, quando si parla di mail. :)
MSingleField = ( <Name of any header-field> / "Bytes" ) [ ":" ]
                          ^^^
Pare che non sia cosě, perň... anche se non ne ho capito il motivo.
Anche Agent consente il filtraggio di qualsiasi header (e non solo
header), per le mail, a differenza di quanto capita per i msg news,
proprio perché il protocollo lo consente...



Probabilmente è vero, ma per header si intendono quelli che, nel tuo
messaggio originale hai chaimato "primo gruppo di header". Tanto per
capirci, un messaggio è fatto da:
-------------------
Header
Header
Header
            <-- Riga bianca
Corpo
Corpo
Corpo
...
-------------------
Quindi con Hamster dovresti poter filtrare qualsiasi header, purchè sia
tale.
E' chiaro che se ti capita un HTML dichiarato nel corpo, non lo verdrai.
In questi casi dovresti però avere comunque un Header (vero) del tipo:
Content-Type: multipart/alternative;
che dichiara che il corpo è fatto di più parti, _alternative tra di loro_
(nel senso che lo stesso identico contenuto è ripetuto nelle varie parti, ma
"espresso" in modo diverso (es: HTML e plain text)).
Probabilmente dovrebbe bastarti.
--
alexseb chiocciola 
freeweb.org
http://alexseb.freeweb.org

Content-Type: multipart/alternative;
E a me non l'aveva filtrato, come ho scritto. :(
Ma PaoloR ha scritto che adesso a lui funziona, quindi devo aver 
sbagliato qualcosa, e credo pure di avere capito che cosa: io ho fatto le
prove spedendo da OE ad Hamster, in locale. La prima cosa che sta
scritta nell'help di Hamster, riguardo al mailfilt, è che viene usato
quando si scaricano le mail da un POP3 remoto: siccome il POP3 remoto
nelle mie prove non c'era proprio, non è stato usato il mailfilt.
Il che ha provato solo che sono rincitrullito. :(


 che sia (cosa che Agent fa, per esempio).
Si potrebbe, in effetti, ma probabilmente non è stato fatto per il costo (in
termini di tempo macchina).
Se ad esempio hai tra le mani un msg di un paio di MByte (perché ha, ad
esempio, un allegato), sciropparsi circa 25000 righe, magari come regexp,
potrebbe stare mooooolto tempo (secondi?). Agent come se la cava, in questi
casi?
Alex


casi?
A meno di avere davvero moltissimi messaggi mooolto lunghi, non credo 
che ci sarebbero troppi problemi: pensa ad una global search di Agent 
sul body di decine di migliaia di messaggi news: per quanto, ci 
vogliono minuti, non ore. (E poi, se uno ha tempo e il filtro lo 
vuole, diamogli la possibilità di scegliere, direi).
Or ora ho provato la regexp
body:%{^f.*bar}
su un ng con 18K body. Agent ha completato il tutto in poco più di un 
minuto, con 39 riscontri.
Volendosi limitare a filtrare gli header, anche 'sparsi', penso 
sarebbe ancora più facile, purché si prendano come riferimento le 
linee boundary.
Poi, si potrebbe guardare l'encoding per evitare il filtraggio 
sull'encoding bynary (per esempio) etc. etc. etc.
Certo dipende anche da come si programma la cosa. Ma, fra noi due, 
l'esperto di programmazione sei tu: dimmi tu. :)


casi?
A meno di avere davvero moltissimi messaggi mooolto lunghi, non credo 
che ci sarebbero troppi problemi: pensa ad una global search di Agent 
sul body di decine di migliaia di messaggi news: per quanto, ci 
vogliono minuti, non ore. (E poi, se uno ha tempo e il filtro lo 
vuole, diamogli la possibilità di scegliere, direi).
Or ora ho provato la regexp
body:%{f.*bar}


 minuto, con 39 riscontri.
E' un tempo MOSTRUOSO! ;-)))))
Come giustamente hai detto, "se uno ha tempo", funziona. Il punto è che non
stai parlando di tempo "off-line": tutto 'sto bel lavoro succede _mentre_
stai scaricando la posta, e non credo sia accettabile attendere svariati
secondi tra il d/l di un messaggio e l'altro, quando ti capita una mail
lunga.
<pensiero tra me e me>
Certo, si potrebbero sempre imbastire due 3d separati: uno la scarica e
l'altro la smista, ma diventa più complicato...
</pensiero tra me e me>
Cmq, credo che il punto cruciale sia un altro: i filtri di Hamster, sia news
che posta, sembrano nascere soprattutto per decidere se scaricare o non
scaricare i singoli messaggi; tant'è che se per quel server hai _almeno una
regola_ che prevede il "lascia sul server" o il "killalo dal server, senza
pietà", Hamster prima "sniffa" gli header con "TOP xx yy" (che torna le
prime tot righe del msg), proprio per evitare il peggio. In questo modo puoi
filtrare senza problemi anche mailbombing et similia.
Ma se per decidere scaricare un messaggio o meno, dovessi prima scaricarmelo
tutto...
Fine divagazione ;-))
Tornando al problema concreto, probabilmente quello che vuoi fare tu (cioè
sostanzialmente smistare della posta "particolare") è più sensato farlo dopo
il download, con un script che vada a ravanare "ad hoc" tra i msg ricevuti.
Ciao


tutto...
Beh, ovviamente il filtraggio del body ha senso solo per i filtri di 
smistamento, a patto che vengano eseguiti a download ultimato. E, 
comunque, per limitare eventuali danni si potrebbe subordinare tale 
filtro sul body ad un filtro sulla dimensione del messaggio: filtra 
il body solo se la dim. è minore di X (qui non so come Hamster si 
comporti ora: vale a dire, se valuti anche la seconda proposizione di 
un AND logico, anche dopo aver trovato falsa la prima, oppure, più 
intelligentemente, si blocchi subito).
Salutoni.


 smistamento.
...
Mi trovi pienamente d'accordo. A quel punto, per il solo secondo gruppo
sarebbe logico poter avere ulteriori "meta-campi" (ScoreFields, insomma) su
cui lavorare, come ad esempio (le sto sparando a caso) "Body-Contains",
"Body-MIME-Type", ecc.
Chissà se Thomas G. Liesner avrebbe voglia di mettersi all'opera? Per adesso
ha un paio di cosucce su cui lavorare, magari dopo la prossima non-beta...
