envoi automatique de messages par une application

Anor

07/06/2004 à 20:44

Bonjour,
ça dépend du langage utilisé par ton application.

Soit tu envoies tes messages avec CDO
http://memoaccess.free.fr/outlook.htm#SendMailCDO

Soit tu pilotes outlook par automation ou Simple MAPI,
mais tu installes un petit programme résident qui clique
sur le bouton de confirmation à ta place lorsqu'il apparaît :

http://www.express-soft.com/ftp/ClickYesSetup.exe

hum... tiens...étrange ... l'éditeur ne le propose plus en téléchargement
depuis ses pages html directement .....??

Voilà
à+

--
Arnaud
--------------------------------------------------
Site Perso : http://memoaccess.free.fr
/Réponses souhaitées sur ce forum, merci/
--------------------------------------------------

| Bonjour,
|
| J'utilise une application qui publie automatiquement des
| mails avec Outlook 2002.
|
| Outlook réagit avec un message d'avertissement de
| sécurité :
|
| " Un programme tente d'envoyer automatiquerment des
| courriers en votre nom. L'autorisez vous à poursuivre ?
| Si cette action est inattendue, il se peut qu'il s'agisse
| d'un virus : dans ce cas, choisissez Non. "
|
| Comment contourner (ou déseactiver) cet avertissement qui
| empêche les envois automatique via des programmes tiers ?
|
| p.s. : Contrairement au cas exposé dans la base de
| connaissances, je n'ai aucun bidule "ICQ..." à désactiver.
|
| Merci d'avance pour vos réponses ;)

Grég

08/06/2004 à 01:07

Bonjour/soir,

"Lastoul" a écrit dans le message de
news:1942e01c44ca2$ac691fc0$

Bonjour,

J'utilise une application qui publie automatiquement des
mails avec Outlook 2002.

Pour compléter la réponse d'Anor, si cette application est commerciale ou
supportée, il en existe peut-être une mise à jour qui n'utilise pas les
parties "nouvellement" protégées.

Pour information, en plus de l'automatisation du click et de CDO, il existe
aussi la programmaition en utilisant MAPI (à ne pas confondre avec Simple
MAPI) pour résoudre votre problème.

--
Grég

Anor

08/06/2004 à 22:24

Salut,

Grég wrote:
| Bonjour/soir,
|
|
|| "Lastoul" a écrit dans le message de
|| news:1942e01c44ca2$ac691fc0$ Bonjour,
||
|| J'utilise une application qui publie automatiquement des
|| mails avec Outlook 2002.
|
| Pour compléter la réponse d'Anor, si cette application est
| commerciale ou supportée, il en existe peut-être une mise à jour qui
| n'utilise pas les parties "nouvellement" protégées.
|
| Pour information, en plus de l'automatisation du click et de CDO, il
| existe aussi la programmaition en utilisant MAPI (à ne pas confondre
| avec Simple MAPI) pour résoudre votre problème.

Si tu as un exemple, je suis preneur ;-))

il y a aussi la bibliothèque redemption qu'on peut programmer
http://www.dimastr.com/redemption/
mais c'est peut-être un peu lourdingue quand on peut faire autrement ...

à+
--
Arnaud
--------------------------------------------------
Site Perso : http://memoaccess.free.fr
/Réponses souhaitées sur ce forum, merci/
--------------------------------------------------

Grég

09/06/2004 à 20:21

Bonjour/soir,
"Anor" <http://memoaccess.free.fr/anor/email.htm> a écrit dans le message de
news:40c62087$0$21558$

Salut,

Grég wrote:
| Bonjour/soir,
|
|

| Pour information, en plus de l'automatisation du click et de CDO, il
| existe aussi la programmaition en utilisant MAPI (à ne pas confondre
| avec Simple MAPI) pour résoudre votre problème.

Si tu as un exemple, je suis preneur ;-))

Je lis les RFC, mais je sais aussi chercher sur MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcsample98/html/_sample_mfc_npp.asp
!-)))

il y a aussi la bibliothèque redemption qu'on peut programmer
http://www.dimastr.com/redemption/
mais c'est peut-être un peu lourdingue quand on peut faire autrement ...

C'est toujours plus simple que (Extended) MAPI !

--
Grég

Anor

09/06/2004 à 20:52

Salut,

Grég wrote:
| Je lis les RFC, mais je sais aussi chercher sur MSDN:
|
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcsample98/html/_sample_mfc_npp.asp
| !-)))

yough ! ça fait mal au crâne oui !!

|| il y a aussi la bibliothèque redemption qu'on peut programmer
|| http://www.dimastr.com/redemption/
|| mais c'est peut-être un peu lourdingue quand on peut faire autrement
|| ...
|
| C'est toujours plus simple que (Extended) MAPI !

Effectivement, par "lourdingue", mon subconscient pensait au niveau "portabilité"
puisqu'il faut faire suivre la dll, la régistrer, avec le risque que les références
se perdent les chèvres ;-))

à+
--
Arnaud
--------------------------------------------------
Site Perso : http://memoaccess.free.fr
/Réponses souhaitées sur ce forum, merci/
--------------------------------------------------

Jacques ROBERT

11/06/2004 à 17:38

Je rencontre le même problème que ceux évoqués dans les
mesages précédents, lautomatisation du click permet de le
contourner mais n'est pas très satisfaisant sur le fond.

S'agisant dans un cas d'un module Access et dans l'autre
d'un publipostage avec Word pour des besoins internes .

Y a t il d'autres solutions ?
Comment utilise t on MAPI ?

Merci d'avance

Jacques ROBERT

-----Message d'origine-----
Bonjour/soir,

"Lastoul" a écrit dans le message
de

news:1942e01c44ca2$ac691fc0$
Bonjour,

J'utilise une application qui publie automatiquement des
mails avec Outlook 2002.

Pour compléter la réponse d'Anor, si cette application
est commerciale ou

supportée, il en existe peut-être une mise à jour qui
n'utilise pas les

parties "nouvellement" protégées.

Pour information, en plus de l'automatisation du click et
de CDO, il existe

aussi la programmaition en utilisant MAPI (à ne pas
confondre avec Simple

MAPI) pour résoudre votre problème.

--
Grég

.

Anor

11/06/2004 à 17:50

Bonjour,
Je te préconise d'essayer en premier CDO :
code vba à adapter :
http://memoaccess.free.fr/outlook.htm#SendMailCDO

--
à+
Arnaud
--------------------------------------------------
Site Perso : http://memoaccess.free.fr
/Réponses souhaitées sur ce forum, merci/
--------------------------------------------------

Jacques ROBERT wrote:
| Je rencontre le même problème que ceux évoqués dans les
| mesages précédents, lautomatisation du click permet de le
| contourner mais n'est pas très satisfaisant sur le fond.
|
| S'agisant dans un cas d'un module Access et dans l'autre
| d'un publipostage avec Word pour des besoins internes .
|
| Y a t il d'autres solutions ?
| Comment utilise t on MAPI ?
|
| Merci d'avance
|

Grég

15/06/2004 à 18:17

Arnaud,

J'ai (toujours) quelques doutes sur la pérénité de l'utilisation de CDO pour
"contourner" les messages de sécurité: Voici un extrait d'un message de Ken
Slovak qui, généralement, sait de quoi il parle !-)))
Cela ne limite-t-il pas sérieusement l'utilisation de CDO?

"Ken Slovak - [MVP - Outlook]" a écrit dans le message
de news:

Each CDO Message object has a Recipients collection.

....

Be aware though that in secure versions of Outlook that access to CDO's
Recipients collection will fire the security prompts. Even in Outlook
2003,

where VBA code is inherently trusted if all Outlook objects are derived
from

the Application object, CDO code is never trusted.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm

--
Grég

"Anor" <http://memoaccess.free.fr/anor/email.htm> a écrit dans le message de
news:40c9d4d3$0$21566$

Bonjour,
Je te préconise d'essayer en premier CDO :
code vba à adapter :
http://memoaccess.free.fr/outlook.htm#SendMailCDO

--
à+
Arnaud
--------------------------------------------------
Site Perso : http://memoaccess.free.fr
/Réponses souhaitées sur ce forum, merci/
--------------------------------------------------

...

Anor

15/06/2004 à 19:17

Bonjour Grég et merci pour ce message.

La réponse de Ken a été faite à quelqu'un qui ouvrait une session MAPI.

Je ne sais pas quels sont les "risques", la fiabilité ou les failles du code que je propose,
mais en tout cas,
pour des utilisations simples pour ne pas dire simplistes comme
l'envoi de messages d'avertissement à un responsable de service en fonction
de seuils d'alerte atteints lors de saisies dans une base de données, cela fonctionne
de manière parfaitement transparente et acceptable.

(sans accéder toutefois à la collection cdo.recipients ce qui empèche de
sauvegarder le message dans outlook ou de savoir exactement quels messages ont été envoyés
mais dans l'appli access à laquelle je fais référence, il suffit de renseigner une table des
alertes envoyées si pas d'erreur
lors de l'exécution de la méthode .send sur l'object cdo.message)

on ne peut pas parler de pérénité, car je ne sais pas si la dll cdosys.dll ou
cdoex.dll sera longtemps installée sur nos systèmes.
reste la fameuse cdo.dll version 1.2x plus compliquée....

Et c'est justement à cause de ce genre de petit détails que je ne m'aventurerai
pas à commercialiser (de toute façon ce n'est pas mon métier)
ni à développer bénévolement une quelconque application basée sur le couple access/outlook
ou vba/cdo qui en fonction des modifications opérées par la bande à bill, risqueraient de mettre
en mauvaise posture le fonctionnement d'une PME.

Pour terminer, pour éviter les messages d'erreur, on peut aussi réinventer la roue
et exploiter à 100% l'api winsock.dll

c'est aussi lourd à faire fonctionner que mapi, mais ça envoie des messages
indépendemment du logiciel de messagerie et de manière tout à fait transparente ....
Ne pas chercher à atteindre les dossiers ou le carnet d'adresses quand même ;-))

a+
Arnaud

Grég wrote:
| Arnaud,
|
| J'ai (toujours) quelques doutes sur la pérénité de l'utilisation de
| CDO pour "contourner" les messages de sécurité: Voici un extrait d'un
| message de Ken Slovak qui, généralement, sait de quoi il parle !-)))
| Cela ne limite-t-il pas sérieusement l'utilisation de CDO?
|
| "Ken Slovak - [MVP - Outlook]" a écrit dans le
| message de news:
|| Each CDO Message object has a Recipients collection.
|
|| ....
|
||
|| Be aware though that in secure versions of Outlook that access to
|| CDO's Recipients collection will fire the security prompts. Even in
|| Outlook 2003, where VBA code is inherently trusted if all Outlook
|| objects are derived from the Application object, CDO code is never
|| trusted.
|| --
|| Ken Slovak
|| [MVP - Outlook]

Bonjour Grég et merci pour ce message.

La réponse de Ken a été faite à quelqu'un qui ouvrait une session MAPI.

Je ne sais pas quels sont les "risques", la fiabilité ou les failles du code que je propose,
mais en tout cas,
pour des utilisations simples pour ne pas dire simplistes comme
l'envoi de messages d'avertissement à un responsable de service en fonction
de seuils d'alerte atteints lors de saisies dans une base de données, cela fonctionne
de manière parfaitement transparente et acceptable.

(sans accéder toutefois à la collection cdo.recipients ce qui empèche de
sauvegarder le message dans outlook ou de savoir exactement quels messages ont été envoyés
mais dans l'appli access à laquelle je fais référence, il suffit de renseigner une table des
alertes envoyées si pas d'erreur
lors de l'exécution de la méthode .send sur l'object cdo.message)

on ne peut pas parler de pérénité, car je ne sais pas si la dll cdosys.dll ou
cdoex.dll sera longtemps installée sur nos systèmes.
reste la fameuse cdo.dll version 1.2x plus compliquée....

Et c'est justement à cause de ce genre de petit détails que je ne m'aventurerai
pas à commercialiser (de toute façon ce n'est pas mon métier)
ni à développer bénévolement une quelconque application basée sur le couple access/outlook
ou vba/cdo qui en fonction des modifications opérées par la bande à bill, risqueraient de mettre
en mauvaise posture le fonctionnement d'une PME.

Pour terminer, pour éviter les messages d'erreur, on peut aussi réinventer la roue
et exploiter à 100% l'api winsock.dll

c'est aussi lourd à faire fonctionner que mapi, mais ça envoie des messages
indépendemment du logiciel de messagerie et de manière tout à fait transparente ....
Ne pas chercher à atteindre les dossiers ou le carnet d'adresses quand même ;-))

a+
Arnaud

Grég wrote:
| Arnaud,
|
| J'ai (toujours) quelques doutes sur la pérénité de l'utilisation de
| CDO pour "contourner" les messages de sécurité: Voici un extrait d'un
| message de Ken Slovak qui, généralement, sait de quoi il parle !-)))
| Cela ne limite-t-il pas sérieusement l'utilisation de CDO?
|
| "Ken Slovak - [MVP - Outlook]" <kenslovak@mvps.org> a écrit dans le
| message de news:eWLeIIvTEHA.3140@tk2msftngp13.phx.gbl...
|| Each CDO Message object has a Recipients collection.
|
|| ....
|
||
|| Be aware though that in secure versions of Outlook that access to
|| CDO's Recipients collection will fire the security prompts. Even in
|| Outlook 2003, where VBA code is inherently trusted if all Outlook
|| objects are derived from the Application object, CDO code is never
|| trusted.
|| --
|| Ken Slovak
|| [MVP - Outlook]

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour Grég et merci pour ce message.

La réponse de Ken a été faite à quelqu'un qui ouvrait une session MAPI.

Je ne sais pas quels sont les "risques", la fiabilité ou les failles du code que je propose,
mais en tout cas,
pour des utilisations simples pour ne pas dire simplistes comme
l'envoi de messages d'avertissement à un responsable de service en fonction
de seuils d'alerte atteints lors de saisies dans une base de données, cela fonctionne
de manière parfaitement transparente et acceptable.

(sans accéder toutefois à la collection cdo.recipients ce qui empèche de
sauvegarder le message dans outlook ou de savoir exactement quels messages ont été envoyés
mais dans l'appli access à laquelle je fais référence, il suffit de renseigner une table des
alertes envoyées si pas d'erreur
lors de l'exécution de la méthode .send sur l'object cdo.message)

on ne peut pas parler de pérénité, car je ne sais pas si la dll cdosys.dll ou
cdoex.dll sera longtemps installée sur nos systèmes.
reste la fameuse cdo.dll version 1.2x plus compliquée....

Et c'est justement à cause de ce genre de petit détails que je ne m'aventurerai
pas à commercialiser (de toute façon ce n'est pas mon métier)
ni à développer bénévolement une quelconque application basée sur le couple access/outlook
ou vba/cdo qui en fonction des modifications opérées par la bande à bill, risqueraient de mettre
en mauvaise posture le fonctionnement d'une PME.

Pour terminer, pour éviter les messages d'erreur, on peut aussi réinventer la roue
et exploiter à 100% l'api winsock.dll

c'est aussi lourd à faire fonctionner que mapi, mais ça envoie des messages
indépendemment du logiciel de messagerie et de manière tout à fait transparente ....
Ne pas chercher à atteindre les dossiers ou le carnet d'adresses quand même ;-))

a+
Arnaud

Grég wrote:
| Arnaud,
|
| J'ai (toujours) quelques doutes sur la pérénité de l'utilisation de
| CDO pour "contourner" les messages de sécurité: Voici un extrait d'un
| message de Ken Slovak qui, généralement, sait de quoi il parle !-)))
| Cela ne limite-t-il pas sérieusement l'utilisation de CDO?
|
| "Ken Slovak - [MVP - Outlook]" a écrit dans le
| message de news:
|| Each CDO Message object has a Recipients collection.
|
|| ....
|
||
|| Be aware though that in secure versions of Outlook that access to
|| CDO's Recipients collection will fire the security prompts. Even in
|| Outlook 2003, where VBA code is inherently trusted if all Outlook
|| objects are derived from the Application object, CDO code is never
|| trusted.
|| --
|| Ken Slovak
|| [MVP - Outlook]

Grég

15/06/2004 à 21:30

Arnaud,

"Anor" <http://memoaccess.free.fr/anor/email.htm> a écrit dans le message de
news:40cf2f1f$0$13928$

Bonjour Grég et merci pour ce message.

C'est un plaisir. Merci pour ta longue réponse.

La réponse de Ken a été faite à quelqu'un qui ouvrait une session MAPI.

Oui, mais le message de base ( news:)
demandait si (et comment) on pouvait récupérer des informations sur des
messages encryptés ne se trouvant pas sur un serveur Exchange avec CDO.

Je ne sais pas quels sont les "risques", la fiabilité ou les failles du
code que je propose,

mais en tout cas,
pour des utilisations simples pour ne pas dire simplistes comme
l'envoi de messages d'avertissement à un responsable de service en
fonction

de seuils d'alerte atteints lors de saisies dans une base de données, cela
fonctionne

de manière parfaitement transparente et acceptable.

(sans accéder toutefois à la collection cdo.recipients ce qui empèche de
sauvegarder le message dans outlook ou de savoir exactement quels messages
ont été envoyés

mais dans l'appli access à laquelle je fais référence, il suffit de
renseigner une table des

alertes envoyées si pas d'erreur
lors de l'exécution de la méthode .send sur l'object cdo.message)

on ne peut pas parler de pérénité, car je ne sais pas si la dll cdosys.dll
ou

cdoex.dll sera longtemps installée sur nos systèmes.
reste la fameuse cdo.dll version 1.2x plus compliquée....

Et c'est justement à cause de ce genre de petit détails que je ne
m'aventurerai

pas à commercialiser (de toute façon ce n'est pas mon métier)
ni à développer bénévolement une quelconque application basée sur le
couple access/outlook

ou vba/cdo qui en fonction des modifications opérées par la bande à bill,
risqueraient de mettre

en mauvaise posture le fonctionnement d'une PME.

Mes doutes se situent principalement de ce coté: je ne vois pas pourquoi on
pourrait plus "automatiser" (sans blocage) avec CDO qu'avec Simple MAPI,
alors que le modèle n'est pas plus sécurisé !

Pour terminer, pour éviter les messages d'erreur, on peut aussi réinventer
la roue

et exploiter à 100% l'api winsock.dll

Il y a un tas de petits utilitaires (l'un des plus connus BLAT) permettant
de faire ces envois en lignes de commandes, c'est à dire en laissant les
autres jouer avec winsock.dll. Entre nous, pour envoyer un message, je ne
suis sûr que cela sois plus compliqué d'utiliser winsock que (Extended) MAPI
!-))

c'est aussi lourd à faire fonctionner que mapi, mais ça envoie des
messages

indépendemment du logiciel de messagerie et de manière tout à fait
transparente ....

Ne pas chercher à atteindre les dossiers ou le carnet d'adresses quand
même ;-))

Au moins, il n'y a pas à créer un profil de messagerie... Ce qui m'a pas mal
cassé les pieds quand j'avais à le faire, sans Outlook, pour permettre
l'envoie des messages d'exploitation de SqlServer par exemple !-)))

--
Grég

...

Arnaud,

"Anor" <http://memoaccess.free.fr/anor/email.htm> a écrit dans le message de
news:40cf2f1f$0$13928$636a15ce@news.free.fr...

Bonjour Grég et merci pour ce message.

C'est un plaisir. Merci pour ta longue réponse.

La réponse de Ken a été faite à quelqu'un qui ouvrait une session MAPI.

Oui, mais le message de base ( news:ubgFLwlTEHA.2372@TK2MSFTNGP11.phx.gbl)
demandait si (et comment) on pouvait récupérer des informations sur des
messages encryptés ne se trouvant pas sur un serveur Exchange avec CDO.

Je ne sais pas quels sont les "risques", la fiabilité ou les failles du
code que je propose,

mais en tout cas,
pour des utilisations simples pour ne pas dire simplistes comme
l'envoi de messages d'avertissement à un responsable de service en
fonction

de seuils d'alerte atteints lors de saisies dans une base de données, cela
fonctionne

de manière parfaitement transparente et acceptable.

(sans accéder toutefois à la collection cdo.recipients ce qui empèche de
sauvegarder le message dans outlook ou de savoir exactement quels messages
ont été envoyés

mais dans l'appli access à laquelle je fais référence, il suffit de
renseigner une table des

alertes envoyées si pas d'erreur
lors de l'exécution de la méthode .send sur l'object cdo.message)

on ne peut pas parler de pérénité, car je ne sais pas si la dll cdosys.dll
ou

cdoex.dll sera longtemps installée sur nos systèmes.
reste la fameuse cdo.dll version 1.2x plus compliquée....

Et c'est justement à cause de ce genre de petit détails que je ne
m'aventurerai

pas à commercialiser (de toute façon ce n'est pas mon métier)
ni à développer bénévolement une quelconque application basée sur le
couple access/outlook

ou vba/cdo qui en fonction des modifications opérées par la bande à bill,
risqueraient de mettre

en mauvaise posture le fonctionnement d'une PME.

Mes doutes se situent principalement de ce coté: je ne vois pas pourquoi on
pourrait plus "automatiser" (sans blocage) avec CDO qu'avec Simple MAPI,
alors que le modèle n'est pas plus sécurisé !

Pour terminer, pour éviter les messages d'erreur, on peut aussi réinventer
la roue

et exploiter à 100% l'api winsock.dll

Il y a un tas de petits utilitaires (l'un des plus connus BLAT) permettant
de faire ces envois en lignes de commandes, c'est à dire en laissant les
autres jouer avec winsock.dll. Entre nous, pour envoyer un message, je ne
suis sûr que cela sois plus compliqué d'utiliser winsock que (Extended) MAPI
!-))

c'est aussi lourd à faire fonctionner que mapi, mais ça envoie des
messages

indépendemment du logiciel de messagerie et de manière tout à fait
transparente ....

Ne pas chercher à atteindre les dossiers ou le carnet d'adresses quand
même ;-))

Au moins, il n'y a pas à créer un profil de messagerie... Ce qui m'a pas mal
cassé les pieds quand j'avais à le faire, sans Outlook, pour permettre
l'envoie des messages d'exploitation de SqlServer par exemple !-)))

--
Grég

...

Vous avez filtré cet utilisateur ! Consultez son message

Arnaud,

"Anor" <http://memoaccess.free.fr/anor/email.htm> a écrit dans le message de
news:40cf2f1f$0$13928$

Bonjour Grég et merci pour ce message.

C'est un plaisir. Merci pour ta longue réponse.

La réponse de Ken a été faite à quelqu'un qui ouvrait une session MAPI.

Oui, mais le message de base ( news:)
demandait si (et comment) on pouvait récupérer des informations sur des
messages encryptés ne se trouvant pas sur un serveur Exchange avec CDO.

Je ne sais pas quels sont les "risques", la fiabilité ou les failles du
code que je propose,

mais en tout cas,
pour des utilisations simples pour ne pas dire simplistes comme
l'envoi de messages d'avertissement à un responsable de service en
fonction

de seuils d'alerte atteints lors de saisies dans une base de données, cela
fonctionne

de manière parfaitement transparente et acceptable.

(sans accéder toutefois à la collection cdo.recipients ce qui empèche de
sauvegarder le message dans outlook ou de savoir exactement quels messages
ont été envoyés

mais dans l'appli access à laquelle je fais référence, il suffit de
renseigner une table des

alertes envoyées si pas d'erreur
lors de l'exécution de la méthode .send sur l'object cdo.message)

on ne peut pas parler de pérénité, car je ne sais pas si la dll cdosys.dll
ou

cdoex.dll sera longtemps installée sur nos systèmes.
reste la fameuse cdo.dll version 1.2x plus compliquée....

Et c'est justement à cause de ce genre de petit détails que je ne
m'aventurerai

pas à commercialiser (de toute façon ce n'est pas mon métier)
ni à développer bénévolement une quelconque application basée sur le
couple access/outlook

ou vba/cdo qui en fonction des modifications opérées par la bande à bill,
risqueraient de mettre

en mauvaise posture le fonctionnement d'une PME.

Mes doutes se situent principalement de ce coté: je ne vois pas pourquoi on
pourrait plus "automatiser" (sans blocage) avec CDO qu'avec Simple MAPI,
alors que le modèle n'est pas plus sécurisé !

Pour terminer, pour éviter les messages d'erreur, on peut aussi réinventer
la roue

et exploiter à 100% l'api winsock.dll

Il y a un tas de petits utilitaires (l'un des plus connus BLAT) permettant
de faire ces envois en lignes de commandes, c'est à dire en laissant les
autres jouer avec winsock.dll. Entre nous, pour envoyer un message, je ne
suis sûr que cela sois plus compliqué d'utiliser winsock que (Extended) MAPI
!-))

c'est aussi lourd à faire fonctionner que mapi, mais ça envoie des
messages

indépendemment du logiciel de messagerie et de manière tout à fait
transparente ....

Ne pas chercher à atteindre les dossiers ou le carnet d'adresses quand
même ;-))

Au moins, il n'y a pas à créer un profil de messagerie... Ce qui m'a pas mal
cassé les pieds quand j'avais à le faire, sans Outlook, pour permettre
l'envoie des messages d'exploitation de SqlServer par exemple !-)))

--
Grég

...

envoi automatique de messages par une application

10 réponses

Veuillez sélectionner un problème