El 2005-04-07 a las 12:22 +0200, AleOP escribió:
El jue, 07-04-2005 a las 11:47 +0200, Camaleón escribió:
No creo que ni Postfix ni Qpopper tengan control sobre el ancho de banda de sus procesos (aunque estaría muy bien :-P)
Hasta cierto punto. Cuando el ancho de banda es corto, postfix recomienda bajar el limite de procesos que atienden o crean conexiones smtp: /etc/postfix/main.cf: default_process_limit = 10 O bien, ajustar los limites de cada uno de los procesos que interesan. En la documentación hay un QSHAPE_README.html y un TUNING_README.html que aplican.
Evidentemente, estos dos servidores de correo no tienen nada que ver con lo que todos conocemos más o menos como "traffic shaper". No me refería a eso, tampoco. Sino, más bien, a que saturan con la forma que tienen de manejar las colas (¡a quién se le ocurre meter todo el correo de un usuario en un solo fichero!) cualquier servidor que se precie.
No es un problema de colas de correo, sino un problema de saturación del ancho de banda al enviar un único correo grande. Respecto a lo del "fichero unico", recuerda que eso sólo sucede en recepción, y sólo cuando le dices que lo haga así. El postfix archiva el correo como le digas que lo haga (local(8)) --> ./README_FILES/OVERVIEW: * The local(8) delivery agent understands UNIX-style mailboxes, qmail- compatible maildir files, Sendmail-style system-wide aliases(5) databases, and Sendmail-style per-user .forward files. Multiple local delivery agents can be run in parallel, but parallel delivery to the same user is usually limited. The local(8) delivery agent has hooks for alternative forms of local delivery: you can configure it to deliver to mailbox files in user home directories, you can configure it to delegate mailbox delivery to an external command such as procmail, or you can delegate delivery to a different Postfix delivery agent. Así que si quieres tipo maildir, pues lo pones. Y, si el manejo se lo dejas al procmail, que es lo tipico en SuSE, pues el procmail también puede hacerlo como maildir. En el caso de transmisión, que es el que nos ocupa, el postfix emplea siempre un fichero por cada correo.
, por lo que si quiere enviar 100 MB. en un correo, entiendo que el servidor SMTP no le pondrá pegas (no es su cometido) e intentará utilizar el mayor ancho de banda disponible.
Ya. Pero, insisto: un buen sistema operativo (como creo que es el que nos ocupa y que tú y yo adoramos por encima de todas las cosas, amén), sabe qué hacer en esos casos. Vuelvo a insistir: yo estoy constantemente utilizando el correo (tengo mi propio servidor, con chequeo anti-spam y antivirus), navegando, bajándome software con el navegador y, a la vez, enchufado a un p2p, y jamás he tenido el más mínimo problema. Linux es muy listo y reparte muy bien siempre las conexiones. Y si no lo hace, mira a ver en la etiqueta del software, no sea que ponga "M$"...
Eso no es del todo cierto. El susefirewall prevee un ajuste (FW_HTB_TUNE_DEV) para los casos en los que el envio (upload) colapsa la recepción - que es precisamente el problema que nos ocupa. # 27.) # Tuning your upstream a little bit via HTB (Hierarchical Token Bucket) # for more information about HTB see http://www.lartc.org # # If your download collapses while you have a parallel upload, # this parameter might be an option for you. It manages your # upload stream and reserves bandwidth for special packets like # TCP ACK packets or interactive SSH. # It's a list of devices and maximum bandwidth in kbit. # For example, the german TDSL account, provides 128kbit/s upstream # and 768kbit/s downstream. We can only tune the upstream. # Así, recomienda que si la velocidad de envio contratada esl 128 que se ponga algo como esto: FW_HTB_TUNE_DEV="ppp0,125" para que el encolado sea manejado por el linux y no por el modem DSL - si es eso lo que se usa; el dispositivo cambiará en cada caso.
Me decanto más por un programa / aplicación específica para controlar este tema.
No. Que revise su instalación o configuración del Postfix o que lo jubile, y opte por el cambio.
Al postfix no le pasa nada. Y recomendar un programa crítico como el qmail (aunque muy bueno) que no está en la distro no es tan buena opción - y menos cuando no es ese el problema. -- Saludos Carlos Robinson