Lightroom: Exported emails don't appear in Outlook's sent items folder.

Assuming all Lightroom is doing is telling the OS to handle the "mailto" protocol request, I'm uncertain what more can be done. It is odd.

However, here is a potential workaround (I don't use Outlook for any reason anymore, so I cannot test this):

Create a rule based on “Apply rule on messages I send”, and possible some keyword in the other headers -- the idea is that you want Lightroom-originating emails to trigger the rule.

Have this rule drop a copy into any folder you like, including the regular Sent Items folder.

P.S. Does anybody know whether bug reports like this posted here find their way to the Adobe product team? Or do we have to raise bugs via a different route?

P.P.S. I take back what I wrote about the built-in email client being an acceptable workaround if it had a "Bcc by default" option. That would only be acceptable if the built-in client also came with the option to send photos as true attachments rather than as in-line images. The latter just doesn't work well for many recipients, especially on Windows systems.

AFAIK, there is no such thing as an SMTP header called "account". I doubt it is using MAPI, though if it is then using Outlook as a service is probably never going store the sent messages, as Outlook is not really acting as a mailer.

If it is bringing up an Outlook edit window with a MIME attachment for the image, which you can further edit with body content and it is still not saving a copy in the Sent Items folder, then this is not a mailto protocol issue, either. At this point, mailto has triggered the OS protocol handler, and the rest is up to the mailer.

At issue is that Outlook is starting up in a state where it does not automatically do this. Now, Outlook has "smart" features (like any other modern mailer) that tries to sense which "account" a message is associated with. And it has the notion of a default account. My guess is that under these circumstances, some Outlook configurations will start up with a default account setting that has no associated Sent Items folder.

As a hail-mary, you can try to force the account settings via these registry settings:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\outlook\options
DWORD VALUE 1 ForceAccountSelection

I don't know if this is supported for your version of Outlook, so you might have to change that "14.0" to something reasonable on your system.

Now, all this might do is save the items to the "wrong" sent items folder, especially if you are using an IMAP account. If this is the case, then the problem is definitely how Outlook as the mailto handler is deciding how to manage mail items it is being told to manage.

I guess what I'm saying is that, if this is a mailto: link that Outlook is handling because the OS is telling it to (i.e., an outlook edit window is coming up), then there is little Lightroom can do to change this. Once the mailer is open, what it does in terms of saving the message and so on is a function of the mailer, not the agent that initiated the mailto link in the first place.

An easy test would be to construct a mailto link with an "attach=" clause, and see what Outlook does.

mailto:lastname.firstname@xxx.com?subject=Test_Attachment&body=This%20is%20a%20test%20email.&attach=C:\Documents%20and%20Settings\username\Desktop\foldername\APPname_20121123.log

Change the email address to match your account in Outlook. Change the path after the "&attach=" to point to a test file to attach to the email. Put this link in a web page and click on it from a web browser.

John Verne, that's my whole point -- and you've just proven that you're mistaken. I did what you asked, and when I clicked on the link containing the mailto HREF that you specified, the Outlook message that was created DID have the Save Sent Item To option set to my default Sent Items folder, and a copy of the outgoing message WAS saved when I sent it. (There was no attachment in the message, though.)

Again, again, that's my whole point. Outlook is just doing what it's told. Every other program I have come across that calls Outlook for sending its email -- and even the simple mailto link that you asked me to try -- leaves the default setting for Save Sent Item To alone. Lightroom is the exception. That is why it is pretty clear that there's something that Lightroom is doing in calling Outlook that is causing the message not to be saved.

As you know from the link you created, mailto has attributes that can be specified as part of the call. MAPI too. So it would stand to reason that one of those attributes somehow affects the behavior of the Save Sent Item To setting. And Lightroom is messing that up.

I don't know whether this is relevant, but I found some documentation on the web saying that there is a MAPI property called PR_SENTMAIL_ENTRYID that needs to be set by the application generating the email, which should be copied from the PR_IPM_SENTMAIL_ENTRYID to use the default Sent Items folder of the email client. Adobe, any chance that you guys forget to set this property (or set it wrong) when you make the MAPI call from Lightroom?

I'm no expert here, but I'm just sayin'...

The only attributes a mailto link accepts are SMTP headers, SMTP body and the special "attach" parameter. The point is that mailto is a very simple URL-type protocol, and once the handling application starts up, the calling application doesn't have any say in the matter.

By the way, the reason I provided the example above is to work from the known to the unknown to determine the scope of the problem. I am not at all interested in proving anyone "right" or "wrong". This is the wrong attitude when working on problems. I did not prove myself "mistaken" because I never made any strong assertion in the first place.

What I did say is that if Lightroom is using the mailto protocol, then it is Outlook that is at fault. This is an obvious conclusion given the facts.

The only reason I am taking the time to explain this is to suggest that what Lightroom is doing does not involved the mailto protocol at all. This is what we have proven with the little test above.

Something else is at play here.

If MAPI is being used, then Crom save us all, because MAPI is such a hopelessly insecure and broken system that we are lucky it manages to send anything at all.

My guess is that the reason this problem persists is that it is nearly impossible to reproduce consistently on arbitrary systems, which is my experience with MAPI-style conventions in the past.

All very nice, thank you. (And I really think it is MAPI.) Now how do we get someone from Adobe who can actually fix this to take notice?