Newsgroup: it.comp.os.linux.sys
Titolo: Exim + SpamAssassin : preferenze per utente

Qualcuno di voi ha mai integrato Exim con SpamAssassin ed allo stesso tempo far onorare le preferenze per ciascun utente a quest'ultimo?
 
Ovviamente parlo di check fatti non in fase di delivery ma in fase di sessione smtp.
 
Considerato che il check in fase DATA viene fatto una sola volta per messaggio (ed un messaggio può essere diretto a più destinatari con impostazioni differenti), come si può ovviare al problema senza fare strani loop:
 
 mail -> exim -> pipe a spamc -> exim -> delivery
 
vorrei accorpare tutto:
 
 mail -> exim con SA -> delivery

  mail -> exim con SA -> delivery
 
 
...in questo caso, però, se il messaggio ha destinatari multipli devi
decidere quale ruleset applicare. Puoi fare tutti i loop che ti pare, ma
da questo non esci.
 

 da questo non esci.
 
Beh, no, il "puoi fare tutti i loop che ti pare, ma da questo non esci" non si applica in caso di loop. (oppure sei arrivato lungo con il quote)
 
Se mando in pipe la mail a spamassassin subito prima del delivery, riesco a selezionare il ruleset in base al reale destinatario, dato che il delivery (e di conseguenza il mio pipe) sarebbe richiamato per ciascun destinatario.

 ciascun destinatario.
 
La mail sempre una rimane, a meno che non trasformi una mail in ingresso
in due in coda.
 
Se l'obiettivo č taggare diversamente, funziona anche (pur portando a
potenziali duplicazioni del messaggio nel caso di due destinatari che
siano uno alias dell'altro).
 
Ma se hai una soglia di SA oltre la quale vuoi applicare rejection, non
lo fai, dato che o rigetti per entrambi o non rigetti per nessuno.
 
 
(discorso vecchio, ormai eviscerato in multipli thread)

 lo fai, dato che o rigetti per entrambi o non rigetti per nessuno.
 
Il reject smtp non lo posso fare, ma un dev/null si.
 
Ma comunque il mio problema è taggare (e delivery nella .Junk), non rigettare. Il reject viene fatto a monte e non customizzato per destinatario.
 
In soldoni, tutto ciò che arriva in pasto a SA, *per me* non è spam, poi se il cliente vuole aumentare il filtro, si imposta il livello di tagging ed Exim istruisce dovecot a consegnare nella .Junk, ma non viene buttato via nulla (quindi zero reject)

 In soldoni, tutto ciò che arriva in pasto a SA, *per me* non è spam, poi se il cliente vuole aumentare il filtro, si imposta il livello di tagging ed Exim istruisce dovecot a consegnare nella .Junk, ma non viene buttato via nulla (quindi zero reject)
 
Ok, ma in tal caso quale è la ragione per non eseguire SA in fase di
local delivery, dove eviti anche i problemi di alias explosion?
 

 local delivery, dove eviti anche i problemi di alias explosion?
 
Per evitare il loop, (il check in local delivery è come sto facendo ora)
Sono in cerca di una ottimizzazione ma dubito sia possibile.

 pu� esistere. O consegno o espando gli alias.
 
Ma il tuo post originale diceva:
 
�Qualcuno di voi ha mai integrato Exim con SpamAssassin ed allo stesso
tempo far onorare le preferenze per ciascun utente a quest'ultimo?
 
Ovviamente parlo di check fatti non in fase di delivery ma in fase di
sessione smtp.�
 
 
Non ci ho capito una fava, probabilmente...
 

 Non ci ho capito una fava, probabilmente...
 
Allora.
Io adesso ho il check in fase di *delivery*. E qui integrare le preferenze utente è semplice, basta mandare la mail in pipe a SA e poi farsela sparare indietro (esattamente come postfix+amavis, per intenderci)
 
Vorrei evitare questo loop integrando tutto in fase DATA, ma, come giustamente dici, dubito sia possibile onorare le preferenze utente, dato che la mail, in quel preciso momento, è ancora singola per tutti i recipient.

 Vorrei evitare questo loop integrando tutto in fase DATA, ma, come giustamente dici, dubito sia possibile onorare le preferenze utente, dato che la mail, in quel preciso momento, è ancora singola per tutti i recipient.
 
Tra l'altro, ciò che effettivamente non so fare è istruire SA ad usare solo e soltanto gli scores finali da DB, senza dover veicolare tutte le preferenze. 
In pratica vorrei poter leggere solo il "required_hits" da DB, tutto il resto è standard.
 
Attualmente ho tutte le preferenze su DB e non mi piace.

 Ovviamente parlo di check fatti non in fase di delivery ma in fase di sessione smtp.
 
A leggere le email successive, non ho capito perchè vuoi fare scoring nella
sessione smtp.
 
Ad ogni modo, se vuoi fare reject (o altro) nella sessione smtp e usare gli
score user-based, credo che l'unica sia scriversi un router/director ''fake''
che sostanzialmente simula un delivery, con il corretto uuid.
 
 
No, non saprei come fare, faccio tutto site-wide.
 
-- 
  The number of UNIX installations has grown to 10, with more expected.
	(_The UNIX Programmer's Manual_, Second Edition, June 1972)

 che sostanzialmente simula un delivery, con il corretto uuid.
 
Sto facendo grossomodo così, exim usa SA come transport e quest'ultimo ributta la mail dentro exim per provvedere al delivery finale.

 ributta la mail dentro exim per provvedere al delivery finale.
 
Ah quindi generi backscatter ...
 

 Ah quindi generi backscatter ...
 
E perchè mai?
Il backscatter lo generi se, una volta ributtato in exim, droppi.
Ma io ho ben scritto che tutto ciò che arriva a SA non sarà
mai droppato, in Exim ho un filtro che bypassa tutte le ACL se il
protocollo è "spam-scanned"


s/droppi/rigetti/g

 s/droppi/rigetti/g
 
Io non droppo/rigetto/cancello/bouncizzo (brrrr che termine!) nulla.
Tutto ciò che proviene da SA viene accettato indiscriminatamente e consegnato in .Junk (c'è un transport creato adhoc), sempre e comunque.
 
accept condition = ${if {eq {$received_protocol}{spam-scanned}}}
 
come prima riga di ogni ACL.

 Io non droppo/rigetto/cancello/bouncizzo (brrrr che termine!) nulla.
 
La correzione era semplicemente legata al fatto che droppare la mail non
causa backscatter (ancorchč poi possa dare altri problemi). Rigettarla
dopo la chiusura della sessione SMTP col mittente (o -ugh-
"bouncizzarla") lo causa...
 

 "bouncizzarla") lo causa...
 
Ok, ma io non faccio nessuno dei due.