Je bloque depuis quelques jours avec une config de postfix que je
n'arrive pas à faire fonctionner (avec dovecot) :
Durant le RCPT de postfix, je récupère le statut du quota via le
"service quota" de dovecot .... un service de quota qui ne prend pas en
compte les alias, seulement les boîtes finales.
Mon problème est que ce policy_check envoie l'alias pour vérification
des quota et non pas le véritable email final d'où un echec avec comme
réponse : "Unknown user" ... seulement pour les alias.
Je ne comprends pas car l'option suivante n'est pas activée, et postfix
est sensé effectuer le mapping de l'alias :
#receive_override_options = no_address_mappings
Une idée pour mapper un alias avant de l'envoyer à mon check_policy ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/555C6DDC.8070402@ingescom.com
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Samuel
Le 20/05/2015 13:19, Samuel a écrit :
Bonjour à tous,
Je bloque depuis quelques jours avec une config de postfix que je n'arrive pas à faire fonctionner (avec dovecot) :
Durant le RCPT de postfix, je récupère le statut du quota via le "service quota" de dovecot .... un service de quota qui ne prend pas en compte les alias, seulement les boîtes finales.
Mon problème est que ce policy_check envoie l'alias pour vérification des quota et non pas le véritable email final d'où un echec avec comme réponse : "Unknown user" ... seulement pour les alias.
Je ne comprends pas car l'option suivante n'est pas activée, et postfix est sensé effectuer le mapping de l'alias :
#receive_override_options = no_address_mappings
Une idée pour mapper un alias avant de l'envoyer à mon check_policy ?
Pour ceux qui auraient le même problème, je n'ai pas trouvé de solution, mais plutôt un contournement du problème :
J'ai remplacé le check_policy_service par un check_recipient_access avec les bons champs dans la requête SQL et en récupérant directement le contenu de la table quota.
Ce qui m'embête avec mon problème, c'est qu'il existe pas mal de messages sur le sujet sans vraiment apporter de solution viable (du genre modifier la structure de la table users pour y inclure les alias ... ce que je voudrais éviter de faire).
Donc je je sais pas trop si mon problème vient d'une limitation logicielle ou d'une mauvaise configuration de ma part ...
Voilà. Samuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le 20/05/2015 13:19, Samuel a écrit :
Bonjour à tous,
Je bloque depuis quelques jours avec une config de postfix que je
n'arrive pas à faire fonctionner (avec dovecot) :
Durant le RCPT de postfix, je récupère le statut du quota via le
"service quota" de dovecot .... un service de quota qui ne prend pas
en compte les alias, seulement les boîtes finales.
Mon problème est que ce policy_check envoie l'alias pour vérification
des quota et non pas le véritable email final d'où un echec avec comme
réponse : "Unknown user" ... seulement pour les alias.
Je ne comprends pas car l'option suivante n'est pas activée, et
postfix est sensé effectuer le mapping de l'alias :
#receive_override_options = no_address_mappings
Une idée pour mapper un alias avant de l'envoyer à mon check_policy ?
Pour ceux qui auraient le même problème, je n'ai pas trouvé de solution,
mais plutôt un contournement du problème :
J'ai remplacé le check_policy_service par un check_recipient_access avec
les bons champs dans la requête SQL et en récupérant directement le
contenu de la table quota.
Ce qui m'embête avec mon problème, c'est qu'il existe pas mal de
messages sur le sujet sans vraiment apporter de solution viable (du
genre modifier la structure de la table users pour y inclure les alias
... ce que je voudrais éviter de faire).
Donc je je sais pas trop si mon problème vient d'une limitation
logicielle ou d'une mauvaise configuration de ma part ...
Voilà.
Samuel.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/555DB1E0.6080700@ingescom.com
Je bloque depuis quelques jours avec une config de postfix que je n'arrive pas à faire fonctionner (avec dovecot) :
Durant le RCPT de postfix, je récupère le statut du quota via le "service quota" de dovecot .... un service de quota qui ne prend pas en compte les alias, seulement les boîtes finales.
Mon problème est que ce policy_check envoie l'alias pour vérification des quota et non pas le véritable email final d'où un echec avec comme réponse : "Unknown user" ... seulement pour les alias.
Je ne comprends pas car l'option suivante n'est pas activée, et postfix est sensé effectuer le mapping de l'alias :
#receive_override_options = no_address_mappings
Une idée pour mapper un alias avant de l'envoyer à mon check_policy ?
Pour ceux qui auraient le même problème, je n'ai pas trouvé de solution, mais plutôt un contournement du problème :
J'ai remplacé le check_policy_service par un check_recipient_access avec les bons champs dans la requête SQL et en récupérant directement le contenu de la table quota.
Ce qui m'embête avec mon problème, c'est qu'il existe pas mal de messages sur le sujet sans vraiment apporter de solution viable (du genre modifier la structure de la table users pour y inclure les alias ... ce que je voudrais éviter de faire).
Donc je je sais pas trop si mon problème vient d'une limitation logicielle ou d'une mauvaise configuration de ma part ...
Voilà. Samuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Daniel Caillibaud
Le 21/05/15 à 12:22, Samuel a éc rit :
S> Ce qui m'embête avec mon problème, c'est qu'il existe pas mal de S> messages sur le sujet sans vraiment apporter de solution viable (du S> genre modifier la structure de la table users pour y inclure les alias S> ... ce que je voudrais éviter de faire).
Dans ce cas, c'est qu'il te faut une autre requete sql multi-table pour rem onter user+alias, et c'est cette requete que tu utilise dans ton policy_check
-- Daniel
Il existe 10 types de gens, ceux qui comprennent le binaire et les autres.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le 21/05/15 à 12:22, Samuel <debian-user-french-2010@ingescom.com> a éc rit :
S> Ce qui m'embête avec mon problème, c'est qu'il existe pas mal de
S> messages sur le sujet sans vraiment apporter de solution viable (du
S> genre modifier la structure de la table users pour y inclure les alias
S> ... ce que je voudrais éviter de faire).
Dans ce cas, c'est qu'il te faut une autre requete sql multi-table pour rem onter user+alias, et
c'est cette requete que tu utilise dans ton policy_check
--
Daniel
Il existe 10 types de gens, ceux qui comprennent le binaire et les autres.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20150521075338.54039331@mfssd
S> Ce qui m'embête avec mon problème, c'est qu'il existe pas mal de S> messages sur le sujet sans vraiment apporter de solution viable (du S> genre modifier la structure de la table users pour y inclure les alias S> ... ce que je voudrais éviter de faire).
Dans ce cas, c'est qu'il te faut une autre requete sql multi-table pour rem onter user+alias, et c'est cette requete que tu utilise dans ton policy_check
-- Daniel
Il existe 10 types de gens, ceux qui comprennent le binaire et les autres.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Samuel
Bonjour,
Le 21/05/2015 14:53, Daniel Caillibaud a écrit :
Le 21/05/15 à 12:22, Samuel a écrit :
S> Ce qui m'embête avec mon problème, c'est qu'il existe pas mal de S> messages sur le sujet sans vraiment apporter de solution viable (du S> genre modifier la structure de la table users pour y inclure les alias S> ... ce que je voudrais éviter de faire).
Dans ce cas, c'est qu'il te faut une autre requete sql multi-table pour remonter user+alias, et c'est cette requete que tu utilise dans ton policy_check
C'est ce que j'avais mis en place (en changeant la requête user_query de dovecot) et testé jusqu'à ce que je réalise qu'en fait ça valide (et ça créé dans la table quota) un utilisateur correspondant à l'alias ... l'alias et l'email sont bien incrémentés à l'ajout d'un email ... par contre quand 'email' se retrouve en over-quota et qu'il supprime des emails, seul le champ "email' de la table quota est mis à jour ... pas le champ de l'alias ce qui fait que 'alias' reste en over-quota.
Donc avec ce système je n'avais pas réussi à gérer proprement les quota pour les suppressions de mail pour l'alias.
D'où ma question d'origine pour pouvoir choisir l'email à envoyer au check_policy_service.
Samuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Bonjour,
Le 21/05/2015 14:53, Daniel Caillibaud a écrit :
Le 21/05/15 à 12:22, Samuel <debian-user-french-2010@ingescom.com> a écrit :
S> Ce qui m'embête avec mon problème, c'est qu'il existe pas mal de
S> messages sur le sujet sans vraiment apporter de solution viable (du
S> genre modifier la structure de la table users pour y inclure les alias
S> ... ce que je voudrais éviter de faire).
Dans ce cas, c'est qu'il te faut une autre requete sql multi-table pour remonter user+alias, et
c'est cette requete que tu utilise dans ton policy_check
C'est ce que j'avais mis en place (en changeant la requête user_query de
dovecot) et testé jusqu'à ce que je réalise qu'en fait ça valide (et ça
créé dans la table quota) un utilisateur correspondant à l'alias ...
l'alias et l'email sont bien incrémentés à l'ajout d'un email ... par
contre quand 'email' se retrouve en over-quota et qu'il supprime des
emails, seul le champ "email' de la table quota est mis à jour ... pas
le champ de l'alias ce qui fait que 'alias' reste en over-quota.
Donc avec ce système je n'avais pas réussi à gérer proprement les quota
pour les suppressions de mail pour l'alias.
D'où ma question d'origine pour pouvoir choisir l'email à envoyer au
check_policy_service.
Samuel.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/555DDC89.2070100@ingescom.com
S> Ce qui m'embête avec mon problème, c'est qu'il existe pas mal de S> messages sur le sujet sans vraiment apporter de solution viable (du S> genre modifier la structure de la table users pour y inclure les alias S> ... ce que je voudrais éviter de faire).
Dans ce cas, c'est qu'il te faut une autre requete sql multi-table pour remonter user+alias, et c'est cette requete que tu utilise dans ton policy_check
C'est ce que j'avais mis en place (en changeant la requête user_query de dovecot) et testé jusqu'à ce que je réalise qu'en fait ça valide (et ça créé dans la table quota) un utilisateur correspondant à l'alias ... l'alias et l'email sont bien incrémentés à l'ajout d'un email ... par contre quand 'email' se retrouve en over-quota et qu'il supprime des emails, seul le champ "email' de la table quota est mis à jour ... pas le champ de l'alias ce qui fait que 'alias' reste en over-quota.
Donc avec ce système je n'avais pas réussi à gérer proprement les quota pour les suppressions de mail pour l'alias.
D'où ma question d'origine pour pouvoir choisir l'email à envoyer au check_policy_service.
Samuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Daniel Caillibaud
Le 21/05/15 à 15:24, Samuel a éc rit : S> C'est ce que j'avais mis en place (en changeant la requête user_query de S> dovecot)
Ah ben non, faut que tu crée une nouvelle requete pour cet usage de check _policy_service sans casser les requêtes existantes, sinon évidemment dovecot va utiliser ce tte requete modifiée pour trouver les users et ça va remonter les alias aussi et évidemment créer d'autre problèmes.
Mais c'est un principe assez générique, quand tu veux réutiliser un t ruc fourni par un paquet qu'il faut modifier pour en faire un usage voisin mais différent, faut ut iliser une version dupliquée puis modifiée (ça évite de casser l'existant et évite a ussi que la prochaine mise à jour du paquet écrase tes modifs).
-- Daniel
Ce qui, probablement, fausse tout dans la vie, c'est qu'on est convaincu qu'on dit la vérité parce qu'on dit ce qu'on pense Sacha Guitry
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le 21/05/15 à 15:24, Samuel <debian-user-french-2010@ingescom.com> a éc rit :
S> C'est ce que j'avais mis en place (en changeant la requête user_query de
S> dovecot)
Ah ben non, faut que tu crée une nouvelle requete pour cet usage de check _policy_service sans
casser les requêtes existantes, sinon évidemment dovecot va utiliser ce tte requete modifiée
pour trouver les users et ça va remonter les alias aussi et évidemment créer d'autre problèmes.
Mais c'est un principe assez générique, quand tu veux réutiliser un t ruc fourni par un paquet
qu'il faut modifier pour en faire un usage voisin mais différent, faut ut iliser une version
dupliquée puis modifiée (ça évite de casser l'existant et évite a ussi que la prochaine mise à
jour du paquet écrase tes modifs).
--
Daniel
Ce qui, probablement, fausse tout dans la vie, c'est qu'on est
convaincu qu'on dit la vérité parce qu'on dit ce qu'on pense
Sacha Guitry
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20150522183014.524990fb@mfssd
Le 21/05/15 à 15:24, Samuel a éc rit : S> C'est ce que j'avais mis en place (en changeant la requête user_query de S> dovecot)
Ah ben non, faut que tu crée une nouvelle requete pour cet usage de check _policy_service sans casser les requêtes existantes, sinon évidemment dovecot va utiliser ce tte requete modifiée pour trouver les users et ça va remonter les alias aussi et évidemment créer d'autre problèmes.
Mais c'est un principe assez générique, quand tu veux réutiliser un t ruc fourni par un paquet qu'il faut modifier pour en faire un usage voisin mais différent, faut ut iliser une version dupliquée puis modifiée (ça évite de casser l'existant et évite a ussi que la prochaine mise à jour du paquet écrase tes modifs).
-- Daniel
Ce qui, probablement, fausse tout dans la vie, c'est qu'on est convaincu qu'on dit la vérité parce qu'on dit ce qu'on pense Sacha Guitry
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Samuel
Le 23/05/2015 01:30, Daniel Caillibaud a écrit :
Le 21/05/15 à 15:24, Samuel a écrit : S> C'est ce que j'avais mis en place (en changeant la requête user_query de S> dovecot)
Ah ben non, faut que tu crée une nouvelle requete pour cet usage de check_policy_service sans casser les requêtes existantes, sinon évidemment dovecot va utiliser cette requete modifiée pour trouver les users et ça va remonter les alias aussi et évidemment créer d'autre problèmes.
Le problème est que la table quota est gérée par dovecot (ajout suppression de champ etc ...) et que le fichier de conf lié à cette table quota est très sommaire et ne permet, à priori, pas de personnaliser les requêtes (rien vu en ce sens sur http://wiki2.dovecot.org/Quota/Dict) :
Je ne vois pas comment utiliser "username_field" pour récupérer et l'alias et le user dans 2 tables différentes.
Si j'ai bien compris que c'est à ce niveau qu'il faut intervenir.
Samuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le 23/05/2015 01:30, Daniel Caillibaud a écrit :
Le 21/05/15 à 15:24, Samuel <debian-user-french-2010@ingescom.com> a écrit :
S> C'est ce que j'avais mis en place (en changeant la requête user_query de
S> dovecot)
Ah ben non, faut que tu crée une nouvelle requete pour cet usage de check_policy_service sans
casser les requêtes existantes, sinon évidemment dovecot va utiliser cette requete modifiée
pour trouver les users et ça va remonter les alias aussi et évidemment créer d'autre problèmes.
Le problème est que la table quota est gérée par dovecot (ajout
suppression de champ etc ...) et que le fichier de conf lié à cette
table quota est très sommaire et ne permet, à priori, pas de
personnaliser les requêtes (rien vu en ce sens sur
http://wiki2.dovecot.org/Quota/Dict) :
Je ne vois pas comment utiliser "username_field" pour récupérer et
l'alias et le user dans 2 tables différentes.
Si j'ai bien compris que c'est à ce niveau qu'il faut intervenir.
Samuel.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/55606CA7.5060403@ingescom.com
Le 21/05/15 à 15:24, Samuel a écrit : S> C'est ce que j'avais mis en place (en changeant la requête user_query de S> dovecot)
Ah ben non, faut que tu crée une nouvelle requete pour cet usage de check_policy_service sans casser les requêtes existantes, sinon évidemment dovecot va utiliser cette requete modifiée pour trouver les users et ça va remonter les alias aussi et évidemment créer d'autre problèmes.
Le problème est que la table quota est gérée par dovecot (ajout suppression de champ etc ...) et que le fichier de conf lié à cette table quota est très sommaire et ne permet, à priori, pas de personnaliser les requêtes (rien vu en ce sens sur http://wiki2.dovecot.org/Quota/Dict) :
Je ne vois pas comment utiliser "username_field" pour récupérer et l'alias et le user dans 2 tables différentes.
Si j'ai bien compris que c'est à ce niveau qu'il faut intervenir.
Samuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Daniel Caillibaud
Le 23/05/15 à 14:03, Samuel a éc rit : S> Je ne vois pas comment utiliser "username_field" pour récupérer et S> l'alias et le user dans 2 tables différentes. S> S> Si j'ai bien compris que c'est à ce niveau qu'il faut intervenir.
Probable, je connais pas ta structure de table, tu dois écrire une requet e sql qui sorte login ou alias dans un seul champ, et tu utilise cette requete dans postfix, sans toucher aux requetes déjà écrites pour dovecot.
Si t'es pas à l'aise avec des if dans le select, tu peux indiquer 2 reque tes dans ta conf postfix
et tu regarde la doc pour la syntaxe de ces fichier cf, c'est du genre
user = xxx password = xxx hosts = xxx dbname = xxx query = SELECT champ FROM table WHERE autreChamp = '%s'
Le %s dépend de cle (ça peut être une adresse, un domaine, suivant le contexte), ce que tu doit remonter dépend aussi du contexte.
-- Daniel
J'aurais aimé être publicitaire pour faire dire des conneries aux vedet tes.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le 23/05/15 à 14:03, Samuel <debian-user-french-2010@ingescom.com> a éc rit :
S> Je ne vois pas comment utiliser "username_field" pour récupérer et
S> l'alias et le user dans 2 tables différentes.
S>
S> Si j'ai bien compris que c'est à ce niveau qu'il faut intervenir.
Probable, je connais pas ta structure de table, tu dois écrire une requet e sql qui sorte login
ou alias dans un seul champ, et tu utilise cette requete dans postfix, sans toucher aux
requetes déjà écrites pour dovecot.
Si t'es pas à l'aise avec des if dans le select, tu peux indiquer 2 reque tes dans ta conf
postfix
et tu regarde la doc pour la syntaxe de ces fichier cf, c'est du genre
user = xxx
password = xxx
hosts = xxx
dbname = xxx
query = SELECT champ FROM table WHERE autreChamp = '%s'
Le %s dépend de cle (ça peut être une adresse, un domaine, suivant le contexte), ce que tu
doit remonter dépend aussi du contexte.
--
Daniel
J'aurais aimé être publicitaire pour faire dire des conneries aux vedet tes.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20150523114713.5d013da6@mfssd
Le 23/05/15 à 14:03, Samuel a éc rit : S> Je ne vois pas comment utiliser "username_field" pour récupérer et S> l'alias et le user dans 2 tables différentes. S> S> Si j'ai bien compris que c'est à ce niveau qu'il faut intervenir.
Probable, je connais pas ta structure de table, tu dois écrire une requet e sql qui sorte login ou alias dans un seul champ, et tu utilise cette requete dans postfix, sans toucher aux requetes déjà écrites pour dovecot.
Si t'es pas à l'aise avec des if dans le select, tu peux indiquer 2 reque tes dans ta conf postfix
et tu regarde la doc pour la syntaxe de ces fichier cf, c'est du genre
user = xxx password = xxx hosts = xxx dbname = xxx query = SELECT champ FROM table WHERE autreChamp = '%s'
Le %s dépend de cle (ça peut être une adresse, un domaine, suivant le contexte), ce que tu doit remonter dépend aussi du contexte.
-- Daniel
J'aurais aimé être publicitaire pour faire dire des conneries aux vedet tes.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Samuel
Le 23/05/2015 18:47, Daniel Caillibaud a écrit :
Le 23/05/15 à 14:03, Samuel a écrit : S> Je ne vois pas comment utiliser "username_field" pour récupérer et S> l'alias et le user dans 2 tables différentes. S> S> Si j'ai bien compris que c'est à ce niveau qu'il faut intervenir.
Probable, je connais pas ta structure de table, tu dois écrire une requete sql qui sorte login ou alias dans un seul champ, et tu utilise cette requete dans postfix, sans toucher aux requetes déjà écrites pour dovecot.
On est bien d'accord, c'est dans postfix qu'il faut agir ... intervenir dans dovecot complique la chose.
Si t'es pas à l'aise avec des if dans le select, tu peux indiquer 2 requetes dans ta conf postfix
et tu regarde la doc pour la syntaxe de ces fichier cf, c'est du genre
user = xxx password = xxx hosts = xxx dbname = xxx query = SELECT champ FROM table WHERE autreChamp = '%s'
Le %s dépend de cle (ça peut être une adresse, un domaine, suivant le contexte), ce que tu doit remonter dépend aussi du contexte.
C'est ce que j'ai utilisé : accéder directement au contenu de la table quota via pré-sélection dans table users et forwards :
smtpd_recipient_restrictions = check_recipient_access mysql:check_quota ... check_quota_query = select if(bytes>'12582912', '552 5.2.2 Quota exceeded (mailbox for user is full)', 'PERMIT') from quota where email = '%u@%d' or email=(select destination from forwards where source='%u@%d')
Et c'est vrai que cette rustine fonctionne bien ... mais sur une Jessie, dans le fichier /etc/dovecot/conf.d/90-quota.conf, il est mentionné cette page qui concerne l'utilisation du "service quota-status" pour postfix : https://sys4.de/de/blog/2013/04/08/postfix-dovecot-mailbox-quota/
Cette page donne cette commande pour interroger ce service (port 12340) depuis postfix :
Mon problème est que cette commande envoie en variable l'alias en valeur finale (qui n'existe pas dans la table quota de postfix -> unknown user) et non pas le user final (après mapping de l'alias).
Ma question était donc de savoir comment interroger un service via cette commande de postfix en choississant sa variable à envoyer. Je n'arrive pas à lier le "check_policy_service inet" à une requête SQL, ni même comment passer une variable en valeur.
La rustine employée fonctionne bien, mais je me demandais comment faire fonctionner la méthode telle que conseillée dans les fichiers de conf sur Jessie ...
Merci.
Samuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le 23/05/2015 18:47, Daniel Caillibaud a écrit :
Le 23/05/15 à 14:03, Samuel <debian-user-french-2010@ingescom.com> a écrit :
S> Je ne vois pas comment utiliser "username_field" pour récupérer et
S> l'alias et le user dans 2 tables différentes.
S>
S> Si j'ai bien compris que c'est à ce niveau qu'il faut intervenir.
Probable, je connais pas ta structure de table, tu dois écrire une requete sql qui sorte login
ou alias dans un seul champ, et tu utilise cette requete dans postfix, sans toucher aux
requetes déjà écrites pour dovecot.
On est bien d'accord, c'est dans postfix qu'il faut agir ... intervenir
dans dovecot complique la chose.
Si t'es pas à l'aise avec des if dans le select, tu peux indiquer 2 requetes dans ta conf
postfix
et tu regarde la doc pour la syntaxe de ces fichier cf, c'est du genre
user = xxx
password = xxx
hosts = xxx
dbname = xxx
query = SELECT champ FROM table WHERE autreChamp = '%s'
Le %s dépend de cle (ça peut être une adresse, un domaine, suivant le contexte), ce que tu
doit remonter dépend aussi du contexte.
C'est ce que j'ai utilisé : accéder directement au contenu de la table
quota via pré-sélection dans table users et forwards :
smtpd_recipient_restrictions = check_recipient_access mysql:check_quota
...
check_quota_query = select if(bytes>'12582912', '552 5.2.2 Quota
exceeded (mailbox for user is full)', 'PERMIT') from quota where email =
'%u@%d' or email=(select destination from forwards where source='%u@%d')
Et c'est vrai que cette rustine fonctionne bien ... mais sur une Jessie,
dans le fichier /etc/dovecot/conf.d/90-quota.conf, il est mentionné
cette page qui concerne l'utilisation du "service quota-status" pour
postfix : https://sys4.de/de/blog/2013/04/08/postfix-dovecot-mailbox-quota/
Cette page donne cette commande pour interroger ce service (port 12340)
depuis postfix :
Mon problème est que cette commande envoie en variable l'alias en valeur
finale (qui n'existe pas dans la table quota de postfix -> unknown
user) et non pas le user final (après mapping de l'alias).
Ma question était donc de savoir comment interroger un service via cette
commande de postfix en choississant sa variable à envoyer. Je n'arrive
pas à lier le "check_policy_service inet" à une requête SQL, ni même
comment passer une variable en valeur.
La rustine employée fonctionne bien, mais je me demandais comment faire
fonctionner la méthode telle que conseillée dans les fichiers de conf
sur Jessie ...
Merci.
Samuel.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/5560BF4A.5080600@ingescom.com
Le 23/05/15 à 14:03, Samuel a écrit : S> Je ne vois pas comment utiliser "username_field" pour récupérer et S> l'alias et le user dans 2 tables différentes. S> S> Si j'ai bien compris que c'est à ce niveau qu'il faut intervenir.
Probable, je connais pas ta structure de table, tu dois écrire une requete sql qui sorte login ou alias dans un seul champ, et tu utilise cette requete dans postfix, sans toucher aux requetes déjà écrites pour dovecot.
On est bien d'accord, c'est dans postfix qu'il faut agir ... intervenir dans dovecot complique la chose.
Si t'es pas à l'aise avec des if dans le select, tu peux indiquer 2 requetes dans ta conf postfix
et tu regarde la doc pour la syntaxe de ces fichier cf, c'est du genre
user = xxx password = xxx hosts = xxx dbname = xxx query = SELECT champ FROM table WHERE autreChamp = '%s'
Le %s dépend de cle (ça peut être une adresse, un domaine, suivant le contexte), ce que tu doit remonter dépend aussi du contexte.
C'est ce que j'ai utilisé : accéder directement au contenu de la table quota via pré-sélection dans table users et forwards :
smtpd_recipient_restrictions = check_recipient_access mysql:check_quota ... check_quota_query = select if(bytes>'12582912', '552 5.2.2 Quota exceeded (mailbox for user is full)', 'PERMIT') from quota where email = '%u@%d' or email=(select destination from forwards where source='%u@%d')
Et c'est vrai que cette rustine fonctionne bien ... mais sur une Jessie, dans le fichier /etc/dovecot/conf.d/90-quota.conf, il est mentionné cette page qui concerne l'utilisation du "service quota-status" pour postfix : https://sys4.de/de/blog/2013/04/08/postfix-dovecot-mailbox-quota/
Cette page donne cette commande pour interroger ce service (port 12340) depuis postfix :
Mon problème est que cette commande envoie en variable l'alias en valeur finale (qui n'existe pas dans la table quota de postfix -> unknown user) et non pas le user final (après mapping de l'alias).
Ma question était donc de savoir comment interroger un service via cette commande de postfix en choississant sa variable à envoyer. Je n'arrive pas à lier le "check_policy_service inet" à une requête SQL, ni même comment passer une variable en valeur.
La rustine employée fonctionne bien, mais je me demandais comment faire fonctionner la méthode telle que conseillée dans les fichiers de conf sur Jessie ...
Merci.
Samuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
