Avec procmail, je voudrais une sorte de "else if". La page man de
procmailrc dit:
E This recipe only executes if the immediately preceding recipe was
not executed. Execution of this recipe also disables any immedi-
ately following recipes with the 'E' flag. This allows you to
specify `else if' actions.
D'après la dernière phrase, c'est a priori ce que je veux pour rejeter
un message si (A et non B et (C ou D)), en faisant ceci (je n'explicite
pas ce qui est entre crochets):
:0
* [conditions A sur plusieurs lignes]
{
:0
* [conditions B sur plusieurs lignes]
{
}
:0 E
* [conditions C sur plusieurs lignes]
{
[rejet du message]
}
:0 E
* [conditions D sur plusieurs lignes]
{
[rejet du message]
}
}
Note: je ne peux pas grouper les conditions A et B pour éviter
d'utiliser le drapeau E, car les conditions de B s'expriment sur
plusieurs lignes et "non (X et Y)" signifie "non X ou non Y", et
il n'y a pas moyen d'exprimer le "ou" dans une règle (sauf avec
une regexp très compliquée).
Le problème est que la page man dit "immediately preceding recipe",
donc si la 2e règle du bloc (celle avec les conditions C) n'est pas
exécutée, alors la 3e règle (celle avec les conditions D) sera
exécutée, i.e. si les conditions A, B et D sont vérifiées, alors
le message sera rejeté. Donc le drapeau E ne fait pas vraiment un
"else if". Ou alors il faudrait mettre un drapeau E sur la règle
avec les conditions B; mais dans ce cas, que se passe-t-il? quelle
est la règle qui précède immédiatement? Le manuel ne me semble pas
très clair. AMHA, il y a aussi un double sens pour "execute" dans
le paragraphe que je cite: le premier a plutôt le sens de "être
considérée", sinon cela voudrait dire que les conditions ne sont
pas testées!
Sinon je peux toujours faire ceci:
:0
* [conditions A sur plusieurs lignes]
{
:0
* !^F
{
# pas de From, donc impossible
}
:0 E
* [conditions B sur plusieurs lignes]
{
}
:0 E
* [conditions C sur plusieurs lignes]
{
[rejet du message]
}
:0 E
* [conditions D sur plusieurs lignes]
{
[rejet du message]
}
}
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
Jacques L'helgoualc'h
Le 16-10-2005, Vincent Lefevre a écrit :
Bonjour,
bonjour,
Avec procmail, je voudrais une sorte de "else if". La page man de procmailrc dit:
E This recipe only executes if the immediately preceding recipe was not executed. Execution of this recipe also disables any immedi- ately following recipes with the 'E' flag. This allows you to specify `else if' actions.
D'après la dernière phrase, c'est a priori ce que je veux pour rejeter un message si (A et non B et (C ou D)), en faisant ceci (je n'explicite pas ce qui est entre crochets):
[...]
Note: je ne peux pas grouper les conditions A et B pour éviter d'utiliser le drapeau E, car les conditions de B s'expriment sur plusieurs lignes et "non (X et Y)" signifie "non X ou non Y", et il n'y a pas moyen d'exprimer le "ou" dans une règle (sauf avec une regexp très compliquée).
Ben, il y a aussi le scoring, ou une construction à la Morgan. Ce n'est pas non plus très lisible...
Le problème est que la page man dit "immediately preceding recipe", donc si la 2e règle du bloc (celle avec les conditions C) n'est pas exécutée, alors la 3e règle (celle avec les conditions D) sera exécutée, i.e. si les conditions A, B et D sont vérifiées, alors le message sera rejeté.
Tu l'as vérifié ?
Bon, dans ton cas je mettrais plutôt un sous-bloc correspondant à (C ou D), pour mieux coller à ton expression logique :
:0 * (A) { :0 * (B) { }
:0 E { :0 * (C) (action)
:0 E * (C) (action) } }
Donc le drapeau E ne fait pas vraiment un "else if". Ou alors il faudrait mettre un drapeau E sur la règle avec les conditions B; mais dans ce cas, que se passe-t-il?
ça n'a pas vraiment de sens ?
quelle est la règle qui précède immédiatement?
La seule candidate, c'est A, non ?
Le manuel ne me semble pas très clair. AMHA, il y a aussi un double sens pour "execute" dans le paragraphe que je cite: le premier a plutôt le sens de "être considérée", sinon cela voudrait dire que les conditions ne sont pas testées!
Oui...
Sinon je peux toujours faire ceci:
:0 * [conditions A sur plusieurs lignes] { :0 * !^F { # pas de From, donc impossible
Pas de "^From ", c'est une erreur possible --- !^ est plus vite tapé :)
[...]
Des commentaires?
La syntaxe procmail n'est pas la meilleure pour la logique --- surtout quand on se relit longtemps après :/
Pour ma part, je suis passé à maildrop, ou tes conditions s'expriment de façon beaucoup plus « naturelle » :
Avec procmail, je voudrais une sorte de "else if". La page man de
procmailrc dit:
E This recipe only executes if the immediately preceding recipe was
not executed. Execution of this recipe also disables any immedi-
ately following recipes with the 'E' flag. This allows you to
specify `else if' actions.
D'après la dernière phrase, c'est a priori ce que je veux pour rejeter
un message si (A et non B et (C ou D)), en faisant ceci (je n'explicite
pas ce qui est entre crochets):
[...]
Note: je ne peux pas grouper les conditions A et B pour éviter
d'utiliser le drapeau E, car les conditions de B s'expriment sur
plusieurs lignes et "non (X et Y)" signifie "non X ou non Y", et
il n'y a pas moyen d'exprimer le "ou" dans une règle (sauf avec
une regexp très compliquée).
Ben, il y a aussi le scoring, ou une construction à la Morgan.
Ce n'est pas non plus très lisible...
Le problème est que la page man dit "immediately preceding recipe",
donc si la 2e règle du bloc (celle avec les conditions C) n'est pas
exécutée, alors la 3e règle (celle avec les conditions D) sera
exécutée, i.e. si les conditions A, B et D sont vérifiées, alors
le message sera rejeté.
Tu l'as vérifié ?
Bon, dans ton cas je mettrais plutôt un sous-bloc correspondant à (C ou
D), pour mieux coller à ton expression logique :
:0
* (A)
{
:0
* (B)
{ }
:0 E
{
:0
* (C)
(action)
:0 E
* (C)
(action)
}
}
Donc le drapeau E ne fait pas vraiment un "else if". Ou alors il
faudrait mettre un drapeau E sur la règle avec les conditions B; mais
dans ce cas, que se passe-t-il?
ça n'a pas vraiment de sens ?
quelle est la règle qui précède immédiatement?
La seule candidate, c'est A, non ?
Le manuel ne me semble pas très clair. AMHA, il y a aussi un double
sens pour "execute" dans le paragraphe que je cite: le premier a
plutôt le sens de "être considérée", sinon cela voudrait dire que les
conditions ne sont pas testées!
Oui...
Sinon je peux toujours faire ceci:
:0
* [conditions A sur plusieurs lignes]
{
:0
* !^F
{
# pas de From, donc impossible
Pas de "^From ", c'est une erreur possible --- !^ est plus vite tapé :)
[...]
Des commentaires?
La syntaxe procmail n'est pas la meilleure pour la logique --- surtout
quand on se relit longtemps après :/
Pour ma part, je suis passé à maildrop, ou tes conditions s'expriment de
façon beaucoup plus « naturelle » :
Avec procmail, je voudrais une sorte de "else if". La page man de procmailrc dit:
E This recipe only executes if the immediately preceding recipe was not executed. Execution of this recipe also disables any immedi- ately following recipes with the 'E' flag. This allows you to specify `else if' actions.
D'après la dernière phrase, c'est a priori ce que je veux pour rejeter un message si (A et non B et (C ou D)), en faisant ceci (je n'explicite pas ce qui est entre crochets):
[...]
Note: je ne peux pas grouper les conditions A et B pour éviter d'utiliser le drapeau E, car les conditions de B s'expriment sur plusieurs lignes et "non (X et Y)" signifie "non X ou non Y", et il n'y a pas moyen d'exprimer le "ou" dans une règle (sauf avec une regexp très compliquée).
Ben, il y a aussi le scoring, ou une construction à la Morgan. Ce n'est pas non plus très lisible...
Le problème est que la page man dit "immediately preceding recipe", donc si la 2e règle du bloc (celle avec les conditions C) n'est pas exécutée, alors la 3e règle (celle avec les conditions D) sera exécutée, i.e. si les conditions A, B et D sont vérifiées, alors le message sera rejeté.
Tu l'as vérifié ?
Bon, dans ton cas je mettrais plutôt un sous-bloc correspondant à (C ou D), pour mieux coller à ton expression logique :
:0 * (A) { :0 * (B) { }
:0 E { :0 * (C) (action)
:0 E * (C) (action) } }
Donc le drapeau E ne fait pas vraiment un "else if". Ou alors il faudrait mettre un drapeau E sur la règle avec les conditions B; mais dans ce cas, que se passe-t-il?
ça n'a pas vraiment de sens ?
quelle est la règle qui précède immédiatement?
La seule candidate, c'est A, non ?
Le manuel ne me semble pas très clair. AMHA, il y a aussi un double sens pour "execute" dans le paragraphe que je cite: le premier a plutôt le sens de "être considérée", sinon cela voudrait dire que les conditions ne sont pas testées!
Oui...
Sinon je peux toujours faire ceci:
:0 * [conditions A sur plusieurs lignes] { :0 * !^F { # pas de From, donc impossible
Pas de "^From ", c'est une erreur possible --- !^ est plus vite tapé :)
[...]
Des commentaires?
La syntaxe procmail n'est pas la meilleure pour la logique --- surtout quand on se relit longtemps après :/
Pour ma part, je suis passé à maildrop, ou tes conditions s'expriment de façon beaucoup plus « naturelle » :
Dans l'article <slrndl6lgq.a2t.lhh+, Jacques L'helgoualc'h <lhh+ écrit:
Le 16-10-2005, Vincent Lefevre a écrit :
Avec procmail, je voudrais une sorte de "else if". La page man de procmailrc dit:
E This recipe only executes if the immediately preceding recipe was not executed. Execution of this recipe also disables any immedi- ately following recipes with the 'E' flag. This allows you to specify `else if' actions.
Note: je ne peux pas grouper les conditions A et B pour éviter d'utiliser le drapeau E, car les conditions de B s'expriment sur plusieurs lignes et "non (X et Y)" signifie "non X ou non Y", et il n'y a pas moyen d'exprimer le "ou" dans une règle (sauf avec une regexp très compliquée).
Ben, il y a aussi le scoring, ou une construction à la Morgan.
J'ai aussi pensé au scoring (mais la syntaxe est un peu bizarre, alors j'ai toujours peur de faire une erreur bête). La construction à la Morgan, c'est ce que je cherchais à faire, mais je n'avais pas pensé au sous-bloc supplémentaire.
Le problème est que la page man dit "immediately preceding recipe", donc si la 2e règle du bloc (celle avec les conditions C) n'est pas exécutée, alors la 3e règle (celle avec les conditions D) sera exécutée, i.e. si les conditions A, B et D sont vérifiées, alors le message sera rejeté.
Tu l'as vérifié ?
Non. Je suppose que le véritable comportement est différent de celui documenté. L'auteur n'a visiblement pas les idées très claires, et s'il touche au code sans réfléchir plus, un upgrade risque de tout casser! Ceci dit, l'auteur ne veut visiblement plus toucher au code pour cette raison (surtout que c'est écrit assez salement, AMHA).
Bon, dans ton cas je mettrais plutôt un sous-bloc correspondant à (C ou D), pour mieux coller à ton expression logique :
:0 * (A) { :0 * (B) { }
:0 E { :0 * (C) (action)
:0 E * (C) (action) } }
Excellente idée!
Donc le drapeau E ne fait pas vraiment un "else if". Ou alors il faudrait mettre un drapeau E sur la règle avec les conditions B; mais dans ce cas, que se passe-t-il?
ça n'a pas vraiment de sens ?
C'est un peu ce que je pense. Je crois qu'il faut éviter (même si ça fonctionne actuellement comme je le veux, je ne pense pas que ce soit future-proof).
quelle est la règle qui précède immédiatement?
La seule candidate, c'est A, non ?
Peut-être. Mais comme la règle A n'est pas complètement exécutée, peut-on vraiment dire qu'elle précède?
:0 * !^F { # pas de From, donc impossible
Pas de "^From ", c'est une erreur possible
Je pensais plutôt à pas d'en-tête "From:". En fait, je vérifie la présence d'un "From:" dans une règle précédente:
Dans l'article <slrndl6lgq.a2t.lhh+no_spam@ulysse.maison>,
Jacques L'helgoualc'h <lhh+no_spam@free.fr> écrit:
Le 16-10-2005, Vincent Lefevre a écrit :
Avec procmail, je voudrais une sorte de "else if". La page man de
procmailrc dit:
E This recipe only executes if the immediately preceding recipe was
not executed. Execution of this recipe also disables any immedi-
ately following recipes with the 'E' flag. This allows you to
specify `else if' actions.
Note: je ne peux pas grouper les conditions A et B pour éviter
d'utiliser le drapeau E, car les conditions de B s'expriment sur
plusieurs lignes et "non (X et Y)" signifie "non X ou non Y", et
il n'y a pas moyen d'exprimer le "ou" dans une règle (sauf avec
une regexp très compliquée).
Ben, il y a aussi le scoring, ou une construction à la Morgan.
J'ai aussi pensé au scoring (mais la syntaxe est un peu bizarre,
alors j'ai toujours peur de faire une erreur bête). La construction
à la Morgan, c'est ce que je cherchais à faire, mais je n'avais pas
pensé au sous-bloc supplémentaire.
Le problème est que la page man dit "immediately preceding recipe",
donc si la 2e règle du bloc (celle avec les conditions C) n'est pas
exécutée, alors la 3e règle (celle avec les conditions D) sera
exécutée, i.e. si les conditions A, B et D sont vérifiées, alors
le message sera rejeté.
Tu l'as vérifié ?
Non. Je suppose que le véritable comportement est différent de celui
documenté. L'auteur n'a visiblement pas les idées très claires, et
s'il touche au code sans réfléchir plus, un upgrade risque de tout
casser! Ceci dit, l'auteur ne veut visiblement plus toucher au code
pour cette raison (surtout que c'est écrit assez salement, AMHA).
Bon, dans ton cas je mettrais plutôt un sous-bloc correspondant à (C
ou D), pour mieux coller à ton expression logique :
:0
* (A)
{
:0
* (B)
{ }
:0 E
{
:0
* (C)
(action)
:0 E
* (C)
(action)
}
}
Excellente idée!
Donc le drapeau E ne fait pas vraiment un "else if". Ou alors il
faudrait mettre un drapeau E sur la règle avec les conditions B; mais
dans ce cas, que se passe-t-il?
ça n'a pas vraiment de sens ?
C'est un peu ce que je pense. Je crois qu'il faut éviter (même si ça
fonctionne actuellement comme je le veux, je ne pense pas que ce soit
future-proof).
quelle est la règle qui précède immédiatement?
La seule candidate, c'est A, non ?
Peut-être. Mais comme la règle A n'est pas complètement exécutée,
peut-on vraiment dire qu'elle précède?
:0
* !^F
{
# pas de From, donc impossible
Pas de "^From ", c'est une erreur possible
Je pensais plutôt à pas d'en-tête "From:". En fait, je vérifie la
présence d'un "From:" dans une règle précédente:
Dans l'article <slrndl6lgq.a2t.lhh+, Jacques L'helgoualc'h <lhh+ écrit:
Le 16-10-2005, Vincent Lefevre a écrit :
Avec procmail, je voudrais une sorte de "else if". La page man de procmailrc dit:
E This recipe only executes if the immediately preceding recipe was not executed. Execution of this recipe also disables any immedi- ately following recipes with the 'E' flag. This allows you to specify `else if' actions.
Note: je ne peux pas grouper les conditions A et B pour éviter d'utiliser le drapeau E, car les conditions de B s'expriment sur plusieurs lignes et "non (X et Y)" signifie "non X ou non Y", et il n'y a pas moyen d'exprimer le "ou" dans une règle (sauf avec une regexp très compliquée).
Ben, il y a aussi le scoring, ou une construction à la Morgan.
J'ai aussi pensé au scoring (mais la syntaxe est un peu bizarre, alors j'ai toujours peur de faire une erreur bête). La construction à la Morgan, c'est ce que je cherchais à faire, mais je n'avais pas pensé au sous-bloc supplémentaire.
Le problème est que la page man dit "immediately preceding recipe", donc si la 2e règle du bloc (celle avec les conditions C) n'est pas exécutée, alors la 3e règle (celle avec les conditions D) sera exécutée, i.e. si les conditions A, B et D sont vérifiées, alors le message sera rejeté.
Tu l'as vérifié ?
Non. Je suppose que le véritable comportement est différent de celui documenté. L'auteur n'a visiblement pas les idées très claires, et s'il touche au code sans réfléchir plus, un upgrade risque de tout casser! Ceci dit, l'auteur ne veut visiblement plus toucher au code pour cette raison (surtout que c'est écrit assez salement, AMHA).
Bon, dans ton cas je mettrais plutôt un sous-bloc correspondant à (C ou D), pour mieux coller à ton expression logique :
:0 * (A) { :0 * (B) { }
:0 E { :0 * (C) (action)
:0 E * (C) (action) } }
Excellente idée!
Donc le drapeau E ne fait pas vraiment un "else if". Ou alors il faudrait mettre un drapeau E sur la règle avec les conditions B; mais dans ce cas, que se passe-t-il?
ça n'a pas vraiment de sens ?
C'est un peu ce que je pense. Je crois qu'il faut éviter (même si ça fonctionne actuellement comme je le veux, je ne pense pas que ce soit future-proof).
quelle est la règle qui précède immédiatement?
La seule candidate, c'est A, non ?
Peut-être. Mais comme la règle A n'est pas complètement exécutée, peut-on vraiment dire qu'elle précède?
:0 * !^F { # pas de From, donc impossible
Pas de "^From ", c'est une erreur possible
Je pensais plutôt à pas d'en-tête "From:". En fait, je vérifie la présence d'un "From:" dans une règle précédente:
Ben, il y a aussi le scoring, ou une construction à la Morgan.
J'ai aussi pensé au scoring (mais la syntaxe est un peu bizarre,
;)
[...] Je suppose que le véritable comportement est différent de celui documenté. L'auteur n'a visiblement pas les idées très claires, et s'il touche au code sans réfléchir plus, un upgrade risque de tout casser! Ceci dit, l'auteur ne veut visiblement plus toucher au code pour cette raison (surtout que c'est écrit assez salement, AMHA).
Le développement semble figé à la version 3.22 depuis très longtemps... je n'ai pas vérifié si le bug du flag H explicite est enfin corrigé.
[...]
[Maildrop]
Tu l'avais mentionné lors d'une discussion dans debian-user-french. Est-ce qu'il y a des limitations par rapport à procmail?
Pas que je sache ; évidemment, j'ai dû tout reprendre, et en ai profité pour simplifier. Les trucs usuels de procmail ont leur équivalent, et il y a quelques constructions commodes, comme la seule chose un peu compliquée de mon ~/.mailfilter :
MOI="la regexp de mes adresses" # $FROM est défini par maildrop
# [...] if ( lookup("$AUTRES", ".greenlist") ) to .maildirs/dialogues/
La doc est beaucoup plus courte que celle de procmail ; bien sûr, le nombre d'utilisateurs semble plus faible --- mais c'est aussi qu'il n'ont pas besoin d'une ML pour trouver comment faire des trucs (apparemment) simples :) -- Jacques L'helgoualc'h
Le 17-10-2005, Vincent Lefevre a écrit :
Jacques L'helgoualc'h écrit:
[flag E]
Je vais faire un rapport du bug de documentation.
OK.
[ ou ]
Ben, il y a aussi le scoring, ou une construction à la Morgan.
J'ai aussi pensé au scoring (mais la syntaxe est un peu bizarre,
;)
[...] Je suppose que le véritable comportement est différent de celui
documenté. L'auteur n'a visiblement pas les idées très claires, et
s'il touche au code sans réfléchir plus, un upgrade risque de tout
casser! Ceci dit, l'auteur ne veut visiblement plus toucher au code
pour cette raison (surtout que c'est écrit assez salement, AMHA).
Le développement semble figé à la version 3.22 depuis très longtemps...
je n'ai pas vérifié si le bug du flag H explicite est enfin corrigé.
[...]
[Maildrop]
Tu l'avais mentionné lors d'une discussion dans debian-user-french.
Est-ce qu'il y a des limitations par rapport à procmail?
Pas que je sache ; évidemment, j'ai dû tout reprendre, et en ai profité
pour simplifier. Les trucs usuels de procmail ont leur équivalent, et il
y a quelques constructions commodes, comme la seule chose un peu
compliquée de mon ~/.mailfilter :
MOI="la regexp de mes adresses"
# $FROM est défini par maildrop
# [...]
if ( lookup("$AUTRES", ".greenlist") )
to .maildirs/dialogues/
La doc est beaucoup plus courte que celle de procmail ; bien sûr, le
nombre d'utilisateurs semble plus faible --- mais c'est aussi qu'il
n'ont pas besoin d'une ML pour trouver comment faire des trucs
(apparemment) simples :)
--
Jacques L'helgoualc'h
Ben, il y a aussi le scoring, ou une construction à la Morgan.
J'ai aussi pensé au scoring (mais la syntaxe est un peu bizarre,
;)
[...] Je suppose que le véritable comportement est différent de celui documenté. L'auteur n'a visiblement pas les idées très claires, et s'il touche au code sans réfléchir plus, un upgrade risque de tout casser! Ceci dit, l'auteur ne veut visiblement plus toucher au code pour cette raison (surtout que c'est écrit assez salement, AMHA).
Le développement semble figé à la version 3.22 depuis très longtemps... je n'ai pas vérifié si le bug du flag H explicite est enfin corrigé.
[...]
[Maildrop]
Tu l'avais mentionné lors d'une discussion dans debian-user-french. Est-ce qu'il y a des limitations par rapport à procmail?
Pas que je sache ; évidemment, j'ai dû tout reprendre, et en ai profité pour simplifier. Les trucs usuels de procmail ont leur équivalent, et il y a quelques constructions commodes, comme la seule chose un peu compliquée de mon ~/.mailfilter :
MOI="la regexp de mes adresses" # $FROM est défini par maildrop
# [...] if ( lookup("$AUTRES", ".greenlist") ) to .maildirs/dialogues/
La doc est beaucoup plus courte que celle de procmail ; bien sûr, le nombre d'utilisateurs semble plus faible --- mais c'est aussi qu'il n'ont pas besoin d'une ML pour trouver comment faire des trucs (apparemment) simples :) -- Jacques L'helgoualc'h
Vincent Lefevre
Dans l'article <slrndl7eqc.foa.lhh+, Jacques L'helgoualc'h <lhh+ écrit:
Le 17-10-2005, Vincent Lefevre a écrit : [Maildrop]
Tu l'avais mentionné lors d'une discussion dans debian-user-french. Est-ce qu'il y a des limitations par rapport à procmail?
Pas que je sache ; évidemment, j'ai dû tout reprendre, et en ai profité pour simplifier. Les trucs usuels de procmail ont leur équivalent, et il y a quelques constructions commodes, comme la seule chose un peu compliquée de mon ~/.mailfilter : [...]
La doc ne semble pas indiquer comment rejeter un mail (en le bounçant avec message d'erreur configurable).
Dans l'article <slrndl7eqc.foa.lhh+no_spam@ulysse.maison>,
Jacques L'helgoualc'h <lhh+no_spam@free.fr> écrit:
Le 17-10-2005, Vincent Lefevre a écrit :
[Maildrop]
Tu l'avais mentionné lors d'une discussion dans debian-user-french.
Est-ce qu'il y a des limitations par rapport à procmail?
Pas que je sache ; évidemment, j'ai dû tout reprendre, et en ai profité
pour simplifier. Les trucs usuels de procmail ont leur équivalent, et il
y a quelques constructions commodes, comme la seule chose un peu
compliquée de mon ~/.mailfilter :
[...]
La doc ne semble pas indiquer comment rejeter un mail (en le bounçant
avec message d'erreur configurable).
Dans l'article <slrndl7eqc.foa.lhh+, Jacques L'helgoualc'h <lhh+ écrit:
Le 17-10-2005, Vincent Lefevre a écrit : [Maildrop]
Tu l'avais mentionné lors d'une discussion dans debian-user-french. Est-ce qu'il y a des limitations par rapport à procmail?
Pas que je sache ; évidemment, j'ai dû tout reprendre, et en ai profité pour simplifier. Les trucs usuels de procmail ont leur équivalent, et il y a quelques constructions commodes, comme la seule chose un peu compliquée de mon ~/.mailfilter : [...]
La doc ne semble pas indiquer comment rejeter un mail (en le bounçant avec message d'erreur configurable).
Le 17-10-2005, Vincent Lefevre <vincent+ a écrit : [...]
La doc ne semble pas indiquer comment rejeter un mail (en le bounçant avec message d'erreur configurable).
Ah oui --- « man maildropex » donne un exemple de vacation... mais pour les bounces, il y a maintenant trop d'adresses usurpées, et maildrop intervient un peu tard. Amha, le rejet doit intervenir dès la session SMTP. -- Jacques L'helgoualc'h
Le 17-10-2005, Vincent Lefevre <vincent+news@vinc17.org> a écrit :
[...]
La doc ne semble pas indiquer comment rejeter un mail (en le bounçant
avec message d'erreur configurable).
Ah oui --- « man maildropex » donne un exemple de vacation... mais pour
les bounces, il y a maintenant trop d'adresses usurpées, et maildrop
intervient un peu tard. Amha, le rejet doit intervenir dès la session
SMTP.
--
Jacques L'helgoualc'h
Le 17-10-2005, Vincent Lefevre <vincent+ a écrit : [...]
La doc ne semble pas indiquer comment rejeter un mail (en le bounçant avec message d'erreur configurable).
Ah oui --- « man maildropex » donne un exemple de vacation... mais pour les bounces, il y a maintenant trop d'adresses usurpées, et maildrop intervient un peu tard. Amha, le rejet doit intervenir dès la session SMTP. -- Jacques L'helgoualc'h
Vincent Lefevre
Dans l'article <slrndl96qt.oaf.lhh+, Jacques L'helgoualc'h <lhh+ écrit:
Le 17-10-2005, Vincent Lefevre <vincent+ a écrit : [...]
La doc ne semble pas indiquer comment rejeter un mail (en le bounçant avec message d'erreur configurable).
Ah oui --- « man maildropex » donne un exemple de vacation... mais pour les bounces, il y a maintenant trop d'adresses usurpées, et maildrop intervient un peu tard. Amha, le rejet doit intervenir dès la session SMTP.
Ce que je ne contrôle pas du tout puisque la machine héberge plusieurs domaines. Donc pas de maildrop pour moi.
Dans l'article <slrndl96qt.oaf.lhh+no_spam@ulysse.maison>,
Jacques L'helgoualc'h <lhh+no_spam@free.fr> écrit:
Le 17-10-2005, Vincent Lefevre <vincent+news@vinc17.org> a écrit :
[...]
La doc ne semble pas indiquer comment rejeter un mail (en le bounçant
avec message d'erreur configurable).
Ah oui --- « man maildropex » donne un exemple de vacation... mais pour
les bounces, il y a maintenant trop d'adresses usurpées, et maildrop
intervient un peu tard. Amha, le rejet doit intervenir dès la session
SMTP.
Ce que je ne contrôle pas du tout puisque la machine héberge plusieurs
domaines. Donc pas de maildrop pour moi.
Dans l'article <slrndl96qt.oaf.lhh+, Jacques L'helgoualc'h <lhh+ écrit:
Le 17-10-2005, Vincent Lefevre <vincent+ a écrit : [...]
La doc ne semble pas indiquer comment rejeter un mail (en le bounçant avec message d'erreur configurable).
Ah oui --- « man maildropex » donne un exemple de vacation... mais pour les bounces, il y a maintenant trop d'adresses usurpées, et maildrop intervient un peu tard. Amha, le rejet doit intervenir dès la session SMTP.
Ce que je ne contrôle pas du tout puisque la machine héberge plusieurs domaines. Donc pas de maildrop pour moi.
