Salut,
Je cherche qqun pour h=E9berger un service SMTP pour les collaborateurs =
de ma boite quand ils sont chez des clients. S'il y a du SSL c'est =
mieux.
Pour ceux qui sont int=E9ress=E9s, =E9vitez =E0 tout prix le MailPlan =
d'OVH : 1.20 Eur une fois pour toutes mais merci la qualit=E9 de service =
! En ce moment tout ce qui sort est tagg=E9 comme spam !! La classe =
quand on envoie une propale =E0 un client !!!!
Merci du tuyau.
Raph
bah... je ne sais pas mais il me semble que la proportion de serveurs de mails qui mettent en oeuvre le SMTP AUTH est quand même importante...
Si le SMTP AUTH était à déconseiller,... peut-etre que sans SSL c'est parceque ça fait transiter les identifiant presque en clair (juste un encodage base64?) ? mais bon...
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Tue, 08 Mar 2005 20:15:16 +0100 ) Raph :
[...]
bah... je ne sais pas mais il me semble que la proportion de serveurs de
mails qui mettent en oeuvre le SMTP AUTH est quand même importante...
Si le SMTP AUTH était à déconseiller,... peut-etre que sans SSL c'est
parceque ça fait transiter les identifiant presque en clair (juste un
encodage base64?) ? mais bon...
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
bah... je ne sais pas mais il me semble que la proportion de serveurs de mails qui mettent en oeuvre le SMTP AUTH est quand même importante...
Si le SMTP AUTH était à déconseiller,... peut-etre que sans SSL c'est parceque ça fait transiter les identifiant presque en clair (juste un encodage base64?) ? mais bon...
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Raph
"Rakotomandimby (R12y) Mihamina" a écrit dans le message de news:
bah... je ne sais pas mais il me semble que la proportion de serveurs de mails qui mettent en oeuvre le SMTP AUTH est quand même importante...
Si le SMTP AUTH était à déconseiller,... peut-etre que sans SSL c'est parceque ça fait transiter les identifiant presque en clair (juste un encodage base64?) ? mais bon...
Voila les raisons, avec lesquelles je suis assez d'accord finalement :
<< Des solutions pour permettre l'autentification par d'autres biais tout en evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui ont certes le merite d'exister, mais necessitent une intervention specifique en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
"Rakotomandimby (R12y) Mihamina" <mihamina@mail.rktmb.org> a écrit dans le message de news: pan.2005.03.08.19.20.47.164443@mail.rktmb.org...
bah... je ne sais pas mais il me semble que la proportion de serveurs de
mails qui mettent en oeuvre le SMTP AUTH est quand même importante...
Si le SMTP AUTH était à déconseiller,... peut-etre que sans SSL c'est
parceque ça fait transiter les identifiant presque en clair (juste un
encodage base64?) ? mais bon...
Voila les raisons, avec lesquelles je suis assez d'accord finalement :
<< Des solutions pour permettre l'autentification par d'autres biais tout en
evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth
et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui
ont certes le merite d'exister, mais necessitent une intervention specifique
en vue de les installer (d'où facturation supplémentaire), et leur présence
pourrait représenter un risque potentiel de sécurité pour votre serveur (ou
d'utilisation mauvaise/abusive par un de vos clients) >>
"Rakotomandimby (R12y) Mihamina" a écrit dans le message de news:
bah... je ne sais pas mais il me semble que la proportion de serveurs de mails qui mettent en oeuvre le SMTP AUTH est quand même importante...
Si le SMTP AUTH était à déconseiller,... peut-etre que sans SSL c'est parceque ça fait transiter les identifiant presque en clair (juste un encodage base64?) ? mais bon...
Voila les raisons, avec lesquelles je suis assez d'accord finalement :
<< Des solutions pour permettre l'autentification par d'autres biais tout en evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui ont certes le merite d'exister, mais necessitent une intervention specifique en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
Spyou
<< Des solutions pour permettre l'autentification par d'autres biais tout en evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui ont certes le merite d'exister, mais necessitent une intervention specifique en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
Le probleme sera le meme chez un prestataire X ou Y fournissant un service de SMTP. tu restera responsable de ce que tu fais avec.
<< Des solutions pour permettre l'autentification par d'autres biais tout en
evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth
et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui
ont certes le merite d'exister, mais necessitent une intervention specifique
en vue de les installer (d'où facturation supplémentaire), et leur présence
pourrait représenter un risque potentiel de sécurité pour votre serveur (ou
d'utilisation mauvaise/abusive par un de vos clients) >>
Le probleme sera le meme chez un prestataire X ou Y fournissant un
service de SMTP. tu restera responsable de ce que tu fais avec.
<< Des solutions pour permettre l'autentification par d'autres biais tout en evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui ont certes le merite d'exister, mais necessitent une intervention specifique en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
Le probleme sera le meme chez un prestataire X ou Y fournissant un service de SMTP. tu restera responsable de ce que tu fais avec.
fox[
Raph wrote:
[snip]
Voila les raisons, avec lesquelles je suis assez d'accord finalement :
<< Des solutions pour permettre l'autentification par d'autres biais tout en evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui ont certes le merite d'exister, mais necessitent une intervention specifique en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
Si on raisonne comme cela alors il vaut mieux eviter d'installer un SMTP, ca prend du temps et cela, je cite: "pourrait représenter un risque potentiel de sécurité pour votre serveur". Et puis pareil pour tous les autres services...
Fox.
Raph wrote:
[snip]
Voila les raisons, avec lesquelles je suis assez d'accord finalement :
<< Des solutions pour permettre l'autentification par d'autres biais tout en
evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth
et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui
ont certes le merite d'exister, mais necessitent une intervention specifique
en vue de les installer (d'où facturation supplémentaire), et leur présence
pourrait représenter un risque potentiel de sécurité pour votre serveur (ou
d'utilisation mauvaise/abusive par un de vos clients) >>
Si on raisonne comme cela alors il vaut mieux eviter d'installer un
SMTP, ca prend du temps et cela, je cite: "pourrait représenter un
risque potentiel de sécurité pour votre serveur". Et puis pareil pour
tous les autres services...
Voila les raisons, avec lesquelles je suis assez d'accord finalement :
<< Des solutions pour permettre l'autentification par d'autres biais tout en evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui ont certes le merite d'exister, mais necessitent une intervention specifique en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
Si on raisonne comme cela alors il vaut mieux eviter d'installer un SMTP, ca prend du temps et cela, je cite: "pourrait représenter un risque potentiel de sécurité pour votre serveur". Et puis pareil pour tous les autres services...
Fox.
Rakotomandimby (R12y) Mihamina
( Wed, 09 Mar 2005 11:46:56 +0100 ) Raph :
Si le SMTP AUTH était à déconseiller,... peut-etre que sans SSL c'est parceque ça fait transiter les identifiant presque en clair (juste un encodage base64?) ? mais bon...
Voila les raisons, avec lesquelles je suis assez d'accord finalement :
<< Des solutions pour permettre l'autentification par d'autres biais tout en evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui ont certes le merite d'exister, mais necessitent une intervention specifique en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
Je redirige vers fr.comp.mail.serveurs.
D'une part tu dis qu'ils déconseillent le SMTP AUTH, mais ils ne proposent pas de solutions alternatives.
Pourtant tous les serveurs de mails qui existent ont bien un truc pour ne pas rester relai ouvert.
Deuxièmement, en fait c'est tu voulais que le SMTP AUTH soit implémenté gratuitement par quelqu'un pour toi, sur ton serveur. Je dis cela parcequ'ils justifient une facturation (mais c'est vrai que ce n'est pas une preuve que tu l'a demandé gratuitement, c'est vrai)
Dans le cas le plus simple il s'agit de rajouter quelques lignes dans le fichier de conf, mais les cas sont loins d'etre toujours simples. Donc tu as un dédié, tant qu'a payer, autant payer pour l'implémentation du SMTP AUTH que de payer ailleurs, en plus...
Quant à la possibilité que tes clients (collabos en fait) en abusent, ben je pense que c'est à toi de les soumettre à une certaine dicsipline et "charte d'utilisation". Parceque si par crainte des abus des autres on s'abstenait, on ne sortirai pas de chez soi... :-)
Récapitulons: - T'as quoi comme serveur de mail (MTA)? version ? - quel OS? version ? - Quelle st la conf actuelle ? - Et avec ces renseignement on devrait déjà avoir une idée du niveau de difficulté de la chose.
Tu peux faire aussi une petite recherche sur google avec "smtp auth <le_nom_de_ton_serveur>" pour voir un peu commentça se passe... Si ça se trouve tu peux le faire toi-même...
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Wed, 09 Mar 2005 11:46:56 +0100 ) Raph :
Si le SMTP AUTH était à déconseiller,... peut-etre que sans SSL c'est
parceque ça fait transiter les identifiant presque en clair (juste un
encodage base64?) ? mais bon...
Voila les raisons, avec lesquelles je suis assez d'accord finalement :
<< Des solutions pour permettre l'autentification par d'autres biais tout en
evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth
et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui
ont certes le merite d'exister, mais necessitent une intervention specifique
en vue de les installer (d'où facturation supplémentaire), et leur présence
pourrait représenter un risque potentiel de sécurité pour votre serveur (ou
d'utilisation mauvaise/abusive par un de vos clients) >>
Je redirige vers fr.comp.mail.serveurs.
D'une part tu dis qu'ils déconseillent le SMTP AUTH, mais ils ne
proposent pas de solutions alternatives.
Pourtant tous les serveurs de mails qui existent ont bien un truc pour ne
pas rester relai ouvert.
Deuxièmement, en fait c'est tu voulais que le SMTP AUTH soit
implémenté gratuitement par quelqu'un pour toi, sur ton serveur. Je dis
cela parcequ'ils justifient une facturation (mais c'est vrai que ce n'est
pas une preuve que tu l'a demandé gratuitement, c'est vrai)
Dans le cas le plus simple il s'agit de rajouter quelques lignes dans le
fichier de conf, mais les cas sont loins d'etre toujours simples. Donc tu
as un dédié, tant qu'a payer, autant payer pour l'implémentation du
SMTP AUTH que de payer ailleurs, en plus...
Quant à la possibilité que tes clients (collabos en fait) en abusent,
ben je pense que c'est à toi de les soumettre à une certaine dicsipline
et "charte d'utilisation". Parceque si par crainte des abus des autres on
s'abstenait, on ne sortirai pas de chez soi... :-)
Récapitulons:
- T'as quoi comme serveur de mail (MTA)? version ?
- quel OS? version ?
- Quelle st la conf actuelle ?
- Et avec ces renseignement on devrait déjà avoir une idée du niveau de
difficulté de la chose.
Tu peux faire aussi une petite recherche sur google avec "smtp auth
<le_nom_de_ton_serveur>" pour voir un peu commentça se passe... Si ça se
trouve tu peux le faire toi-même...
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Si le SMTP AUTH était à déconseiller,... peut-etre que sans SSL c'est parceque ça fait transiter les identifiant presque en clair (juste un encodage base64?) ? mais bon...
Voila les raisons, avec lesquelles je suis assez d'accord finalement :
<< Des solutions pour permettre l'autentification par d'autres biais tout en evitant d'etre un relai ouvert ("open relay") existent, comme SMTP_auth et POP before SMTP que vous citez, mais il s'agit là d'ajouts tardifs qui ont certes le merite d'exister, mais necessitent une intervention specifique en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
Je redirige vers fr.comp.mail.serveurs.
D'une part tu dis qu'ils déconseillent le SMTP AUTH, mais ils ne proposent pas de solutions alternatives.
Pourtant tous les serveurs de mails qui existent ont bien un truc pour ne pas rester relai ouvert.
Deuxièmement, en fait c'est tu voulais que le SMTP AUTH soit implémenté gratuitement par quelqu'un pour toi, sur ton serveur. Je dis cela parcequ'ils justifient une facturation (mais c'est vrai que ce n'est pas une preuve que tu l'a demandé gratuitement, c'est vrai)
Dans le cas le plus simple il s'agit de rajouter quelques lignes dans le fichier de conf, mais les cas sont loins d'etre toujours simples. Donc tu as un dédié, tant qu'a payer, autant payer pour l'implémentation du SMTP AUTH que de payer ailleurs, en plus...
Quant à la possibilité que tes clients (collabos en fait) en abusent, ben je pense que c'est à toi de les soumettre à une certaine dicsipline et "charte d'utilisation". Parceque si par crainte des abus des autres on s'abstenait, on ne sortirai pas de chez soi... :-)
Récapitulons: - T'as quoi comme serveur de mail (MTA)? version ? - quel OS? version ? - Quelle st la conf actuelle ? - Et avec ces renseignement on devrait déjà avoir une idée du niveau de difficulté de la chose.
Tu peux faire aussi une petite recherche sur google avec "smtp auth <le_nom_de_ton_serveur>" pour voir un peu commentça se passe... Si ça se trouve tu peux le faire toi-même...
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Raph
"Spyou" a écrit dans le message de news: 422eda44$0$27047$
Le probleme sera le meme chez un prestataire X ou Y fournissant un service de SMTP. tu restera responsable de ce que tu fais avec.
Oui mais le jour où un collaborateur se fait piquer ses identifiants, c'est pas mon serveur qui sera saturé et blacklisté à cause d'un spammeur quelconque ...
"Spyou" <root@spyou.org> a écrit dans le message de news: 422eda44$0$27047$626a14ce@news.free.fr...
Le probleme sera le meme chez un prestataire X ou Y fournissant un
service de SMTP. tu restera responsable de ce que tu fais avec.
Oui mais le jour où un collaborateur se fait piquer ses identifiants, c'est pas mon serveur qui sera saturé et blacklisté à cause d'un spammeur quelconque ...
"Spyou" a écrit dans le message de news: 422eda44$0$27047$
Le probleme sera le meme chez un prestataire X ou Y fournissant un service de SMTP. tu restera responsable de ce que tu fais avec.
Oui mais le jour où un collaborateur se fait piquer ses identifiants, c'est pas mon serveur qui sera saturé et blacklisté à cause d'un spammeur quelconque ...
Rakotomandimby (R12y) Mihamina
( Wed, 09 Mar 2005 12:59:51 +0100 ) Raph :
Oui mais le jour où un collaborateur se fait piquer ses identifiants
...tu les changeras. Les identifiants, ça se change. Il y a des serveurs de mail qui font des stats. Si tu vois une activité supérieure à la normale, tu commence par changer les identifians. si ça revient, c'est que c'est bon. Si ça revient pas, alors là tu t'insquiète.
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Wed, 09 Mar 2005 12:59:51 +0100 ) Raph :
Oui mais le jour où un collaborateur se fait piquer ses identifiants
...tu les changeras. Les identifiants, ça se change.
Il y a des serveurs de mail qui font des stats.
Si tu vois une activité supérieure à la normale, tu commence par
changer les identifians. si ça revient, c'est que c'est bon. Si ça
revient pas, alors là tu t'insquiète.
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Oui mais le jour où un collaborateur se fait piquer ses identifiants
...tu les changeras. Les identifiants, ça se change. Il y a des serveurs de mail qui font des stats. Si tu vois une activité supérieure à la normale, tu commence par changer les identifians. si ça revient, c'est que c'est bon. Si ça revient pas, alors là tu t'insquiète.
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Raph
"Rakotomandimby (R12y) Mihamina" a écrit dans le message de news:
Deuxièmement, en fait c'est tu voulais que le SMTP AUTH soit implémenté gratuitement par quelqu'un pour toi, sur ton serveur. Je dis
Non je n'ai pass demandé gratuitement. C'est juste un souci "sécuritaire".
Dans le cas le plus simple il s'agit de rajouter quelques lignes dans le fichier de conf, mais les cas sont loins d'etre toujours simples. Donc tu as un dédié, tant qu'a payer, autant payer pour l'implémentation du SMTP AUTH que de payer ailleurs, en plus...
En fait je n'ai pas le root. C'est une formule d'infogérance assez sympa puisqu'elle me permet de ne pas me soucier des mises à jour du serveur. Ca m'a surpris au début, mais finalement je n'ai pas du tout envie de changer, je n'ai plus le stress permanent de la faille !!
"Rakotomandimby (R12y) Mihamina" <mihamina@mail.rktmb.org> a écrit dans le message de news: pan.2005.03.09.11.46.22.740297@mail.rktmb.org...
Deuxièmement, en fait c'est tu voulais que le SMTP AUTH soit
implémenté gratuitement par quelqu'un pour toi, sur ton serveur. Je dis
Non je n'ai pass demandé gratuitement. C'est juste un souci "sécuritaire".
Dans le cas le plus simple il s'agit de rajouter quelques lignes dans le
fichier de conf, mais les cas sont loins d'etre toujours simples. Donc tu
as un dédié, tant qu'a payer, autant payer pour l'implémentation du
SMTP AUTH que de payer ailleurs, en plus...
En fait je n'ai pas le root. C'est une formule d'infogérance assez sympa puisqu'elle me permet de ne pas me soucier des mises à jour du serveur. Ca m'a surpris au début, mais finalement je n'ai pas du tout envie de changer, je n'ai plus le stress permanent de la faille !!
"Rakotomandimby (R12y) Mihamina" a écrit dans le message de news:
Deuxièmement, en fait c'est tu voulais que le SMTP AUTH soit implémenté gratuitement par quelqu'un pour toi, sur ton serveur. Je dis
Non je n'ai pass demandé gratuitement. C'est juste un souci "sécuritaire".
Dans le cas le plus simple il s'agit de rajouter quelques lignes dans le fichier de conf, mais les cas sont loins d'etre toujours simples. Donc tu as un dédié, tant qu'a payer, autant payer pour l'implémentation du SMTP AUTH que de payer ailleurs, en plus...
En fait je n'ai pas le root. C'est une formule d'infogérance assez sympa puisqu'elle me permet de ne pas me soucier des mises à jour du serveur. Ca m'a surpris au début, mais finalement je n'ai pas du tout envie de changer, je n'ai plus le stress permanent de la faille !!
Laurent SINTES
en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
Si on raisonne comme cela alors il vaut mieux eviter d'installer un SMTP, ca prend du temps et cela, je cite: "pourrait représenter un risque potentiel de sécurité pour votre serveur".
Chaque prestataire a sa spécificité. Chez nous, c'est d'être très à cheval sur la sécurité et encore plus spécifiquement sur le problème du spam. Et vu que l'on garantit le fonctionnement du serveur, il est normal que nous prévenions nos clients des risques liés aux demandes qu'ils formulent.
Une fois averti des avantages et inconvénients, il peuvent s'orienter vers telle ou telle solution en toute connaissance de cause.
Et puis pareil pour tous les autres services...
Je ne suis pas d'accord, il est existe des services plus sensibles que d'autres. Meme si le smtp est moins sensible que des abominations comme telnet ou rlogin, il n'en demeure pas moins un service sur lequel il faut faire très attention, surtout quand on commence à distibuer des identifications pour SMTP_AUTH.
en vue de les installer (d'où facturation supplémentaire), et leur présence
pourrait représenter un risque potentiel de sécurité pour votre serveur (ou
d'utilisation mauvaise/abusive par un de vos clients) >>
Si on raisonne comme cela alors il vaut mieux eviter d'installer un
SMTP, ca prend du temps et cela, je cite: "pourrait représenter un
risque potentiel de sécurité pour votre serveur".
Chaque prestataire a sa spécificité. Chez nous, c'est d'être très
à cheval sur la sécurité et encore plus spécifiquement sur le
problème du spam. Et vu que l'on garantit le fonctionnement du serveur,
il est normal que nous prévenions nos clients des risques liés aux
demandes qu'ils formulent.
Une fois averti des avantages et inconvénients, il peuvent s'orienter
vers telle ou telle solution en toute connaissance de cause.
Et puis pareil pour
tous les autres services...
Je ne suis pas d'accord, il est existe des services plus sensibles
que d'autres. Meme si le smtp est moins sensible que des abominations
comme telnet ou rlogin, il n'en demeure pas moins un service sur
lequel il faut faire très attention, surtout quand on commence à
distibuer des identifications pour SMTP_AUTH.
en vue de les installer (d'où facturation supplémentaire), et leur présence pourrait représenter un risque potentiel de sécurité pour votre serveur (ou d'utilisation mauvaise/abusive par un de vos clients) >>
Si on raisonne comme cela alors il vaut mieux eviter d'installer un SMTP, ca prend du temps et cela, je cite: "pourrait représenter un risque potentiel de sécurité pour votre serveur".
Chaque prestataire a sa spécificité. Chez nous, c'est d'être très à cheval sur la sécurité et encore plus spécifiquement sur le problème du spam. Et vu que l'on garantit le fonctionnement du serveur, il est normal que nous prévenions nos clients des risques liés aux demandes qu'ils formulent.
Une fois averti des avantages et inconvénients, il peuvent s'orienter vers telle ou telle solution en toute connaissance de cause.
Et puis pareil pour tous les autres services...
Je ne suis pas d'accord, il est existe des services plus sensibles que d'autres. Meme si le smtp est moins sensible que des abominations comme telnet ou rlogin, il n'en demeure pas moins un service sur lequel il faut faire très attention, surtout quand on commence à distibuer des identifications pour SMTP_AUTH.
fox[
Laurent SINTES wrote:
Chaque prestataire a sa spécificité. Chez nous, c'est d'être très à cheval sur la sécurité et encore plus spécifiquement sur le problème du spam. Et vu que l'on garantit le fonctionnement du serveur, il est normal que nous prévenions nos clients des risques liés aux demandes qu'ils formulent.
Une fois averti des avantages et inconvénients, il peuvent s'orienter vers telle ou telle solution en toute connaissance de cause.
Je ne suis pas d'accord, il est existe des services plus sensibles que d'autres. Meme si le smtp est moins sensible que des abominations comme telnet ou rlogin, il n'en demeure pas moins un service sur lequel il faut faire très attention, surtout quand on commence à distibuer des identifications pour SMTP_AUTH.
Donc, si j'en crois votre post precedent, vous faites plus facilement confiance a une IP fixe (se trouve-t-elle derriere un firewall ? se firewall est-il VRAIMENT bien configure ? les personnes ayant des windows au bout de cette IP fixe sont ils des idiots qui se loguent le matin en arrivant sur leur windows prefere avec le login 'Administrateur' ? etc...) qu'a un login / mot de passe ? A savoir que si vous leur demandez de ne pas laisser leur MUA prefere memoriser ces memes login / mot de passe il sera peut-etre plus difficile de leur voler que de trouver un windows XP pas ou peu a jour avec un pauvre Blaster et cie :)
Il y a la une logique qui m'echappe quelque peu, mais pourquoi pas :)
En parlant d'autres services *a risques* , vous leur donnez un acces FTP a vos clients ? :)
Laurent SINTES wrote:
Chaque prestataire a sa spécificité. Chez nous, c'est d'être très
à cheval sur la sécurité et encore plus spécifiquement sur le
problème du spam. Et vu que l'on garantit le fonctionnement du serveur,
il est normal que nous prévenions nos clients des risques liés aux
demandes qu'ils formulent.
Une fois averti des avantages et inconvénients, il peuvent s'orienter
vers telle ou telle solution en toute connaissance de cause.
Je ne suis pas d'accord, il est existe des services plus sensibles
que d'autres. Meme si le smtp est moins sensible que des abominations
comme telnet ou rlogin, il n'en demeure pas moins un service sur
lequel il faut faire très attention, surtout quand on commence à
distibuer des identifications pour SMTP_AUTH.
Donc, si j'en crois votre post precedent, vous faites plus facilement
confiance a une IP fixe (se trouve-t-elle derriere un firewall ? se
firewall est-il VRAIMENT bien configure ? les personnes ayant des
windows au bout de cette IP fixe sont ils des idiots qui se loguent le
matin en arrivant sur leur windows prefere avec le login
'Administrateur' ? etc...) qu'a un login / mot de passe ?
A savoir que si vous leur demandez de ne pas laisser leur MUA prefere
memoriser ces memes login / mot de passe il sera peut-etre plus
difficile de leur voler que de trouver un windows XP pas ou peu a jour
avec un pauvre Blaster et cie :)
Il y a la une logique qui m'echappe quelque peu, mais pourquoi pas :)
En parlant d'autres services *a risques* , vous leur donnez un acces
FTP a vos clients ? :)
Chaque prestataire a sa spécificité. Chez nous, c'est d'être très à cheval sur la sécurité et encore plus spécifiquement sur le problème du spam. Et vu que l'on garantit le fonctionnement du serveur, il est normal que nous prévenions nos clients des risques liés aux demandes qu'ils formulent.
Une fois averti des avantages et inconvénients, il peuvent s'orienter vers telle ou telle solution en toute connaissance de cause.
Je ne suis pas d'accord, il est existe des services plus sensibles que d'autres. Meme si le smtp est moins sensible que des abominations comme telnet ou rlogin, il n'en demeure pas moins un service sur lequel il faut faire très attention, surtout quand on commence à distibuer des identifications pour SMTP_AUTH.
Donc, si j'en crois votre post precedent, vous faites plus facilement confiance a une IP fixe (se trouve-t-elle derriere un firewall ? se firewall est-il VRAIMENT bien configure ? les personnes ayant des windows au bout de cette IP fixe sont ils des idiots qui se loguent le matin en arrivant sur leur windows prefere avec le login 'Administrateur' ? etc...) qu'a un login / mot de passe ? A savoir que si vous leur demandez de ne pas laisser leur MUA prefere memoriser ces memes login / mot de passe il sera peut-etre plus difficile de leur voler que de trouver un windows XP pas ou peu a jour avec un pauvre Blaster et cie :)
Il y a la une logique qui m'echappe quelque peu, mais pourquoi pas :)
En parlant d'autres services *a risques* , vous leur donnez un acces FTP a vos clients ? :)
