Discussion :

[Pfeffer]

Bonjour,

Si je viens vers vous c'est pour avoir vos opinions sur une stratégie de groupe au niveau développement de nos applications.

Historiquement, nous avons dans notre entreprise des applications WinForm, Windows Service et portail Web (C#, ASP.NET). Nous sommes une équipe de quelques développeurs qui maintiennent ces applications et qui développe les nouveaux besoins.

Aujourd'hui la politique du groupe change, on soutraite (même si c'est cher)... Et nos postes de développement sont bridés pour des raisons de sécurité. Merci de me donner votre ressentis sur les exemples suivants et d'argumenter si vous pouvez.

Ex1:
Nos applications WinForm qui tournent sur des postes clients ne peuvent plus utiliser certaines fonctionnalités qui permettent entre autre d'envoyer des mails de notification préconçus par SMTP. En effet on ne peut plus attaquer le SMTP directement, il rejette les adresses IP des utilisateurs !

La solution qu'on nous propose de mettre en place, c'est d'utiliser l'Outlook de l'utilisateur par nos applications pour palier à ce problème !
Qu'en pensez vous ?

Pour ma part je trouve cela aberrant dans le sens ou si une application tente d'envoyer un mail à partir de l'Outlook de l'utilisateur, un message de sécurité apparaît indiquant que quelqu'un tente d'envoyer un mail ... Bref si on ne veut pas que les utilisateurs soient dérangés toutes les 5 minutes par ce message, il faut reconfigurer Outlook sur chaque poste client pour que ce message n'apparaisse plus. Au niveau de la sécurité cela me parait nettement moins bien.

Ex2:
Aujourd'hui on nous demande de maintenir un Windows Service qui se connecte à une plateforme FTPS. Problème, avec les contraintes de sécurité qui ont été mises en place, à partir de nos postes de développement on ne peut plus attaquer la plateforme FTPS.

La solution qu'on nous propose, est d'utiliser "Remote Debugging" pour faire du pas à pas et développer notre outil.

Qu'en pensez vous?

Pour ma part, un poste de développement doit avoir toutes les configurations requises pour être dans le même environnement que la machine AQ et PROD.

[Logan Mauzaize]

Je dirai que vous avez de très mauvais administrateur système ?

Il est tout à fait possible de configurer finement les restrictions/exceptions réseaux pour interdire/autoriser :

• certaines applications : Outlook
• certains protocoles applicatifs : SMTP
• certains ports : 25
• certaines destination pour les ports sortants (cas d'un filtrage depuis la machine) : le serveur de messagerie
• etc.

Ces conditions pouvant être mariés avec autant de joie qu'on le fait avec nos chers opérateurs SQL ^^.
Le filtrage pouvant s'opérer tant au niveau du poste (avec un pare-feu) que de l'équipement réseau (avec un routeur).

Un exemple de configuration dans votre cas. Dans l'annuaire d'entreprise créé un groupe qui décrit les gens qui sont autorisés à exécuter votre(s) applications(s) et pour toutes ces personnes autoriser le traffic des exécutables concernés à ouvrir le port SMTP (25) vers le serveur de messagerie (ou un relai).

[Pfeffer]

Et selon vous la solution d'utiliser Outlook comme relais dans nos applications .NET ça vous parait être une idée défendable? Ou non ?

[Logan Mauzaize]

Je poserai la question autrement :

• Est-ce que l'utilisation d'Outlook a un impact utilisateur ? Si oui, c'est aux utilisateurs de répondre (ou un réprésentant : AMOA, MOA, etc.)
• En sus, est-ce que le coût, les délais et les moyens technique (quoique c'est qu'une question de coût ou de pression hiérarchique) pour faire autrement correspondent aux contraintes du projet ? Et c'est à vous et la MOA de répondre à cette dernière question

[Mat.M]

Et selon vous la solution d'utiliser Outlook comme relais dans nos applications .NET ça vous parait être une idée défendable? Ou non ?

bonjour pourquoi vouloir utiliser Outlook pour la couche/partie envoi de messages ?
Je viens de quitter un projet de développement ( logiciel de diagnostic immobilier), le logiciel utilise Word pour imprimer les documents.
Et si on veut utiliser ce logiciel de diagnostic immobilier ,il n'y pas de module d'impression interne ce qui fait que c'est impossible d'imprimer des diagnostics immobiliers sans Ms-Word ,eh bien le client doit passer à la caisse et payer une licence Ms-Office et c'est pour ça que Microsoft gagne de l'argent..
ce n'est pas le seul projet d'ailleurs sur lequel j'ai travaillé.
J'ai aussi travaillé sur un logiciel où il y avait des courbes à sortir et pareil le client qui achetait le logiciel devait également acheter Ms-Office pour imprimer les courbes.
Parce que c'est une grosse facilité de piloter Word ou Excel pour imprimer...plutôt que de se casser la tête

Parenthèse et digression mise de côté,passer par les outils de Ms-Office par certains côtés c'est très pratique parce qu'il y a d'excellentes fonctionnalités et ça fait gagner du temps
Si on doit tout redévelopper une couche d'envoi d'email par SMPT ça va prendre du temps.

Le revers de la médaille c'est que tu ne peux pas toujours faire ce que tu veux avec les outils MS-Office et notamment, parfois ce qui se passe c'est des fenêtres modales qui s'affichent de manière impronptue ;

Pour ma part je trouve cela aberrant dans le sens ou si une application tente d'envoyer un mail à partir de l'Outlook de l'utilisateur, un message de sécurité apparaît indiquant que quelqu'un tente d'envoyer un mail ...

c'est ce que j'ai voulu expliquer.
Personnellement ça ne fait pas du tout pro de rebidouiller après

Donc je ce que je conseille c'est de prendre un petit peu de temps de bien étudier les possibilités de liaison logicielle avec Outlook,étudier toute la hiérarchie de classes d'Outlook , de faire des petits projets/programmes d'essai qui pilotent Outlook avec C# ou VB.NET et voir si Outlook satisfait les besoins.

Si tu utilises Outlook le projet logiciel aura une autre dépendance logicielle..
il faut tenir compte de ça et je serais tenté d'écrire "on n'est jamais mieux servi que par soi-même"
L'inconvénient de cette formule c'est que ça prend du temps de développement et que ça risque de coûter financièrement sur un projet de développement

La solution qu'on nous propose de mettre en place, c'est d'utiliser l'Outlook de l'utilisateur par nos applications pour palier à ce problème !
Qu'en pensez vous ?

attention avec cette logique : si dans ton projet NET, tu crées des objets Outlook tu les appelles pour envoyer des messages ok c'est bien...
Mais que du jour au lendemain Microsoft décide de modifier les classes d'Outlook accessibles en .NET (ou autres) bref le SDK d'Outlook eh bien il faut tout réecrire !
C'est comme les incompatibilités de framework entre le Framework 1.0 .NETet le dernier qui vient d'être mis-à-disposition ( le 4.5)
C'est ça le problème d'être dépendant d'un point de vue logiciel

Maintenat pour ce qui est du problème d'envoi d'emails c'est un problème d'administrateurs système comme le mentionne mon prédecesseur Nemek

[lunatix]

De mon experience, il faut s'appuyer le moins possible sur le poste client (trop variable, trop de changement etc...)

si le smtp n'est plus accessible, collez un web service dessus pour le masquer, et mettez un client ws dans l'application cliente.