Page 1 sur 1

Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 22:03
par arnauds
Bonjour à tous, et merci d'avance pour votre aide.
Je suis en train de monter un serveur sous Windows server 2016 pour notre applicatif métier dans mon entreprise. Ce serveur servira uniquement en bureau à distance pour ce logiciel. Les clients messagerie sont en local sur les postes.
Par contre depuis notre application métier, nous pouvons envoyer des fichiers via un client mail. J'ai donc installé thunderbird sur le server pour pouvoir paramétrer les différents comptes des utilisateurs (nous sommes 5), mais je souhaiterai ne pas synchroniser la réception de mail. En gros n'utiliser que l'envoi. Quand on sélectionne la fonction depuis le logiciel, il ouvre thunderbird et on sélectionne le compte avec lequel on veut envoyer le mail, mais Impossible de trouver la solution avec mes maigres connaissances en informatique.
Merci de votre aide si vous avez une idée.
A bientôt.
Arnaud.

Re: Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 22:33
par lool_lauris
Salut,

Jamais fait ce genre de manip mais par exemple si tu ne configures que le serveur sortant (smtp) sur un ou plusieurs comptes... ???

Re: Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 22:54
par Jean-Claude
Bonjour,

Si ton application métier réside sur un serveur dédié, je suppose qu'elle s'exécute néanmoins sur chaque poste client, comme le ferait une application purement locale.
Ce qui permet l'exécution simultanée sur plusieurs postes clients. Chaque poste travaillant avec une instance de cette application.
Dans l'affirmative, cette application devrait d'office appeler le Thunderbird sur le poste client. Il n'y aurait donc rien à paramétrer sur le serveur d'applications.

A+

Re: Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 22:55
par arnauds
Salut.
Il n accepte pas la validation des paramètres sans éléments sur le serveur entrant. J ais essaye...

Re: Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 22:57
par arnauds
Bonsoir.
Non justement l applicatif métier se lance sur le serveur sinon je n aurais pas le problème en effet.

Re: Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 23:06
par lool_lauris
arnauds a écrit : 17 déc. 2018, 22:55 Salut.
Il n accepte pas la validation des paramètres sans éléments sur le serveur entrant. J ais essaye...
Oui c'est sûr mais si tu "trafiques", après coup, un paramètre du serveur entrant, par exemple un port incorrect ?

Re: Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 23:10
par arnauds
Pour valider les paramètres du compte il fait un test, si ce dernier ne marche pas il refuse la validation des paramètres...
J'ai essayé également.
Autant on peut ajouter plusieurs smtp sur un compte autant on ne peut pas ajouter plusieurs pop sur le même compte.
A+

Re: Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 23:17
par Jean-Claude
Chaque utilisateur se connecte-t-il directement au serveur ? Avec un identifiant et un mot de passe ?
Dans l'affirmative, chaque utilisateur a donc un espace personnel "roaming / appdata" sur le serveur.
Si tu te connectes au serveur avec chaque identifiant d'utilisateur potentiel, et que tu lances Thunderbird, tu devrais donc créer autant de profils Thunderbird qu'il y a d'utilisateurs autorisés.
Pour chaque utilisateur, tu pourras créer l'adresse mail propre.
Lorsque l'utilisateur se connecte et lance le logiciel métier, Thunderbird sera d'office connecté au profil de Thunderbird qui lui est propre, et à son adresse mail propre.
Mais cela n'empêchera pas la réception de mails. Je ne vois pas comment limiter Thunderbird à la seule fonction d'envoi.
Si le compte dans Thunderbird est en IMAP, la réception de mails ne devrait pas être trop gênante.

A+

Re: Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 23:30
par arnauds
En effet il faut que j'arrive à associer chaque compte mail à chaque session windows et par créer l'ensemble dans toutes les sessions, tu as raison, il faut que je regarde comment paramétrer cela dans ce sens sur W16. c'etait pour un problème de confidentialité mais en effet si seul le compte de l'utilisateur remonte dans la session rds c'est beaucoup plus cohérent.
Merci pour votre aide!

Je viens de réessayer de trafiquer les valeurs, ca marche si on ne laisse pas le champs vide comme je l'avais fait au premier coup. mais je vais mettre en place la deuxième solution c'est plus propore me semblet-il.
A bientôt.

Re: Utiliser uniquement l'envoi

Publié : 17 déc. 2018, 23:52
par Jean-Claude
arnauds a écrit : 17 déc. 2018, 23:30 c'etait pour un problème de confidentialité mais en effet si seul le compte de l'utilisateur remonte dans la session rds c'est beaucoup plus cohérent.
Cette sécurité ne sera garantie que si l'utilisateur n'a pas les droits "Admin" sur le serveur. Ainsi, il ne pourra pas ouvrir l'espace personnel (appdata) d'un autre.
Mais tu devras connaître le mot de passe du compte Thunderbird de chaque utilisateur si tu veux créer son adresse dans Thunderbird. Ce qui est gênant, et pourrait te créer un problème lorsque l'utilisateur change son mot de passe Thunderbird sur son PC. Il devrait donc, en plus, pouvoir faire (et y penser) ce changement dans son Thunderbird sur le serveur.
Cette configuration ne me semble pas idéale.
Actuellement en entreprise, je pense qu'idéalement, on virtualiserait les applications métiers, résidant sur un serveur d'applications, pour que ce soit une instance virtualisée qui s'exécute sur chaque PC client, comme une application locale.

A+

Re: Utiliser uniquement l'envoi

Publié : 18 déc. 2018, 09:43
par arnauds
Ok, merci de ta réponse, en effet ce n'est pas idéal en terme de gestion des mots de passe de messagerie, à l'heure actuelle, je les gère tous et je ne sais même pas si mes collaborateurs connaissent leur mot de passe de (j'avais tout paramétré à la livraison des postes, et nous sommes très peu à utiliser le webmail. nous sommes chez OVH pour l'hebergement). Cela reste gérable pour moi de cette manière.
En ce qui concerne l'applicatif métier, Batigest de chez Sage, le lancement de l'applicatif via le serveur n'est pas possible en local, la base de données est trop importante pour nos débits de connexion. Nous sommes multi sites et la solution retenue du bureau à distance est justement là pour permettre le nomadisme aux collaborateurs itinérants.
A+