Re: [sympa-fr] Utilisation des "custom conditions"

[David Verdin <adresse@cachée>]

Bonjour,

Frédéric Perrin a écrit :
> Le Mon, 31 Mar 2008 14:31:07 +0200, David Verdin
> <adresse@cachée> a écrit :
>   
> > > Plus précisément, mon problème est que notre école, qui héberge la
> > > grande partie des comptes mails utilisés, a changé de nom il y a
> > > peu. Donc, toutes les inscriptions qui utilisaient l'ancien nom
> > > de domaine ne sont plus reconnues par Sympa.
> > >   
> > >       
> > Pourquoi ? Les personnes sont toujours abonnées avec leur ancienne 
> > adresse, non ? donc ça devrait marcher. Sauf si votre MTA ne
> > reconnaît plus les adresses de l'ancien domaine. dans ce cas, les
> > messages n'arrivent même pas à Sympa.
> > Quel scenario "send" employez-vous ?
> >     
>
> Avant de répondre, j'ajoute quelque chose qui n'était pas du tout
> évident dans mon message précédent : je suis élève de l'école, et je
> fait partie des admins du réseau des élèves du campus. Nous n'avons
> pas de contrôle sur la façon dont les adresses mail de l'école sont
> gérées. La logistique informatique de l'école vient de configurer le
> webmail pour envoyer les messages avec un From: sur le nouveau nom.
>   
Donc les adresses à utiliser désormais sont celles avec le nouveau nom.
Comme vous n'avez pas la main sur la gestion des adresses, alors la 
meilleure solution est encore de demander à vos abonnés de changer leur 
adresse dans Sympa.
Après tout, les nouvelles adresses vont finalement devenir la règle, 
donc autant commencer à les appliquer.
> Les listes de diffusion sont gérées par les élèves ; chaque
> propriétaire de liste décide du scénario qu'il veut utiliser. Une
> grande partie des listes ont un scénario du style "si l'adresse vient
> de l'école ou du campus, ou si elle est inscrite à la liste, alors
> accepter le message", dans ce cas pas de problème, il a suffi
> d'ajouter le nouveau nom dans le scénario. Pour des listes plus
> privées, qui sont réservées aux abonnés, c'est là que certains
> messages passaient par la modération ou étaient rejetés, car
> l'expéditeur avait déjà configuré son outil de messagerie pour
> utiliser le nouveau nom, ou utilisait le webmail de l'école.
>   
Voui, c'est normal. L'adresse mail sert d'identifiant dans Sympa.
> > > Par ailleurs, certaines personnes commencent déjà à utiliser le
> > > nouveau nom de domaine pour le champ From:, d'autres l'ancien.
> > > Comment dire à Sympa, sans utiliser les "custom conditions", que
> > > si une adresse adresse@cachée n'est pas inscrite à une ML
> > > mais que adresse@cachée l'est (ou inversement), alors le
> > > mail doit être accepté ?
> > >   
> > >       
> > Eh bien si les listes résultent d'inclusions automatiques, vous
> > pouvez éventuellement modifier vos sources de données pour, dans un
> > premier temps inclure les deux adresses email et, dans un second
> > temps, supprimer les anciennes adresses.
> > Dans le cas des inscriptions manuelles, vous pouvez également
> > réaliser des doublons et inscrivant toutes les nouvelles adresses
> > (en accédant directement à la base de données, par exemple) en plus
> > des anciennes. On peut se dire que les personnes n'utilisent qu'une
> > de ces adresses à la fois.
> >     
>
> Pour information, c'est ce que j'ai fini par faire. Quelque chose du
> style :
>
> Pour chaque personne inscrite avec @anciennom, Faire :
>     Si l'inscription @nvnom a déjà été faite,
>     Alors ne rien faire, en se disant que si la personne a déjà
>                 commencé la démarche, elle le fera jusqu'au bout.
>     Sinon :
>         Ajouter l'inscription @nvnom dans user_table
>         Ajouter les inscriptions @nvnom dans subscriber_table
>         Ajouter les droits admin pour @nvnom dans admin_table
>         Passer les inscriptions @anciennom en 'nomail'
>
> Le script utilisé (très sale) est disponible sur demande.
>   
Attention : La table admin_table n'est qu'un cache des informations sur 
les propriétaires et modérateurs.
Toutes ces informations trouvent leur source dans les fichiers de config 
de liste et de Sympa.
Par conséquent, si vous voulez que les nouvelles adresses soient prises 
en compte pour les admins, vous devez également changer les fichiers de 
config.
La table admin_table sera alors automatiquement mise à jour.

Quand les anciennes adresses auront définitivement disparu, il faudra 
sans doute faire tourner un script similaire pour les supprimer.
>   
> > Si votre MTA continue à accepter les deux noms de domaines, vous ne 
> > ferez peut-êtr même pas augmenter les bounces.
> >     
> > > J'aimerais autant que possible éviter la solution "on transforme
> > > ancien-nom.fr en nouveau-nom.fr dans les inscriptions, et on dit
> > > aux gens de changer la configuration  de leur logiciel de
> > > messagerie". 
> > >       
> > Il va bien falloir qu'ils le fassent un jour, sinon la lisibilité
> > des adresses mail va diminuer, non ?
> >     
>
> Mmmh, si on pouvait s'attendre à ce qu'un campus entier fasse la
> démarche de changement de configuration, même s'il suffit d'aller sur
> une interface Web, ça se saurait...
>
>   
C'est pourtant ce qui finit par se passer.
L'organisme où je travaillais précédemment a changé d'adresse également. 
Après une période de transition de six mois, les anciennes adresses sont 
devenues invalides.
Si on veut que le nouveau nom soit pris en compte, c'est la seule 
solution, à mon avis.


Cordialement,

--
David Verdin
Comité réseau des universités