What's with the hostility here? Let's both pretend we are five years
old, and my comeback is "asked you first!" The OP asked WHY MS chose
to handle it that way, and you did not answer it. So why would you
expect me to come back and prove something if you don't have to answer?
There's no section in any RFC that says what Outlook must support.
Microsoft can choose to be compliant with anything it wants or choose
not to. But none of that is relevant. You seem to be confused about
what RFCs do and what they are for. The RFC describes what happens "on
the wire." Once Outlook gets the data, Outlook can present it anyway
that its designers want to, as far as the RFCs are concerned. As long
as Outlook can issue the correct commands and understand the correct
commands WHEN COMMUNICATING WITH something that is RFC compliant, then
it's RFC compliant. The RFCs for on the wire protocols don't govern
the MUA's user interface and they shouldn't.
That doesn't change the fact that the protocol is designed to support
folders in a specific manner. The conceptual difference between IMAP
and POP3 is that IMAP is designed to support keeping mail on the server
and in specified folders, while POP3 is just a crude way of getting
mail from a server, and has nothing to do with sent mail. If I can't
go from one computer to another and still see my sent mail in my Sent
Items folder for my IMAP server, then I'm not getting what I want. But
more to the point, Outlook is not even using IMAP when sending mail.
It's ignoring it, sending the mail through SMTP, and not letting the
IMAP server even know about the message. The problem then becomes one
of leading the user to believe that the client will use IMAP when it
does nothing of the sort when mail is sent.
If you don't want to answer why, I can always speculate. Answers can
range from the cynical to the pragmatic, but if Microsoft is not
telling us why they made the decision, that's the best we have for now.
I suppose that Microsoft didn't do more with IMAP because they could
get away with it. By adding a bit of IMAP support, they could appease
some of their users who had complained about it being missing. A
bigger problem is that few ISPs support it. If ISPs are offering their
customers 2GB mailboxes, but telling them that they have to use POP3,
then there is not a compelling reason for vendors to jump on it since
there's no critical mass. There is a reason for every vendor but
Microsoft to do it. They have to be better or they can't convince
people to use their product instead of the big dog on the block. But
Microsoft will put its money where it gets the most visibility. That's
what businesses do. Since Microsoft is not an email client company
but a large software company, they don't have to worry if people will
buy Outlook instead of something else. Their question is whether they
have enough features to keep existing users from looking for something
else. It's a given that Outlook will be on people's computers when
they get Office. Microsoft started bundling it when they sold the whole
suite at a competitive price, so if people already had the client, they
would have to justify spending money for an alternative to something
that's already on their PCs. Once it becomes so widely deployed, the
question is whether there's enough leakage over this issue to justify
the expense of fixing it (or changing it if you insist.) It's a
legitimate business strategy. People like me are stuck with Outlook
since it integrates with so many other things that it's not practical
to move to something else. If other clients don't have MAPI support,
then I'd have to duplicate my contacts in Outlook anyway for my phone
system to work. That's more work than setting up a few rules to get
things close to behaving.
It's still hard to understand why MS put more complete IMAP support in
OE, though.
