Newsgroup: it.comp.os.linux.sys
Titolo: Postfix reject_unverified_recipient

E' possibile fare in modo che il reject_unverified_recipient verifichi
non solo
la presenza della mailbox ma anche della sua 'disponibilità'?
Ad esempio: se la mailbox è overquota, posso fare reject direttamente
sugli hub?
Partendo dal presupposto che:
1) non ho modo/non voglio sincronizzare i dati delle mailbox anche sui
vari mail-hub
2) non ho modo/non voglio accedere ai server di posta di destinazione
perchè non sono miei.
In sostanza, io ho un hub che riceve posta per altri mailserver e fa
semplicemente (o quasi) relay.
Tali mailserver gestiscono in maniera autonoma le mailbox con le
proprie quote e le proprie politiche interne (no antispam che è
centralizzato sugli hub).
Se il gestore di tale mailserver cancella una mail, o la mail va in
overquota o tale mail viene messa in reject mediante varie
access_list, come posso saperlo io 'a monte' e rigettare le mail con
tale destinazione?
Io ho un solo hub che mi fa relay sul server corretto. L'unica cosa
che so dei destinatari sono i domini.
Dominio 
pippo.it
 fa relay su 111.222.333.444
dominio 
pluto.com
 fa relay su 222.333.444.555
Le mailbox vere e proprie non le vedo e non le voglio nemmeno vedere.
Si può fare in qualche modo?

 sugli hub?
Non dipende dal verify, ma solo da cosa gli viene risposto in fase di 
verifica dei destinatari.
Se nella fase di verifica il backend risponde "puppa", per il frontend è 
puppa. Nulla sa nè può sapere delle ragioni per cui la puppa è tale.
Però tieni conto che:
- il reject per mailbox over quota lo si fa solamente quando si sa la 
dimensione del messaggio da consegnare. Questa la sai solamente al 
termine della fase DATA (sì, in teoria anche in MAIL FROM in ESMTP, ma 
non è un dato credibile a priori, nè sempre disponibile)
- ne consegue che a verify verrà plausibilmente risposto "OK", anche se 
poi la mail da consegnare è di dimensione tale da portare a "puppa", 
dato che l'operazione di verifica per sua natura non arriva mai alla 
fase DATA

 non è un dato credibile a priori, nè sempre disponibile)
Ok. questo infatti lo sapevo, ma magari tiravi fuori dal cilindro una
super soluzione :) Ci ho provato...
Allora, io ho un MX/mailhub che deve ricevere la posta per X domini.
Tali X domini sono configurati su Y server di storage (dovecot) per le
caselle.
Il grosso dello spam lo filtro sugli hub.
Il problema, nei server gestiti da me, è solo la quota.
*sembrerebbe* che si possa usare LMTP per la consegna. Dal quel che ho
capito (poco a dire il vero), LMTP si può intendere come un metodo di
consegna 'via rete'.
Dato che dovecot controlla le quote in fase di delivery, forse usando
LMTP in fase di delivery dovrei riuscire ad interrogare il postfix/
dovecot sullo storage e rifiutare le mail a livello di MX.
Attualmente uso un semplice relay, per usare LMTP dovrei configurare
le caselle sugli MX (come se fossero locali) e dirgli di fare delivery
via LMTP verso un server interno.
In questo modo, forse, dovrei aver risolto il problema del delivery e
del controllo quota, nei server sotto il mio controllo, ma nel caso di
server di clienti, dove io non ho alcun accesso, come mi tutelo da
eventuali REJECT/BOUNCE fatti dal cliente? Facendo reject a valle
degli MX tutta la rumenta torna indietro a me ed io non la voglio.
Ricapitolando, correggimi se sbaglio:
per i miei server:
MX con sopra le caselle (solo questi dati: email, server_destinazione)
Storage LMTP/dovecot con le caselle configurate (username, password,
quota ecc)
L'MX fa il delivery via LMTP verso il server di destinazione che gli
dirà se la quota è stata superata o meno. In caso positivo, rifiuta la
mail, altrimenti la consegna. Ma riesco a fare un reject 'lato mx'
così facendo? Altrimenti tutto sto gioco non serve a nulla.
Tu, come consegni le mail ai server pop/imap? (rispondi in privato se
preferisci)
Mi basta sapere la 'struttura' non i dettagli, perchè proprio non
capisco come far comunicare i frontend con i backend riuscendo a fare
reject sempre e solo sul frontend, e tutelandomi (nel caso di backend
gestiti da terzi) da porcate sui backend. Ci vorrebbe proprio un
protocollo di comunicazione 'interne', potrebbe essere LMTP?
Scusa per il 'casino', vado di fretta e sto scrivendo quello che mi
passa per la testa senza riordinare i pensieri....
Tnx.

 gestiti da terzi) da porcate sui backend.
Sostanzialmente: puoi fare tutto quel che vuoi, il reject per over-quota 
sui frontend non lo puoi mai portare tutto in fase SMTP, in quanto ci 
sono limitazioni del protocollo stesso ad impedirtelo.
Un po' di esempi:
- dato che la dimensione la sai solo in fase END OF DATA, che fai se la 
mail supera la quota di un utente ma è destinata a più di uno? La 
rigetti per tutti? La accetti per tutti in barba alla quota?
- simile, ma peggio ancora: se il destinatario è una lista di 
distribuzione di N utenti, tra i quali solamente M andrebbero 
over-quota? Qui anche operare prima della fase DATA non ti aiuta, dato 
che comunque il destinatario SMTP è uno solo...
Soluzioni complete non sono possibili.
Devi solo trovare una soluzione che rappresenti un compromesso tra la 
complessità di implementazione e la quantità di backscatter che andresti 
a generare, altro non puoi fare.

 a generare, altro non puoi fare.
Però, se io invio ad un utente yahoo (giusto per fare un esempio) over-
quota,
il messaggio mi viene rifiutato sugli MX...
Come è possibile allora? Hanno una cariola di MX e, sicuramente, una
cariola di backend...

 cariola di backend...
Con basi-utenti così piatte è più facile: basta esportare ai frontend lo 
spazio residuo nelle mailbox degli utenti.
Scrivere un policy daemon per postfix che verifichi che size(mail) <= 
size(mailbox) ci si mette 5 minuti (scriverlo scalabile è altra cosa, ma 
si esula).
Yahoo però non è un dominio-tipo: lì non c'è nulla che assomigli ad un 
alias "sales" ricevuto da 5 persone diverse, per dire.
Dopodichè: prova ad inviare (magari a mano con telnet, in modo da non 
specificare neanche il size in fase MAIL FROM) a *due* utenti yahoo, uno 
dei quali va over-quota e l'altro no.
Vedi che accade... ;-)

 Vedi che accade... ;-)
Mai provato, e non ho nemmeno mail over-quota con cui provare.
Che accade?
Quindi in sostanza, per la quota non ci sono altre soluzioni che non
fare un bounce
a valle degli MX ?
E per tutelarmi da un pirla che mi manda in reject sullo storage una
mailbox?
Comunque, il mio problema più grosso (per il momento) è sistemare sta
storia della quota.
Se mi dici che un bounce a valle (quindi quando la mail è già stata
splittata) non è
una eresia (nel caso lo fosse: workaround?) opterò per questa
soluzione SENZA LMTP e
continuando ad usare il relay di tutti i domini verso host arbitrari
nella mia rete.
Si accettano consigli nel caso qualcuno avesse già adottato una
soluzione simile.

 a valle degli MX ?
Aumentando la complessità, come detto prima, puoi fare in modo di 
rigettare l'accettazione di messaggi diretti ad una singola mailbox che 
andrebbe over-quota.
Bisogna vedere se il lavoro necessario ad ottenere questo risultato vale 
il numero di backscatter risparmiati.
Per realtà come Yahoo! sicuramente sì. Per te probabilmente no. Certo se 
lo vuoi fare comunque male non fa.
Il problema backscatter è da compromesso: non li puoi eliminare del 
tutto, perchè fanno parte del protocollo stesso. Puoi solo cercare di 
non generarne troppi.

 non generarne troppi.
Forse non ti ho seguito per bene.
Per backscatter risparmiati intendi quelli che non genereranno bounce
sui backend perchè
bloccati direttamente sugli MX causa quota superata totalmente?
Chi ha 10K liberi, ma riceve una mail da 50K, genererà sempre un
bounce sui backend.
Il policy potrebbe aiutarmi solo a limitare tale numero di bounce
filtrandone alcuni a monte.
E' così? Ho capito bene?
In tal caso: chissenefrega.
L'importante però è mandare in bounce gli overquota e non in reject,
giusto per far arrivare segnalazione al mittente.

 A ritrovarsi una fork-bomb sul mailserver basta poco...
EUREKA!
A che serve il policy daemon? In questo caso a nulla.
Avendo un check_recipient_access basta inserire
pi...@pluto.com
   REJECT: User overquota.
- Semplice
- Scalabile
- Performante
- Stabile (non è un damone che potrebbe morire)
(effettivamente, potevo pensarci anche prima)

 (effettivamente, potevo pensarci anche prima)
Sicuro, ma in questo caso andresti comunque ad accettare una mail che fa 
sforare quota, dato che ancora le quota non son sforate e la restriction 
non č applicata.
Se questo ti sta bene, sě, č una strada...

 Se questo ti sta bene, sì, è una strada...
No, non mi sta bene, ma con un policy daemon non risolveresti comunque
la cosa perchè:
a) il recipient lo devo rifiutare, singolarmente, quindi in fase RCPT TO
b) poichè sono in fase RCPT TO, non ho ancora la dimensione del messaggio
Per avere la dimensione del messaggio devo aspettare l'end of data ed in 
tal caso non potrei più fare il reject di un singolo recipient, dato che 
è già stato accetto. O blocco tutta la mail, o accetto tutti e faccio 
bounce dopo.
In tal caso, allora, meglio rifiutare a priori chi ha la casella piena, e
rifiutare *dopo* chi sfora.

 bounce dopo.
La prima: blocchi tutta la mail, ma solamente nel caso in cui abbia un 
solo destinatario. Nel caso di destinatari multipli, accetti e generi il 
bounce dopo (che è quel che si diceva sopra, poi).
Che peraltro, viene anche banale, da quel che riporta la documentazione:
«The "recipient" attribute is available only in the "RCPT TO" stage, and 
in the "DATA" and "END-OF-MESSAGE" stages when Postfix accepted only one 
recipient for the current message.»
(tratto da 
http://www.postfix.org/SMTPD_POLICY_README.html
)

 recipient for the current message.»
Quindi si tratterebbe di controllare semplicemente la presenza del RCPT TO
dal policy daemon, se presente, faccio le operazioni, altrimenti di 
default accetto.
Ciò non toglie che sarebbe interessante (sopratutto su server trafficati)
adottare entrambe le soluzioni: reject in fase di RCPT TO per chi ha già 
sforato, chi 'sopravvive' passa al policy daemon che in caso di RCPT TO 
multipli accetta tutto in silenzio, altrimenti fa il suo bel controllo e 
uccide chi non ha abbastanza quota.