Newsgroup: it.comp.os.linux.sys
Titolo: Postfix restriction classess

Tempo fa avevo provato a sperimentare le restriction classess di
postfix senza successo.
Ora le devo implementare ed ho gli stessi problemi.
Facciamo un po di ordine:
in 
main.cf
 ho
smtpd_recipient_restrictions =
   reject_unauth_destination
   check_recipient_access mysql:/etc/postfix/mysql-
recipient_restrictions.cf
smtpd_restriction_classes = PROTETTA, NONPROTETTA
PROTETTA =
   permit_mynetworks
   ,permit_sasl_authenticated
   ,reject_unauth_destination
   ,reject_rbl_client 
list.dsbl.org
   ,reject_rbl_client 
zen.spamhaus.org
   ,reject_rbl_client 
combined.njabl.org
   ,check_recipient_access hash:/etc/postfix/forza_amavis
NONPROTETTA =
   permit_mynetworks
   ,permit_sasl_authenticated
   ,reject_unauth_destination
----
in 
mysql-recipient_restrictions.cf
 ho qualcosa di sto tipo:
query = SELECT IF(protetta='1','PROTETTA','NONPROTETTA') FROM
recipient_restrictions WHERE recipient = '%s' AND attivo = '1' LIMIT 1
che teoricamente dovrebbe mettermi in PROTETTA tutti gli indirizzi
aventi "protetta" = "1"
Eppure, non funziona.
E poi ho un altro problema, se la query non ritorna risultati, in che
classe mi mette l'utente?

 classe mi mette l'utente?
Semplice: nessuna.
Il che potrebbe suggerire che potrebbe essere sensato selezionare gli 
utenti da mandare in una classe, applicando l'altra a tutti quelli che 
non son finiti nella prima...

 non son finiti nella prima...
Ok, come immaginavo, ma quindi per fare la classe di default mi basta
usare
smtpd_recipient_restrictions = ... ??
Non viene usata ANCHE da quelle in PROTETTA?
In alternativa, forse posso fare un transport personalizzato e passare
tutto come parametri (-o)
direttamente nel transport ma preferirei una soluzione più pulita (e
le classi penso siano la soluzione più pulita, o sbaglio).

 Perň, lato postfix, non mi entra nella classe PROTETTA
Secondo me il problema non č quello, ma il fatto che quello che 
oltrepassa tutta la restriction, anzichč incocciare in un "accept" 
finale finisce per uscire dalla restriction_class e passare quindi alla 
successiva.
Taglio un po' tutto e ti dico come la farei io in maniera piů semplice:
in 
main.cf
:
smtpd_restriction_classes = PROTETTA, NONPROTETTA
PROTETTA =
  [vari filtri di tuo gusto]
  accept
NONPROTETTA =
  [vari filtri di tuo gusto]
  accept
smtpd_recipient_restrictions =
  [filtri comuni applicati per tutti]
  check_recipient_access mysql:/etc/postfix/mysql-PROTETTA.cf
  NONPROTETTA
  reject
In /etc/postfix/mysql-PROTETTA.cf:
query = SELECT 'PROTETTA' FROM recipient_restrictions WHERE recipient = 
'%s' AND attivo = '1' LIMIT 1
In 'sta maniera quel che č protetto entra nella prima restriction, quel 
che non lo č va da per forza nella seconda.
Nota che IMHO quel permit_mynetworks applicato dopo 
reject_unauth_destination nel tuo ruleset originale non ha alcun senso...

 reject_unauth_destination nel tuo ruleset originale non ha alcun senso...
Ora verifico meglio tutto il setup, sto facendo un po di esperimenti.
Intato grazie, poi se funziona, ti faccio sapere.

 reject_unauth_destination nel tuo ruleset originale non ha alcun senso...
Scusa, ma dove lo vedi?

 Scusa, ma dove lo vedi?
smtpd_recipient_restrictions =
    reject_unauth_destination
    check_recipient_access mysql:/etc/postfix/mysql-
recipient_restrictions.cf
smtpd_restriction_classes = PROTETTA, NONPROTETTA
PROTETTA =
    permit_mynetworks
    [...]
dato che in PROTETTA passano per permit_mynetworks, e che in PROTETTA ci 
finiscono dopo esser gią passati per reject_unauth_destination ...

 finiscono dopo esser già passati per reject_unauth_destination ...
Si si, l'avevo notato adesso.
Dunque, ho provato. Ovviamente il tuo metodo funziona.
A sto punto, dato che NONPROTETTA è semplicemente la classe di chi non
vuole antispam, faccio prima a fare qualcosa di analogo a quanto da te
suggerito:
smtpd_restriction_classes = PROTETTA
PROTETTA =
  [vari filtri di tuo gusto]
  accept <==== forse intendevi permit? accept mi da errore.
smtpd_recipient_restrictions =
  [filtri comuni applicati per tutti] <== in sostanza solo l'anti
relay
  check_recipient_access mysql:/etc/postfix/mysql-PROTETTA.cf
  permit
Quindi, di default la mail entra in "smtpd_recipient_restrictions" e
vengono applicati
i controlli antirelay, poi viene interrogato il db per verificare se
la mail è PROTETTA oppure no, in caso fosse protetta viene eseguita la
classe "PROTETTA" altrimenti la mail viene accettata. L'unico motivo
per cui non accettare la mail, come detto prima, sono i controlli
antirelay che la bloccano ad inizio classe.
Pensi sia corretto?
Tutte le volte che mi son messo a lavorare con 'ste classi ne sono
uscito matto.

 Pensi sia corretto?
Direi che fila, se è quel che vuoi ottenere.
Anche se fatta così, faccio notare che ottenevi lo stesso risultato 
senza restriction_classes facendo il ruleset così:
smtpd_recipient_restrictions =
  [filtri comuni applicati per tutti]
  check_recipient_access mysql:/etc/postfix/mysql-NONPROTETTI.cf
  [VARI RULESET]
  permit
in mysql:/etc/postfix/mysql-NONPROTETTI.cf:
query = SELECT 'OK' FROM recipient_restrictions WHERE recipient = '%s' 
AND protetta = '0' AND attivo = '1' LIMIT 1
In questo modo avevi che chi ha il flag "protetta" pari a 0 salta tutta 
la parte del ruleset, dato che la mail viene accettata subito.
Il vantaggio delle restriction_classes è proprio nel momento in cui vuoi 
mantenere profili con ruleset diversi...

 mantenere profili con ruleset diversi...
E' vero ma almeno sono già predisposto ad usi futuri.
Alla fin fine credo che farò qualcosa di sto tipo:
smtpd_restriction_classes = PROTETTA, NONPROTETTA
PROTETTA =
  [vari filtri di tuo gusto]
  permit
NONPROTETTA =
  [vari filtri di tuo gusto]
  permit
smtpd_recipient_restrictions =
  [filtri comuni applicati per tutti]
  check_recipient_access mysql:/etc/postfix/mysql-PROTETTA.cf
  permit
così facendo chi è in PROTETTA mi esegue solo PROTETTA (oltre ai
comuni) e non NONPROTETTA,
invece chi è in NONPROTETTA mi esegue solo NONPROTETTA e no PROTETTA.
Prima, invece, NONPROTETTA veniva eseguita da tutti. Meglio mettere le
mani avanti, potrei aver bisogno di far eseguire qualche cosa solo a
chi è in NONPROTETTA, così facendo non devo cambiare nulla. Mentre
invece per far eseguire qualcosa in comune, tanto vale metterlo prima
del check_recipient_access anzichè 'perdere' una classe facendola
eseguire sempre.
Adesso come adesso, potrei fare senza restriction classes come da te
indicato ma:
1) per i motivi di cui sopra preferisco avere il setup già pronto per
usi futuri;
2) non ho un flag 'protetto' nel database e non ho nemmeno un elenco
di indirizzi su cui metterlo, o meglio, dovrei cambiare varie tabelle.
Ho solamente una tabella dove chi è presente è per forza in PROTETTA e
quindi per fare come dici te dovrei ribaltare la query o cambiare il
db (aka: meglio stare buonini)