Mailitem save with HTTP mail account

  • Thread starter Thread starter Joe
  • Start date Start date
J

Joe

How can I save changes to my mailitem object with the .save() method in my
Outlook addin when dealing with an email on an HTTP mail account, such as
Hotmail? The error I get right now is "messages on the server cannot be
modified." Is there something special I have to do to the message? Thanks

Joe
guiderygil@@hot[nospam]]mail.com
 
How do I do this programmatically? I need to my addin to work without
distinguishing between different types of email accounts (POP3,Hotmail,etc.)
Thanks

Joe



Ken Slovak - said:
It would have to be downloaded and not left on the server.




Joe said:
How can I save changes to my mailitem object with the .save() method in my
Outlook addin when dealing with an email on an HTTP mail account, such as
Hotmail? The error I get right now is "messages on the server cannot be
modified." Is there something special I have to do to the message? Thanks

Joe
guiderygil@@hot[nospam]]mail.com
Click to expand...
Click to expand...
 
Another question is, if I can't somehow get the message to save, can I
distinguish which message is from an HTTP mail account or a POP 3 and deal
with them accordingly?

Joe

Joe said:
How do I do this programmatically? I need to my addin to work without
distinguishing between different types of email accounts (POP3,Hotmail,etc.)
Thanks

Joe



Ken Slovak - said:
It would have to be downloaded and not left on the server.
Click to expand...
in
my
Outlook addin when dealing with an email on an HTTP mail account, such as
Hotmail? The error I get right now is "messages on the server cannot be
modified." Is there something special I have to do to the message? Thanks

Joe
guiderygil@@hot[nospam]]mail.com
Click to expand...
Click to expand...
Click to expand...
 
As far as I know you'd have to set the properties of the HTTP email account
to download items to the local PST file. I don't know how to do that from
code. It might be a registry setting for the account, in which case you'd
have to experiment to see what registry value for the account changes when
you make the change in the UI settings. Then you could write code to change
that registry setting. However, the changes might not take effect unless
Outlook was closed and re-started.

To see where items are coming from you might have to parse the Internet
headers looking for something that is a header common to the HTTP account
that's not there for POP3 or IMAP emails. To get at the headers you would
have to use CDO 1.21 (optional installation for Outlook 2000 and later and
the headers are subject to the security prompts) or Redemption code (a 3rd
party library from www.dimastr.com/redemption). See
http://www.slovaktech.com/code_samples.htm#InternetHeaders for a CDO 1.21
code sample for getting the Internet headers.
 
Thanks for the help! This has helped me out alot... I've incorporated the
code from the link you provided me into my code. One question though... when
using Redemption to avoid the security errors, it actually adds a header to
the "mailitem". Am I doing something wrong here? I see how the HTTP account
emails have a header but not the POP3 accounts with CDO, but when using the
code with a SafeMailItem, a header exists for both.... Is there something
special I must do? Thanks.

Joe
 
I've never seen Redemption add a header to an email message except when I
wanted it to do so using a MAPI property to create an X-header. Show the
code you're using. My link uses CDO code to get the headers, it's strictly
read-only. Any such code translated into Redemption code would also be
read-only for the headers.

All POP3 messages that were received should have headers in both CDO and
Redemption code. Messages sent strictly within an Exchange organization
wouldn't since they never went over the Internet.
 
I use the code on that webpage (which causes the security prompts) and there
are only headers for the POP3 messages.
I transfer it to a Redemption mailitem, and both types of messages have
headers. Here's the code I use with Redemption:

Dim m_olMailItem as MailItem
Dim SafeMail As Redemption.SafeMailItem
Const CdoPR_TRANSPORT_MESSAGE_HEADERS = &H7D001E

SafeMail = CreateObject("Redemption.SafeMailItem")
SafeMail.Item = m_olMailItem
SafeMail.Fields(CdoPR_TRANSPORT_MESSAGE_HEADERS)

I've compared it all... and using the CDO and Redemption methods both
result in the same header for the POP3 emails, but the CDO method produces
no header for the HTTP emails and Redemption produces a header (although
probably half the size) for the HTTP emails

Am I doing something wrong?

Joe
 
Oops.. one more thing I forgot to mention. If this ends up being the case
where a header is recieved used CDO and Redemption, I noticed that the
Header recieved in the CDO method for a POP3 account has the Status: U
header information (there to specify if the message has been read or not)...
well, the Hotmail header does not have this as a portion of their Header...
I guess due to the fact that they are not a POP3 server. If I can't find any
other way to differentiate between HTTP mail account emails and POP3 mail
account emails, can I just do a search for the string "Status: " and if it
finds it in the header, I know the email is from a POP3 account, if it
doesn't find it, I will know the email is from an HTTP account? Will this
also be true for exchange server environments (hence, the emails from
exchange servers do not contain the "Status: " line in their header)?

Thanks Ken, I appreciate all your help.

Joe
guide[nospam-]rygil@hot[-toomuchspam-]]mail.com
 
I see that CDO isn't showing the headers while Redemption is for emails
downloaded from Hotmail, but I have no idea why that is. I can see the
headers using OutlookSpy (www.dimastr.com).

I see a major difference in the headers of a Hotmail item, at least here.
They start with an X-header "X-Message-Info:" that isn't there in POP3
emails. I do not see a Status field in the headers, at least here, so that
may be dependent on the email servers involved. In something like this
always test on different servers since they may produce different results.
 
Back
Top