[hackmeeting] La lista "rula" rara

[Miquel]

El Friday, 02 Mar 2001, a las 00:42, Pere Picornell contaba:

> en mi opini?n...
> 
> 
> 1- Toda la vida en todas las listas se ha contestado con Reply. Es mas 
> comodo no tener que pensar "en esta lista, reply to all, en la otra, 
> reply..." (el 5o punto explica pq no responder a todas las listas con reply 
> to all)

esto no es exacto: hay cantidad de listas, cada vez mas, donde no se
reescribe el reply_to, por ejemplo en las listas de Debian, que son las
que mejor conozco.

[...]

> 3- Todo nuevo que entre en la lista tendra que ser informado, ya que aunque 
> se informe en el mail de presentaci?n, no se enteraran ya que nadie lo lee 
> (son como las licencias de usuario, en parte).

Solo hay que fijarse un poco en el TO: antes de enviar (una buena
costumbre en cualquier caso, para evitar errores y disgustos)... Es mas
una cuestion de "cultura" en el uso del correo, que una peculiaridad
nuestra que haya que advertir... aunque si se ve necesario, se puede
avisar como dices en el mensaje de bienvenida.

> 4- Logicamente, seran informados cuando hayan respondido a particulares en 
> vez de a la lista, cosa que si que supone una molestia, tanto para ellos 
> como para el recibidor de los mensajes, que lo normal es que los remita a 
> la lista.

como ha comentado joseba, es mucho peor enviar por error un mensaje
privado a la lista, lo cual es imposible tal como est? ahora
configurada.

> 5- Al hacer reply to all, en el campo To aparecen los emails de quienes han 
> respondido al mail o de quien lo ha enviado, y en el campo Cc aparece el 
> mail de la lista. Por lo tanto quien escribi? o respondi? al mensaje va a 
> recibirlo 2 veces. He tenido que eliminarlos del campo To para que no pase 
> esto.

Pues fijate que esa es la forma tradicional de hacerlo: si te incluyen
en el CC: supone que la respuesta te va a llegar m?s r?pido (pues no
tiene que procesar tu mensaje el servidor de listas, ni esperar la cola
del MTA con los otros doscientos colisteros), por lo tanto es algo que
se suele considerar un detalle. En las listas mas serias es bastante
normal todavia responder a todo el hilo, ademas de a la lista, se
considera una deferencia, aunque te llegue por partida doble.

Ademas hay mucha gente que filtra las listas en carpetas diferentes, y
recibe en el inbox los mensajes particulares, por lo que ve antes cuando
alguien le ha respondido (suele tenerse mas "vigilado" el inbox que las
carpetas de listas). 

[...]

> 
> Como veis, no me gusta el cambio. Yo lo dejaria como antes.
> 

ya ver?s como el inconveniente es minimo y las ventajas son muchas ;-)

> Lo que ignoro es que problema hay con la reescriptura de cabezales. Alguien 
> podria explicarmelo plis?
> 

No es un "problema" como tal, sino un principio de los hackers que
escribieron los primeros RFC y que dise?aron lo que debia haber en las
cabeceras: es un principio "minimalista" para los administradores en los
que nos recomiendan no tocar cabeceras si no hay una buena razon para
ello. As? resume el "principio" Chip Rosenthal:

	"The "Principle of Minimal Munging" is a good rule that will
	keep you out of trouble. It says you should not make any changes
	to an email header unless you know precisely what you want to
	do, why you want to do it, and what it will affect. Unless you
	can articulate a clear reason for munging and understand the
	full consequences of the action, you should not do it. 

	The "Principle of Minimal Munging" will help you avoid the sorts
	of problems we are about to discuss. This principle is a rule
	designed to be broken, but you can avoid some significant
	heartache by thinking hard and long before you do so."  

echa un ojo a http://garcon.unicom.com/FAQ/reply-to-harmful.html, all?
se argumentan con detalle las razones, y que en sindominio hacemos
nuestras ;-)

> Nos vemos! :)
> 

venga, hasta otra :-)

m.


-- 
Miquel Vidal            | http://mi.barrapunto.com/yonderboy
miquel en sindominio.net   | Proyecto laespiral.org
CSOA el Laboratorio     | Using Debian GNU/Linux 
www.sindominio.net      | GnuPG public information: 1024D/F724244F
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 228 bytes
Descripción: no disponible
Url        : https://listas.sindominio.net/mailman/private/hackmeeting/attachments/20010302/02c150c7/attachment-0002.pgp