Hola, Jose Antonio: Jose Antonio Cortijo Solera escribi� en linux.debian.user.spanish:
> Hola de nuevo a todos, > > sigo con mi cruzada personal en contra del windows NT 4 a reemplazar por > una woody. tras conseguir hacer funcionar SAMBA como PDC y configurar > SQUID como proxy, me encuentro en estos momentos con el problema de > permitir que los clientes con su outlook :( , puedan leer y mandar correo. > He estado investigando y encontre unos proxy de pop3 y smtp > http://www.quietsche-entchen.de/software/ > > pero no consigo hacerlos funcionar, el outlook me dice que no consigue > encontrar el nombre del servidor especificado. > No se si tambien debo poner un proxy DNS para que las peticiones de > resolucion de DNS de los clientes sean atendidas. Se que en SQUID, como la > conexion la realiza el server, es este el que resuelve el nombre y > conecta, pero en el tema del correo , es el cliente quien _busca_ al > server de correo. entonces, segun lo veo yo, se deberia habilitar tambien > un proxy DNS? alguno que funcione bien? > Yo te dir�a que para servicios de DNS estar�as mejor servido (y de manera m�s sencilla) implement�ndolos *en* tu proxy, en lugar de *con* tu proxy. Quiero decir: instala un servidor dns-cache en la m�quina y que los clientes de la red lo usen (si est�s utilizando servicios DHCP, esta configuraci�n puede realizarse autom�ticamente), en lugar del externo que est�n usando ahora. S�lo la m�quina proxy tendr� acceso a servicios de DNS del exterior, bien directamente, bien a trav�s (forwarding) de los DNS de tu ISP. Exactamente lo mismo es v�lido para los servicios SMTP: instala un servidor SMTP en el proxy y que los clientes se configuren para usarlo. En funci�n de las necesidades, ese servidor estar�a configurado para intentar enviar directamente el correo a destino, o utilizar�a como relay los que est�n usando ahora mismo los clientes. Para los servicios POP tambi�n podr�a servir la misma aproximaci�n, sobre todo si ahora mismo todos los clientes utilizan cuentas de correo en un solo dominio: el correo lo puede "bajar" fetchmail al servidor y desde all� lo recogen tus clientes. Si existen cuentas de m�s de un proveedor pero son fijas, el mismo principio es v�lido, solo que t� tendr�s m�s trabajo para bajar el correo de todos esos sitios. Finalmente, si cada usuario puede tener las cuentas POP externas que les de la gana y a�adir o borrar en cualquier momento, esta aproximaci�n no vale y necesitar�s un proxy de aplicaci�n para POP, pero entonces lo que quiz� tengas que replantearte es todo tu esquema de seguridad: �vale la pena montar la conexi�n mediante proxies, en lugar de NAT, cuando luego tus usuarios est�n enviando contrase�as POP en claro -probablemente las mismas en m�s de un caso que usan para los servicios internos- por Internet? -- SALUD, Jes�s *** [EMAIL PROTECTED] ***
