Lost addresses

  • Thread starter Thread starter Jim S
  • Start date Start date
J

Jim S

If I send to bcc addresses the sent mail (imap) keeps no record of
who I sent to. With my memory thats a disaster. Is this normal?
 
Jim S said:
If I send to bcc addresses the sent mail (imap) keeps no record of
who I sent to. With my memory thats a disaster. Is this normal?

Double-click on the sent item to open in its own window. If the header
pane isn't shown, use the View -> Message header menu to show it.

If you Bcc a lot, you might want to add the Bcc field to the listing
pane (where is listed the items you sent). In the Sent Items folder,
right-click on the header row, select Field Chooser, and add the Bcc
field in whatever position you want.
 
Double-click on the sent item to open in its own window. If the header
pane isn't shown, use the View -> Message header menu to show it.

If you Bcc a lot, you might want to add the Bcc field to the listing
pane (where is listed the items you sent). In the Sent Items folder,
right-click on the header row, select Field Chooser, and add the Bcc
field in whatever position you want.

Thanks, but it doesn't look as if you use IMAP.
I discovered elsewhere that IMAP does not save Bcc addresses and you have
to set the settings to save SENT emails to a folder on your desktop rather
than to the IMAP Sent Mail - then you can do what you said from there.
--
Jim S
Tyneside UK
www.jimscott.co.uk
http://geordiecamii.wordpress.com
http://geordiecam.wordpress.com/
 
Jim S said:
Thanks, but it doesn't look as if you use IMAP.
I discovered elsewhere that IMAP does not save Bcc addresses and you have
to set the settings to save SENT emails to a folder on your desktop rather
than to the IMAP Sent Mail - then you can do what you said from there.

I wasn't aware that the Sent Items folder had different attributes saved
for its records depending on the type of account. If the attribute
(Bcc) is in the saved copy in a file on the hard disk, that attribute
had to be in the source from which the file was created. So it's there.
That it is not visible is a deficiency of the GUI for Outlook.

I bet if you used a .pst database editor (e.g., ) to look at the record
that the Bcc attribute (field) is defined for that e-mail record. After
all, for it to show up in the disk file copy meant it had to be in the
record from which that disk file copy was generated. Outlook doesn't
use magic.

Microsoft's PST editor (freeware):
http://www.microsoft.com/downloads/details.aspx?FamilyID=3D1C7482-4C6E-4EC5-983E-127100D71376
(considered out of date and MCFMAPI is recommended)

OutlookSpy (trialware):
http://www.dimastr.com/outspy/home.htm

MFCMAPI (free):
http://mfcmapi.codeplex.com/

Of course, using these tools means you know the database schema used for
structure and records within the PST database file, or that you're
willing to guess and learn.

If it's in the saved file copy, it came from the PST database file.
Outlook doesn't show everything in its database so this IMAP instance of
the Sent Items folder must exhibit the deficiency you describe. No, I
don't use IMAP but then I didn't think there would be a difference in
what Outlook displays for a record's fields in its views.
 
I wasn't aware that the Sent Items folder had different attributes saved
for its records depending on the type of account. If the attribute
(Bcc) is in the saved copy in a file on the hard disk, that attribute
had to be in the source from which the file was created. So it's there.
That it is not visible is a deficiency of the GUI for Outlook.

I bet if you used a .pst database editor (e.g., ) to look at the record
that the Bcc attribute (field) is defined for that e-mail record. After
all, for it to show up in the disk file copy meant it had to be in the
record from which that disk file copy was generated. Outlook doesn't
use magic.

Microsoft's PST editor (freeware):
http://www.microsoft.com/downloads/details.aspx?FamilyID=3D1C7482-4C6E-4EC5-983E-127100D71376
(considered out of date and MCFMAPI is recommended)

OutlookSpy (trialware):
http://www.dimastr.com/outspy/home.htm

MFCMAPI (free):
http://mfcmapi.codeplex.com/

Of course, using these tools means you know the database schema used for
structure and records within the PST database file, or that you're
willing to guess and learn.

If it's in the saved file copy, it came from the PST database file.
Outlook doesn't show everything in its database so this IMAP instance of
the Sent Items folder must exhibit the deficiency you describe. No, I
don't use IMAP but then I didn't think there would be a difference in
what Outlook displays for a record's fields in its views.

:-)
I barely understood a word of that, but if for example you are using gmail
and check the sent mail folder (via browser) then there is no record of any
bcc info., so it's hardly likely that it would appear in the Outlook
synchronised email.
--
Jim S
Tyneside UK
www.jimscott.co.uk
http://geordiecamii.wordpress.com
http://geordiecam.wordpress.com/
 
Jim S said:
:-)
I barely understood a word of that, but if for example you are using gmail
and check the sent mail folder (via browser) then there is no record of any
bcc info., so it's hardly likely that it would appear in the Outlook
synchronised email.

(Please down a cup of strong coffee before continuing.)

Still, if saving a record (e-mail item) into a disk file results in
showing the Bcc field then that field had to be in the record held in
Outlook's local database. Since you're synchronizing to the folder up
on the IMAP server, Outlook only shows you its information rather than
Outlook's database information.

Although you are using IMAP to receive e-mails, you are still using SMTP
to send e-mails. The SMTP server should never see and never include the
Bcc field in its copy of e-mails sent out from it. If the client
mistakeningly added a Bcc field, the SMTP server should strip it out
before sending that e-mail. Since the SMTP server's copy doesn't
contain the Bcc field, and because Gmail saves the SMTP copy of the sent
e-mail into its Sent Items folder, you can't see the Bcc field. It's
not there in Gmail's copy. Gmail never got an e-mail that had the Bcc
header in it so what it got to save also doesn't have the Bcc header.

The Bcc header should never be included in your sent e-mail (what your
e-mail client sends). Your client compiles a list of recipients that
are aggregated from the To, Cc, and Bcc headers. It then uses that list
in the RCPT-TO command that it sends to the SMTP server. Recipients
never get to see the commands that were sent between your e-mail client
and the e-mail server. They only get to see the headers (which are just
data within your message). The Bcc recipients were in the compiled list
along with all the To and Cc recipients but told to the server via the
RCPT-TO command. Your e-mail client included a To and Cc header but it
should never include a Bcc header as that would thwart the purpose of
using it. Recipients should never see who was listed in the Bcc *field*
in your e-mail client (which should NOT be included as a header in the
e-mail that your e-mail client sends to the server). That means Gmail's
copy of the e-mail never had a Bcc header, so the copy saved in Gmail's
"Sent Items" folder never had a Bcc header to show you from there.
Gmail didn't get it so it can't show what it didn't get.

After sending the RCPT-TO command to the server that lists all the
recipients, your e-mail client then sends your message which consists of
the headers, a blank delimiter line, and the body of your message via
the DATA command. The headers and body are all data for your message.
Since your client should never include the Bcc *field* as a Bcc header
in the data of your message, the server won't ever get that header.

Because the e-mail client is never supposed to include the Bcc header
means the server never sees it. It was never part of the DATA sent to
it. What the server can show you for its copy of the message is what it
got. It doesn't add the list of recipients from the RCPT-TO command
into your e-mail copy. Commands are just between client and server, not
within the data transferred between them that constitutes the message.
Because IMAP has you synchronizing to THEIR server-side folder, and
because their copy of your outbound e-mail will never have the Bcc
header (since your client never added it), then you cannot see the Bcc
header in THEIR copy of what they got from your client. It was never up
there on their server for it to include in their copy in their folder.

POP doesn't synchronize with server-side folders. POP has no concept of
folders. It only understands the concept of a mailbox (which is the
Inbox folder as presented by the webmail client for your e-mail
provider). There are no folder commands in POP. That means what you
see in your e-mail client for POP accounts are *local-only* folders.
Because they are local, they contain and can show all the fields in the
records in the database for those items. You entered a non-blank value
for the Bcc *field* when you composed an e-mail. Your e-mail client
records that value. When your e-mail client sends your e-mail via SMTP,
it does NOT include a Bcc *header* in that message (in the DATA command
it uses to upload the message to the server). Although the server never
saw the Bcc header, your local e-mail client recorded the value you
entered in the Bcc *field* for that record in its database. That's why
you can see the Bcc field value when you view your local database but
why that field is missing from the server's copy.

The server should never get a message containing a Bcc header. If it
does contain a Bcc header, it should strip it out (and completely ignore
that header). Since the server never got an e-mail with that header (or
stripped it out), it won't be in the copies of your outbound e-mails
that the server retains. Your e-mail client knows there was a non-blank
value for the Bcc *field*. That value is stored in its local database.
With POP, you are viewing your LOCAL folders so you can see all the
fields which includes the Bcc field (if non-blank). With IMAP, you are
viewing the REMOTE folders up on the server. That means you can only
view what they recorded as contained within the e-mail that they
received from you - and that won't have any Bcc headers in them (your
client didn't include a Bcc header). As long as you synchronize against
the server's folders for an IMAP account, you see what they got, not
what is recorded in your local e-mail client's database.

I haven't bothered using IMAP but I believe you can choose against which
server-side folders you synchronize. Somewhere in the account
definition you create within Outlook for an IMAP account is the
folder(s) to which you synchronize. Typically just the [root] folder is
specified which means the root folder (Inbox) on the server along with
other standard folders up there. If you create user-defined folder
beyond the standard ones, you have to modify your IMAP account in
Outlook to add those server-side user-defined to get also get
synchronized; else, you'll see them when you use the webmail interface
to your account but you won't see them in the client. Since you can
specify which folders to include when synchronizing your client to your
server-side folders, you might be able to remove the "Sent Items"
folder. That means you will no longer be viewing (synchronizing) the
server-side "Sent Items" folder up on the server but instead be viewing
your local (client-side) "Sent Items" folder in your e-mail client.
Like I said, I don't use IMAP so I can't try this. I don't know if you
can choose to NOT sync to the standard list of folders up on the server.
Someone else familiar with using IMAP can tell you if you can de-sync
from the server-side "Sent Items" folder so you can then see the local
folder by that same name.

- You compose an e-mail.
- You enter a non-blank string into the Bcc *field* displayed in the
new-mail compose window. That field becomes part of the record for
that item in your e-mail client's database.
- Your e-mail client recorded the Bcc value as a field in the record it
saves in its database for that e-mail item.
- When your e-mail client sends your e-mail, it does NOT add a Bcc
header.
o It collects all the recipients from the To, Cc, and Bcc fields in
the new-mail compose window.
o It use the RCPT-TO command it sends to the server to tell the server
the list of recipients. No recipient gets to see that command or
its parameters. That just between your client and the server.
o Your client pushes your message out using the DATA command. Your
message consists of: headers (which will NOT have a Bcc header), a
blank delimiter line (to show where headers end), and the body of
your message.
- The SMTP server never gets an e-mail containing the Bcc header (or, if
it does, should strip it out). The copy of your outbound e-mail that
gets up on the server will not contain a Bcc header since your client
never included it in the DATA command.
- If you extract records out of your e-mail client's database (e.g.,
saving an e-mail record into a disk file), it has all those fields in
the database record to save into the file copy. The Bcc field is one
of those in the record so it is available in the database.
- Since your server never got an e-mail with the Bcc header inside of
it, the copy it saves also won't have the Bcc header.
- IMAP has you sync to the *remote* or server-side folders. Those
contain copies of your e-mails that your server received. Those won't
have the Bcc header in them since it was never there to the server.
- POP has you view your *local* or client-side folders in your e-mail
client. That can show you any fields in the e-mail record in the
message store (database) for your e-mail client.

With IMAP, you're seeing what the server got - and the server never got
an e-mail that included a Bcc header.
 
Jim S said:
:-)
I barely understood a word of that, but if for example you are using gmail
and check the sent mail folder (via browser) then there is no record of any
bcc info., so it's hardly likely that it would appear in the Outlook
synchronised email.

(Please down a cup of strong coffee before continuing.)

Still, if saving a record (e-mail item) into a disk file results in
showing the Bcc field then that field had to be in the record held in
Outlook's local database. Since you're synchronizing to the folder up
on the IMAP server, Outlook only shows you its information rather than
Outlook's database information.

Although you are using IMAP to receive e-mails, you are still using SMTP
to send e-mails. The SMTP server should never see and never include the
Bcc field in its copy of e-mails sent out from it. If the client
mistakeningly added a Bcc field, the SMTP server should strip it out
before sending that e-mail. Since the SMTP server's copy doesn't
contain the Bcc field, and because Gmail saves the SMTP copy of the sent
e-mail into its Sent Items folder, you can't see the Bcc field. It's
not there in Gmail's copy. Gmail never got an e-mail that had the Bcc
header in it so what it got to save also doesn't have the Bcc header.

The Bcc header should never be included in your sent e-mail (what your
e-mail client sends). Your client compiles a list of recipients that
are aggregated from the To, Cc, and Bcc headers. It then uses that list
in the RCPT-TO command that it sends to the SMTP server. Recipients
never get to see the commands that were sent between your e-mail client
and the e-mail server. They only get to see the headers (which are just
data within your message). The Bcc recipients were in the compiled list
along with all the To and Cc recipients but told to the server via the
RCPT-TO command. Your e-mail client included a To and Cc header but it
should never include a Bcc header as that would thwart the purpose of
using it. Recipients should never see who was listed in the Bcc *field*
in your e-mail client (which should NOT be included as a header in the
e-mail that your e-mail client sends to the server). That means Gmail's
copy of the e-mail never had a Bcc header, so the copy saved in Gmail's
"Sent Items" folder never had a Bcc header to show you from there.
Gmail didn't get it so it can't show what it didn't get.

After sending the RCPT-TO command to the server that lists all the
recipients, your e-mail client then sends your message which consists of
the headers, a blank delimiter line, and the body of your message via
the DATA command. The headers and body are all data for your message.
Since your client should never include the Bcc *field* as a Bcc header
in the data of your message, the server won't ever get that header.

Because the e-mail client is never supposed to include the Bcc header
means the server never sees it. It was never part of the DATA sent to
it. What the server can show you for its copy of the message is what it
got. It doesn't add the list of recipients from the RCPT-TO command
into your e-mail copy. Commands are just between client and server, not
within the data transferred between them that constitutes the message.
Because IMAP has you synchronizing to THEIR server-side folder, and
because their copy of your outbound e-mail will never have the Bcc
header (since your client never added it), then you cannot see the Bcc
header in THEIR copy of what they got from your client. It was never up
there on their server for it to include in their copy in their folder.

POP doesn't synchronize with server-side folders. POP has no concept of
folders. It only understands the concept of a mailbox (which is the
Inbox folder as presented by the webmail client for your e-mail
provider). There are no folder commands in POP. That means what you
see in your e-mail client for POP accounts are *local-only* folders.
Because they are local, they contain and can show all the fields in the
records in the database for those items. You entered a non-blank value
for the Bcc *field* when you composed an e-mail. Your e-mail client
records that value. When your e-mail client sends your e-mail via SMTP,
it does NOT include a Bcc *header* in that message (in the DATA command
it uses to upload the message to the server). Although the server never
saw the Bcc header, your local e-mail client recorded the value you
entered in the Bcc *field* for that record in its database. That's why
you can see the Bcc field value when you view your local database but
why that field is missing from the server's copy.

The server should never get a message containing a Bcc header. If it
does contain a Bcc header, it should strip it out (and completely ignore
that header). Since the server never got an e-mail with that header (or
stripped it out), it won't be in the copies of your outbound e-mails
that the server retains. Your e-mail client knows there was a non-blank
value for the Bcc *field*. That value is stored in its local database.
With POP, you are viewing your LOCAL folders so you can see all the
fields which includes the Bcc field (if non-blank). With IMAP, you are
viewing the REMOTE folders up on the server. That means you can only
view what they recorded as contained within the e-mail that they
received from you - and that won't have any Bcc headers in them (your
client didn't include a Bcc header). As long as you synchronize against
the server's folders for an IMAP account, you see what they got, not
what is recorded in your local e-mail client's database.

I haven't bothered using IMAP but I believe you can choose against which
server-side folders you synchronize. Somewhere in the account
definition you create within Outlook for an IMAP account is the
folder(s) to which you synchronize. Typically just the [root] folder is
specified which means the root folder (Inbox) on the server along with
other standard folders up there. If you create user-defined folder
beyond the standard ones, you have to modify your IMAP account in
Outlook to add those server-side user-defined to get also get
synchronized; else, you'll see them when you use the webmail interface
to your account but you won't see them in the client. Since you can
specify which folders to include when synchronizing your client to your
server-side folders, you might be able to remove the "Sent Items"
folder. That means you will no longer be viewing (synchronizing) the
server-side "Sent Items" folder up on the server but instead be viewing
your local (client-side) "Sent Items" folder in your e-mail client.
Like I said, I don't use IMAP so I can't try this. I don't know if you
can choose to NOT sync to the standard list of folders up on the server.
Someone else familiar with using IMAP can tell you if you can de-sync
from the server-side "Sent Items" folder so you can then see the local
folder by that same name.

- You compose an e-mail.
- You enter a non-blank string into the Bcc *field* displayed in the
new-mail compose window. That field becomes part of the record for
that item in your e-mail client's database.
- Your e-mail client recorded the Bcc value as a field in the record it
saves in its database for that e-mail item.
- When your e-mail client sends your e-mail, it does NOT add a Bcc
header.
o It collects all the recipients from the To, Cc, and Bcc fields in
the new-mail compose window.
o It use the RCPT-TO command it sends to the server to tell the server
the list of recipients. No recipient gets to see that command or
its parameters. That just between your client and the server.
o Your client pushes your message out using the DATA command. Your
message consists of: headers (which will NOT have a Bcc header), a
blank delimiter line (to show where headers end), and the body of
your message.
- The SMTP server never gets an e-mail containing the Bcc header (or, if
it does, should strip it out). The copy of your outbound e-mail that
gets up on the server will not contain a Bcc header since your client
never included it in the DATA command.
- If you extract records out of your e-mail client's database (e.g.,
saving an e-mail record into a disk file), it has all those fields in
the database record to save into the file copy. The Bcc field is one
of those in the record so it is available in the database.
- Since your server never got an e-mail with the Bcc header inside of
it, the copy it saves also won't have the Bcc header.
- IMAP has you sync to the *remote* or server-side folders. Those
contain copies of your e-mails that your server received. Those won't
have the Bcc header in them since it was never there to the server.
- POP has you view your *local* or client-side folders in your e-mail
client. That can show you any fields in the e-mail record in the
message store (database) for your e-mail client.

With IMAP, you're seeing what the server got - and the server never got
an e-mail that included a Bcc header.

Aha!
--
Jim S
Tyneside UK
www.jimscott.co.uk
http://geordiecamii.wordpress.com
http://geordiecam.wordpress.com/
 
Back
Top