Newsgroup: it.comp.os.linux.sys
Titolo: Postfix - message_size_limit

Ciao.
Alcuni clienti mi chiedono di poter ricevere messaggi con allegati 
superiori all'attuale message_size_limit.
E' possibile fare una sorta di distinzione magari utilizzando una 
colonna su mysql?
Qualchè patch che faccia al mio caso?
Non volevo 'aprire' il rubinetto a tutti e googolando un po non ho 
trovato una soluzione valida.
la configurazione attuale è: postfix+mysql+virtual+maildrop+amavis

 Qualchè patch che faccia al mio caso?
Non me ne sono mai interessato, ma il size limit supportato dal sistema
viene annunciato in risposta a EHLO:
$ telnet 
ussmsl102.unicredit.it
 25
Trying 193.193.172.158...
Connected to 
USSMSL102.unicredit.it
.
Escape character is '^]'.
220 
ussmsl102.unicredit.it
 ESMTP Symantec Mail Security
EHLO test
250-ussmsl102.unicredit.it
250-PIPELINING
250-SIZE 10485760
250-VRFY
250-ETRN
250 8BITMIME
Poichè quindi avviene *prima* di RCPT TO, non credo postfix lo possa
fare nativamente come configurazione globale o mappa (o, se lo fa, non
mi sovviene con cosa).
Puoi però impostare un limite molto alto (che quindi verrà annunciato in
fase di EHLO, e applicato *comunque* globalmente), e poi applicare
limiti inferiori per-recipient con un policy daemon fatto all'uopo.

 limiti inferiori per-recipient con un policy daemon fatto all'uopo.
Avevo pensato ad utilizzare amavis.
Al momento *tutti* gli utenti passano su amavis, poi in base alla policy 
  del singolo utente, vengono attivati i servizi di antivirus, antispam 
ed altro.
La mia conoscenza di perl è molto molto molto bassa quindi implemenatre 
un controllo sulla dimensione del messaggio (semplicissimo per chi 
conosce perl) per me diventa un calvario :(
Amavis (le ultime versioni) hanno già questo controllo, però, (lo dice 
amavis) non posso fare upgrade dalla mia versione a quella attuale 
perchè ci sono troppe differenze nel database e nel codice del 
programma. (2.2 -> 2.3 mi pare oppure 2.2 -> 3.X non ricordo)
Cambiare il DB per aggiornarlo a quello attuale non è minimamente 
pensabile. E' un server di produzione ed è meglio stare fermi (ho notato 
poi che i due DB cambiano 'sostanzialmente' e dovrei riscrivere 
pressapoco tutti i vari script creati da noi)

 mi sovviene con cosa).
scusa, ma cosa avviene *prima* di cosa ? :P
250 e' una info, non e' li' che viene deciso niente ne' tantomeno e' da
informazioni server-side che i limiti vengono imposti :P
e' una info, l'enforcement avviene altrove
http://snipurl.com/lpne
ciao,
--
oggei

 Avevo pensato ad utilizzare amavis.
Plausibile, ma agisce in post-queue.
Al di là delle problematiche che citi, agire sulla mail in fase di
accettazione è decisamente più "pulito" che accettarla e poi rimbalzarla
se troppo grossa...
Prendere un policy daemon in perl già fatto
(
http://www.postfix.org/addon.html#policy
) e smanacciarlo un po' per
fare quello che devi fare richiede comunque conoscenze di perl
abbastanza banali.
Prova nel caso a buttare una sarda anche sulla ML di postfix, probabile
qualcuno abbia già realizzato qualcosa.

 qualcuno abbia già realizzato qualcosa.
Per il momento ho solo sondato e non ho trovato nulla....
Più tardi vedo di andare anche a pesca.

 e' una info, l'enforcement avviene altrove
Sono con te, ma se annunci in quella fase una size più bassa della
dimensione del messaggio è possibile che il peer SMTP non tenti nemmeno
il delivery.
Dipende poi dall'implementazione dell'SMTP client, ovviamente, ma in
giro c'è di tutto e non mi stupirei di nulla...

 se troppo grossa...
Ripensandoci, facendo fare il controllo ad amavis,l'SMTP client non 
saprà mai se il messaggio è troppo grosso in quando viene accettato 
ugualmente.
L'unico modo per comunicarlo al mittente (altrimenti la gente non si 
vede recapitare la posta senza sapere il motivo) è con un bounce. Il che 
significa aumentare notevolmente il carico di lavoro del server (se per 
ogni mail over size ci deve essere un bounce......)

Skull ha scritto:

afair un client che tenga conto delle smtp service extensions
dovrebbe acconsentire, altrimenti a che servirebbero?

frick ha scritto:

forse non ho spiegato bene cio' che intendevo : nessun server si fida
(nessun server DEVE fidarsi) dell'ack del client, implicito o meno, alle
informazioni che gli ha passato.
qualsiasi 2xx, nel caso dei protocolli "a righe", e' informativo e
_basta_, altrimenti sarebbe sufficiente sbattersene lato client per
dossare tutto :PP
che poi il buon m*a dall'altra parte decida di rispettarlo e neanche
provare a spedire il messaggio e blabla ok, ma il check, sulle
dimensioni in questo caso, e' il medesimo che verrebbe fatto anche con
una sessione SMTP non E (helo). E meno male :)
ciao,
--
oggei

 una sessione SMTP non E (helo). E meno male :)
E dunque?
Il problema dell'OP è quello di *far passare* alcuni messaggi più grossi
del normale.
Mica il contrario...

 qualcuno abbia già realizzato qualcosa.
Facendo alcune valutazioni, mi conviene tenere in piedi un altro postfix 
(stessa macchina oppure su un altro server dedicato alle mail grosse) e 
spostare gli utenti da una parte all'altra (al momento sono pochi).
Postfix1: message limit = 10Mb
Postfix2: message limit = 50Mb
La soluzione sullo stesso server è la più semplice da implementare, così 
nessun cliente deve cambiare l'ip del pop3 e io devo solo cambiare il 
transport (tramite il DB di mysql).
O sto dimenticando qualche cosa?
Comunque sto notando che i vari servizi di jumbo mail (ad esempio 
libero) altro non sono che uno spazio web di 2GB e durante l'invio della 
mail viene inserito un link al file caricato in precedenza. In pratica 
la mail non è mai di 2GB. Quindi di cosa si lamentano i miei clienti?!?! 
pazzoidi....

 Mica il contrario...
Esatto. Ho scritto (qualche secondo fa) una risposta dicendo di aver 
trovato soluzione. E dicendo anche che i miei clienti forse non hanno 
ben chiaro il funzionamento dei vari jumbomail in giro (stile libero).
Si lamentano perchè vogliono inviare + di 30MB.[1]
[1] a me personalmente non mi è mai capitato di inviare mail così 
grosse. anche perchè ci vuole un quarto d'ora a messaggio (256KBit/Sec)
A voi capita spesso?

 pazzoidi....
ma tu spiegagli che non si può fare.
Io lascerei perdere e li educherei a NON farlo anche perchè ricorda:
- di solito ci sono due server SMTP nella transazione, ovvero il tuo e
quello che riceve.
Se tu lasci passare dal client un messaggio da 30 mega e lo spedisci su uno
dei miei server, secondo te lo accetto ? In altre parole, secondo te quanta
gente c'è che lo accetterebbe ? Suvvia.
Spiegagli che non è bene farlo.
Max

 Mica il contrario...
beh, ma il problema della tua prima risposta all'OP e', cito :
Non me ne sono mai interessato, ma il size limit supportato dal sistema
viene annunciato in risposta a EHLO:
[blah]
Poichè quindi avviene *prima* di RCPT TO, non credo postfix lo possa
fare nativamente come configurazione globale o mappa (o, se lo fa, non
mi sovviene con cosa).
fine della citazione.
Perche' magari poi ci si incasina non capendosi su ste cose
comunque ho pastato uno shorturl dal quale qualcosa si potrebbe
ricavare, imo.
ciao,
--
oggei

 fine della citazione.
Ammetto di essere poco chiaro (mi capita spesso :-D), ma il senso,
tradotto, voleva essere:
"Poichè message_size_limit viene annunciato in EHLO, se anche potessi
escludere un recipient dalla sua applicazione è probabile che il client
SMTP, vedendo quel limite in EHLO, non ci provi nemmeno, ergo dubito sia
definito un meccanismo per farlo".

 ricavare, imo.
...sicuramente c'ho ricavato il link che porta al pdf di una tesi
dai contenuti potenzialmente interessanti (anche se a prima vista
mi pare che alcuni dei risultati siano un po' strani e inattesi).
http://web.onda.com.br/nadal/Trabalho_Jeronimo_Zucco.pdf
E' in portoghese ma, forse, potrebbe anche valere un tentativo di
lettura.
Fabio

 definito un meccanismo per farlo".
ecco infatti era questo che ti "contestavo" :P
ciao,
--
oggei

 mi pare che alcuni dei risultati siano un po' strani e inattesi).
io parlo di 
http://snipurl.com/lpne
ciao,
--
oggei


Ma ni!!! :-D
" nessun server si fida (nessun server DEVE fidarsi) dell'ack del
client, implicito o meno, alle informazioni che gli ha passato."
Però io non ho mai detto che la pubblicazione del SIZE in risposta
all'EHLO sia tutto quello che postfix fa... :-P
E' solo che, venendo fatta *prima* che venga ricevuto RCPT_TO, non hai
modo di annunciare un SIZE diverso a seconda dell'RCPT... :-\
Ok. Ci stiamo definitivamente intorcolando...
Cmq, come interessantemente facevi notare, il reale SIZE del messaggio
si sa solo a transazione SMTP completa, alla chiusura della fase DATA.
Questo implica che, anche facendolo con un policy daemon, la puoi
applicare solo in smtpd_end_of_data_restrictions.
Il che a sua volta implica l'impossibilità di accettare una mail per un
recipient si e un altro no (ovviamente nel caso di recipient multipli),
dato che oramai è tardi.
Almeno, non senza fare cose più complicate...

 io parlo di 
http://snipurl.com/lpne
Quelle sono le pagine del vecchio mantainer. Ho seguito il link verso
le pagine del nuovo mantainer, dove ho trovato il pdf di cui sopra.
Per completezza, il progetto ora sembra sia ospitato su:
http://web.onda.com.br/nadal/
Fabio

 dato che oramai è tardi.
Be', non sempre. Si puo' usare il SIZE passsato con MAIL e verificare 
quello in fase RCPT a fonte di una coppia recipient:max_size e quindi
rigettare recipient per recipient. Funzia, ovviamente, soltanto con i
client SMTP che passano SIZE con MAIL.
Fabio


and adapted to snapshot 20001121 by Xavier Beaudouin. It was merged
with mainstream Postfix for snapshot 20010128 by Wietse.
...
ciao,
--
oggei

 with mainstream Postfix for snapshot 20010128 by Wietse.
Non capisco che attinenza abbia con il mio post. Ho solo detto di aver 
trovato quel pdf linkato nelle pagine del nuovo sito del progetto vda,
a cui sono arrivato leggiucchiando attorno al link che hai postato via
snipurl, e che punta al readme ospitato sul vecchio sito ("unmantained
now")[1].
Dove sta il problema? Cosa m'e' sfuggito? Ho detto qualcosa di errato?
Non dovevo leggere il resto del sito ma solo il readme? :-P
Fabio
[1] 
http://www.oav.net/vda/
.


Se vogliamo continuare a farlo solo in fase SMTP, ovviamente.
Fabio

 Max
Concordo pienamente.
Ma non è tanto un problema di invio messaggi giganti ma di ricezione.
L'invio avviene solo da utenti autenticati che si contano sulle dite 
delle mani.
Il problema è che vogliono ricevere messaggi grossi.
Spiegare che ci sono 2 smtp? la risposta sarà: smtp?!? si mangia?

 dato che oramai è tardi.
Credo che adotterò la soluzione di CtRiX: dire agli idioti che non si 
può fare perchè dipende anche da chi riceve non solo da chi manda (e 
viceversa)


Per chiarire: non e' che ho soltanto guardato i post senza leggerli :-P
Certo, anche il SIZE passato in MAIL viene dal client e potrebbe essere
errato o manipolato maliziosamente ma, IMHO, occorre valutare l'aspetto
"policy max_size" per quello che e'. Per come lo intendo io, anche quel
dato, benche' dichiarato dai client, e' adeguato a raggiungere lo scopo
nella stragrande maggioranza dei casi. E sempre per come lo intendo io,
la "stragrande maggioranza" e' gia' abbastanza, visto che non si tratta
di sicurezza ma soltanto di un migliore uso delle risorse e/o di limiti
contrattuali, ed una eventuale violazione di questo enforcement sarebbe
del tutto veniale e irrilevante nell'economia complessiva del servizio.
Fabio