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

[Frédéric Perrin <adresse@cachée>]

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.

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.

> > 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.

> 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...

-- 
Fred
Réseau des Élèves de TELECOM Bretagne