Reply-To list

[Jean Brange <adresse@cachée>]

Bonjour/soir

Voila j'ai trouve dans le code de sympa que le Reply-to n'etait pas modifie si
deja defini . Ca me pose un tout petit probleme.

En effet malgre les l'insistance de certains sur la liste pour deconseiller le
Reply-To liste que je comprends et que j'applique egalement parfois, il y a en
revanche un cas ou le Reply-To list me convient c'est celui du forum avec
echange d'idee, debats etc. en general le nombre d'abonne est restreint et 
j'ai
une liste qui fonctionne comme ca depuis un an et on a aucun probleme de bruit
lie au reply (elle est en Send private).

Donc le choix de sympa est-il obligatoire ? correspond-il a une necessite des
RFCs ? 

Le probleme:  j'ai fait un tour sur mon sendmail.cf qui lui (evidement, gasp)
definit le reply-to. Donc les messages que j'envoie , me revienne par default
pas par la liste. Est-ce courant chez vous ? 


Que me conseillez vous ? Changer ma config sendmail, utiliser reply a tous sur
mon mailer, modifier sympa.pl ?
En realite le probleme est pour mes correspondants, c'est a eux de faire
reply-to-all car MON sendmail fixe le reply-to ! c'est la que ca m'embete le
plus.


un deuxiemme point: comment ajouter une liste sur le serveur:

on definit la liste, on arrete sympa et on relance sympa.

pour moi ca va j'ai une dizaine de liste, mais au cru vous faites vraiment
comme ca ? J'ai reflechi au probleme et j'ai parcouru le code pour trouver ou
sympa list ses config et creee ses tables, mais c'est vite devenu confus entre
tous les modules. J'imaginerai bien l'equivalent d'un kill -HUP mais je ne
pense pas que ce soit possible avec perl, donc j'ai pense a des commandes
d'administrations:

        create nom_de_la_liste owner            cree une liste avec un
proprio
        modify nom_de_la_liste send private     modify un parametre
        modify nom_de_la_liste owner            ajoute un proprio
        drop   nom_de_la_liste owner            supprime un proprio
        drop   nom_de_la_liste                  supprime la liste

les messages pourraient etre envoyes a sympa, il faudrait definir une 
procedure
d'authentification ie: le message vient de l'utilisateur sympa@localhost mais
je pense que ca doit etre forgeable, on pourrait avoir un controle MD5 ?

Si je trouve le temps dans les 2 mois qui vient je veux bien me mettre
la-dessus, mais il me faudrait des tuyaux sur la procedure d'initialisation de
sympa.

Jean Brange