martes, 31 de enero de 2012

Wine History

Wine's roots can be traced back to 1993. At the time several forces were converging that made running Windows applications appealing. Microsoft had successfully steered its Windows program to the forefront of personal computers. IBM had hopes that OS/2 would catch on, but even they admitted that support of Windows programs was necessary and built the ability into their product. The free software movement spawned in the eighties was rapidly gaining ground as people discovered it was possible to run a multiuser, multitasking operating system on a PC. 

Sun's acquisition of Praxsys Technologies in September of 1992 led to the development of a product called Wabi. Sun first demonstrated the software at the 1993 Solaris Developers Conference. It allowed users of Solaris x86 and Solaris 2.2 for SPARC to run Windows applications out of the box. Other products at the time allowed Windows programs to be run, but they required machine-level emulation and the installation of DOS and Windows. Wabi was unique in that it allowed Windows windowing calls to be translated directly to X Windows calls. By emulating the rest of the x86 code it was possible to actually run Windows programs faster on a RISC workstation! Wabi's more advanced features included Bitstream's font handling technology to handle TrueType fonts. 

Users of the upstart Linux operating system began discussing the possibility of a similar approach in June of 1993. At the time, the chances of Wabi being ported to Linux were slim to none. A mailing list was set up to facilitate discussion. The name "Wine" was quickly adopted. Several of the early developers included some of the first Linux kernel hackers including Eric Youngdale and David Metcalfe. Other recognizable names included Alexandre Julliard who now leads Wine and Miguel de Icaza of GNOME fame. Bob Amstadt headed the development. 

Initial work consisted of getting a program loader working that could run Windows' 16-bit binaries. That work was primarily headed by Bob. Alexandre's involvement centered around merging windowing functions written by Peter MacDonald in Tcl/Tk. Progress moved along quickly, and within the first 6 months it was possible to run Solitaire. November of 1993 also saw the first port of Wine to another architecture - John Brezak submitted patches to allow Wine to run on NetBSD. Bob estimated that with the current rate of development the team was six months to a year away from release. Ironically, Wine continued to be six months to a year from release for the next decade. 

Early communication between developers took many forms, including the linux-kernel mailing list. The very first Wine mailing list was operated by Robert to allow discussions between developers. After a year with many successes and growing interest in the project they asked for the creation of the newsgroup comp.emulators.ms-windows.wine. The vote was overwhelmingly in favor of its creation and it became part of the Usenet hierarchy on July 19th, 1994. The current mailing lists where most development is discussed were created by Doug Ridgway in October, 1998. 

The early years saw many changes to Wine's development. Robert stepped down in 1994 and Alexandre took over development. Windowing was rewritten as straight Xlib calls. Perhaps most importantly, Microsoft began releasing 32-bit code and adding new functionality to their operating systems. It was no longer enough to just load code and run it, a tighter integration was needed with the underlying operating systems (primarily Linux.) Mechanisms needed to be added that supported network connections and registry files. Wine's architecture had relied on a shared address space between applications. Gradually it became clear that address space separation was needed to increase security and support shared libraries trying to access the same space. Work commenced in early 2000 and continues to this day. 

Alexandre recalled some of the early milestones for Wine in a keynote he gave at the first Wineconf:
  • May 1995: beginnings of Win32 support
  • July 1995: switch to autoconf
  • January 1996: Word and Excel reported to run
  • November 1997: Creation of winehq.com web site
Volunteers began contributing to aspects other than programming. John Sheets and Susan Farley worked on some of the original documentation. Doug Ridgway set up the WineHQ web site in 1997. The site was taken over by Corel for a few years, and then CodeWeavers took it over from them in March, 2002. Jeremy Newman now serves as the webmaster. The Wine Weekly News first appeared on the web site in 1999. Originally authored by Eric Pouech, Brian Vincent took over in 2001. Over the past few years several features have been added to the web site. A redesign in early 2003 added several pages to help new users get acquainted with Wine, project lists for developers to think about, and a large list of Frequently Asked Questions

In 1998 a strategic decision was made by Corel to wholeheartedly support Linux. The key elements were centered around providing a Linux-based system that was both simple to install and easy to use. To this end, they sought to provide both a Linux based distribution and support for their applications. Corel's suite of office programs demanded a high level of Wine sophistication. For the first time in Wine history commercial development was funding its development. Internally, Corel had two different teams working on Linux. One group concentrated on server development, the other on application support. Corel maintained a great relationship with Wine, partly due to the involvement of another company doing a lot of the work - CodeWeavers.

The bubble soon burst. Rumors began circulating at the end of 2000 that Corel would discontinue its support for Linux. By early 2001 Corel officially announced it would spin off its Linux division, specifically the group working on the distribution. Their support for work on Wine ended. The intellectual property and some of the developers eventually formed a new Linux company - Xandros. 

It wasn't long before others joined in to fill the void. By this time Alexandre had already taken a position with CodeWeavers doing much of the low level work on Wine. CodeWeavers had gotten involved with Wine in 1999 and were contracted by Corel to improve parts of Wine that would benefit Corel's applications. CodeWeavers began developing their own products and putting a lot of polish on Wine. Their own version of Wine included graphical management tools and an easy setup. Several distributions made it available for download. Their first product, CrossOver Plugin, allowed Linux users to run Netscape plugins designed for Windows. Newer versions of the product have added support for even more plugins. They released CrossOver Office in March, 2002 to provide support for office applications like Excel and Lotus Notes.
TransGaming formed in August of 2001. Gavriel State, who had been with Corel, left and formed his own company. Newer PC games had been focusing on Microsoft's DirectX interfaces for everything from input devices to 3D acceleration. By tying it to their operating systems it made porting games to different platforms very difficult. DirectX support in Wine was first added by Marcus Meissner in 1997 and was very limited. Gav sought to commercialize the development of it and create a new version of Wine designed for gamers. More technologies than just DirectX were needed and some of the early work focused on including support for copy protection measures. WineX 1.0 was released in October of 2001 with support for six games.
Also in 2001 another company announced intentions to work with Wine. Lindows.com wanted to create a Linux distribution that was simple to use and let users run Windows programs. It wasn't long before they abandoned the idea in favor of native Linux applications. Before that happened they sponsored Wineconf - a three day event in March, 2002 that brought together developers from around the world. To make matters more interesting, on the eve of the conference the Wine community had concluded another licensing flamewar discussion.

Wine's storied history of licensing has sparked many debates. The issue of licensing surrounds itself with two primary areas - the license of the Wine code itself and the license of applications produced using Winelib. The Wine developers' goal is to give people the ability to both implement and add to the Wine project in such a way it doesn't hinder others from doing the same. At the same time they want to give other developers the chance to port their application without the fear of being bound to a software license that prevents them from doing what they want with their creation.

In the beginning, Wine adopted a BSD-style license. At the end of 1999 discussion began about changing the license. Richard Stallman had pointed out that it was incompatible with the GPL which potentially causes problems with any open source project wishing to use Wine code. Most developers didn't see a need to craft a new license and the X11 license, a derivative of the BSD license, had the most support. A vote was called for and in January of 2000 Alexandre announced that it would become the new license of Wine.
In March of 2002 a poll was conducted among both the free and commercial developers of Wine to see if there was interest in moving to a different license. Most developers did not want their code to be appropriated by a commercial entity and there were concerns that might happen. After much debate they chose the Lesser General Public License and on March 9th, 2002 the Wine source code became bound to those terms. The LGPL, often referred to as a "copyleft" license, required the Wine developers to abide by some guidelines:
  • Source code (including all changes from the original Wine sources) must be made available to people who receive a binary of Wine. This also applies if Wine is used as a library, in which case only the source of Wine (including all changes) must be made available.
  • Simply linking with Wine does not mean you need to make the source code available for your program.
The immediate effect was the creation of the ReWind project to further the X11-licensed codebase. Many key developers agreed to allow their additions to be used by both the X11 and LGPL Wine code. Most have decided to focus their efforts on synchronizing with the LGPL'ed Wine and the vast majority of development and new features appear there first. Picking a favorite software license is left as an exercise for the reader.

Shortly after changing the license development began to pick up at a greater pace. More patches began to appear, Alexandre made more CVS commits, and more applications were reported to work. By the end of 2003 DLL separation achieved a milestone with the split of the kernel32/ntdll combination. Most of the architectural changes to support a beta release were in place. Another developer's conference was held in January, 2004 in St. Paul Minnesota sponsored by CodeWeavers. Once again, a roadmap was laid out for tasks that needed to be completed.

Wine 0.9.0 was declared "beta quality" in 2005 (more things working than not) and Wine 1.0 was finally released in mid-2008. 

Development continues apace, with new development releases every two weeks. Wine has grown to over 1.4 million lines of C code over the past decade. Nearly 700 people have contributed in some fashion. As always, you can expect Wine to be released sometime this year; or maybe early next year. Or perhaps we'll just wait for you to become involved and finish those important user interfaces and documentation bits. 

Source : http://wiki.winehq.org/WineHistory
Download: http://www.winehq.org/download/

La historia de debian

  • 1 Introducción -- ¿Qué es el proyecto Debian?
    • 1.1 El comienzo
    • 1.2 Pronunciación de Debian
  • 2 Líderes
  • 3 Publicaciones de Debian
  • 4 La historia detallada
    • 4.1 Las versiones 0.x
    • 4.2 Las versiones 1.x
    • 4.3 Las versiones 2.x
    • 4.4 Las versiones 3.x
    • 4.5 Hechos Importantes
    • 4.6 ¿Qué sigue?
  • A El manifiesto de Debian Linux
    • A.1 ¿Qué es Debian Linux?
    • A.2 ¿Por qué se está elaborando Debian?
    • A.3 ¿De qué manera intentará Debian poner fin a estos problemas?

 

Una breve historia de Debian
Capítulo 1 - Introducción -- ¿Qué es el proyecto Debian?


El proyecto Debian es un grupo mundial de voluntarios que se esfuerzan por producir una distribución de sistema operativo que este compuesta enteramente de software libre. El producto principal del proyecto a la fecha es la distribución de software Debian GNU/Linux, la cual incluye a Linux como núcleo del sistema operativo, así como miles de aplicaciones pre-empaquetadas. Se soportan en mayor o menor medida distintos tipos de procesadores, incluyendo el procesador Intel i386 y superiores, y los procesadores Alpha, ARM, Intel IA-64, Motorola 68k, MIPS, PA-RISC, PowerPC, Sparc (y UltraSparc), IBM S/390 y Hitachi SuperH.
Debian motivó la formación de Software In The Public Interest, Inc., una organización sin ánimo de lucro, ubicada en Nueva York. SPI fue fundada para ayudar a Debian y otras organizaciones similares a desarrollar y distribuir hardware y software abierto. Entre otras cosas, SPI provee un mecanismo por el cual el proyecto Debian puede aceptar contribuciones que sean deducibles de impuestos en los Estados Unidos de América. 

Para obtener más información acerca del Software libre, consulte el Contrato social de debian y las Directrices de software libre de Debian asociadas, o bien la página ¿Qué significa libre?.

1.1 El comienzo

Ian Murdock fundó oficialmente el proyecto Debian el 16 de agosto de 1993. Hasta ese momento, el concepto de una «distribución» de Linux era nuevo. Ian pretendió que Debian fuera una distribución realizada de forma abierta, siguiendo el espíritu de Linux y GNU (lea el manifiesto provisto como un apéndice a este documento para más detalles). La creación de Debian fue patrocinada por el proyecto GNU de la FSF durante un año (noviembre de 1994 a noviembre de 1995). 

Debian estaba pensada para ser desarrollada cuidadosa y conscientemente y ser mantenida y soportada con un cuidado similar. Lo que comenzó con un pequeño y grupo muy unido de hackers de software libre, fue creciendo gradualmente hasta convertirse en una gran comunidad de desarrolladores y usuarios bien organizada. 

Debian es la única distribución que está abierta a las contribuciones de cada desarrollador y usuario que deseen participar con su trabajo. Y es la única distribución relevante de Linux que no es una entidad comercial. Es el único gran proyecto con una constitución, contrato social, y documento de directrices que organizan el proyecto. Debian es también la única distribución que se «micro-empaqueta» y que utiliza una detallada información de las dependencias de cada paquete con respecto a otros para asegurar la consistencia del sistema cuando tiene lugar una actualización. 

Debian ha adoptado un gran conjunto de directrices y procedimientos para el empaquetamiento y la distribución de software para poder alcanzar y mantener altos estándares de calidad. Se producen herramientas, sistemas automáticos y documentación de cada uno de los aspectos claves de Debian de una forma abierta y visible para poder sostener estos estándares.

1.2 Pronunciación de Debian

La pronunciación oficial de Debian es «deb i an». El nombre tiene su origen en los nombres del creador de Debian, Ian Murdock, y su esposa, Debra. 

Una breve historia de Debian
Capítulo 2 - Líderes


Debian ha tenido varios líderes desde sus comienzos en el año 1993.
Ian Murdock fundó Debian en agosto de 1993 y lo condujo hasta marzo de 1996.
Bruce Perens condujo Debian desde abril de 1996 hasta diciembre de 1997.
Ian Jackson condujo Debian desde enero de 1998 hasta diciembre de 1998.
Wichert Akkerman condujo Debian desde enero de 1999 hasta marzo del 2001.
Ben Collins condujo Debian desde abril del 2001 hasta abril del 2002.
Bdale Garbee condujo Debian desde abril del 2002 hasta abril del 2003.
Martin Michlmayr fue elegido en marzo del 2003 y es el líder de proyecto en la actualidad. 

Capítulo 3 - Publicaciones de Debian


Debian 0.01 hasta 0.90 (agosto-diciembre de 1993)
Debian 0.91 (enero de 1994): Esta publicación disponía de un sencillo sistema de empaquetamiento que permitía instalar y desinstalar paquetes. Varias docenas de personas formaban parte del proyecto en ese momento. 

Debian 0.93R5 (marzo de 1995): En este momento se asignaron responsabilidades de cada paquete a cada uno de los desarrolladores, y se empezó a utilizar el administrador de paquetes (dpkg) para instalar los paquetes después de la instalación del sistema base. 

Debian 0.93R6 (noviembre de 1995): Aparece dselect. Esta fue la última publicación de Debian que utilizaba el formato binario a.out. En este momento había cerca de 60 desarrolladores. Bdale Garbee construyó el primer servidor master.debian.org y HP lo alojó en paralelo con la publicación de 0.93R6. La utilización de un servidor maestro específico en el cual los desarrolladores de Debian podían construir cada publicación llevó directamente a la formación de una red de servidores espejos, e indirectamente al desarrollo de la mayoría de las directrices y procedimientos utilizados para manejar actualmente el proyecto. 

La versión 1.0 nunca fue publicada: Accidentalmente Infomagic, un proveedor de CDs, lanzó una versión de desarrollo de Debian y la tituló como 1.0. El 11 de diciembre de 1995, Debian e Infomagic anunciaron conjuntamente que esta versión fue equívoca. Bruce Perens explica que la información colocada en 5 CDs de "Recurso para el Desarrollador de Linux Infomagic" de noviembre de 1995, como "Debian 1.0" no es la versión 1.0 de Debian, mas bien era una versión de desarrollo temprana que está solo parcialmente en formato ELF, que probablemente no iniciará o no se ejecutará correctamente, y no representará la calidad de un sistema Debian publicado. Para evitar la confusión entre la versión prematura de la versión en CD y la actual versión de Debian, el proyecto Debian renombró su siguiente versión a "Debian 1.1". La Debian 1.0 prematura en Cd está desaprobada y no debe ser usada.

Debian 1.1 Buzz (17 de junio de 1996): Esta fue la primera versión de Debian con un nombre en código. fue tomado, como todos los demás hasta ahora, de un personaje de la película Toy Story... en este caso, Buzz Lightyear. En esa ocasión, Bruce Perens tomó la dirección del proyecto desde Ian Murdock, y Bruce estaba trabajando en Pixar, la compaña que produce la película. Esta versión estaba completamente en formato ELF, usado en el kernel Linux 2.0, y contenía 474 paquetes. 

Debian 1.2 Rex (12 de diciembre de 1996) Nombrada como el dinosaurio de plástico de la película. Esta versión consistió en 848 paquetes a cargo de 120 desarrolladores. 

Debian 1.3 Bo (5 de junio de 1997): El nombre viene de Bo Peep, la pastora. Esta versión consistió en 974 paquetes a cargo de 200 desarrolladores. 

Debian 2.0 Hamm (24 de julio de 1998): El nombre por el cerdito de la película. Esta fue la primera versión de Debian multiplataforma, con soporte para arquitecturas Motorola 68000 series. Con Ian Jackson como líder del proyecto, esta versión hace la transición a libc6, y consistió en mas de 1500 paquetes a cargo de mas de 400 desarrolladores. 

Debian 2.1 Slink (9 de marzo de 1999): El nombre por el perrito de la película. Se agregaron dos arquitecturas más, Alpha y SPARC. Con Wichert Akkerman como líder del proyecto, esta versión consistía en 2250 paquetes y requería 2 CDs en el paquete oficial. La clavé técnica de la innovación fue la introducción de apt, una nueva interfase para la administración de paquetes. Mundialmente usado, apt condujo las cuestiones resultantes del continuo crecimiento de Debian, y estableció un nuevo paradigma para la adquisición de paquetes y la instalación de sistemas operativos Open source. 

Debian 2.2 Potato (15 de agosto del 2000): El nombre por el «Mr Potato Head» de la película. Esta versión agregó soporte para las arquitecturas PowerPC y ARM. Con Wichert como líder del proyecto todavía, esta versión consistió en mas de 3900 paquetes binarios derivados de mas de 2600 paquetes fuentes a cargo de mas de 450 desarrolladores de Debian. 

Debian 3.0 woody (19 de julio del 2002): El nombre por el personaje principal de la película: «woody» el vaquero. Aún mas arquitecturas fueron agregadas en esta versión: IA-64, HP PA-RISC, MIPS (big endian), MIPS (little endian) y S/390. Esta es también la primera versión que incluye software criptográfico debido a las restricciones para la exportación que estaban siendo iniciadas en EEUU, y también la primera en incluir KDE, ahora que los problemas de licencia con QT fueron resueltas. Con Bdale Garbee recientemente designado como líder del proyecto, y mas de 900 desarrolladores de Debian, esta versión contenía alrededor de 8500 paquetes binarios y 7 CDs binarios en el paquete oficial 

Capítulo 4 - La historia detallada


4.1 Las versiones 0.x

Debian la empezó Ian Murdock en agosto de 1993, en ese entonces un estudiante de la Universidad de Purdue. Por un año (desde noviembre de 1994 a noviembre de 1995), Debian fue patrocinada por el proyecto GNU de la Free Software Foundation, la organización fundada por Richard Stallman y asociada con la Licencia Pública General (GPL). 

Debian 0.01 hasta Debian 0.90 fue publicada entre agosto y diciembre de 1993. Ian Murdock escribió: 

«Debian 0.91 fue publicada en enero de 1994. Tenía un primitivo sistema de empaquetamiento que permitía a los usuarios manipular paquetes pero que no hacía mucho más (ciertamente no tenía dependencias ni nada por el estilo). Hasta ese momento, habían unas pocas docenas de personas trabajando en Debian, aunque todavía estaba prácticamente ensamblando las distribuciones yo mismo. 0.91 fue la última versión terminada de esta manera.» 

«La mayor parte de 1994 se pasó organizando el proyecto Debian mientras que otros podían contribuir mas efectivamente, por ejemplo trabajando en dpkg (Ian Jackson fue por mucho tiempo el responsable de este). No hubieron versiones publicadas en 1994 que yo recuerde, aunque hubieron varias versiones internas en las que trabajamos para hacer el proceso correcto.» 

«Debian 0.93 Release 5 tuvo lugar en marzo de 1995 y fue la primera versión «moderna» de Debian: Esta tuvo muchos mas desarrolladores (aunque no recuerdo cuantos exactamente), cada uno a cargo de sus propios paquetes, y dpkg se usaba para instalar y mantener todos estos paquetes después de que el sistema base esté instalado.» 

«Debian 0.93 Release 6 apareció en noviembre de 1995 y fue la última versión con a.out. Habían aproximadamente 60 desarrolladores responsables de paquetes en la versión 0.93R6. Si mal no recuerdo, dselect apareció por primera ves en la versión 0.93R6.» 

Ian Murdock también apunta que Debian 0.93R6 «... siempre fue mi versión favorita de Debian», aunque él admite sobre la posibilidad de algún prejuicio personal, como el había parado de trabajar activamente en el proyecto en marzo de 1996 durante la preproducción de Debian 1.0, que fue publicada como Debian 1.1 para evitar confusiones después de que un fabricante de CDs llamara erróneamente a una versión no publicada como Debian 1.0. Ese incidente llevó al concepto de imágenes de CDROM «oficiales», como una forma de que el proyecto ayude a los vendedores a evitar este error. 

Durante agosto de 1995 (entre Debian 0.93 Release 5 y Debian 0.93 Release 6), Hartmut Koptein inició la primera migración de Debian, para la familia Motorola m68k. El informa que «Muchos, muchos paquetes eran i386-centric (little endian, -m486, -O6 y todos para libc4) y ha sido muy duro conseguir en mi máquina una base de paquetes sobre los que comenzar(una Atari Medusa 68040, 32 MHz). Después de tres meses (en noviembre de 1995), descargué 200 paquetes de 250 paquetes disponibles, todos para libc5!» Luego comenzó otra migración junto con Vincent Renardias y Martin Schulze, para la familia PowerPC. 

Desde aquel tiempo, el proyecto Debian estuvo creciendo para incluir varias migraciones a otras arquitecturas, y otra migración al nuevo kernel (no linux), el microkernel GNU Hurd.
Un miembro del proyecto desde sus comienzos, Bill Mitchell, recuerda que el kernel Linux
«... estaba entre la 0.99r8 y la 0.99r15 cuando comenzamos. Por un largo tiempo, yo pude construir el kernel en menos de 30 minutos en una máquina basada en 386 con 20 MHz, y pude también hacerlo en una instalación Debian en la misma cantidad de tiempo con 10Mb de espacio en disco.» 

« ... recuerdo al grupo inicial incluyendo a Ian Murdock, yo mismo, Ian Jackson, otro Ian que no recuerdo su apellido, Dan Quinlan, y alguna otra gente que no recuerdo sus nombres. Matt Welsh fue también parte del grupo inicial o se unió tempranamente (ha dejado el proyecto). Alguien instaló una lista de correo, y desde entonces empezamos a funcionar.» 

« Según lo recuerdo, no comenzamos con un plan, tampoco comenzamos con cualquier plan. Comenzamos recogiendo fuentes para una colección de paquetes al azar. Con el tiempo, nos enfocamos en una colección de items que podrían ser requeridos en la distribución: el kernel, un shell, update, getty, varios programas más y ficheros de soporte necesarios para inicializar el sistema, y un conjunto de utilidades.»

4.1.1 El Primer sistema de Empaquetamiento de Debian

En las primeras faces del proyecto, los miembros consideraron la distribución de paquetes fuente solamente. Cada paquete consistiría en el código fuente principal más un parche «Debianizado», y los usuarios podrían descomprimir los fuentes, aplicar los parches, y compilar los binarios ellos mismos. Pronto comprendieron que algún esquema de distribución de binarios sería necesario. La primera herramienta de empaquetamiento, escrita por Ian Murdock y llamada dpkg, creaba un paquete binario en un formato específico de Debian, y podría ser usado luego para desempaquetar e instalar los ficheros del paquete. Ian Jackson pronto tomó el desarrollo de la herramienta de empaquetamiento, renombrando la herramienta a dpkg-deb y escribiendo una interfase que nombró dpkg para facilitar el uso de dpkg-deb y proveer las Dependencias y Conflictos del sistema Debian de hoy. Los paquetes producidos por estas herramientas tenían una cabecera que listaba la versión de la herramienta usada para crear el paquete y una sección dentro del paquete para un archivo producido por tar, que mediante cierta información de control se separaba de la cabezera. 

En ese momento se levantó cierto debate entre los miembros del proyecto -- Algunos pensaron que el formato específico de Debian creado por dpkg-deb debía ser quitado a favor del formato producido por el programa ar. Después de varios formatos de archivo revisados y herramientas de empaquetamiento revisadas, el formato ar fue adoptado. La clave de este cambio es que este hace posible que un paquete Debian pueda ser desempaquetado en cualquier sistema Unix sin la necesidad de ejecutar un programa que no sea confiable. En otras palabras, solo herramientas estándares presentes en cada sistema Unix como 'ar' y 'tar' son requeridas para desempaquetar un paquete binario de Debian y examinar su contenido.

4.2 Las versiones 1.x

Cuando Ian Murdock dejó Debian, designó a Bruce Perens como el siguiente líder del proyecto. Bruce se interesó por primera ves en Debian cuando estaba intentando crear una distribución Linux en CD para ser llamada «Linux for Hams», la cual incluiría software Linux útil para radioaficionados. Dándose cuenta de que el sistema Debian básico requeriría de mucho mas trabajo para soportar su proyecto, Bruce acabó por trabajar en el sistema Linux base y herramientas de instalación relacionadas, posponiendo su distribución para radioaficionados, incluyendo la organización (con Ian Murdock) del primer conjunto de scripts de instalación de Debian, que hoy en día resultó en el disquete de rescate de Debian (Debian Rescue Floppy).
Ian Murdock afirma: 

«Bruce era la elección natural para relevarme, pues yo había mantenido el sistema base por casi un año, había estado llevando al máximo la capacidad del proyecto conforme mi disponibilidad de tiempo para dedicar a Debian decrecía rápidamente». 

Inicializó varias facetas importantes del proyecto, incluyendo la coordinación de esfuerzos para producir las directrices de Software Libre de Debian y el Contrato Social de Debian, así también la puesta en marcha de «The Open Hardware Project». Durante su tiempo como líder del proyecto, Debian había ganado cuota de mercado y una reputación de plataforma para usuarios serios y técnicamente capaces. 

Bruce Perens también encabezó los esfuerzos para crear Software in the Public Interest, Inc.. Originalmente con el objetivo de proveer al proyecto Debian una entidad legal capaz de aceptar donaciones, sus finalidades se expandieron rápidamente para incluir soporte para proyectos de software libre fuera del proyecto Debian. 

Durante ese tiempo se publicaron las siguientes versiones de Debian:
  • 1.1 Buzz publicada en junio de 1996 (474 paquetes, kernel 2.0, completamente ELF, dpkg)
  • 1.2 Rex publicada en diciembre de 1996 (848 paquetes, 120 desarrolladores)
  • 1.3 Bo publicada en julio de 1997 (974 paquetes, 200 desarrolladores)
Hubieron varias versiones intermedias «puntuales» hechas a la 1.3, siendo la última la 1.3.1R6. 

Bruce Perens fue relevado por Ian Jackson como Líder del proyecto Debian en los comienzos de enero de 1998, después de llevar el proyecto durante buena parte de la preparación de la publicación de la 2.0.

4.3 Las versiones 2.x

Ian Jackson se convirtió en el líder del proyecto Debian a comienzos de 1998, y poco después se le añadió al organigrama de Software in the Public Interest en calidad de Vicepresidente. Después de la dimisión del tesorero (Tim Sailer), Presidente (Bruce Perens), y Secretario (Ian Murdock), se convirtió en el Presidente del Consejo y se eligieron los tres nuevos miembros: Martin Schulze (Vicepresidente), Dale Scheetz (Secretario), y Nils Lohner (Tesorero). 

Debian 2.0 (Hamm) se publicó en julio de 1998 para las arquitecturas Intel i386 y la serie Motorola 68000. Este versión marcó el traslado hacia una nueva versión de las bibliotecas de C del sistema (libc6, basadas en glibc2). En el momento de la publicación, había más de 1500 paquetes mantenidos por más de 400 desarrolladores de Debian. 

Wichert Akkerman relevó a Ian Jackson como líder del proyecto Debian en enero de 1999. Debian 2.1 fue publicada el 9 de marzo de 1999, después un retraso de una semana al surgir complicaciones de última hora. 

Debian 2.1 (Slink) presentaba soporte oficial para dos nuevas arquitecturas: Alpha y Sparc. Los paquetes de las X-Windows incluidos con Debian 2.1 se reorganizaron en gran medida con respecto a versiones anteriores, y 2.1 incluía apt, la nueva generación de la interfase para el gestor de paquetes de Debian. Además, esta versión de Debian fue la primera en requerir 2 CD-ROMs para el «Official Debian CD set»; la distribución incluía aproximadamente 2250 paquetes.
El 21 de abril de 1999, Corel Corporation y el K Desktop Project formaron efectivamente una alianza con Debian cuando Corel anunció sus intenciones de publicar una distribución Linux basada en Debian y en el entorno de escritorio producido por el grupo KDE. Durante los siguientes meses de primavera y verano, apareció otra distribución basada en Debian, Storm Linux, y el proyecto Debian eligió un nuevo logotipo, con la particularidad de disponer de una versión oficial, para materiales aprobados por Debian, como sitios Web del proyecto y CD-ROMs oficiales, y un logotipo no oficial para su uso en materiales que mencionen o deriven de Debian. 

Una nueva y única adaptación comenzó también en ese momento para el núcleo Hurd. Esta es la primera adaptación que usa un núcleo distinto a Linux, y en su lugar usa GNU Hurd, una versión basada en el microkernel GNU Mach.
Debian 2.2 (potato) se publicó el 15 de agosto del 2000 para las arquitecturas Intel i386, las series Motorola 68000, alpha, SUN Sparc, PowerPC, y ARM. Es la primera versión en incluir las arquitecturas PowerPC y ARM. Al momento de la publicación, había más de 3900 paquetes binarios y más de 2600 paquetes fuente mantenidos por más de 450 desarrolladores de Debian.
Un hecho interesante acerca de Debian 2.2 es que él mostró cómo un esfuerzo de software libre podría llevar a un moderno sistema operativo a pesar de todas las cuestiones al rededor de él. Esto fue completamente estudiado por un grupo de interés en un artículo llamado Counting potatoes citado a continuación:
"[...] usamos el sistema sloccount de David A. Wheeler para determinar el número de líneas de código fuente (SLOC) físicas de Debian 2.2 (aka potato). Mostramos que Debian 2.2 incluye mas de 55,000,000 SLOC físico (casi dos veces más que Red Hat 7.1, publicado aproximadamente 8 meses después), mostrando que el modelo de desarrollo de Debian (basado en el trabajo de un gran grupo de voluntarios desarrolladores al rededor del mundo) es tan capaz como otros métodos de desarrollo [...] esto también muestra que si Debian se hubiese desarrollado usando métodos tradicionales propietarios, el modelo COCOMO estima que su costo podría cerrarse en $1.9 billones de dólares para desarrollar Debian 2.2. Además, ofrecemos un análisis de lenguajes de programación usados en la distribución (C tiene cerca del 70%, C++ cerca del 10%, LISP y Shell están cerca del 5%, con muchos otros que siguen), y los paquetes más grandes (Mozilla, el kernel Linux, PM3, XFree86, etc.)"

4.4 Las versiones 3.x

Antes de que woody puediera comenzar a ser preparada para ser publicada, hubo que hacer un cambio en el sistema del archivo en ftp-master. Los almacenes de paquetes, que permitieron que distribuciones de propósito especial como la nueva distribución «pruebas» pudieran ser usadas por primera vez para conseguir que woody estuviera lista para su publicación, fueron activatadas en ftp-master a mediados de Deciembre del 2000. Un almacén de paquetes es simplemente una colección de diferentes versiones de un paquete determinado, desde la cuál multiples distribuciones (actualmente experimental, «inestable», «pruebas», y «estable») pueden tomar paquetes, que luego son incluidos en el archivo Packages de dicha distribución.
Al mismo tiempo una nueva distribución fué «pruebas» incluida. Principalmente, paquetes de «inestable» considerados estables transladados a «pruebas» (después de un periodo de algunas semenas). Esto fué introducido para reducir el tiempo de estabilización y darle al proyecto la habilidad de preparar una nueva publicación en cualquier momento.
En ese período, algunas de las compañías que estaban entregando versiones modificadas de Debian cerraron. Corel vendió su división de Linux en el primer cuarteto de 2001, Stormix se declaró en bancarrota el 17 de enero de 2001, y Progeny detuvo el desarrollo de su distribución el 01 de octubre de 2001.
La estabilización para la siguiente publicación comenzó el 01 de julio de 2001. Aún asi, le tomó al proyecto un poco más de un año publicar la nueva versión, debido a problemas en los diskettes de inicio, debido a la inclusión de programas de cifrado en el archivo principal y a cambios en la estructura subyacente (el archivo de paquetes entrantes y la arquitectura de seguridad). En ese tiempo, la publicación estable (Debian 2.2) fué revisada hasta siete veces, y dos líderes del proyecto fueron elegidos: Ben Collins (en 2001) y Bdale Garbee. Asi también, el trabajo en muchas áreas de Debian mas allá de la creación de paquetes continuó creciendo, incluyendo la internacionalización, el sitio web de Debian (más de mil páginas) fué traducido a más de 20 lenguajes diferentes, y la instalación de la próxima versión estaba lista para 23 idiomas. Se iniciaron dos proyectos internos: Debian Junior (para niños) y Debian Med (para la práctica y la investigación médica) durante el proceso de publicación de woody otorgando al proyecto diferentes enfoques que hacen a Debian adecuado para esas tareas.
El trabajo en Debian no impidió a los desarrolladores organizar una reunión anual denominada Debconf. La primera conferencia se realizó del 1 al 5 de julio junto con Libre Software Meeting (LSM) en Bordeaux (Francia) reuniendo a 40 desarrolladores. La segunda conferencia tuvo lugar en Toronto (Canada) el 5 de julio de 2002 con mas de 80 participantes.
Debian 3.0 (woody) fué publicada el 19 de julio de 2002 para las arquitecturas Intel i386, Motorola 68000 series, alpha, SUN Sparc, PowerPC, ARM, HP PA-RISC, IA-64, MIPS, MIPS (DEC) e IBM s/390. Esta fué la primera versión en incluir los las adaptaciones a las arquitecturas HP PA-RISC, IA-64, MIPS, MIPS (DEC) e IBM s/390. Al momento de la publicación, existían cerca de 8500 paquetes binarios desarrollados por mas de mil desarrolladores de Debian, convirtiéndose en la primera versión en ser publicada en formato DVD además de los ya acostumbrados CD-ROMs.

4.5 Hechos Importantes


4.5.1 Julio de 2000: Muere Joel Klecker

El 11 de julio de 2000, Joel Klecker, quien era también conocido como Espy, falleció a la edad de 21 años. Ninguno de los que vieron el apodo 'Espy' en #mklinux ó en las listas y canales de Debian llegó a pensar jamás que detrás de ese apodo existía un joven sufriendo la Distrofia muscular de Duchenne. Mucha gente solo lo conoció como 'el tipo de la biblioteca glib y la powerpc en Debian' y nunca tuvo idea de las cosas terribles contra las que Joel luchó. A pesar de su discapacidad física, él compartió su brillante mente con otros.
Joel Klecker (conocido también como Espy) no será olvidado.

4.5.2 Octubre de 2000: Implementación de los almacenes de paquetes

James Troup reportó que había estado trabajando en la reimplementación de las herramientas de mantenimiento de los archivos y migrando al nuevo sistema de almacenes de paquetes. A partir de esta fecha, los ficheros son almacenados en un directorio llamado como el paquete fuente correspondiente dentro del directorio de los almacenes. Los directorios de distribuciones solo contendrán ficheros Packages los que a su vez contienen referencias al almacén. Esto simplifica la sobreposición de «pruebas» y «inestable». El archivo también está siendo administrado con bases de datos PostgreSQL las que agilizan las consultas.

4.5.3 Marzo de 2001: Muere Christopher Rutter

El 01 de Marzo de 2001, Christopher Matthew Rutter (también conocido como cmr) murió al ser atropellado por un automóvil a la edad de 19. Christopher era un miembro joven y bastante conocido del proyecto Debian ayudando en la adaptación a la arquitectura ARM.
Chris Rutter no será olvidado.

4.5.4 Marzo de 2001: Muere Fabrizio Polacco

El 28 de Marzo de 2001, Fabrizio Polacco falleció después de una larga enfermedad. El proyecto Debian hace mensión a su buen trabajo y gran dedicación a Debian y al software libre. Las contribuciones de Fabrizio no serán olvidadas, y otros desarrolladores continuarán con su trabajo.
Fabrizio Polacco no será olvidado.

4.5.5 Julio de 2002: Muere Martin Butterweck

El 21 de Julio de 2002, Martin Butterweck (también conocido como blendi) falleció luego de luchar contra la leuzemia. Martin era un joven miembro del proyecto quien recientemente se había unido a Debian.
Martin Butterweck no será olvidado.

4.5.6 Noviembre de 2002: El fuego destruye un servidor de Debian

Alrededor de las 08:00 CET el 20 de noviembre del 2002, el Network Operations Center (NOC) de la Universidad de Twente se incendió. El edificio se destruyó por completo. Los bomberos habían dejado de lado las esperanzas de proteger el área de servidores. Entre otras cosas el centro hospedaba satie.debian.org que contenía tanto el archivo de seguridad y non-US así como las bases de datos de new-maintainer (nm) y control de calidad (qa). Debian reconstruyó estos servicios en el servidor klecker, que había sido recientemente transladado de EE.UU. a los Paises Bajos.

4.5.7 Mayo de 2004: Mueren Manuel Estrada Sainz y Andrés García

El 9 de Mayo del 2004, Manuel Estrada Sainz (ranty) y Andrés García (ErConde) fallecen en un trágico accidente automovilístico cuando retornaba de la conferencia de software libre que tuvo lugar en Valencia, España.
Manuel Estrada Sainz y Andrés García no serán olvidados.

4.6 ¿Qué sigue?

El proyecto Debian continúa trabajando en la distribución «inestable» (que lleva el nombre clave sid, en honor el malvado e "inestable" niño que es el vecino de Andy en la película Toy Story (quien jamás debería salir de casa). Sid es el nombre permanente para la distribución inestable y siempre se encuentra 'Still In Development' (aún en desarrollo). La mayoría de los paquetes nuevos ó las actualizaciones son cargadas en esta distribución. 

La distribución «pruebas» está pensada para convertirse en la siguiente publicación «estable» y en la actualidad lleva el nombe clave sarge

Para sarge, Debian está trabajando en un nuevo marco para instalaciones llamado debian-installer, la nueva Glibc 2.3 y el nuevo GNU GCC 3.2. 

Apéndice A - El manifiesto de Debian Linux


Escrito por Ian A. Murdock, Revisado 01/06/94

A.1 ¿Qué es Debian Linux?

Debian Linux es una distribución de Linux completamente nueva. En vez de estar desarrollada por un individuo aislado o un grupo, como se han desarrollado otras distribuciones de Linux en el pasado, Debian se desarrolla abiertamente en el espíritu de Linux y GNU. El propósito principal del proyecto Debian es acabar creando una distribución que esté a la altura del nombre de Linux. Debian se están ensamblando con cuidado y a conciencia, y se le dará apoyo y mantenimiento con una atención similar. 

Es también un intento por crear una distribución no comercial que será capaz de competir efectivamente en el mercado comercial. Será distribuida, llegado el caso, por la Free Software Foundation en CD-ROM, y la Debian Linux Association ofrecerá la distribución en disquetes y cinta junto con los manuales impresos, el soporte técnico y otras cuestiones igualmente importantes para el usuario final. Todo lo anterior estará disponible por poco más que el coste original, y esa pequeña diferencia se destinará al más amplio desarrollo de software libre para todos los usuarios. Tal distribución es esencial para el éxito del sistema operativo Linux en el mercado comercial, y debe hacerse por parte de organizaciones en situación de avanzar con éxito y abogar por el software libre sin la presión de los beneficios o los ingresos.

A.2 ¿Por qué se está elaborando Debian?

Las distribuciones son esenciales para el futuro de Linux. En esencia, le eliminan al usuario la necesidad de buscar, obtener, compilar, instalar e integrar correctamente gran número de herramientas esenciales para conseguir un sistema Linux en funcionamiento. En su lugar, la carga de construir el sistema recae sobre el creador de la distribución, y muchos usuarios continuarán usando una distribución por pura conveniencia incluso después de haberse familiarizado con el sistema operativo. De esta manera, las distribuciones juegan un papel realmente importante. 

A pesar de su obvia importancia, las distribuciones han atraído poco la atención de los desarrolladores. Existe una sencilla razón para ello: no son ni fáciles ni fascinantes de construir, y requieren gran cantidad de esfuerzo continuado por parte de su creador con el fin de mantener la distribución libre de errores y además actualizada. Una cosa es ensamblar un sistema empezando desde cero, y otra muy distinta asegurarse de que otros lo instalen fácilmente, se pueda instalar y utilizar en gran variedad de configuraciones de hardware, contenga programas que otros vayan a considerar útiles, y se actualice cuando los componentes mismos experimenten mejoras. 

Muchas distribuciones han empezado como sistemas bastante buenos, pero conforme va pasando el tiempo el mantenimiento de la distribución se convierte en una prioridad secundaria. Un caso que viene a cuento es el de Softlanding Linux System (más conocida como SLS). Es bastante posible que sea la distribución de Linux más plagada de errores y peor mantenida; por desgracia, también es la más generalizada. Sin lugar a dudas, es la distribución que atrae la mayor parte de la atención de los muchos «distribuidores» comerciales de Linux que han surgido para capitalizar la creciente popularidad del sistema operativo. 

Se trata verdaderamente de una mala combinación, pues la mayoría de personas que obtienen Linux de estos distribuidores reciben una distribución de Linux plagada de errores y deficientemente mantenida. Como si esto no fuera ya bastante malo, estos «distribuidores» tienen una alarmante tendencia a publicitar engañosamente características no funcionales, o incluso extremadamente inestables, de su producto. Combínese esto con el hecho de que los compradores esperan que el producto esté a la altura de su publicidad, y que muchos creen que se trata de un sistema operativo comercial (hay también una tendencia a no mencionar que Linux es libre y gratuito y que se distribuye bajo los términos de la licencia pública general de GNU). 

Para acabar de rematarlo, estos «distribuidores» están en realidad consiguiendo suficientes beneficios de su esfuerzo para justificar la compra de anuncios mayores en más revistas; es el clásico ejemplo de un comportamiento inaceptable recompensado por aquellos que simplemente no conocen nada mejor. Evidentemente hay que hacer algo para remediar la situación.

A.3 ¿De qué manera intentará Debian poner fin a estos problemas?

El diseño de Debian es lo bastante abierto para asegurar que el sistema tiene la más alta calidad y que refleja las necesidades de la comunidad de usuarios. Al implicar a otras personas de diversas capacidades y bagajes, Debian puede desarrollarse de forma modular. Sus componentes son de alta calidad porque a los que tienen experiencia en cierta área se les da la oportunidad de construir o mantener los componentes individuales de Debian que implica dicha área. Implicar a otros asegura además que a la distribución pueden incorporarse valiosas contribuciones durante su desarrollo; de esta manera, se crea una distribución basada en las necesidades y deseos de los usuarios, en vez de las necesidades y deseos del constructor. Es muy difícil para un pequeño grupo anticiparse a estas necesidades y deseos por anticipado sin las aportaciones directas de otros. 

Debian Linux también será distribuida en un soporte físico por la Free Software Foundation y la Debian Linux Association. Esto proporcionará Debian a los usuarios sin acceso a Internet o FTP, y además hace que productos y servicios tales como manuales impresos y soporte técnico estén a disposición de todos los usuarios del sistema. De esta manera, Debian puede usarse por parte de muchos más individuos y organizaciones que lo que sería posible en otro caso; la prioridad estará en proporcionar un producto de primera fila y no en los beneficios o los ingresos, y el margen de los productos o los servicios puede usarse para mejorar el software en sí para todos los usuarios, hayan pagado por su Debian o no. 

La Free Software Foundation juega un papel extremadamente importante en el futuro de Debian. Por el simple hecho de distribuirla, se envía al mundo el mensaje de que Linux no es un producto comercial y que nunca lo será, pero ello no quiere decir que Linux no sea nunca capaz de competir comercialmente. Para aquellos que disientan, les reto a que expliquen racionalmente el éxito de GNU Emacs y de GCC, que no son software comercial pero que han tenido bastante impacto sobre el mercado comercial con independencia de ese hecho. 

Ha llegado el tiempo de concentrarse en el futuro de Linux más que en el destructivo objetivo de enriquecerse a expensas de la entera comunidad de Linux y de su futuro. El desarrollo y distribución de Debian puede no ser la respuesta a los problemas que he apuntado en este Manifiesto, pero espero que al menos atraiga suficiente atención sobre estos problemas para permitir resolverlos.



INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DE CORREOS EN CENTOS 5.7



ELABORADO POR:
 TUAPPSMARTPHONE





ÍNDICE GENERAL

ANTECEDENTES

INTRODUCCIÓN

DESARROLLO

ANEXOS

CONCLUSIONES

BIBLIOGRAFÍA Y FUENTES DE CONSULTA

                                                   





ANTECEDENTES

Un servidor de correo es una aplicación informática ubicada en una página web en internet cuya función es parecida al Correo postal solo que en este caso los correos (otras veces llamados mensajes) que circulan, lo hacen a través de nuestras Redes de transmisión de datos y a diferencia del correo postal, por este medio solo se pueden enviar adjuntos de ficheros de cualquier extensión y no bultos o paquetes al viajar la información en formato electrónico.
Los servidores de correo a menudo realizan diferentes funciones según sea el uso que se planifique para el mismo.
Agente de Transferencia de Correo (del inglés Mail Transport Agent o MTA; también Message Transport Agent, Agente de Transporte de Mensajes) es uno de los programas que ejecutan los servidores de correo, y tiene como fin transferir un conjunto de datos de una computadora a otra.
El MTA, tiene varias formas de comunicarse con otros servidores de correo:
1.- Recibe los mensajes desde otro MTA. Actúa como "servidor" de otros servidores.
2.- Envía los mensajes hacia otro MTA. Actúa como un "cliente" de otros servidores.
3.- Actúa como intermediario entre un "Mail Submision Agent" y otro MTA.

Algunas soluciones de correo que incluyen un MTA son:
Sendmail, qmail, Postfix, Exim, Mdaemon, Mercury Mail Transport System , Lotus Notes (IBM) y Microsoft Exchange Server.
Por defecto el protocolo estándar para la transferencia de correos entre servidores es el SMTP, o Protocolo Simple de Transferencia de Correo. Está definido en el RFC 2821 y es un estándar oficial de Internet.
Un servidor de correo realiza una serie de procesos que tienen la finalidad de transportar información entre los distintos usuarios. Usualmente el envió de un correo electrónico tiene como fin que un usuario (remitente) cree un correo electrónico y lo envié a otro (destinatario). Esta acción toma típicamente 5 pasos.
1.- El usuario inicial crea un "correo electrónico"; un archivo que cumple lo estándares de un correo electrónico. Usara para ello una aplicación ad-hoc. Las aplicaciones más usadas, en indistinto orden son: Outlook Express (Microsoft), Oulook (Microsoft),Mozilla Thuntherbird (Mozilla), Pegasus Mail (David Harris), IBM Lotus Notes (IBM); etc.
2.- El archivo creado es enviado a un almacén; administrado por el servidor de correo local al usuario remitente del correo; donde se genera una solicitud de envió.
3.- El servicio MTA local al usuario inicial recupera este archivo e inicia la negociación con el servidor del destinatario para el envió del mismo.
4.- El servidor del destinatario valida la operación y recibe el correo, depositándolo en el "buzón" correspondiente al usuario receptor del correo. El "buzón" no es otra cosa que un registro en una base de datos.
5.- Finalmente el software del cliente receptor del correo recupera este archivo o "correo" desde el servidor almacenando una copia en la base de datos del programa cliente de correo, ubicada en la computadora del cliente que recibe el correo.
A diferencia de un servicio postal clásico, que recibe un único paquete y lo transporta de un lugar a otro; el servicio de correo electrónico copia varias veces la información que corresponde al correo electrónico.
Este proceso que en la vida real ocurre de manera muy rápida involucra muchos protocolos. Por ejemplo para obtener los mensajes del servidor de correos receptor, los usuarios se sirven de clientes de correo que utilizan el protocolo POP3 o el protocolo IMAP para recuperar los "correos" del servidor y almacenarlos en sus computadores locales.
Si tiene en cuenta el proceso, hay por lo menos una copia del correo en el servidor de envío y otra copia en el servidor de recepción.
Las políticas de funcionamiento de cada servidor, con o sin aviso a los usuarios remitente y/o destinatario, podrían:
1.- No recibir correos de acuerdo a algún parámetro.
2.- Destruir las copias de los correos, por ejemplo al transferirlos satisfactoriamente.
3.- Copiar los correos a algún otro registro o archivo.
4.- Enviar una o más copias a otros destinatarios.
5.- No destruir nunca los correos almacenados.
Es de suma importancia considerar qué entidad, institución y funcionario son los responsables de administrar finalmente los servidores de correo que usamos. Los correos pueden en muchos casos ser fuente de invasión a la privacidad.
Las raíces de Sendmail se remontan al nacimiento del correo electrónico, una década antes de que naciese ARPANET, el precursor de Internet. Por entonces, cada buzón de usuario era un fichero con derechos de sólo lectura y las aplicaciones de correo eran simplemente texto incorporado en ese fichero. Cada usuario tenía que abrir y meterse de lleno en el fichero de correo para buscar correos antiguos y leer el correo nuevo era toda una faena. La primera transferencia real de un fichero de mensaje de correo entre dos equipos tuvo lugar hasta el año de 1972, año en el que el correo electrónico empezó a transferirse por FTP a través de un protocolo de red NCP.

Este método de comunicación más sencillo muy pronto se hizo popular, incluso hasta el punto de representar la mayor parte del tráfico de ARPANET en menos de un año.

Sin embargo, la falta de estándares entre los protocolos existentes convirtió al correo electrónico en más difícil de enviar desde algunos sistemas y así continuó hasta que ARPANET creó el estándar TCP/IP en 1982. Un nuevo protocolo, SMTP, que se materializaba en el transporte de mensajes. Estos avances, en combinación con la sustitución de los ficheros host por DNS, permitieron que se materializasen los agentes MTA con funciones completas. Sendmail,
que creció a partir de un precedente sistema de entrega de correo electrónico denominado Delivermail, muy pronto se convirtió en estándar a medida que Internet comenzaba a expandirse y a utilizarse más ampliamente.

PROTOCOLO SMTP

Simple Mail Transfer Protocol (SMTP) Protocolo Simple de Transferencia de Correo, es un protocolo de la capa de aplicación. Protocolo de red basado en texto utilizado para el intercambio de mensajes de correo electrónico entre computadoras u otros dispositivos SMTP se basa en el modelo cliente-servidor, donde un cliente envía un mensaje a uno o varios receptores. La comunicación entre el cliente y el servidor consiste enteramente en líneas de texto compuestas por caracteres ASCII. El tamaño máximo permitido para estas líneas es de 1000 caracteres.

Las respuestas del servidor constan de un código numérico de tres dígitos, seguido de un texto explicativo. El número va dirigido a un procesado automático de la respuesta por autómata, mientras que el texto permite que un humano interprete la respuesta. En el protocolo SMTP todas las órdenes, réplicas o datos son líneas de texto, delimitadas por el carácter <CRLF>. Todas las réplicas tienen un código numérico al comienzo de la línea.
En el conjunto de protocolos TCP/IP, el SMTP va por encima del TCP, usando normalmente el puerto 25 en el servidor para establecer la conexión.

PROTOCOLO POP 3
POP3 está diseñado para recibir correo, no para enviarlo; le permite a los usuarios con conexiones intermitentes ó muy lentas (tales como las conexiones por módem), descargar su correo electrónico mientras tienen conexión y revisarlo posteriormente incluso estando desconectados. Cabe mencionar que la mayoría de los clientes de
correo incluyen la opción de dejar los mensajes en el servidor, de manera tal que, un cliente que utilice POP3 se conecta, obtiene todos los mensajes, los almacena en la computadora del usuario como mensajes nuevos, los elimina del servidor y finalmente se desconecta. En contraste, el protocolo IMAP permite los modos de operación conectado y desconectado.

Los clientes de correo electrónico que utilizan IMAP dejan por lo general los mensajes en el servidor hasta que el usuario los elimina directamente. Esto y otros factores hacen que la operación de IMAP permita a múltiples clientes acceder al mismo buzón de correo. La mayoría de los clientes de correo electrónico soportan POP3 ó IMAP; sin embargo, solo unos cuantos proveedores de internet ofrecen IMAP como valor agregado de sus servicios.

PROTOCOLO IMAP
Internet Message Access Protocol, o su acrónimo IMAP, es un protocolo de red de acceso a mensajes electrónicos almacenados en un servidor. Mediante IMAP se puede tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a Internet. IMAP tiene varias ventajas sobre POP, que es el otro protocolo empleado para obtener correo desde un servidor. Por ejemplo, es posible especificar en IMAP carpetas del lado servidor. Por otro lado, es más complejo que POP ya que permite visualizar los mensajes de manera remota y no descargando los mensajes como lo hace POP.




INTRODUCCIÓN

En este documento se pretende apoyar a las personas que tengan la inquietud o necesidad de instalar un servidor de correos ya sea con fines didácticos o comerciales, el objetivo principal es servir de apoyo y como referencia a la hora de configurar este tipo de servidores, las herramientas aquí empeladas son de software libre que se rigen bajo la licencia GPL de la Free Software Foundation, con esto cualquier persona que necesite configurar un servidor de correos y que no quiera gastas dinero en licencia de software privado encontrara una solución idónea en este documento. Como sistema operativo utilizaremos un plataforma GNU/Linux como Centos 5.7, se configurara con los protocolos correspondientes SMTP, POP3, IMAP, y el servidor Devecot y Sendmail. Los prerrequisitos necesarios para tener éxito en la implementación de este documento es que el lector tenga conocimientos básicos de GNU/Linux y ya cuente con una maquina con Fedora 13 preinstalado y con una conexión a internet, no es necesario que domine la Shell o terminal de los sistemas GNU/Linux ya que se explicaran las líneas de código que se tendrán que teclear.


 
DESARROLLO


1.- INSTALACIÓN DE PAQUETES NECESARIOS



-SENDMAIL
-DOVECOT
-SPAMASSIM
-M4
-MAKE
-SQUIRRELMAIL
-APACHE
-CLAMAV
-CLIENTE DE CORREO (THUNDERBIRD, OUTLOOK,ETC)








 
 








2.- CONFIGURACIÓN DE FICHEROS

Nota: para editar un archivo se necesita entrar en la terminal como root y el programa para editar el archivo es nano, es fácil de utilizar, por ejemplo para editar el archivo /etc/mail/Access; utilizamos el siguiente comando; nano /etc/mail/access; para guardar cambios tecleamos CTRL + O y para cerrar nano tecleamos CTRL + X.
·         configuración del fichero /etc/mail/access
·         configuración del fichero /etc/mail/local-host-names
·         configuración del fichero /etc/mail/relay-domains…(si no existe el fichero tenemos que crearlo)
·         configuración del fichero /etc/mail/sendmail.mc
Abrimos el fichero sendmail.mc y borramos todo su contenido y pegamos las siguientes líneas tal y como se muestre abajo, o de lo contrario modifique el archivo para que quede igual;
********************************************************************************
divert(-1)dnl
dnl #
dnl # This is the sendmail macro config file for m4. If you make changes to
dnl # /etc/mail/sendmail.mc, you will need to regenerate the
dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is
dnl # installed and then performing a
dnl #
dnl #     /etc/mail/make
dnl #
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for linux')dnl
OSTYPE(`linux')dnl
dnl #
dnl # Do not advertize sendmail version.
dnl #
dnl define(`confSMTP_LOGIN_MSG', `$j Sendmail; $b')dnl
dnl #
dnl # default logging level is 9, you might want to set it higher to
dnl # debug the configuration
dnl #
dnl define(`confLOG_LEVEL', `9')dnl
dnl #
dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #
dnl define(`SMART_HOST', `smtp.your.provider')dnl
dnl #
define(`confDEF_USER_ID', ``8:12'')dnl
dnl define(`confAUTO_REBUILD')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST', `True')dnl
define(`confDONT_PROBE_INTERFACES', `True')dnl
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/var/log/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A')dnl
dnl #
dnl # The following allows relaying if the user authenticates, and disallows
dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links
dnl #
define(`confAUTH_OPTIONS', `A p')dnl
dnl #
dnl # PLAIN is the preferred plaintext authentication method and used by
dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do
dnl # use LOGIN. Other mechanisms should be used if the connection is not
dnl # guaranteed secure.
dnl # Please remember that saslauthd needs to be running for AUTH.
dnl #
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl #
dnl # Rudimentary information on creating certificates for sendmail TLS:
dnl #     cd /etc/pki/tls/certs; make sendmail.pem
dnl # Complete usage:
dnl #     make -C /etc/pki/tls/certs usage
dnl #
define(`confCACERT_PATH', `/etc/ssl/uaem1.edu.mx')dnl
define(`confCACERT', `/etc/ssl/uaem1.edu.mx/sendmail.crt')dnl
define(`confSERVER_CERT', `/etc/ssl/uaem1.edu.mx/sendmail.crt')dnl
define(`confSERVER_KEY', `/etc/ssl/uaem1.edu.mx/sendmail.key')dnl
dnl #
dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's
dnl # slapd, which requires the file to be readble by group ldap
dnl #
dnl define(`confDONT_BLAME_SENDMAIL', `groupreadablekeyfile')dnl
dnl #
dnl define(`confTO_QUEUEWARN', `4h')dnl
dnl define(`confTO_QUEUERETURN', `5d')dnl
dnl define(`confQUEUE_LA', `12')dnl
dnl define(`confREFUSE_LA', `18')dnl
define(`confTO_IDENT', `0')dnl
dnl FEATURE(delay_checks)dnl
FEATURE(`no_default_msa', `dnl')dnl
FEATURE(`smrsh', `/usr/sbin/smrsh')dnl
FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
dnl #
dnl # The following limits the number of processes sendmail can fork to accept
dnl # incoming messages or process its message queues to 20.) sendmail refuses
dnl # to accept connections once it has reached its quota of child processes.
dnl #
dnl define(`confMAX_DAEMON_CHILDREN', `20')dnl
dnl #
dnl # Limits the number of new connections per second. This caps the overhead
dnl # incurred due to forking new sendmail processes. May be useful against
dnl # DoS attacks or barrages of spam. (As mentioned below, a per-IP address
dnl # limit would be useful but is not available as an option at this writing.)
dnl #
dnl define(`confCONNECTION_RATE_THROTTLE', `3')dnl
dnl #
dnl # The -t option will retry delivery if e.g. the user runs over his quota.
dnl #
FEATURE(local_procmail, `', `procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
dnl #
dnl # For using Cyrus-IMAPd as POP3/IMAP server through LMTP delivery uncomment
dnl # the following 2 definitions and activate below in the MAILER section the
dnl # cyrusv2 mailer.
dnl #
dnl define(`confLOCAL_MAILER', `cyrusv2')dnl
dnl define(`CYRUSV2_MAILER_ARGS', `FILE /var/lib/imap/socket/lmtp')dnl
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 587 for
dnl # mail from MUAs that authenticate. Roaming users who can't reach their
dnl # preferred sendmail daemon due to port 25 being blocked or redirected find
dnl # this useful.
dnl #
 DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl #
dnl # For this to work your OpenSSL certificates must be configured.
dnl #
 DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
dnl #
dnl # The following causes sendmail to additionally listen on the IPv6 loopback
dnl # device. Remove the loopback address restriction listen to the network.
dnl #
dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl
dnl #
dnl # enable both ipv6 and ipv4 in sendmail:
dnl #
dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')
dnl #
dnl # We strongly recommend not accepting unresolvable domains if you want to
dnl # protect yourself from spam. However, the laptop and users on computers
dnl # that do not have 24x7 DNS do need this.
dnl #
dnl FEATURE(`accept_unresolvable_domains')dnl
dnl #
dnl FEATURE(`relay_based_on_MX')dnl
dnl #
dnl # Also accept email sent to "localhost.localdomain" as local email.
dnl #
LOCAL_DOMAIN(`localhost.localdomain')dnl
dnl #
dnl # The following example makes mail from this host and any additional
dnl # specified domains appear to be sent from mydomain.com
dnl #
MASQUERADE_AS(`correotaap.edu.mx')dnl
dnl #
dnl # masquerade not just the headers, but the envelope as well
dnl #
FEATURE(masquerade_envelope)dnl
dnl #
dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well
dnl #
FEATURE(masquerade_entire_domain)dnl
dnl #
dnl MASQUERADE_DOMAIN(localhost)dnl
dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl
dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl
dnl MASQUERADE_DOMAIN(mydomain.lan)dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
dnl MAILER(cyrusv2)dnl
*******************************************************************************


3.- Configuración del servidor Dovecot
En el archivo dovecot.conf vamos a eliminar unas palabras que no necesitamos para este manual que son las palabras, imaps y pop3s.
·         configurar el archivo /etc/dovecot.conf
Ubica la siguiente línea;
#protocols = imap imaps pop3 pop3s
Y borra las palabras: imaps y pop3s
4.- administración de usuarios
La administración de usuarios será básica, solo se darán de alta usuarios por el momento no se especificaran cuotas de espacio en el disco.
·         Para dar de alta un usuario con contraseña tecleamos en este orden las siguientes líneas de comandos(como usuario root);

terminal# useradd -s /sbin/nologin nombreDelsuario
terminal# passswd nombreDelsuario
terminal# saslpasswd2 nombreDelsuario

5.- Iniciar el servidor de correo
Ahora después de estos básicos pasos, donde configuramos los archivos del servidor y también hemos dado de alta cuentas de correo, nos disponemos a iniciar el servidor de correos con el siguiente comando;
terminal# /etc/init.d/sendmail start
También necesitamos indicar el servicio más que es el de autentificación de usuarios y lo hacemos con el siguiente comando.
terminal# /etc/init.d/saslauthd start


CORREO ELECTRÓNICO SQUIRRELMAIL
INSTALACIÓN DE SQUIRRELMAIL

SquirrelMail es un interesante, extensible, funcional y robusto software para correo y que permite acceder al usuario a su correo electrónico desde el navegador de su predilección.
SquirrelMail está escrito en PHP4 y cumple con los estándares como correo a través de interfaz HTTP. Incluye su propio soporte para los protocolos IMAP y SMTP. Además todos las página se muestran con HTML 4.0 sin la necesidad de JavaScript para una máxima compatibilidad con cualquier navegador.
SquirrelMail incluye toda la funcionalidad deseada para un cliente de correo como un robusto soporte MIME, libreta de direcciones y administración de carpetas.
Procedimientos
Instalación del software requerido.

yum -y install squirrelmail httpd
Configuración de SquirrelMail

Ir al directorio /usr/share/squirrelmail/config/ y ejecutar el guión de configuración que se encuentra en el interior:

cd /usr/share/squirrelmail/config/
./conf.pl

Lo anterior le devolverá una interfaz de texto muy simple de utilizar, como la mostrada a continuación:

SquirrelMail Configuration : Read: config.php (1.4.3)
---------------------------------------------------------
Main Menu --
1.  Organization Preferences
2.  Server Settings
3.  Folder Defaults
4.  General Options
5.  Themes
6.  Address Books (LDAP)
7.  Message of the Day (MOTD)
8.  Plugins
9.  Database


D.  Set pre-defined settings for specific IMAP servers

C.  Turn color on
S   Save data
Q   Quit

Command >>

Ingrese hacia las preferencias de la organización y defina el nombre de la empresa, el logotipo y sus dimensiones, El mensaje en la barra de título de la ventana del navegador, el idioma a utilizar, URL y el título de la página principal del servidor de red.

SquirrelMail Configuration : Read: config.php (1.4.3)
---------------------------------------------------------
Organization Preferences
1.  Organization Name      : TAAP
2.  Organization Logo      : ../images/sm_logo.png
3.  Org. Logo Width/Height : (308/111)
4. 
Organization Title     : Bienvenido al Webmail de Su_empresa.
5.  Signout Page           :
6. 
Default Language       : es_ES
7.  Top Frame              : _top
8.  Provider link          : http://mx/tapp/index.htm
9.  Provider name          : UAEM

R   Return to Main Menu
C.  Turn color on
S   Save data
Q   Quit
Command >>

En las opciones de servidores defina solamente el dominio a utilizar. Si el servidor de correo va a coexistir en el mismo sistema con el servidor HTTP, no hará falta modificar más en esta sección. Se puede especificar otro servidor SMTP o IMAP.

SquirrelMail Configuration : Read: config.php (1.4.3)
---------------------------------------------------------
Server Settings

General
-------
1.  Domain                 : correotapp.edu.mx
2.  Invert Time            : false
3.  Sendmail or SMTP       : Sendmail
         
A.  Update IMAP Settings   : localhost:143 (uw)
B.  Change Sendmail Config : /usr/sbin/sendmail
                       
R   Return to Main Menu
C.  Turn color on
S   Save data
Q   Quit

Command >>

En las opciones de las carpetas cambiar Trash por Papelera, Sent por Enviados y Drafts por Borradores.

SquirrelMail Configuration : Read: config.php (1.4.3)
---------------------------------------------------------
Folder Defaults
1.  Default Folder Prefix         : mail/
2.  Show Folder Prefix Option     : true
3.  Trash Folder                  : Papelera
4.  Sent Folder                   : Enviados
5.  Drafts Folder                 : Borradores
6.  By default, move to trash     : true
7.  By default, move to sent      : true
8.  By default, save as draft     : true
9.  List Special Folders First    : true
10. Show Special Folders Color    : true
11. Auto Expunge                  : true
12. Default Sub. of INBOX         : true
13. Show 'Contain Sub.' Option    : false
14. Default Unseen Notify         : 2
15. Default Unseen Type           : 1
16. Auto Create Special Folders   : true
17. Folder Delete Bypasses Trash  : false
18. Enable /NoSelect folder fix   : false
                                 
R   Return to Main Menu
C.  Turn color on
S   Save data
Q   Quit

Command >>

Escoger y habilitar las extensiones (plug-ins) que consideren apropiados para el servicio:

SquirrelMail Configuration : Read: config.php (1.4.3)
---------------------------------------------------------
Plugins
  Installed Plugins
    1. delete_move_next
    2. squirrelspell
    3. newmail
    4. calendar
    5. filters
    6. mail_fetch
    7. translate
    8. abook_take
    9. message_details
    10. sent_subfolders

  Available Plugins:
    11. administrator
    12. bug_report
    13. info
    14. listcommands
    15. spamcop
    16. fortune
         
R   Return to Main Menu
C.  Turn color on
S   Save data
Q   Quit

Command >>

Guardar los cambios pulsando la tecla «S» y luego la tecla «Enter».

USO DEL WEBMAIL

El Webmail SquirrelMail es un cliente de correo que permite visualizar los mensajes de cuentas de email a través de una página web, pudiendo acceder desde cualquier navegador con acceso a Internet. Desde el Webmail, SquirrelMail se pueden realizar todas las operaciones necesarias para gestionar nuestros correos e incluso usarlo como agenda de contactos. Para tener acceso al SquirrelMail del dominio.
Acceder al webmail introduciendo el subdominio "webmail" precedido del nombre del dominio. http://correotaap.edu.mx/webmail .
Acceder a la pantalla de acceso de la cuenta de. Desde dicha pantalla se introduce el nombre de usuario y contraseña de la cuenta de correo. Esta pantalla es común a todas las cuentas de correo de su dominio. Cada cuenta de email dispone de su usuario y contraseña personales.
Una vez al acceder a webmail, se visualiza una pantalla con los diferentes elementos que nos permitirán gestionar nuestros mensajes.
El mensaje Carpeta Actual (current folder) muestra cual de las carpetas listadas es que esta usando por defecto o en ese momento. Después de entrar al sistema, el Carpeta Entrada (Inbox) es el que se mostrará por defecto.
INBOX o ENTRADA.
Bajo el menú horizontal hay un menú vertical donde se pueden seleccionar algunas opciones:
Componer (Compose):
Permite crear y enviar correo, incluye el envío de Adjuntos (attachmentes)
Direcciones (Addresses):
Lleva a la lista de direcciones también conocida como Libreta de Direcciones (address book)
Carpetas (Fólder):
Aquí se realiza toda la manipulación de carpetas. Se pueden crear, borrar, añadir o eliminar carpeta a la lista, editar, renombrar etc.
Opciones (Options):
Permite cambiar los parámetros de visualización del Sistema de correo.
Mensajes:
La lista de mensajes desplegada de una carpeta en particular es conocida como Índice de Mensajes
(Message Index)
Después de pulsar en una carpeta aparece en el marco derecho la lista de mensajes de la carpeta seleccionada. Debajo del menú seleccionado hay una línea que le informa que mail está viendo de manera numérica y cuantos correos en total tiene.
Hay un menú horizontal con tres botones a bajo el mensaje anterior. En el lado izquierdo aparece una lista de los mensajes. A continuación aparece una columna con los siguientes campos: De (From), Fecha (Date),y Asunto (Subject). Estos encabezados separan el mensaje en partes lógicas, De indica quien envía el mensaje o al menos de que dirección de correo nos llego, Fecha muestra el día el cual el email fue enviado.
Asunto, muestra lo que escribió como asunto quien generó el correo.
En la lista de mensajes se podrán notar que los mensajes no leídos aparecen resaltados con negrita mientras que lo mensajes leídos están en texto normal. Cuatro campos forman esta tabla: Una columna para seleccionar el mensaje en la misma línea es objeto de las acciones antes planteadas (mover y borrar), bajo el encabezado De aparece quien envió el mensaje seguidamente aparece la fecha y por último el asunto.
Leyendo un correo:
Pulsar en el asunto de alguno de los correos de la lista. Las direcciones de Web son Vínculos (links) así que podrán pulsar sobre ellas y enviar correos o abrir una página Web. Otra cosa que debe notar son los colores manejados para diferenciar los vínculos. El estándar manejado por el WebMail es el símbolo > antes de cada línea. Un mensaje contestado usando Responder tendrá un color diferente al de Nuevo Correo.
Otro menú horizontal es ahora presentado debajo del menú principal de opciones, esta barra tiene tres secciones. En el lado izquierdo se pueden borrar o regresar. En medio es una navegación directa entre mensajes.
A la derecha son presentadas varias funciones de manejo del correo.
Lista de Mensajes (Message List)
Este vínculo te regresara a la lista de correos, desde donde se llego a esta parte.
Borrar (Delete)
Esta opción borra el mensaje que se está viendo en este momento. Todos los adjuntos que vengan con el correo serán eliminados. Para prevenir la perdida de adjuntos se debe usar la opción de Descargar
Navegación
En la parte de en medio de menú horizontal se encuentran los botones de navegación, previamente se activa si será utilizado texto plano. Haciendo clic sobre esta liga se desplegara el mensaje anterior sin necesidad de regresar a la lista de correos.
Siguiente (Next)
Hacer clic en este vínculo para avanzar al correo inmediatamente posterior al actual. Siguiente será un vínculo activo si existe un siguiente mail o texto si no existen correos posteriores.
Reenviar (Forward)
A la derecha cuando presione vinculo Reenviar, abre la pagina para hacer un correo, conteniendo el mensaje visualizado en la caja de texto, con el siguiente texto: Mensaje Original (Original Message). Los campos para enviar a las direcciones de correos esperan que los llenes. Puede posicionar el cursor en el campo para añadir comentarios al texto ya existente, también se pueden incluir adjuntos en el correo.
Responder (Reply)
Este vínculo regresa un correo nuevo al que origino el mensaje previamente visto, el texto será añadido a la línea de Asunto original y puesto en el campo Asunto. También el texto original del mensaje se añade al cuerpo del correo. El símbolo > es puesto el frente del texto original, También se pueden enviar adjuntos a través de esta opción.
Responder a Todos (Reply All)
Realiza lo mismo que Responder con la diferencia de que la respuesta llegará todas las direcciones involucradas en el correo y no solo a quien lo envió.
Ver todos los encabezados (View all headers)
Esta opción desplegará el encabezado completo de los correos. Esto incluye la ruta que los mensajes tomaron para llegar y un conjunto detallado de información acerca del mismo mensaje.
Bajar este mensaje como un archivo (Download this as a file)
En la parte inferior del correo desplegado encontrarás este vínculo, pulsándolo te permitirá guardar el correo a algún lugar de su disco duro como texto plano. El encabezado se anexara en la parte superior del mensaje.
Archivos Adjuntos (Attachments)
Cualquier adjunto enviado en un correo que se reciba será desplegado en la parte inferior del mensaje como vínculo con una descripción del tipo de archivo de que se trata. Al hacer clic en el nombre del archivo se desplegará el adjunto o se presentara un dialogo de descarga del archivo dependiendo del tipo de archivo.
Enviando Correos:
Haciendo clic en el menú en la opción Componer (Compose) llevara a una nueva página para hacer tu correo. Aquí se encuentran varios campos y botones. Dependiendo de lo que desee realizar algunos de estos campos pueden ser llenados.
Para (To):
Primero vera el campo Para. En este campo debe introducir la dirección de correo electrónico de la persona o personas a quien desee enviar el mensaje.
CC:
El siguiente campo es CC que es una abreviación de Carbon Copy (Copia al Carbón). Si se desea enviar una copia del mensaje, aquí es donde lo puede realizar. Por eso es posible enviarle copias muchos, se pueden tener cuantas gentes se quiera en los campos CC y BBC. El campo A esta reservado a la gente que debe recibir principalmente el mail, mientras que la gente para quien el correo puede ser solamente informativo podría estar en los campos CC y BBC.
BBC:
Es una abreviación de Blind Carbon Copy (Copia al Carbón Ciega). Use este campo para enviar alguna copia del correo sin que los destinatarios en A y CC conozcan acerca de esto.
Asunto (Subject):
Se escribe un encabezado relevante en este campo, el correo electrónico puede ser a gran ahorrador de tiempo y una línea de Asunto adecuado es una buena razón para ello. No debe ser muy largo.
Botón Direcciones (Addresses):
El botón Direcciones abrirá el Libreta de Direcciones (Address Book) después se presenta una ventana de búsqueda. Algunas veces se deberá acceder a la ventana de búsqueda para obtener un resultado. Las funcionalidad del libreta se explica en el capitulo de Direcciones.
Cuerpo de Mensaje (Message Body):
La ventana grande que aparece en blanco es conocida como cuerpo del mensaje y aquí podrá escribir todo lo que desee enviar a las direcciones de correo con quien desea comunicarse.
Adjunto (Attach): Esta ubicado en la parte de inferior de la ventana de Componer, esta característica permite incluir un archivo al correo. El botón browse puede ser presionado para buscar a través de la estructura de directorios y hacer clic en el archivo a incluir. Como alternativa y si se conoce la ruta del archivo puede teclearlo directamente el campo Adjunto. Presionar el botón Agregar (Add) para listar el archivo seleccionado como adjunto y este será mostrado en la parte inferior de la página.
Si el archivo añadido para ser enviado por adjunto no se desea enviar, puede ser seleccionado y posteriormente eliminado presionado botón Borrar (Delete).
Direcciones:
Esta utilería permitirá manejar un directorio con direcciones de correo electrónico, es muy útil cuando se tiene muchas direcciones de correo.
Apodo (Nick Name):
En el campo Apodo puede poner un nombre de algún conocido, es de ayuda para usar palabras nemotécnicas, teclear cualquier palabra que le dé una idea de quien se trata esa dirección electrónica.
Dirección de Correo (Email Address):
Esta debe ser una dirección de correo electrónica completa. Una dirección de correo electrónica consta de tres partes: Primero el identificador, segundo en nombre de correotaap.edu.mx, y tercero un símbolo de @, por ejemplo: Uriel@correotaap.edu.mx, si la dirección de correo electrónico no se teclea correctamente, es muy probable que reciba un correo de error donde notifique que no se pudo enviar el correo a esa dirección.
Información:
Este campo es para poner algunos datos para recordar que persona es, este campo está hecho para ser más largo que el Apodo.
Editar o Borrar (Edit or Delete):
Los botones Editar y Borrar permiten seleccionar una dirección y cambiarle cualquier de los campos arriba vistos, o borrar esta dirección por completo. Solo se permite seleccionar una dirección al mismo tiempo para el botón editar.
Carpetas:
Se pueden almacenar mensajes en diferentes carpetas. Esto es útil si se tiene varios emails y se quieren organizar. La opción de carpetas permita la manipulación de carpetas o subdirectorios.

Instalación y configuración de Spamassassin 

SpamAssassin es una implementación que utiliza un sistema de puntuación, basado sobre algoritmos de tipo genético, para identificar mensajes que pudieran ser sospechosos de ser correo masivo no solicitado, añadiendo cabeceras a los mensajes de modo que pueda ser filtrado por el cliente de correo electrónico o MUA (Mail User Agent).

Instalación a través de yum.

Si dispone de un servidor con CentOS 4 o 5 o bien Red Hat Enterprise Linux 4 o 5, Centos 5.7 (como en este caso),etc, puede utilizar el siguiente mandato:

yum -y install spamassassin procmail
Si se utiliza Sendmail como servidor de correo electrónico, procmail ya debe estar instalado, pues es dependencia del paquete sendmail.

Si se quiere instalar paquetes adicionales para incrementar las capacidades de filtrado de Spamassassin, se pude crear el fichero /etc/yum.repos.d/AL-Server.repo con el siguiente contenido:

[AL-Server] name=AL Server para Enterprise Linux $releasever mirrorlist=http://www.alcancelibre.org/al/el$releasever/al-server gpgcheck=1 gpgkey=http://www.alcancelibre.org/al/AL-RPM-KEY
Hecho lo anterior, será posible instalar los paquetes perl-Mail-SPF, perl-Razor-Agent y pyzor:

yum -y install perl-Mail-SPF perl-Razor-Agent pyzor
Procedimientos

SELinux y el servicio spamasssassin.

Crear nueva política para permitir adjuntar contenido a bitácora de Razor.

A fin de que SELinux permita a spamassassin añadir registros a la bitácora del servicio de Razor, es necesario generar una nueva política.

Se genera un nuevo directorio denominado /usr/share/selinux/packages/spamd:
mkdir /usr/share/selinux/packages/spamd
Cambiarse al directorio /usr/share/selinux/packages/spamd:

cd /usr/share/selinux/packages/spamd
Crear el fichero spamd.te:

vim spamd.te
Añadir el siguiente contenido:

module spamd 1.0;  require {         type spamd_t;         type root_t;         class lnk_file read;         class file { ioctl append }; }  #============= spamd_t ============== allow spamd_t root_t:file { ioctl append };
Lo anterior fue obtenido de la salida del mandato dmesg|grep audit|audit2allow -m spamd>spamd.te en un sistema donde SELinux impedía a spamassassin realizar escritura sobre la bitácora de Razor. En si, define que se permita añadir contenido al fichero /razor-agent.log.

A continuación, se genera un el fichero de módulo para SELinux (spamd.mod) utilizando el mandato checkmodule de la siguiente forma:
checkmodule -M -m -o spamd.mod spamd.te
Luego, se procede a empaquetar el fichero spamd.mod como el fichero spamd.pp:
semodule_package -o spamd.pp -m spamd.mod
Finalmente se vincula el fichero spamd.pp obtenido con las políticas actuales de SELinux y se cargan éstas en el núcleo en ejecución:
semodule -i /usr/share/selinux/packages/spamd/spamd.pp
Una vez cargadas las nuevas políticas, se pueden eliminar los ficheros spamd.te y spamd.mod, pues solo será necesario que exista el fichero binario spamd.pp.

Políticas de SElinux.

A fin de que SELinux permita al servicio spamassassin conectarse a servicios externos, como Razor o Pyzor, utilice el siguiente mandado:
setsebool -P spamassassin_can_network 1
A fin de que SELinux permita a los usuarios del sistema utilizar spamassassin desde sus directorios de inicio, utilice el siguiente mandato:
setsebol -P spamd_enable_home_dirs 1
Si se desea desactivar toda gestión de SELinux sobre el servicio spamassassin, haciendo que todo lo anterior pierda sentido y eliminando la protección que brinda esta implementación, utilice el siguiente mandato:
setsebol -P spamd_disable_trans 1
Iniciar el servicio y añadirlo a los servicios de arranque del sistema.

chkconfig spamassassin on service spamassassin restart
Cabe señalar, que solo es necesario utilizar el servicio spamassassin si el servidor de correo electrónico dispone de una gran cantidad de usuarios, o bien tiene una elevada cantidad de tráfico. Si se dispone de pocos usuarios, es posible utilizar el mandato spamassassin a través del fichero /etc/procmailrc o bien ~/.procmailrc.

Configuración de Procmail

Hay tres formas de utilizar Procmail para hacer uso de Spamassassin.

Utilizando el mandato spamassassin

La forma más simple de utilizar Spamassassin es haciendo uso del mandato spamassassin. Funciona bien solo si se tienen pocos usuarios, pues genera una instancia de éste cada vez que se utiliza o llega un mensaje de correo electrónico al sistema. La siguiente es la configuración recomendada para el fichero /etc/procmail, sí se desea que aplique a todos los usuarios del sistema, o bien el fichero ~/.procmailrc del directorio de inicio de un usuario en particular, sí solo se desea que sea utilizado por algunos usuarios:
:0fw | /usr/bin/spamassassin
Sí se dispone de muchos usuarios, es más conveniente utilizar el mandato spamc, mismo que requiere esté funcionado el servicio spamassassin. La siguiente es la configuración recomendada para el fichero /etc/procmail, sí se desea que aplique a todos los usuarios del sistema, o bien el fichero ~/.procmailrc del directorio de inicio de un usuario en particular, sí solo se desea que sea utilizado por algunos usuarios:
:0fw | /usr/bin/spamc
Todo lo anterior hace que el correo electrónico sea examinado y marcado como Spam si alcanza una cantidad suficiente de puntos. Si se desea realizar un filtrado enviando el correo calificado como Spam hacia una capeta de correo (~/mail/Spam), se puede utilizar lo siguiente:

:0fw | /usr/bin/spamc  # Los mensajes marcados como spam se almacenan en carpeta de spam :0: * ^X-Spam-Status: Yes $HOME/mail/Spam
Configuración del fichero /etc/mail/spamassassin/local.cf.

Se pueden configurar y añadir parámetros con valores en el fichero /etc/mail/spamassassin/local.cf, donde, entre muchos otros, se pueden establecer los siguientes:

required_hits: Se utiliza para establecer la cantidad de puntos acumulados, y asignados por SpamAssassin, en un mensaje para considerar el éste como Spam. El valor predeterminado es 5, acepta decimales y se puede ajustar con un valor inferior o mayor de acuerdo al criterio del administrador. Ejemplo:
4.5report_safe: Determina si el mensaje, si es calificado como spam, se incluye en un adjunto, con el valor 1, o se deja el mensaje tal y como está, con el valor 0. El valor predeterminado es 0.rewrite_headerDefine con que cadena de caracteres se añadirá al mensaje para identificarlo como Spam. El valor predeterminado es [SPAM], y puede cambiarse por lo que considere apropiado el administrador. Ejemplo:whitelist_fromSe utiliza para definir que jamás se considere como Spam los mensajes de correo electrónico cuyo remitente sea un dominio o cuenta de correo electrónico en particular. Se pueden definir varias líneas. Ejemplo:
whitel_from *@u<correotaap.edu.mx
whitelist_from *@correotaap.edu.mx

Se considera Spam un mensaje de correo electrónico emitido por una de estas listas, se puede definir que nunca se considere Spam el correo emitido por dicha lista. Ejemplo: whitelist_to mailman-users@algo.algoblacklist_from

De primera instancia, añada al fichero /etc/mail/spamassassin/local.cf sus direcciones IP locales con el parámetro whitelist_from. Ejemplo:

# These values can be overridden by editing ~/.spamassassin/user_prefs.cf # (see spamassassin(1) for details)  # These should be safe assumptions and allow for simple visual sifting # without risking lost emails.  required_hits 5 report_safe 0 rewrite_header Subject [SPAM] whitelist_from 127.0.01 whitelist_from 192.168.1.91 whitelist_from 201.161.1.226
Sí se utiliza el mandato /usr/bin/spamassassin en el fichero /etc/procmail o ~/.procmailrc, los cambios surten efecto de inmediato. Sí se utiliza el mandato /usr/bin/spamc, para que surtan efecto los cambios se requiere reiniciar el servicio spamassassin:
service spamassassin restart
Incrementando las capacidades de filtrado de Spamassasin

A fin de enriquecer la capacidad de detección de spam de Spamassassin, pueden instalarse paquetes opcionales como perl-Mail-SPF, perl-Razor-Agent. Los tres brindan capacidades adicionales de filtración de spam, descritas más adelante, y pueden contribuir de manera significativa a reducir la cantidad de spam que de otro modo podría pasar por alto Spamassassin.

Para los todos los procedimientos descritos a continuación, se considera que en el servidor de correo electrónico se utiliza como sistema operativo Fedora 13, se tienen instalados los paquetes procmail (requisito del paquete sendmail y opcional para el paquete postfix) y spamassassin y que se tiene configurado al menos lo siguiente en el fichero /etc/procmailrc:

# send mail through spamassassin :0fw | /usr/bin/spamc  # Los mensajes marcados como Spam se almacenan en carpeta ~/mail/Spam :0: * ^X-Spam-Status: Yes $HOME/mail/Spam
Primeramente, y con la finalidad de actualizar el juego de reglas y filtros de Spamassassin, es conveniente utilizar el mandato sa-update de vez en cuando, a lo sumo una o dos veces al mes. Los juegos de reglas y filtros de Spamassassin realmente sufren pocos cambios a lo largo del año y se almacenan en un sub-directorio dentro de /var/lib/spamassassin/. Solo es necesario conservar el sub-directorio con la versión más reciente. El siguiente mandato realizará la consulta y actualización de reglas y filtros de Spamassassin y reiniciará el servicio solamente si se descargó una actualización:

/usr/bin/sa-update && /sbin/service spamassassin restart
Para instalar el conjunto de paquetes que enriquecerán las capacidades de filtrado de Spamassassin, considerando que tiene configurados los depósitos YUM para AL Server de Alcance Libre, ejecute lo siguiente:

yum -y install perl-Mail-SPF perl-Razor-Agent pyzor
Si se utilizan paquetes provenientes de otros depósitos YUM distintos a los de Alcance Libre, el complemento para Pyzor incluido dentro de Spamassassin requerirá además el paquete perl-Digest-SHA:

yum -y install perl-Digest-SHA
A fin de que Spamassassin pueda utilizar los complementos que hacen uso de estas implementaciones, es necesario reiniciar el servicio spamassassin:
/sbin/service spamassassin restart
Perl-Mail-SPF

Perl-Mail-SPF Implementa una protección contra la falsificación de direcciones en el envío de correo electrónico conocida como SPF (Sender Policy Framework o Convenio de Remitentes). Funciona realizando consultas a los servidores DNS en busca del registro TXT para SPF que específica los servidores de correo electrónico autorizados para enviar correo electrónico para un dominio en particular.
Para que un dominio en particular, o bien el propio dominio, sea excluido de este tipo de filtración, requiere contar con un registro similar al siguiente:
dominio.com.           IN        TXT     "v=spf1 mx ptr ~all"
O bien:
dominio.com.           IN        TXT     "v=spf1 mx ptr -all"

Acerca de clamav-milter

Clamav-milter es un componente para añadir (Plug-in) para la biblioteca de filtros de correo (libmilter) de Sendmail, que se encarga de hacer pasar todo el correo entrante, incluyendo todo lo que se reciba a través de rmail/UUCP, a través del ClamAV, que a su vez es un poderoso, y robusto motor, con licenciamiento libre, para la detección de gusanos, troyanos, y virus. Verifica el correo electrónico durante la conexión con el servidor de correo que remite éste ultimo, y lo rechaza automáticamente si éste incluye algún gusanos, troyanos o virus.

Al igual que clamav-milter, el cual es utilizado para la filtración de Spam, representa una excelente alternativa pues tiene un bajo consumo de recursos de sistema, haciéndolo idóneo para servidores con sustento físico obsoleto, o donde otras aplicaciones tiene mayor prioridad en la utilización de recursos de sistema.
Acerca de ClamAV.
ClamAV es un conjunto de herramientas antivirus, libre, y de código fuente abierto, que tiene las siguientes características:
Distribuido bajo los términos de la Licencia Publica General GNU versión 2.
Cumple con las especificaciones de familia de estándares POSIX (Portable Operating System Interface for UNIX o interfaz portable de sistema operativo para Unix).
Exploración rápida.
Detecta más de 720 mil virus, gusanos, y troyanos, incluyendo virus para MS Office.
Capacidad para examinar contenido de archivos ZIP, RAR, Tar, Gzip, Bzip2, MS OLE2, MS Cabinet, MS CHM, y MS SZDD.
Soporte para explorar archivos comprimidos con UPX, FSG, y Petite.
Avanzada herramienta de actualización con soporte para firmas digitales, y consultas basadas sobre DNS.
Equipamiento lógico necesario.
sendmail (previamente configurado)
sendmail-cf
make
m4
clamav
clamav-milter
Creación del usuario para ClamAV.
De modo predeterminado, en los paquetes RPM basados sobre los disponibles para Fedora, el usuario para ClamAV se asigna a través de los mandatos fedora-groupadd, y fedora-useradd el UID, y GID 4 en el sistema. A fin de prevenir un conflicto de UID/GID con otros usuarios, y grupos de sistema, se recomienda crear previamente al grupo, y usuario correspondientes para ClamAV:
groupadd -r clamav
useradd -r -s /sbin/nologin -d /var/lib/clamav -M -c 'Clamav Antivirus' -g clamav clamav
Instalación a través de yum.
Si dispone de un servidor con CentOS 5, y 6 o Red Hat™ Enterprise Linux 5, y 6, puede utilizar el el almacén YUM de Alcance Libre para servidores en producción, descargando el archivo http://www.alcancelibre.org/al/server/AL-Server.repo dentro del directorio /etc/yum.repos.d/:
cd /etc/yum.repos.d/
wget -N http://www.alcancelibre.org/al/server/AL-Server.repo
cd
Este archivo, que se guarda como /etc/yum.repos.d/AL-Server.repo, debe tener el siguiente contenido:
[AL-Server]
name=AL Server para Enterprise Linux $releasever
mirrorlist=http://www.alcancelibre.org/al/el$releasever/al-server
gpgcheck=1
gpgkey=http://www.alcancelibre.org/al/AL-RPM-KEY
La instalación a través del mandato yum requiere utilizar lo siguiente:
yum -y install clamav-milter clamav-milter-sysv clamav-data-empty clamav-update clamav-scanner clamav-scanner-sysvinit
Procedimientos.
SELinux, y el servicio clamav-milter.
CentOS 5, y Red Hat Enterprise Linux 5.
En CentOS 5 ,y Red Hat Enterprise Linux 5 se debe crear una política para permitir al servicio clamd.scan utilizar JIT, y la función execmem().
Genere un nuevo directorio denominado /usr/share/selinux/packages/clamd:
mkdir /usr/share/selinux/packages/clamd
Cambiarse al directorio /usr/share/selinux/packages/clamd:
cd /usr/share/selinux/packages/clamd
wget http://www.alcancelibre.org/linux/secrets/clamd.te
Editar el archivo recién descargado:
vim clamd.te
Asegurarse que tenga el siguiente contenido:
module clamd 1.0;

require {
            type clamd_t;
            class process execmem;
}

#============= clamd_t ==============
allow clamd_t self:process execmem;
Lo anterior fue obtenido de la salida del mandato cat /var/log/audit/audit.log|grep audit|audit2allow -m clamd>clamd.te en un sistema donde SELinux impedía a clamav-milter utilizar la función execmem().
A continuación, se genera un el archivo de módulo para SELinux (clamd.mod) utilizando el mandato checkmodule de la siguiente forma:
checkmodule -M -m -o clamd.mod clamd.te
Luego, se procede a empaquetar el archivo clamd.mod como el archivo clamd.pp:
semodule_package -o clamd.pp -m clamd.mod
Finalmente se vincula el archivo clamd.pp obtenido con las políticas actuales de SELinux, y se cargan éstas en el núcleo en ejecución:
semodule -i /usr/share/selinux/packages/clamd/clamd.pp
Una vez cargadas las nuevas políticas, se pueden eliminar los archivos clamd.te, y clamd.mod, pues solo será necesario que exista el archivo binario clamd.pp.
A fin de evitar realizar todo lo anterior, permitir que el servicio clamd.scan pueda utilizar la función execmem(), y que SELinux impida las conexiones del servicio clamav-milter hacia el servicio clamd.scan, utilice el siguiente mandato:
setsebool -P clamd_disable_trans 1
Para que SELinux permita al servicio clamav-milter funcionar normalmente, y que permita realizar la revisión de correo electrónico, utilice el siguiente mandato:
setsebool -P clamscan_disable_trans 1
Para que SELinux permita al mandato freshclam funcionar normalmente, y que permita actualizar la base de datos de firmas digitales, utilice el siguiente mandato:
setsebool -P freshclam_disable_trans 1
CentOS 6, y Red Hat Enterprise Linux 6.
En CentOS 6, y Red Hat Enterprise Linux 6 solo existe una política a configurar, y es clamd_use_jit, la cual permite al servicio clamd.scan utilizar JIT, y la función execmem().
setsebool -P clamd_use_jit on
Requisitos previos.
Se requiere un servidor de correo con Sendmail, previamente configurado, y funcionando para enviar, y recibir correo electrónico. Para más detalles al respecto, consultar el documento titulado «Configuración básica de Sendmail (Parte I).».
Archivo /etc/mail/sendmail.mc.
Es necesario agregar el siguiente contenido en el archivo /etc/mail/sendmail.mc, justo arriba de la línea MAILER(smtp)dnl.
INPUT_MAIL_FILTER(`clamav', `S=local:/var/run/clamav-milter/clamav.sock, F=, T=S:4m;R:4m')dnl
define(`confINPUT_MAIL_FILTERS', `clamav')dnl
Si se combina con Spamassassin Milter, quedaría del siguiente modo:
INPUT_MAIL_FILTER(`clamav', `S=local:/var/run/clamav-milter/clamav.sock, F=, T=S:4m;R:4m')dnl
INPUT_MAIL_FILTER(`spamassassin', `S=unix:/var/run/spamass-milter/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl
define(`confMILTER_MACROS_CONNECT',`t, b, j, _, , , ')dnl
define(`confMILTER_MACROS_HELO',`s, , , , , ')dnl
define(`confINPUT_MAIL_FILTERS', `spamassassin,clamav')dnl
Configuración.
Clamav-milter depende totalmente de la base de datos de ClamAV. El funcionamiento estándar, que consiste en rechazar correo electrónico que contenga virus, y otros programas malignos, funciona sin necesidad de parámetros adicionales. Las banderas de inicio para clamav-milter están definidas en el archivo /etc/sysconfig/clamav-milter, mismo que permite funcionar normalmente sin necesidad de modificar un solo parámetro, a menos que se necesite especificar alguna opción avanzada definida en la página de manual de clamav-milter.
man clamav-milter
Iniciar, detener, y reiniciar el servicio clamav-milter.
Desde la versión 0.95, ClamAV-milter requiere esté funcionando clamdscan como servicio. Los paquetes de ClamAV incluyen lo necesario a través de clamav-scanner. Solo se requiere agregar al arranque del sistema, y se inicia los servicios clamd.scan, y clamav-milter del siguiente modo, y orden:
chkconfig clamd.scan on
service clamd.scan start
chkconfig clamav-milter on
service clamav-milter start
El archivo /etc/freshclam.conf de los paquetes distribuidos por Alcance Libre ya incluye las modificaciones necesarias para permitir el funcionamiento del mandato freshclam. Sin embargo, si se utilizan paquetes para Fedora, es necesario editar este archivo, y comentar o eliminar la línea 9, que incluye simplemente la palabra inglesa Example, y que de otro mod impediría utilizar el mandato freshclam:
##
## Example config file for freshclam
## Please read the freshclam.conf(5) manual before editing this file.
##


# Comment or remove the line below.
# Example

El archivo /etc/sysconfig/freshclam de los paquetes distribuidos por Alcance Libre ya incluye las modificaciones necesarias para permitir la actualización automática de la base de datos de ClamAV. Si se utilizan paquetes de Fedora, y a fin de mantener actualizada la base de datos de firmas digitales, es necesario editar el archivo /etc/sysconfig/freshclam con el objeto de permitir las actualizaciones automáticas:
### !!!!! REMOVE ME !!!!!!
### REMOVE ME: By default, the freshclam update is disabled to avoid
### REMOVE ME: network access without prior activation
# FRESHCLAM_DELAY=disabled-warn # REMOVE ME
Antes de poner en operación el servidor, es recomendable actualizar manualmente, y de manera inmediata, la base de datos de firmas utilizando el mandato freshclam, desde cualquier terminal como root.
freshclam
Al terminar, considerando que está instalado el paquete sendmail-mc, el cual permite reconfigurar Sendmail a partir del archivo /etc/mail/sendmail.mc, se debe reiniciar el servicio sendmail para que surtan efectos los cambios.
service sendmail restart

 

ANEXOS
Códigos de scripts:
-Inicio de servidor

service httpd start
service spamassassin start
service dovecot start
chkconfig dovecot on
chkconfig spamassassin on
setsebool -P spamassassin_can_network 1
setsebool -P httpd_can_network_connect=1

-Dar de alta usuarios

echo  "Bienvenido  Administrador al script de alta de usuarios"
echo  " "
echo -n "Escribe el nombre del usuario  " ; read NOMBRE
echo " "
echo "el nombre que se introdujo es: $NOMBRE"
useradd -s /sbin/nologin $NOMBRE
echo   " "
echo  "Escribe la contraseña del usuario"
echo  " "
passwd  $NOMBRE
saslpasswd2  $NOMBRE



 CONCLUSIONES

Durante el proceso de desarrollo del servidor de correos se encontraron algunos inconvenientes como son la autentificación de los usuarios algo que es indispensable para que estos puedan mandar correos o recibir correos, debido a que no todos los métodos proporcionados por Sendmail son compatibles con las aplicaciones desarrolladas por Microsoft.

Se ha levantado con éxito el servidor de correo para funcionar con los protocolos POP3, IMAP y SMTP.

La configuración del webmail, ha sido exitosa, se ha manejado como webmail, SquirrelMail.

En apartado de seguridad se ha dejado la configuración avanzada del antivirus clamav y de spamassassin.



BIBLIOGRAFÍA Y FUENTES DE CONSULTA

http://es.wikipedia.org/wiki/Webmail
http://www.alcancelibre.org/staticpages/index.php/como-clamav-milter