"Carlos Jara Sazo" <[EMAIL PROTECTED]> dijo: > Alguien a implementado el tema SPF en sus servidores de nombre con el fin de > agregar otro nivel de proteccion contra el SPAM, necesito alguna experiencia > sobre este tema... De antemano gracias
Mi impresion al respecto: Al igual que todos los esquemas basados en que "todos cooperan", en particular si el cooperar no tiene ningun efecto concreto para quien coopera (es indicarle a los /demas/ que no envias spam (porque habria de creerte?!), no evitar que te llegue), no sirve para nada en la practica. Un sistema que /si/ funciona es greylisting <http://projects.puremagic.com/greylisting/>, una buena implementacion para sendmail esta en <http://hcpnet.free.fr/milter-greylist>. El efecto aca fue magico: De varios cientos (!) de mensajes basura diarios bajo a menos de media docena en mi caso personal. El sistema es muy sencillo: Si llega una conexion de una IP desconocida, se niega con un error temporal y se registra. Si hay reintento de entregar el mismo mensaje despues de un plazo configurable (30 minutos), se considera un servidor valido, y se pone la IP en lista blanca por un tiempo (por omision 3 dias). Los spammers disparan y olvidan (porque muchas de las direcciones que tienen ya no son validas, etc; y guardar para reintentar cuesta recursos), con lo que (por ahora) el sistema es extremadamente efectivo contra spambots (Que es exactamente lo que SPF trata de resolver via decir c/u que maquinas son MTAs legitimos... y funcionara cuando /todos/ lo hagan. No mantener la respìracion mientras esperas... Fallara igual que SPF cuando los spambots comiencen a buscar MTAs legitimos que les distribuyan su bazofia (cosa que ya hacen, BTW)). La desventaja es que los "primeros mensajes" se retrasan, pero como el conjunto de corresponsales suele ser bastante estable en el tiempo, no hay problema. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From [EMAIL PROTECTED] Tue Mar 8 12:00:31 2005 From: [EMAIL PROTECTED] (Horst von Brand) Date: Tue Mar 8 12:00:34 2005 Subject: inhabilitacion de cuentas In-Reply-To: Your message of "Tue, 08 Mar 2005 13:34:13 BST." <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Jhamil Mercado <[EMAIL PROTECTED]> dijo: > Como podria hacer que una cuenta de correo (cuenta de > sistema)se inhabilite en caso de no ser accedida > durante 30 dias por decir (un tiempo determinado), shadow(5) tiene campos de expiracion de password, etc. > ahora si se pudiese hacer que esa cuenta ya no reciba > mas mensajes una vez inhabilitada seria mejor, de tal > forma que esa cuenta no se llene de mensjes si es que > no la utilizan. Nada que yo sepa. En todo caso, tener cuentas viejas en desuso es un grave risgo de seguridad: Se te puede meter un jaquel a una de esas, y nunca te enteras. Mejor eliminarlas cuanto antes, y no recurrir a estas jugarretas. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From [EMAIL PROTECTED] Tue Mar 8 12:23:20 2005 From: [EMAIL PROTECTED] (=?iso-8859-1?Q?Juan_Mart=EDnez?=) Date: Tue Mar 8 12:19:58 2005 Subject: OT: Tarjeta de red In-Reply-To: <[EMAIL PROTECTED]> References: Your message of "Tue, 08 Mar 2005 00:10:33 -0300." <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> > Juan_Martinez <[EMAIL PROTECTED]> dijo: [...] >> > Qué variables tecnicas son comparables? Buffers? velocidad interna? > La cantidad de memoria para buffers, si separa en buffers de entrada y > salida o puede usar la misma memoria para ambos, la cantidad de MACs > que se pueden configurar en sus filtros (para poder interceptar varias > MAC sin tener que recurrir a modo promiscuo y que la discriminacion la > haga software; es importante para multicasting), si maneja o no > checksum IP en hardware. > > Si, esas caracteristicas diferencian tarjetas. Si, las pagas. > > Otro punto importante es la calidad de los drivers. Apoya la empresa > fabricante el desarrollo (hay alguien de alla involucrado (como tarea > en la empresa, en sus ratos "libres"; tienen acceso a la documentacion > los desarrolladores; hay drivers en fuente o solo binarios; ...))? Si > la tarjeta es (razonablemente) popular es mas probable que hayan mas > desarrolladores/probadores. Si es alguna clase de clon es probable que > este mal implemententado y se maree (ver los horrores de la tonelada de > clones de NE2000, codigo que nadie se atreve a tocar porque es seguro > que cualquier cambio minimo haga que alguno deje de funcionar). Es una > de las razones para abstenerse de dLink, son clones malones de otras > cosas (decentes!). > > Tambien es importante la disponibilidad local para > extensiones/reemplazos eventuales. > Excelente. Definitivamente el hardware no es de mis principales fuentes de conocimiento. Mi respuesta era más de un admin. de red flojo que no lee mucho sobre hardware. [...] >> > Alguna tarjeta que sea de reconocida calidad? > >> 3com para mi gusto es de lo mejorcito, junto con intel (Hay NIC >> Cisco?). Se de algunas tarjetas de marcas desconocidas pero de muy >> buena calidad. Por lo general son tarjetas para entornos criticos y >> son naturalmente muy caras. Por lo general la marca de estas tarjetas >> son la misma de los switch de 96 bocas o mas, o de equipos ATM o Frame >> Relay...En este minuto no me acuerdo de ninguna marca en especial... > > Hay tarjetas de la misma marca que son vastamente diferentes en calidad > y rendimiento. Las dLink normales son malas, las dLink 4x son > excelentes. dLink wireless es un asco. Y comparar ATM, FR, Eth, y > switches como que no tiene gran sentido... Mi idea no era compararlos, sino que intentar dar una guia con respecto a que la marca de estos equipos a veces tambien produce NIC y podrían ser una buena alternativa. Saludos Juan M.
