Hola a todos, Tengo una aplicacion para mandar newsletter que manda mail con php, pero en la documentacion no dice q necesita para mandar.... y configure el php.ini pero no me funciona, y segun el ini sirve eso solo para windows y para linux dice sendmail -t -i
como o donde configuro para que pueda mandar mails el php? saludos, Arturo. -- http://animaldelared.blogspot.com From [EMAIL PROTECTED] Fri Sep 22 12:49:26 2006 From: [EMAIL PROTECTED] (Eduardo) Date: Fri Sep 22 13:04:24 2006 Subject: Servidor de Correos In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> El jue, 21-09-2006 a las 22:25 -0400, Horst H. von Brand escribió: > Juan Martínez <[EMAIL PROTECTED]> wrote: > > Horst H. von Brand escribió: > > > Juan MartÃnez <[EMAIL PROTECTED]> wrote: > > >> El Mie, 20 de Septiembre de 2006, 9:34 pm, Marcos Vargas escribió: > > > > > >>> Queria pedirles que me recomienden o en que me tengo que fijar al > > >>> momento de comprar un servidor (procesador,memoria, disco,etc) y > > >>> que servicio (qmail, sendmail, squirrimail), seria el mas adecuado y > > >>> mejor segun uds. para alrededor de 500 cuentas de correo > > >>> institucionales. > > > > > >> Haber...depende todo depende. Algunas pistas... > > >> > > >> - Cuanto tienes de tope por cuenta? (cuotas) > > >> De ahi sale la capacidad del disco para el /home > > >> Para el resto del sistema 10GB es mas que suficiente. > > > Ojo, hay que considerar el espacio para correo (si, aca tenemos > > > perejiles > > > con 1GiB de correo sin borrar...) > > > Por eso sugeria cuotas. Aca en la UMC, para los alumnos, tenemos 250MB > > como cuota blanda y 255MB para dura. > > Y decia "usuarios institucionales"... Aca, si me dejaran, a los perejiles > con mas de 100KiB de mbox les amputaria los deditos, a la altura del codo, > sin anestesia, y una cucharita de te. En publico, para que el resto > escarmiente. Pero son "institucionales"... jajaja HvB parece que tienes un trauma con ese método de tortura :P (te lo he leído en más de una ocacion). Con respecto a lo del 100kiB, no creo que tu mbox sea de 100kiB, y como decia un gran fisico «Dar el ejemplo no es la principal manera de influir sobre los demás; es la única manera.» > [...] > > > >> Tambien, no es malo preguntarse si es necesario respaldar ese servidor. > > > > Como que "preguntarse", /hay/ que hacerlo. COnsiderar grabador de DVD > > > doble capa, y un disco adicional en el cual armar las imagenes (y > > > guardar respaldos tambien). > > > Es que esto depende de las politicas de cada empresa. > > Nope. /Tiene/ que haber suficiente respaldo para poder reponer el servicio > si el cacharro fallece de un sincope multiple. El sistema de correo > electronico es /extremadamente/ critico. Si falla tu servidor web, o DNS, > o... te enteras a la semana; si falla el correo electronico en un par de ms > tienes la oficina llena de usuarios iracundos. Acaso no has visto las > discusiones aca de que "greylisting retrasa el correo!!!"? > > > Dado que no hay legislacion actual sobre la privacidad de la > > correspondencia electronica, puede ser todo un problema hacer > > respaldos. No olvidemos que la jueza Chevesic se valio de un vacio > > legal para incautar los respaldos de los emails del MOP. > > Bueno, si los respaldos duran lo que los originales por leer... > > [...] > > > >> jejeje....la que conozcas mas....Trata de no usar Fedora u otra que tenga > > >> software demasiado actualizado... > > > > No. Usa alguna de vida mas bien larga (Fedora anda de pelos, pero hay > > > que actualizar al menos una vez al an~o). RPMistica, CentOS (clon de > > > RHEL, si no quieres pagar por el soporte); debianita, algun Ubuntu de > > > los designados "para servidor" (tienen una sigla especial) > > > _server_ para ser precisos ;-) > > No, algo de "larga vida". > > > >, no Debian oficial porque el "estable" es prehistorico, > > > Ni tanto ... Pero haciendo mezclas en apt, se puede tener un buen > > compilado a la carta... > > Eso es completamente insano. Estas tomando paquetes de algo que esta > probado para funcionar en conjunto (estable) y le mezclas paquetes en > prueba (ramas no estables). El resultado en principio es /menos/ estable > que la version de prueba pura (que al menos son paquetes que se prueban > juntos). > > > > y el "actual" es 100% experimental > > > > 100% no. Hay paquetes que si pueden tener mucho de experimental. > > O sea, tiene partes experimentales. Cuales son, hoy? Cuales seran man~ana? > Lo sabes en detalle siempre? Tienes como /siempre/ evitar las piezas > experimentales en forma confiable? > [O sea, es experimental para efectos practicos.] > > > Pero Etch (es decir, Debian 4.0) sale estable en diciembre de este > > año. > > Ver para creer. Hay una pelea inmensa entre los debianitas actualmente > porque el cabecilla se involucro en un esquema para financiar a > desarrolladores selectos para acelerar el proceso, y (ojala) cumplir la > fecha prometida. > > > Los paquetes mas _populares_ tienen bastante poca actualizacion > > (normalmente hago upgrade del sistema casi diariamente) > > Y? Que el paquete sea popular no significa que no tenga ranas. O el que sea > actualizado frecuentemente no significa que no resulte critico para tu > funcionalidad deseada. > > > Personalmente, aqui no hay habido ni un solo drama con Etch. > > Bien por ti! Pero la pregunta no es si has tenido problemas, es si pones tu > carrera en juego por no tener problemas fatales en un plazo razonable, bajo > una carga de trabajo /bien/ diferente que la que significa un tarro de uso > personal... y en tal caso, prefiero no ser el unico que esta poniendo su > pellejo en /esa/ linea. > > > Pero, para cerrar este punto... Si el amigo que consulta conoce mas > > los derivados o el propio RH, entonces CentOS es su opcion. Si conoce > > la linea de debian...el mismo debian etch, pero le sugiero muy > > concientemente Ubuntu dapper server.... > > Exacto. RHEL (o SLES, o Ubuntu "server") tienen un grupo de ingenieros > responsable de su funcionamiento como servidor detras.
