Newsgroup: it.comp.os.linux.sys
Titolo: [Domanda niubba] Postfix pre-queue e milter

Ma tra un check in pre-queue e un milter esterno, a parita' di controlli 
eseguiti, cosa e' preferibile ?
Sto cercando di chiarirmi le idee ma piu' leggo e meno riesco a capire perche' 
dovrei preferire l'uno all'altro !
Sul sito di postfix leggo che i milter sono in pre-queue percio' andiamo bene 
dico, evitiamo backscatter inutili, pero' poi vado a vedere e mi sembra che gli 
stessi controlli possano essere fatti anche in pre-queue (lavorando sul 
master.cf
), percio' perche' dovrei preferire l'uno all'altro ?
Da quanto capisco (per la mia situazione per lo meno - situazione semplice 
semplice, 3 domini gestiti in locale con 2 mx e tutto piu' semplice possibile) 
l'uno vale l'altro; se filtro tutto in pre-queue faccio gestire la cosa a 
postfix e se lavoro con un milter vado semplicemente a lavorare con un 
applicativo esterno  che puo' essere messo su un'altra macchina, puo' avere n 
fork (se li gestisce), puo' essere gestito come processo a se' stante ma alla 
fine gestisco tutto il traffico in per-queue comunque, sbaglio ? Se si dove ?
(lo so che sto banalizzando rispetto a chi lavora da un isp o ha n centinaia di 
domini da gestire pero' volevo capire nella piccola realta' cosa cambia)
Grazie
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere... ma la veritï¿œ ï¿œ 
che non avere nulla da perdere significa essere pronti a rischiare tutto ciï¿œ che 
si possiede.

 cosa cambia)
Postfix ha una pletora assai completa di check da poter eseguire sui
dati di *envelope* (che sono pre-queue per natura).
Per quanto riguarda i check sul body e gli header, fornisce solo ed
esclusivamente body/header_checks
Che hanno la stessa efficienza e modulabilitï¿œ di una manï¿œra...
Se vuoi operare controlli fini sul contenuto (banalmente: il check AV),
e lo vuoi fare in pre-queue, devi affidarti a SW di terze parti, sia
questo implementato come proxy SMTP oppure come milter...
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 questo implementato come proxy SMTP oppure come milter...
No, non dirlo, fammi passare un buon Natale..... :-)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 questo implementato come proxy SMTP oppure come milter...
Percio' tra le righe mi stai dicendo che un controllo in pre-queue puo' essere 
fatto solo attraverso un milter o un proxy smtp ?
Ma un'istanza di smtpd in ascolto su una porta X a cui viene rigirata una mail 
attraverso il comando "contents_filtering" viene considerato gia' un proxy smtp 
? Cosi' ne approfitto anche di farmi chiarezza sui termini ed evitare di 
scrivere altri refusi.


 termini ed evitare di scrivere altri refusi.
No, perchï¿œ i content filters agiscono *dopo* l'incodamento, non prima.


 gia' un proxy smtp
smtpd_proxy_filter agisce pre queue, content_filter post.
Ma i milter sono decisamente più efficienti del proxying.

 Ma i milter sono decisamente più efficienti del proxying.
Piu' efficenti per quanto riguarda il carico macchina o piu' efficenti per 
quanto riguarda il lavoro svolto (maggiori compiti, maggiori servizi svolti, etc.) ?
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere... ma la verità è 
che non avere nulla da perdere significa essere pronti a rischiare tutto ciò che 
si possiede.

 No, perchï¿œ i content filters agiscono *dopo* l'incodamento, non prima.
Hummm.... ergo non puoi avere dei proxy in after-queue..... va bene (e ci sta 
anche, mi vien da dire, parliamo di proxy), ma un milter ? E avrebbe senso a 
quel punto ?
La risposta che mi darei sarebbe: <"si, ha senso solo se il milter in questione 
non puo' eseguire il proprio mestiere in pre-queue, percio' senza ancora essere 
stato "ruotato" nella coda corretta">
Ho detto una stronxxta ?


 Ho detto una stronxxta ?
I milter non possono lavorare in post-queue per loro natura (ovvero per
l'implementazione propria dei milter: vengono da sendmail, dove il
concetto di post-queue sostanzialmente non esiste).
Senza che la tiriamo troppo lunga (scrivo nel mezzo di una riunione,
quindi non posso dilungarmi) la sostanza ï¿œ:
- lavorare in pre-queue ï¿œ piï¿œ oneroso e causa una minore resilienza dei
sistemi, dato che non hai meccanismi di queueing che permettano di
assorbire i picchi di carico; inoltre, la latenza delle operazioni
diviene critica in quanto aumenta la concorrenzialitï¿œ dei job e di
conseguenza il carico applicato al sistema ospite
- lavorare in post-queue ï¿œ meno oneroso e piï¿œ gestibile, ma dato che
l'analisi in questa fase avviene dopo che il contatto con l'entitï¿œ
mittente si ï¿œ chiuso, una volta che l'analisi si ï¿œ completata l'unica
cosa che puoi fare ï¿œ tenerti la mail o metterla in quarantena: rigettare
al mittente non ï¿œ piï¿œ possibile, o sarebbe backscatter.
Da qui deriva l'esistenza di entrambi i meccanismi. Stabilire quale dei
due sia piï¿œ opportuno dipende dal tipo di azione che ci si attende di
operare, alla luce delle considerazioni di qui sopra...


 operare, alla luce delle considerazioni di qui sopra...
Ok, grazie mille di nuovo per la lezione, direi che non potevo chiedere di piu', 
cerco di ragionarci un po' sopra poi scegliero'.
Ciao e buone feste.
