Outlook, Access, VBA, and Security Warning
| Author |
Message |
|
Ho
#1 / 5
|
 Outlook, Access, VBA, and Security Warning Using Outlook 2002 and Access 2002 I'm trying to finish a project that will look in a subfolder in
Outlook for any unread email, and add properties of that mailitem
object to a recordset in Access. All was well except for the security
features. I just spent the last couple of hours researching a solution
to the infamous and annoying "A program is trying to access e-mail
addresses you have stored in Outlook. Do you want to allow this?"
dialog box. Needless to say, the solution I found was a third-party
app "clickyes" that fools this dialog box into thinking the "yes"
button is clicked on every occurrence. Now I can continue with my
project, but I have to wonder why the authors of this security feature
didn't think that non-Exchange Server environment users might want to
scale down, or totally disable this protective feature. I would think
there would have to be a way of knowing if the access to an address
book, or email store came from a VBA application within Access. If
not, maybe some sort of secure authentication process that could be
followed so a connection to this information could still be secure,
yet available without interruption.
If I am missing something, please enlighten me. I followed KB articles
on this subject, but ended up learning how I can make Outlook let me
open attachments with previously restricted extensions, and I'm not
sure what that has to do with scripted access to an Outlook Object.
Does anyone know if Microsoft is addressing this issue and hopefully
offering an easier and safer solution in the near future?
Here's the code that throws the dialog warning
Private Sub ImportEmail()
'Outlook Objects Setup
Dim myOlApp As New Outlook.Application
Dim myOlExp As Outlook.Explorer
Dim objMail As MailItem
Dim myNS As Outlook.Items
Dim objItems As ItemProperties
Dim objItem As ItemProperty
Set myOlExp = myOlApp.ActiveExplorer
Set myNS = myOlApp.GetNamespace("MAPI").Folders.GetFirst_
.Folders("-Newsletters").Items
'Access Objects Setup
Dim bd As DAO.Database
Dim rs As DAO.Recordset '*** Add the DAO. in front of Recordset
Set bd = Application.CurrentDb
Set rs = bd.OpenRecordset("SELECT * FROM Email")
Debug.Print "There are "; myNS.Count; "messages to process"
For Each objMail In myNS
If objMail.UnRead = True Then
rs.AddNew
With objMail
.UnRead=False
rs.Fields("subject") = .Subject
rs.Fields("body") = .Body
rs.Fields("ReceivedTime") = .ReceivedTime
rs.Fields("ToName") = .Recipients.Item(1).Name
rs.Fields("ToAddress") = .Recipients.Item(1).Address
rs.Fields("FromName") = .SenderName
rs.Fields("FromAddress") = GetSendAddy(.entryID)
End With
rs.Update
End If
Next
rs.Close
bd.Close
End Sub
Function GetSendAddy(sEntry As String) As String
Dim oSession As MAPI.Session
Dim oMsg As MAPI.Message
Dim oSender As MAPI.AddressEntry
'Establish a CDO (MAPI) Session object and logon to it
Set oSession = CreateObject("MAPI.Session")
oSession.Logon , , False, False
'Locate the current message with the EntryID using CDO
Set oMsg = oSession.GetMessage(sEntry)
'Get the sender's name
Set oSender = oMsg.Sender
'Get the actual email address
GetSendAddy = oSender.Address
oSession.Logoff
End Function
|
| Fri, 15 Jul 2005 02:18:07 GMT |
|
 |
|
Ken Slovak - [MVP - Outlook
#2 / 5
|
Outlook, Access, VBA, and Security Warning There really isn't a way to tell what program has called the Outlook object model and if it's safe. Microsoft has made very plain that for standalone users there will be no changes to how the object model guard is implemented. Your choices are something like click-yes, using Redemption (www.dimastr.com) or writing in Extended MAPI (C++ or Delphi). --
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Lead Author, Beginning VB 6 Application Development, Wrox Press
Attachment Options
http://www.slovaktech.com/attachmentoptions.htm
Extended Reminders
http://www.slovaktech.com/extendedreminders.htm
Quote: > Using Outlook 2002 and Access 2002 > I'm trying to finish a project that will look in a subfolder in
> Outlook for any unread email, and add properties of that mailitem
> object to a recordset in Access. All was well except for the
security
> features. I just spent the last couple of hours researching a
solution
> to the infamous and annoying "A program is trying to access e-mail
> addresses you have stored in Outlook. Do you want to allow this?"
> dialog box. Needless to say, the solution I found was a third-party
> app "clickyes" that fools this dialog box into thinking the "yes"
> button is clicked on every occurrence. Now I can continue with my
> project, but I have to wonder why the authors of this security
feature
> didn't think that non-Exchange Server environment users might want
to
> scale down, or totally disable this protective feature. I would
think
> there would have to be a way of knowing if the access to an address
> book, or email store came from a VBA application within Access. If
> not, maybe some sort of secure authentication process that could be
> followed so a connection to this information could still be secure,
> yet available without interruption.
> If I am missing something, please enlighten me. I followed KB
articles
> on this subject, but ended up learning how I can make Outlook let me
> open attachments with previously restricted extensions, and I'm not
> sure what that has to do with scripted access to an Outlook Object.
> Does anyone know if Microsoft is addressing this issue and hopefully
> offering an easier and safer solution in the near future?
> Here's the code that throws the dialog warning.
> Private Sub ImportEmail()
> 'Outlook Objects Setup
> Dim myOlApp As New Outlook.Application
> Dim myOlExp As Outlook.Explorer
> Dim objMail As MailItem
> Dim myNS As Outlook.Items
> Dim objItems As ItemProperties
> Dim objItem As ItemProperty
> Set myOlExp = myOlApp.ActiveExplorer
> Set myNS = myOlApp.GetNamespace("MAPI").Folders.GetFirst_
> .Folders("-Newsletters").Items
> 'Access Objects Setup
> Dim bd As DAO.Database
> Dim rs As DAO.Recordset '*** Add the DAO. in front of Recordset
> Set bd = Application.CurrentDb
> Set rs = bd.OpenRecordset("SELECT * FROM Email")
> Debug.Print "There are "; myNS.Count; "messages to process"
> For Each objMail In myNS
> If objMail.UnRead = True Then
> rs.AddNew
> With objMail
> .UnRead=False
> rs.Fields("subject") = .Subject
> rs.Fields("body") = .Body
> rs.Fields("ReceivedTime") = .ReceivedTime
> rs.Fields("ToName") = .Recipients.Item(1).Name
> rs.Fields("ToAddress") = .Recipients.Item(1).Address
> rs.Fields("FromName") = .SenderName
> rs.Fields("FromAddress") = GetSendAddy(.entryID)
> End With
> rs.Update
> End If
> Next
> rs.Close
> bd.Close
> End Sub
> Function GetSendAddy(sEntry As String) As String
> Dim oSession As MAPI.Session
> Dim oMsg As MAPI.Message
> Dim oSender As MAPI.AddressEntry
> 'Establish a CDO (MAPI) Session object and logon to it
> Set oSession = CreateObject("MAPI.Session")
> oSession.Logon , , False, False
> 'Locate the current message with the EntryID using CDO
> Set oMsg = oSession.GetMessage(sEntry)
> 'Get the sender's name
> Set oSender = oMsg.Sender
> 'Get the actual email address
> GetSendAddy = oSender.Address
> oSession.Logoff
> End Function
|
| Fri, 15 Jul 2005 23:35:22 GMT |
|
|
|
Ho
#3 / 5
|
Outlook, Access, VBA, and Security Warning I here ya. So, is there a possibility of more options for how this security warning is thrown if I install Exchange Server? I'd rather not use a third party solution if possible. I didn't know that 'Microsoft has made very plain' about standalone user options concerning the object model guard. In fact, when you search the KB, you get options for standalone users to get past the guard, but those options seem to be for email attachments, not accessing the Outlook Object.
Quote: > There really isn't a way to tell what program has called the Outlook > object model and if it's safe. Microsoft has made very plain that for > standalone users there will be no changes to how the object model > guard is implemented. Your choices are something like click-yes, using > Redemption (www.dimastr.com) or writing in Extended MAPI (C++ or > Delphi). > --
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Lead Author, Professional Outlook 2000 Programming, Wrox Press
> Lead Author, Beginning VB 6 Application Development, Wrox Press
> Attachment Options
> http://www.slovaktech.com/attachmentoptions.htm
> Extended Reminders
> http://www.slovaktech.com/extendedreminders.htm
> > Using Outlook 2002 and Access 2002
> > I'm trying to finish a project that will look in a subfolder in
> > Outlook for any unread email, and add properties of that mailitem
> > object to a recordset in Access. All was well except for the
> security
> > features. I just spent the last couple of hours researching a
> solution
> > to the infamous and annoying "A program is trying to access e-mail
> > addresses you have stored in Outlook. Do you want to allow this?"
> > dialog box. Needless to say, the solution I found was a third-party
> > app "clickyes" that fools this dialog box into thinking the "yes"
> > button is clicked on every occurrence. Now I can continue with my
> > project, but I have to wonder why the authors of this security
> feature
> > didn't think that non-Exchange Server environment users might want
> to
> > scale down, or totally disable this protective feature. I would
> think
> > there would have to be a way of knowing if the access to an address
> > book, or email store came from a VBA application within Access. If
> > not, maybe some sort of secure authentication process that could be
> > followed so a connection to this information could still be secure,
> > yet available without interruption.
> > If I am missing something, please enlighten me. I followed KB
> articles
> > on this subject, but ended up learning how I can make Outlook let me
> > open attachments with previously restricted extensions, and I'm not
> > sure what that has to do with scripted access to an Outlook Object.
> > Does anyone know if Microsoft is addressing this issue and hopefully
> > offering an easier and safer solution in the near future?
> > Here's the code that throws the dialog warning.
> > Private Sub ImportEmail()
> > 'Outlook Objects Setup
> > Dim myOlApp As New Outlook.Application
> > Dim myOlExp As Outlook.Explorer
> > Dim objMail As MailItem
> > Dim myNS As Outlook.Items
> > Dim objItems As ItemProperties
> > Dim objItem As ItemProperty
> > Set myOlExp = myOlApp.ActiveExplorer
> > Set myNS = myOlApp.GetNamespace("MAPI").Folders.GetFirst_
> > .Folders("-Newsletters").Items
> > 'Access Objects Setup
> > Dim bd As DAO.Database
> > Dim rs As DAO.Recordset '*** Add the DAO. in front of Recordset
> > Set bd = Application.CurrentDb
> > Set rs = bd.OpenRecordset("SELECT * FROM Email")
> > Debug.Print "There are "; myNS.Count; "messages to process"
> > For Each objMail In myNS
> > If objMail.UnRead = True Then
> > rs.AddNew
> > With objMail
> > .UnRead=False
> > rs.Fields("subject") = .Subject
> > rs.Fields("body") = .Body
> > rs.Fields("ReceivedTime") = .ReceivedTime
> > rs.Fields("ToName") = .Recipients.Item(1).Name
> > rs.Fields("ToAddress") = .Recipients.Item(1).Address
> > rs.Fields("FromName") = .SenderName
> > rs.Fields("FromAddress") = GetSendAddy(.entryID)
> > End With
> > rs.Update
> > End If
> > Next
> > rs.Close
> > bd.Close
> > End Sub
> > Function GetSendAddy(sEntry As String) As String
> > Dim oSession As MAPI.Session
> > Dim oMsg As MAPI.Message
> > Dim oSender As MAPI.AddressEntry
> > 'Establish a CDO (MAPI) Session object and logon to it
> > Set oSession = CreateObject("MAPI.Session")
> > oSession.Logon , , False, False
> > 'Locate the current message with the EntryID using CDO
> > Set oMsg = oSession.GetMessage(sEntry)
> > 'Get the sender's name
> > Set oSender = oMsg.Sender
> > 'Get the actual email address
> > GetSendAddy = oSender.Address
> > oSession.Logoff
> > End Function
|
| Mon, 18 Jul 2005 04:35:14 GMT |
|
|
|
Eric Legaul
#4 / 5
|
Outlook, Access, VBA, and Security Warning Yes, you can get around these restrictions if you are running Exchange Server and have administrator privileges (or you buy the admin a beer). See: http://support.microsoft.com/default.aspx?scid=kb;en-us;263297
--
Eric Legault, MCSD
ADAPSYS - http://www.adapsys.ca
Quote: > I here ya. So, is there a possibility of more options for how this > security warning is thrown if I install Exchange Server? I'd rather > not use a third party solution if possible. I didn't know that > 'Microsoft has made very plain' about standalone user options > concerning the object model guard. In fact, when you search the KB, > you get options for standalone users to get past the guard, but those > options seem to be for email attachments, not accessing the Outlook > Object.
Quote: > > There really isn't a way to tell what program has called the Outlook > > object model and if it's safe. Microsoft has made very plain that for > > standalone users there will be no changes to how the object model > > guard is implemented. Your choices are something like click-yes, using > > Redemption (www.dimastr.com) or writing in Extended MAPI (C++ or > > Delphi). > > --
> > Ken Slovak
> > [MVP - Outlook]
> > http://www.slovaktech.com
> > Lead Author, Professional Outlook 2000 Programming, Wrox Press
> > Lead Author, Beginning VB 6 Application Development, Wrox Press
> > Attachment Options
> > http://www.slovaktech.com/attachmentoptions.htm
> > Extended Reminders
> > http://www.slovaktech.com/extendedreminders.htm
> > > Using Outlook 2002 and Access 2002
> > > I'm trying to finish a project that will look in a subfolder in
> > > Outlook for any unread email, and add properties of that mailitem
> > > object to a recordset in Access. All was well except for the
> > security
> > > features. I just spent the last couple of hours researching a
> > solution
> > > to the infamous and annoying "A program is trying to access e-mail
> > > addresses you have stored in Outlook. Do you want to allow this?"
> > > dialog box. Needless to say, the solution I found was a third-party
> > > app "clickyes" that fools this dialog box into thinking the "yes"
> > > button is clicked on every occurrence. Now I can continue with my
> > > project, but I have to wonder why the authors of this security
> > feature
> > > didn't think that non-Exchange Server environment users might want
> > to
> > > scale down, or totally disable this protective feature. I would
> > think
> > > there would have to be a way of knowing if the access to an address
> > > book, or email store came from a VBA application within Access. If
> > > not, maybe some sort of secure authentication process that could be
> > > followed so a connection to this information could still be secure,
> > > yet available without interruption.
> > > If I am missing something, please enlighten me. I followed KB
> > articles
> > > on this subject, but ended up learning how I can make Outlook let me
> > > open attachments with previously restricted extensions, and I'm not
> > > sure what that has to do with scripted access to an Outlook Object.
> > > Does anyone know if Microsoft is addressing this issue and hopefully
> > > offering an easier and safer solution in the near future?
> > > Here's the code that throws the dialog warning.
> > > Private Sub ImportEmail()
> > > 'Outlook Objects Setup
> > > Dim myOlApp As New Outlook.Application
> > > Dim myOlExp As Outlook.Explorer
> > > Dim objMail As MailItem
> > > Dim myNS As Outlook.Items
> > > Dim objItems As ItemProperties
> > > Dim objItem As ItemProperty
> > > Set myOlExp = myOlApp.ActiveExplorer
> > > Set myNS = myOlApp.GetNamespace("MAPI").Folders.GetFirst_
> > > .Folders("-Newsletters").Items
> > > 'Access Objects Setup
> > > Dim bd As DAO.Database
> > > Dim rs As DAO.Recordset '*** Add the DAO. in front of Recordset
> > > Set bd = Application.CurrentDb
> > > Set rs = bd.OpenRecordset("SELECT * FROM Email")
> > > Debug.Print "There are "; myNS.Count; "messages to process"
> > > For Each objMail In myNS
> > > If objMail.UnRead = True Then
> > > rs.AddNew
> > > With objMail
> > > .UnRead=False
> > > rs.Fields("subject") = .Subject
> > > rs.Fields("body") = .Body
> > > rs.Fields("ReceivedTime") = .ReceivedTime
> > > rs.Fields("ToName") = .Recipients.Item(1).Name
> > > rs.Fields("ToAddress") = .Recipients.Item(1).Address
> > > rs.Fields("FromName") = .SenderName
> > > rs.Fields("FromAddress") = GetSendAddy(.entryID)
> > > End With
> > > rs.Update
> > > End If
> > > Next
> > > rs.Close
> > > bd.Close
> > > End Sub
> > > Function GetSendAddy(sEntry As String) As String
> > > Dim oSession As MAPI.Session
> > > Dim oMsg As MAPI.Message
> > > Dim oSender As MAPI.AddressEntry
> > > 'Establish a CDO (MAPI) Session object and logon to it
> > > Set oSession = CreateObject("MAPI.Session")
> > > oSession.Logon , , False, False
> > > 'Locate the current message with the EntryID using CDO
> > > Set oMsg = oSession.GetMessage(sEntry)
> > > 'Get the sender's name
> > > Set oSender = oMsg.Sender
> > > 'Get the actual email address
> > > GetSendAddy = oSender.Address
> > > oSession.Logoff
> > > End Function
|
| Mon, 18 Jul 2005 05:54:13 GMT |
|
|
|
Ken Slovak - [MVP - Outlook
#5 / 5
|
Outlook, Access, VBA, and Security Warning The attachment restriction bypass using the registry's Level1Remove key have nothing to do with the object model guard. With Exchange and the Outlook security form an admin can enable
various Outlook or CDO methods and eliminate the prompts on access of
various properties. Trusted COM addins can also be developed.
For standalone users the only options are coding in Extended MAPI (C++
or Delphi only), using a utility such as ClickYes (opens you to virus
code executing) or using the Redemption library.
--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Lead Author, Beginning VB 6 Application Development, Wrox Press
Attachment Options
http://www.slovaktech.com/attachmentoptions.htm
Extended Reminders
http://www.slovaktech.com/extendedreminders.htm
Quote: > I here ya. So, is there a possibility of more options for how this
> security warning is thrown if I install Exchange Server? I'd rather
> not use a third party solution if possible. I didn't know that
> 'Microsoft has made very plain' about standalone user options
> concerning the object model guard. In fact, when you search the KB,
> you get options for standalone users to get past the guard, but
those
> options seem to be for email attachments, not accessing the Outlook
> Object.
|
| Mon, 18 Jul 2005 22:24:24 GMT |
|
| |
|
