Francisco Jos� Montilla, pacopepe@insflug.org

``Infobia''- Como.
Francisco Jos� Montilla, [email protected]
v0.98, 26 de Junio de 1998.

Este documento pretende ser una gu�a r�pida de configuraci�n y puesta
en funcionamiento de procedimientos para conectarse a Internet a
trav�s de Infov�a mediante enlaces ppp. Tambi�n puede aplicarse a
casos de acceso "directo" sin mediar Infov�a, o a trav�s de retenet.
As� mismo, describir� un m�todo tal vez no muy ortodoxo pero s� sen�
cillo y eficiente para recoger y mandar el correo a trav�s de este
tipo de conexiones.
______________________________________________________________________

�ndice General:

1. Introducci�n

2. Requisitos.

2.1. Hardware

2.1.1. M�dems

2.1.2. Configuraci�n del m�dem

2.2. Software

3. Conexiones a trav�s de Infov�a.

3.1. M�todo ``A''

3.2. M�todo ``B''

4. Conexiones sin mediar Infov�a.

5. Gesti�n de Correo de Internet.

5.1. M�todo ``A'' o f�cil y g�indosero ;-).

5.2. M�todo ``B''.

5.2.1. Requisitos

5.2.2. Configuraci�n del sistema.

5.2.2.1. popclient

5.2.2.2. fetchmail

5.2.2.3. sendmail

5.2.3. C�mo escribir

5.2.4. Procedimiento.

5.3. M�todo ``C''.

6. Agradecimientos

7. Copyright

8. Anexo: El INSFLUG
______________________________________________________________________

1. Introducci�n

En este documento intentar� explicar un par de m�todos para establecer
conexiones ppp a servidores de acceso a Internet, as� como un sistema
para recoger y enviar el correo a la cuenta del Servidor con el que se
establece la conexi�n.

No soy ni pretendo ser un gur� en LiNUX. Lo que aqu� se describe lo he
extra�do de correo que generosamente me enviaron en su momento
usuarios de Fidonet e Internet, y he probado, experimentado, y buscado
la forma m�s sencilla y f�cil de hacerlo, ya que me consta que una de
las cosas que m�s ilusi�n hace a los reci�n llegados es precisamente
conectarse a Internet a trav�s de LiNUX --- cosa que por cierto, se
realiza mucho m�s eficientemente en este sistema operativo que en
otros, al obtenerse soporte directo del n�cleo o kernel del sistema,
sin tener que recurrir a ``chapuzas'' para ello.---

La motivaci�n por tanto, que me ha llevado a hacer este documento ha
sido el ponerlo a disposici�n de los dem�s (y por que ya estaba
cansado de forwardear una y otra vez los mismos mensajes que
previamente hab�a recibido ;-) y como agradecimiento y granito de
arena a toda la comunidad LiNUX.

Si encuentra cualquier error de concepto, u opina que el m�todo se
puede mejorar, o simplemente quiere hacer alguna aportaci�n a este
documento, no dude en ponerse en contacto conmigo. Estar� encantado de
saberlo.

2. Requisitos.

2.1. Hardware

2.1.1. M�dems

Est� claro: :) adem�s del ordenador, un m�dem. En cuanto al tipo de
m�dem, siempre he recomendado lo mismo: Externo. Un m�dem interno s�lo
tiene raz�n de ser en la poco probable situaci�n de no poseer UARTs
r�pidas (16550A). Si este no es su caso, la mejor apuesta ser� siempre
(hablando de m�dems por RTC (-- Red Telef�nica Conmutada, en oposici�n
a la reciente RDSI--) ) un m�dem externo, de cuanta mejor reputaci�n
mejor; no me gusta entrar en marcas y modelos, pero s� que esta es un
pregunta frecuente en aquellos que se disponen a actualizar o adquirir
uno, por lo que har� una excepci�n.

Las marcas aconsejables son las de siempre: USR, en sus modelos
Sportster o Courier, siempre que no sean winmodems , Supra
(actualmente Diamond) en su modelo Fax, Zyxel, etc. Siempre y cuando
no sean winmodems. Recientemente ha pasado uno por mis manos de
fabricaci�n nacional, cuyo nombre era Vayris (o algo as�), que no
estaba nada mal. En cuanto a velocidades, comprar menos de 33.6 Kbps
hoy en d�a es un desperdicio.

Una cosa s� que est� muy clara en todo caso: rehuir como de la peste
de los denominados winmodems; �stos no poseen chip inteligente, y
realizan sus funciones l�gicas a trav�s de software, que normalmente
no est� disponible (siendo poco probable que alguna vez lo est�, dada
la escasa calidad de dicho "hardware") en LiNUX y otros SOs.

Modelos y Marcas conocidos de �stos son:

� USR Sportster Winmodem

� IBM Aptiva MWAVE

� Sitre Super PC336

� Zoltrix VoiceMail 33600 Win HSP

� M�dems con chip Rockwell RPI

� Tambi�n he recibido �ltimamente frecuentes preguntas de
propietarios de m�dems de chip PCTEL HSP, que desafortunadamente,
no podr�n beneficiarse de las capacidades de conexi�n de Linux,
debido a que pertenece a la funesta categor�a de winmodems.

Resumiendo: NADA de winmodems, a ser posible NO internos, y nada de
PnP.

2.1.2. Configuraci�n del m�dem

Un problema frecuente es el hecho de que ``el m�dem no marca''. En el
90% de los casos, y asumiendo que no son winmodems, se debe a estar
intentando que LiNUX comparta IRQ, bien por estar usando un m�dem
interno, en la t�pica configuraci�n DOS COM4, irq 3, bien por tener la
IRQ asignada a ese puerto ocupada con otro dispositivo.

Linux NO puede compartir IRQs, y esto no es un fallo, es una
necesidad. As� pues, la estrategia es:

1. Configurar el m�dem para que su puerto interno pase a ser el COM2
(/dev/ttyS1 en Linux); la configuraci�n en Linux por defecto para
este puerto es irq 3, direcci�n base 0x02f8. As� pues, si el m�dem
admite ser configurado por jumpers de tal modo, nos habremos
ahorrado trabajo. No olvidar desactivar el COM2 de la Placa madre.

2. Si lo anterior no puede hacerse, pero el m�dem admite (por jumpers,
nada de PnP!) al menos cambiar la IRQ que usar� el puerto interno
del m�dem, asignarle una IRQ distinta de la 3 o 4. Si se tiene
tarjeta de sonido, posiblemente �sta ocupe la IRQ 5, y la 7 es del
LPT1 aunque no se emplee si utilizamos el driver de polling del
n�cleo. La 9 est� en cascada con la 2, as� que una apuesta segura
son las IRQs de la 10 a la 12.

3. Si esto tampoco puede hacerse, la estrategia a seguir es desactivar
el COM2 en la placa base, mediante los jumpers o como suele ser
posible con las placas Pentium, mediante la BIOS, a fin de dejar la
IRQ 3 libre, que ser� usada por defecto por el puerto interno del
m�dem (COM4); o bien cambiar la IRQ utilizada por el COM2 de la
placa, a fin de que pueda ser usada por el puerto interno del
m�dem.

4. Una vez nos hemos asegurado de que el hardware est� empleando los
recursos que debe, hemos de dec�rselo al software. Si hemos
conseguido poner el puerto interno del m�dem como COM2 (�y hemos
desactivado el de la placa!), no hay m�s que hacer, todo lo que
sigue est� pensado para ese caso. Una respuesta t�pica del comando
setserial ser�a:

~]# setserial /dev/ttyS1
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3

5. En caso de haber cambiado la IRQ a utilizar por el puerto interno
del m�dem, (COM4) deberemos dec�rselo a Linux cada vez que lo
arranquemos (incluyendo el comando en el script de arranque
/etc/rc.serial, si nuestra distribuci�n es una Slackware, o en
/etc/rc.d/rc.serial si es RedHat). Si le hemos puesto en la IRQ 10,
y tenemos un m�dem superior a 22.8 Kbps, el comando (o la l�nea a
poner en dicho script) ser�a:

setserial -v /dev/ttyS3 irq 10 spd_vhi

Con el cual le indicamos que el COM4 (/dev/ttyS3) usar� la IRQ 10, y
que bloquee el puerto a alta velocidad (SPeeD Very HIgh).

El par�metro -v har� que el comando devuelva la informaci�n de config�
uraci�n final del puerto.

Si se contin�a com problemas, e incluso si no los tiene, es
recomendable leer el Serie-Como, disponible en
http://www.insflug.org o en el directorio de traducciones
(pub/Linux/docs/HOWTO/translations/es) disponible en cualquier mirror
de sunsite.

2.2. Software

B�sicamente, lo �nico necesario es tener soporte ppp ya por parte del
n�cleo o kernel o por m�dulos, en cuyo caso son necesarios tener
cargados shlc.o y ppp.o, mediante por ejemplo la orden:

modprobe ppp

existen m�todos m�s modernos como kerneld y otros en los que la carga
se automatiza al llamar al otro requisito, el ``demonio'' o daemon
pppd, que suele instalarse en un paquete aparte. T�ngase en cuenta que
si se emplea un kernel posterior al 1.3.95 ha de utilizarse una
versi�n de pppd posterior a la 2.2.0e. Para el kernel 1.2.13 vale a
partir de la 2.1.2d (-- Esto obviamente est� "obsoleto".--) .

Los fuentes de distribuci�n del kernel contienen un m�dulo de
compresi�n ppp, bsd_comp.o, que por problemas de copyright no puede
ser compilado sino es como m�dulo, ni cargado autom�ticamente por
kerneld. El uso de este m�dulo mejora el rendimiento de la conexi�n,
especialmente en lo referente a transferencia de ficheros. Para
evitarnos el tener que cargarlo ``a mano'' tras shlc.o y ppp.o,
podemos crear un alias para pppd:

alias pppd="pppd; modprobe bsd_comp"

que incluiremos en el fichero de personalizaci�n correspondiente, p.
ej. /etc/bashrc si queremos que afecte a todos los usuarios
globalmente, o ~/.bash_profile para cada uno de los usuarios de RedHat
o ~/.bashrc para Slackware.

Ciertamente, no es una soluci�n muy elegante, pero funciona :-).

Para conectarse a un ISP (Internet Service Provider, o Proveedor de
Acceso a Internet) a trav�s de nuestra querid�sima Infov�a, pueden
utilizarse los m�todos que a continuaci�n describo:

3. Conexiones a trav�s de Infov�a.

3.1. M�todo ``A''

1. Fichero /etc/resolv.conf.
corriente, en que obtengamos nuestra direcci�n por asignaci�n
din�mica, se ha de conocer la direcci�n en notaci�n decimal del
servidor de nombres o nameserver del ISP que nos proporciona
acceso. Esta informaci�n se la ha de proporcionar su ISP, y
generalmente ser� de la forma 194.xxx.yyy.zzz. (En la posici�n zzz
generalmente suele emplearse el 2)

El dato restante es el nombre de dominio de su servidor, que ser�
el mismo que aparezca en su direcci�n de correo email, es decir,
todo lo que se encuentra tras la arroba. En mi caso,
[email protected] ser�a por tanto insflug.org.

Una vez conocemos estos datos, editamos (con vi, por ejemplo) el
fichero /etc/resolv.conf, de modo que a�adimos:
/etc/resolv.conf

domain insflug.org
nameserver 194.xxx.yyy.zzz

2. Elaboramos el fichero /etc/ppp/options (S�lo con versiones de pppd
iguales o inferiores a la 2.2.x)

connect /etc/ppp/infovia
crtscts
modem
passive
+ua /etc/ppp/infoviappp # Ojo en pppd version 2.3.x, opcion no valida
noipdefault
debug
defaultroute
asyncmap a0000
/dev/modem # (Este fichero es un enlace a /dev/ttySX)
38400 # (Siempre que su modem soporte esa velocidad)

Nota: Si nuestro pppd es de version 2.2.3 o superior, deberemos modi�
ficar el fichero /etc/ppp/options, suprimiendo la l�nea +ua
/etc/ppp/infoviappp y a�adiendo:

+pap
user id@dominio

As�, utilizar� en su lugar el fichero /etc/ppp/pap-secrets para la
autentificaci�n:

infovia * infovia
id@dominio dominio clave

Para m�s informaci�n sobre pap-secrets ver apartado correspondiente de
la secci�n ``''.

/dev/ttySX es el fichero de dispositivo correspondiente al puerto
donde tengamos el m�dem, generalmente, el COM2 si lo vemos desde
msdos, o /dev/ttyS1 en LiNUX. En caso de que en su sistema no exista
/dev/modem, puede crear un enlace o symlink al puerto donde se encuen�
tra el m�dem, con la orden:

ln -s /dev/ttyS1 /dev/modem

Siempre que el COM2 sea el que est� usando el m�dem. Puede por
supuesto incluir directamente /dev/ttyS1 en lugar de /dev/modem en el
anterior script si lo prefiere.

Para los usuarios de Intercom o bankinter, los ficheros options
ser�an:

� Intercom

connect /etc/ppp/infovia
crtscts
modem
passive
noipdefault
ipcp-accept-local
ipcp-accept-remote
debug
defaultroute
lock
asyncmap a0000
/dev/modem
38400

� Bankinter

connect /etc/ppp/infovia
crtscts
modem
defaultroute
lock
/dev/modem
38400

Los permisos del anterior script pueden ser 640 en forma octal o

-rw-r----- 1 root root

lo cual podemos conseguir con la orden:

chmod 640 /etc/ppp/options

3. Fichero /etc/ppp/infovia

#!/bin/sh
/usr/sbin/chat -v "" atdt055 CONNECT ""

Este fichero debe de hacerse ejecutable, con la orden por ejemplo:
chmod 744 /etc/ppp/infovia

4. Fichero /etc/ppp/infoviappp

su_login
su_password

su_login quiere decir nombre@proveedor, en mi caso pacopepe@insflug.
Este fichero es especialmente delicado, ya que contiene la contrase�a
o password de acceso al ISP, por lo que conviene tener cuidado con sus
permisos; yo no soy un gur� en eso, si alguien con m�s experiencia me
recomienda otro tipo de permisos, se lo agradecer�, yo por ahora lo
tengo como 640, por lo que con la orden

chmod 640 /etc/ppp/infoviappp

quedar�an establecidos los permisos.

5. Ejecutar, como root, pppd. Al momento se escuchar� marcar al m�dem,
y una vez establecida la conexi�n, se escuchar� actividad por parte
del disco duro; tambi�n, en el caso de poseer un m�dem externo, se
observar� las luces de cd, sd y tr encendidas o parpadeando; en
caso de ser interno, podemos constatar que la conexi�n est�
establecida correctamente, y que por tanto, el dispositivo ppp0 ha
sido creado, con una orden como ``top'' o ``ps'' en la que se
observar� como proceso activo.

Tambi�n podemos observar el proceso de conexi�n conmutando a otra
VC, y tecleando la orden

tail -f /var/log/messages

lo cual nos mostrar�, en caso de problemas, los fallos que est�n ocur�
riendo. Un proceso de conexi�n normal aparecer�a como:

May 23 01:51:00 beastie pppd[4485]: pppd 2.1.2 started by root, uid 0
May 23 01:51:00 beastie pppd[4488]: Connecting with /etc/ppp/infovia
May 23 01:51:02 beastie chat[4490]: send (atdt055^M)
May 23 01:51:02 beastie chat[4490]: expect (CONNECT)
May 23 01:51:23 beastie chat[4490]: atdt055^M^M
May 23 01:51:23 beastie chat[4490]: CONNECT -- got it
May 23 01:51:23 beastie chat[4490]: send (^M)
May 23 01:51:23 beastie pppd[4488]: Connected...
May 23 01:51:24 beastie kernel: ppp: channel ppp0 mtu = 1500, mru = 1500
May 23 01:51:24 beastie kernel: ppp: channel ppp0 open
May 23 01:51:24 beastie pppd[4488]: set kernel debugging level to 0
May 23 01:51:24 beastie pppd[4488]: Using interface ppp0
May 23 01:51:24 beastie pppd[4488]: Connect: ppp0 <--> /dev/modem
[...]
May 23 01:51:25 beastie pppd[4488]: ipcp: received ADDR
May 23 01:51:25 beastie pppd[4488]: (172.16.1.1)
May 23 01:51:25 beastie pppd[4488]: (ACK)
May 23 01:51:25 beastie pppd[4488]: ipcp: returning Configure-ACK
May 23 01:51:25 beastie pppd[4488]: fsm_sdata(IPCP): Sent code 2, id 1.
May 23 01:51:25 beastie pppd[4488]: fsm_rconfnakrej(IPCP): Rcvd id 1.
May 23 01:51:25 beastie pppd[4488]: local IP address 194.179.123.229
May 23 01:51:25 beastie pppd[4488]: fsm_sdata(IPCP): Sent code 1, id 2.
May 23 01:51:25 beastie pppd[4488]: IPCP: sending Configure-Request, id 2
May 23 01:51:25 beastie pppd[4488]: fsm_rconfack(IPCP): Rcvd id 2.
May 23 01:51:25 beastie pppd[4488]: ipcp: up
May 23 01:51:25 beastie pppd[4488]: local IP address 194.179.123.229
May 23 01:51:25 beastie pppd[4488]: remote IP address 172.16.1.1

6. Para finalizar la conexi�n podemos emplear el script que suele
acompa�ar al paquete pppd, ppp-off, o bien ``matar'' directamente
el proceso una vez identificado su PID con ps; para ello, si una
vez ejecutado ps observamos la respuesta:

PID TTY STAT TIME COMMAND
58 v01 S 0:01 -bash
[...]
353 v03 R 1:12 pppd
[...]

la orden

kill -9 353

matar� el proceso. No obstante, algunas personas han experimentado
``cuelgues'' de sus servidores si no finalizan la conexi�n con m�todos
``civilizados'' como el script ppp-off.

Uno puede hacerse un ppp-off rudimentario mediante el comando:

killall pppd

Si se quiere saber m�s sobre los comandos de este script, consulte el
comando chat y la documentaci�n sobre pppd.

3.2. M�todo ``B''

El mismo que el empleado para conectar sin mediar Infov�a, descrito en
la secci�n ``Conexiones sin mediar Infov�a.'' a excepci�n de:

1. Fichero /etc/ppp/pap-secrets, que quedar�a as�:

infovia * infovia
id@dominio * su_password

donde id@dominio ser�a, en mi caso, pacopepe@insflug, es decir, su
direcci�n email sin el .es del dominio perteneciente a Espa�a.

Este fichero es especialmente sensible por contener el password, por
lo que se aplica lo dicho anteriormente para el fichero
/etc/ppp/infoviappp en la secci�n ``M�todo ``B'''', punto n�mero 4.

Como se puede observar, lo �nico que var�a es que se a�ade la l�nea
referente a Infov�a.

2. Cambiar la variable NUMERO del script /usr/local/bin/infovia por
055, como corresponde a Infov�a.

4. Conexiones sin mediar Infov�a.

En el caso de que tengamos acceso directo a un servidor, los scripts y
ficheros necesarios ser�an los siguientes:

1. Script /usr/local/bin/infovia

#!/bin/sh

LOCKDIR=/var/spool/uucp
DEVICE=modem
NUMERO=numero_del_Proveedor

if [ -f $LOCKDIR/LCK..$DEVICE ]
then
echo /dev/$DEVICE "El modem esta ocupado."
exit 1
fi

/usr/lib/ppp/fix-cua $DEVICE
(
stty 38400 -tostop crtscts

if /usr/lib/ppp/chat ABORT "NO CARRIER" ABORT BUSY "" ATZ0 OK ATDT$NUMERO CONNECT ""
then
pppd /dev/$DEVICE 38400 crtscts modem lock mtu 1500 defaultroute noipdefault user id@dominio
sleep 10
route add default ppp0
exit 0
else
echo "La llamada PPP ha fallado." 1>&2
exit 1
fi
) < /dev/$DEVICE > /dev/$DEVICE

en donde:

� En la variable NUMERO= deber� reflejar el n�mero de su Proveedor.

� En id@dominio tendr� que poner su direcci�n email sin el

Este script ha de ser ejecutable, por lo que tenemos que otorgarle
permisos de ejecuci�n, con una orden como por ejemplo:

chmod 750 /usr/local/bin/infovia

A decir verdad, este script lo puede colocar donde quiera, si bien
/usr/local/bin/infovia ser�a la situaci�n m�s ``est�ndar''.

2. Fichero /etc/ppp/pap-secrets

id@dominio * su_password

nuevamente, se aplica lo dicho en la secci�n ``M�todo ``B''''.

3. Fichero /etc/resolv.conf
aqu� se aplica lo mismo que en la secci�n ``M�todo ``A'''' punto
n�mero 1.

4. A partir de aqu�, se aplica lo mismo que en la secci�n ``M�todo
``A'''', punto 5, a excepci�n de que por supuesto, no ha de
ejecutarse pppd, ya que lo hacemos ejecutando el script
/usr/local/bin/infovia.

5. ATENCI�N usuarios de RedHat
Si el sistema LiNUX que tiene instalado pertenece a una
distribuci�n RedHat, deber� tener en cuenta lo siguiente:

� En el script /usr/local/bin/infovia deber� modificarse las l�neas
13 y 17, por:

[...]
/usr/lib/ppp/fix-cua $DEVICE --> /usr/sbin/fix-cua $DEVICE
[...]
if /usr/lib/ppp/chat... --> if /usr/sbin/chat...
[...]

ya que la localizaci�n de dichos ficheros en RedHat est� en esos
directorios.

� Para ciertos programas que hacen uso del m�dem, como el binkley, y
otros, resulta inocuo y muy conveniente crear el enlace o symlink
siguiente:

ln -s /var/spool /usr

Para obtener una visi�n m�s completa y detallada en lo que a ppp se
refiere, recomiendo hacerse con la traducci�n del PPP-Como, realizada
por Rafael Agundo, [email protected]. En la secci�n ``Insflug'' se
detallan los servidores donde obtenerlo.

5. Gesti�n de Correo de Internet.

A continuaci�n describir� dos m�todos para gestionar el correo en el
caso que nos ocupa, una m�quina aislada, con conexiones espor�dicas a
su Servidor de Acceso a Internet. El m�todo B es desde luego, poco
ortodoxo y se puede mejorar mucho, por lo que una colaboraci�n en lo
que a configuraciones ``ideales'' de red de este tipo de m�quinas ser�
harto agradecida.

5.1. M�todo ``A'' o f�cil y g�indosero ;-).

Instalar, usar y configurar Netscape, Mosaic u otro navegador con
capacidad de gestionar correo, news, etc.

Como me consta que la inmensa mayor�a de los que empiezan a usar Linux
o bien no poseen una cantidad desmesurada de RAM, ni les sobra disco
duro como para sacrificar m�s de 6 megas en el Netscape, y adem�s
desean aprender a usar m�todos m�s *nixeros y eficaces de gesti�n de
correo, propongo el siguiente (m�s f�cil de configurar incluso que el
netscape) m�todo:

5.2. M�todo ``B''.

5.2.1. Requisitos

1. Popclient. Se precisa instalar el paquete Popclient. En caso de que
la versi�n de �ste use perl, se deber� instalar este �ltimo
tambi�n.

2. popclient se ha quedado desfasado �ltimamente, siendo fetchmail el
que m�s se emplea ahora por ser m�s seguro.

3. Sendmail+IDA. No, no os asust�is ;-) El sendmail+IDA, que viene en
la inmensa mayor�a de las distribuciones, lo tendremos configurado
con editar dos l�neas.

5.2.2. Configuraci�n del sistema.

1. Crear una cuenta en la m�quina con el mismo identificativo que se
tenga en el Proveedor. Por ejemplo, mi identificativo o login en mi
ISP es pacopepe, cosa f�cilmente deducible debido a mi direcci�n de
correo email; por tanto, creo una cuenta en el sistema con login
pacopepe, con el comando adduser: (por supuesto, hay que hacerlo
como root).

Supongamos el login ``probancio'':

/home/linuxdoc-sgml-1.5/working]# adduser probancio

Looking for first available UID... 502
Looking for first available GID... 502

Adding login: probancio...done.
Creating home directory: /home/probancio...done.
Creating mailbox: /var/spool/mail/probancio...done.

Don't forget to set the password.

ahora, le asignamos un password:

/home/linuxdoc-sgml-1.5/working]# passwd probancio
Changing password for probancio
Enter an empty password to quit.
New password (? for help):
New password (again):
Password changed for probancio

y tenemos creada su cuenta.

5.2.2.1. popclient

1. Ahora creamos el siguiente script, que ser� el que ejecutemos para
recoger el correo, al que llamamos, por ejemplo,

#!/bin/sh
#
# getmail, para bajarnos el correo...
#
PATH=/bin:/usr/bin:/usr/local/bin
echo Bajando el correo.....
popclient -3 -u <nombre_usuario> -p <password_del_ISP> -o /var/spool/mail/login <servidor_POP>

Dado que este fichero contiene datos delicados como las passwords del
ISP, lo protegeremos d�ndole los permisos adecuados (700 es lo
recomendable).

Donde en:

<nombre_usuario>
pondremos nuestro identificativo, en mi caso, pacopepe.

<password_del_ISP>
Pues exactamente eso, la clave con la que accede a su servidor.

<...login>
Como se observar� tras crear la cuenta que describimos
anteriormente, en /var/spool/mail/ se crear� un fichero de igual
nombre que el login de dicho usuario; en el caso supuesto
anterior, probancio, este fichero ser�a
/var/spool/mail/probancio.

<servidor_POP>
Aqu� ha de ponerse la direcci�n de vuestro servidor POP; en mi
caso (y suele ser com�n) pop03.insflug.org.

Nota: Al elaborar el script prescindiremos de los signos ``<'' y
``>''; en el ejemplo est�n simplemente para resaltar los par�metros a
completar.

Juan Manuel Villar Navarro [email protected] apunta que en las
versiones 3.xx del popclient no se puede dar por l�nea de comandos la
contrase�a del ISP, (con -p) para ello ha de usarse el fichero
~/.poprc, en el que podemos definir otros par�metros de compor�
tamiento, como el que mantenga los mensajes en el servidor (keep) en
caso de que estemos de pruebas, o por cualquier otra raz�n.

I�igo Gonz�lez [email protected] recomienda usar versiones del popclient
superiores a la 3.0b6, adem�s de sugerir el uso de un programa fil�
trador de correo como procmail, para lo que deberemos a�adir al
comando getmail el par�metro -m procmail.

5.2.2.2. fetchmail

En caso de usar fetchmail, un cliente muy potente y cuya documentaci�n
es bastante clara y precisa, la configuraci�n personal se almacena en
el fichero del directorio personal del usuario, ~/.fetchmailrc.

Un ejemplo del mismo:

poll host-servidor-pop proto pop3 user usuario password pass_usuario is usuario here;

donde

host-servidor-pop
ser�a el nombre del la m�quina servidora de correo v�a pop del
proveedor que utilicemos;

pop3
ser�a el protocolo a emplear, ya que fetchmail soporta otros
tambi�n, como pop2 (obsoleto) imap2bis imap4 y apop y kpop.

seguidamente, le otorgaremos permisos de lectura/escritura �nicamente
para el propietario, hecho muy importante, ya que de lo contrario
podr�an ser accesibles las contrase�as, e incluso el programa se
negar�a a funcionar:

chmod 600 .fetchmailrc

fetchmail ofrece una serie de prestaciones adicionales, como
temporizaci�n, reenv�o, funcionamiento en modo daemon etc... Es un
cliente muy potente y recomendable en cuanto a seguridad se refiere.

En caso de emplearlo, no har�a falta el script getmail, bastar�a con
invocar a fetchmail a secas.

5.2.2.3. sendmail

1. Modificaci�n de la llamada al demonio sendmail, hecha normalmente
en el arranque desde el script /etc/rc.d/init.d/sendmail.init,
(RedHat) o /etc/rc.d/rc.M (Slackware) buscar la l�nea que dice algo
as� como daemon sendmail .... en RedHat, o /usr/sbin/sendmail -bd
-q 15m en Slackware, y modificarla, edit�ndola para que quede:

[...]
.... sendmail -bd -q2d
[...]

Esto lo que hace es que sendmail no intente continuamente mandar el
correo que haya en la cola para salir, o en spool, ya que lo haremos
nosotros manualmente.

Si no hacemos esto veremos que al enviar un email estando desconecta�
dos, el programa donde estemos (el pine, por ejemplo) se quedar�
``congelado'' un buen rato, debido a que sendmail intentar� enviar
inmediatamente el email, y no encontrar� el destino, hasta que final�
mente se produzca un timeout.

2. Modificaci�n de /etc/sendmail.cf. Aqu� buscaremos una l�nea que
comienza por DS:

# "Smart" relay host (may be null)
# DS

y la modificaremos para que quede reflejado nuestro servidor SMTP o de
correo saliente: (en mi caso, smtp.insflug.org):

# "Smart" relay host (may be null)
DSsmtp.insflug.org

ahora buscaremos otra que comienza por DM:

# who I masquerade as (null for no masquerading)
# DM

y la modificamos para que refleje el dominio de nuestra direcci�n de
correo, en mi caso insflug.org:

# who I masquerade as (null for no masquerading)
DMinsflug.org

Con esto, lo que hemos hecho es b�sicamente, "enmascarar" nuestra
direcci�n en la m�quina propia; supongamos que nuestra m�quina se
llama beastie.insflug.org y enviamos un mensaje sin la modificaci�n
anterior; el mensaje llegar� correctamente a su destino, pero no podr�
ser respondido, ya que la direcci�n de retorno no existir�, al figurar
la de nuestra propia m�quina, que en nuestro caso ficticio ser�a
[email protected], en lugar de la de la cuenta de nuestro
ISP, que es [email protected].

Realmente, lo �nico que enmascaramos es el dominio, de ah� la necesi�
dad de crear una cuenta en nuestra m�quina con el mismo login que en
nuestro ISP (probancio en este caso); la l�nea DS... hace que sendmail
rute todos los mensajes salientes hacia internet a trav�s de nuestro
servidor SMTP, que hace de servidor de relevo hacia internet.
Podr�amos no decirle nada, y dejar que se encargara de contactar y
enviar directamente con el servidor de correo entrante de cada
direcci�n, pero eso har�a m�s lento el env�o de los correo, adem�s de
que es mucho m�s r�pida la transferencia con nuestro ISP, al no tener
que salir a internet siquiera.

DM... cambia los from de nuestros mensajes por nuestra verdadera
direcci�n en el ISP.

5.2.3. C�mo escribir

Para responder o escribir nuestro correo podremos usar cualquier
programa escritor de correo, los simples como mail o mailx, un poco
m�s completos como el facil�simo elm, o pine, el modo de correo del
vers�til emacs, etc... recordando siempre hacer uso de estos programas
desde la cuenta que creamos para tal fin (la de probancio en nuestro
caso ficticio).

5.2.4. Procedimiento.

1. Establecer la conexi�n PPP con nuestro servidor, con cualquiera de
los m�todos descritos en las secciones ``Conexiones sin mediar
Infov�a'' o ``Conexiones a trav�s de Infov�a''. Esto se har�
normalmente como root.

2. Ejecutar el script getmail en caso de que queramos recoger el
correo; en caso de querer mandar el correo pendiente por salir,
teclear la orden:

sendmail -q

que ordenar� a sendmail a enviar el correo. (el par�metro -q viene de
queue o la ``cola'' de correo pendiente por salir).
Por supuesto, los procedimientos para establecer la conexi�n y
recoger/mandar correo se pueden automatizar escribiendo scripts
sencillos, pero eso lo dejo ya al gusto y seg�n las circunstancias de
cada uno. Estar� encantado de recibirlos, a fin de incluirlos en la
pr�xima versi�n de este COMO.

5.3. M�todo ``C''.

Empleando clientes de correo capaces de enmascarar al usuario/dominio,
podemos prescindir de la fase de configuraci�n del enmascaramiento de
dominio del sendmail. El cliente de correo (MUA (-- Mail User
Application, aplicaci�n de gesti�n de correo a nivel usuario)--) mutt,
puede hacer esto, a nivel tanto de dominio como de usuario, entre
otras muchas prestaciones que har�n las delicias de los amantes del
modo texto: gesti�n pgp integrada, threads, color... Un cliente muy
recomendable. Su servidor de ftp primario es:

ftp://ftp.cs.hmc.edu/pub/me/mutt

Es posible tambi�n prescindir de la ``chapucilla'' de tener que
emplear el mismo usuario que en el proveedor empleando un MTA (-- Mail
Tranfer Agent, Agente de Gesti�n de transferencia de Correo--) de
configuraci�n m�s flexible y c�moda que sendmail, como el prometedor
qmail, f�cilmente obtenible en Internet, que adem�s ofrece muchas
otras prestaciones, sin la fragilidad en cuanto a seguridad de
sendmail, y menos exigente en cuanto a recursos, lo que le hace ideal
para listas de correo..

6. Agradecimientos

Mi m�s sincero agradecimiento a todos los contertulios de R34.LINUX, y
a los de la Lista de correo de RedHat, as� como a Jos� L. Navarro
Sim�n, 2:345/102.36 y Miguel Cruz por los scripts a trav�s de infov�a,
a Urko Lusa, 2:344/25.8 por los de acceso directo, y a Eric S.
Pulley, [email protected] por las explicaciones con lo relacionado con
el correo.

A Carlos Terr�n por sus correcciones, a Juan Manuel Villar Navarro
[email protected] por sus apuntes sobre popmail, y a I�igo
Gonz�lez [email protected] por las sugerencias sobre procmail, y a Jes�s
Fuentes Saavedra [email protected] por el detalle del
bsd_comp, y tant�simas otras cosas...

A Antonio Verdejo Garc�a aka wait_man, [email protected] por su
lista de winmodems y tantas otras cr�ticas y sugerencias.

7. Copyright

Este documento es Copyright (c)1996 de Francisco Jos� Montilla. Este
trabajo puede ser reproducido en su totalidad o en parte, tanto de
forma impresa como electr�nica, sujeto a las siguientes condiciones:

1. La notificaci�n del copyright y esta licencia debe preservarse
completa en todas las copias, tanto completas como parciales.

2. Cualquier traducci�n o trabajo derivado debe de ser aprobado por el
autor por escrito antes de su distribuci�n.

3. Si se distribuye el Trabajo parcialmente, deben de incluirse
instrucciones para poder obtener la versi�n completa (en forma
impresa o electr�nica), as� como los medios para conseguirla.

4. Pueden ser reproducidas peque�as porciones como ilustraciones para
revistas o citas para otros trabajos sin esta notificaci�n de
permiso si se cita apropiadamente su procedencia.

8. Anexo: El INSFLUG

El INSFLUG forma parte del grupo internacional Linux Documentation
Project, encarg�ndose de las traducciones al castellano de los Howtos
(Comos), as� como la producci�n de documentos originales en aquellos
casos en los que no existe an�logo en ingl�s.

En el INSFLUG se orienta preferentemente a la traducci�n de documentos
breves, como los COMOs y PUFs (Preguntas de Uso Frecuente, las FAQs.
:) ), etc.

Dir�jase a la sede del INSFLUG para m�s informaci�n al respecto.

En la sede del INSFLUG encontrar� siempre las �ltimas versiones de las
traducciones: www.insflug.org. Aseg�rese de comprobar cu�l es la
�ltima versi�n disponible en el Insflug antes de bajar un documento de
un servidor r�plica.

Se proporciona tambi�n una lista de los servidores r�plica (mirror)
del Insflug m�s cercanos a Vd., e informaci�n relativa a otros
recursos en castellano.

Francisco Jos� Montilla, [email protected].