Newsgroup: it.comp.os.linux.sys
Titolo: QoS+postfix+delay & utenti finti

Ciao a tutti.
E' possibile (senza implementare script che controllano periodicamente
la coda di postfix) limitare le mail in uscita provenienti da un dato
host che fa relay sul server di posta?
mi spiego:
server A: invio newsletter a 10000 clienti. Ogni mail fa relay sul
server di posta il quale la invia a destinazione. (sono sotto firewall
e l'smtp in uscita è possibile solo dal server di posta)
server di posta: si vede arrivare 10000 mail e inizia a recapitarle ai
destinatari.Data la mole di lavoro, tutte le altre mail saranno
consegnate con ritardi di 30 minuti.
Si può dire a postfix che le mail provenienti da server A devono
essere recapitate solo quando non ce niente da fare? in pratica
metterle in attesa e mandarle via pian piano.
Come ultima cosa, nella configurazione attuale
(postfix+maildrop+virtual+mysql.....) non sono riuscito a capire come
fare un account di posta fittizio. Ovvero tutto quello che arriva li
deve essere eliminato. Al momento ho tamponato con un colpetto di cron
che svuota la casella. Ma sarebbe meglio fare una eliminazione diretta.
Mi server per le mail di ritorno in caso di indirizzi non esistenti.

 Mi server per le mail di ritorno in caso di indirizzi non esistenti.
in /etc/postfix/
main.cf
:
check_recipient_access hash:$config_directory/blah,
in /etc/postfix/blah:
none...@mydomain.tld	DISCARD
In ogni caso è una porcheria. Gli indirizzi che non esistono *vanno
purgati* dalla lista di invio, quindi quei bounce servono, e vanno
gettati solo dopo usati.

 gettati solo dopo usati.
E lo so. ma le newsletter non sono nostre.
Ed il nostro cliente non si accorge che le mail non esistono per una 
fortuita combinazione di 'sfighe':
- php in safemode (return-path non cambiabile)
- postfix che si autoappropria del return-path mettendo se stesso
- decine di script fatti da un EX (grazie al cielo) collega quindi 
impossibile da sostituire con una funzione di invio mail personalizzata 
con return-path (sfido io a cambiare decine e decine di newsletter 
realizzate senza criterio e senza una parte di codice in comune)
- tempo per risistemare il tutto pressoche in esistente.
di conseguenza tornano indietro tutte a me.
Ed io da bravo le butto via tramite qualcosa tipo
'for in *; do rm $i; done' ogni minuto.

 'for in *; do rm $i; done' ogni minuto.
Invece di arrivare a te, arrivano a chi le manda.
E pur di non vedersi la mail box piena di fuffa, vedrai che ripulisce le
anagrafiche.
Max

 anagrafiche.
Arrivano a me proprio perchè non riesco a cambiare il return path in 
maniera indolore.

 2- il -f postfix lo ignora e mette il proprio return-path (già testato)
[MEGACUT]
non mi risulta nulla di cio che tu dici.
Evidentemente usano un socket sulla 25 per mandare piuttosto che sendmail.
In questo casi si agisce sul codice e non su apache.
Max

 In questo casi si agisce sul codice e non su apache.
Infatti, con php in safe mode per impostare il 5 parametro (il -f di 
sendmail) l'unica è rifarsi una funzione mail aprendo un socket sulla 25.
Altrimenti:
1- php non accetta il return-path
2- postfix cambia returnpath se se lo trova tra gli header
E per aprire un socket significa metter mano a tutti gli script. (Lavoro 
improponibile adesso, magari piu avanti)

 
Ho guardato proprio ora.
Davvero comodo.
Mette tutti i messaggi in hold cosi posso fare un crontab che ogni 30 
minuti ne manda via 50/100 di botto di giorno e 1000 di notte