-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-11-14 a las 09:38 +0100, Emiliano Sutil escribió:
Bueno,
Resumiendo, yo pensaba que las conexiones smtp originadas entre un cliente de correo y un servidor de correo si que se podían autentificar independientemente de a donde iban. Es decir yo pensaba que es distinta una conexión cliente de correo - servidor de correo que una conexión servidor de correo - servidor de correo.
En mi problema de la otra vez, en la que yo no quería que me autentificaran era cuando era mi servidor de correo el que hablaba con su servidor de correo, pero que si usaba un cliente de correo si que me autentificara.
Y ahora quiero lo mismo, que me autentifique si uso directamente el servidor SMTP desde un cliente de correo y que no, si lo que uso es un servidor de correo. Pero claro si no hay distinción alguna entre los 2 tipos de conexión lo veo chungo. Yo en esa maquina tengo alojados un montón de dominios y cualquiera configurando una cuenta que no existe puede llenarla de spam, cosa que no me parece lógica, pero si es así como va pues que se le va a hacer....
Es así, no hay distinción. Ahora bien, puedes hacer lo que hace gmail, que tiene dos servidores distintos: uno es el smtp.gmail.com que sólo admite clientes autentificados vaya a donde vaya, y que no esta publicado como receptor de correo en el DNS, por lo que pueden hacer eso, y otros son los públicos, en los que se acepta el correo con destino interior sin autentificación (porque son públicos) y están listados con registro MX para el dominio gmail.com Pero el resultado es el mismo: gmail tiene abierto al exterior un servidor SMTP en el que cualquiera puede introducir correo si es con destino a gmail. Para los demás listeros, aclaro que hemos estado con el tema en privado, ya que la lista no funcionaba. Le he enviado a estos dos ;-) un correo usando thunderbird y definiendo como servidor de salida uno de los listados como públicos por gmail (gmail-smtp-in.l.google.com), sin usar autorización alguna. CQD :-) Es tu caso: tienes un servidor público en el que te pueden meter correo, porque para eso está. Puedes poner un servidor privado (en internet) para clientes, en el que se pida siempre autorización - pero dado que tienes uno público, los spammers te entrarán por ahí y no ganas nada con esa diferenciación. Los de gmail lo hacen por cuestiones administrativas o de gestión de tráfico: sus razones son de miles o millones de usuarios y de dólares, no son las tuyas. Pero no sufras porque no hay abierto ningún agujero extra a los spammers. Si yo fuera un spammer, no me molestaría en configurar una cuenta ficticia en el thunderbird, porque es muy pesado. Los spammers tienen herramientas propias que se encargan de ello, y actúan como un servidor SMTP especializado y algo limitado, probablemente sólo de salida. No configuran cuentas en el thunderbird o kmail o outlook, aunque el correo incluya cabeceras que parezcan indicar lo contrario: simplemente lo simulan para engañarte. Por tanto, lo pongas como lo pongas, las cuentas te las pueden llenar de spam porque son cuentas de correo que recibien correo, usen el camino que usen. Tienes que usar las medidas habituales: listas negras (con mucho cuidado, puedes perder correo legítimo: hasta a SuSE lo listan), SA, amavis, SPF, Domain key signature, etc. Mira, hay un truco que se usa que es que el servidor de correo en la primera conexión dice que no. A la segunda, pasado un tiempo breve, dice que si. Una cosa tan sencilla tira pa'tras a muchos spammers, porque el software que usan no reintenta, va a enviar miles de correos lo más rápido que puedan, supongo que antes de que les tiren la conexión (usan zombies, pe, y se pueden caer, digo yo. O conexiones wifi robadas). No se entretienen en volver a intentarlo, mientras que cualquier servidor de correo normal vuelve a intentar la conexión durante dias. http://en.wikipedia.org/wiki/Graylisting - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFWbNPtTMYHG2NR9URAlLRAJ4kBbakUmrDUhiRxqsWSnJGObRzoQCfQLoi EcUWO1I5pJAPRKBvlQpF6K4= =XneF -----END PGP SIGNATURE-----