Verily I say unto thee, that Roy Schestowitz spake thusly:
> __/ [ Anonymous ] on Thursday 31 May 2007 03:31 \__
>> 20 Apr 07
>>
>> I save an E-mail in Outlook format with name "yyyy-mm-dd
>> 1st-Init-Last-Name Subject.msg". Attach to an E-mail, renames it
>> to subject.msg and replaces name in cc: list with current global
>> address name. Problem is person's title has changed and E-mail was
>> sent prior to person's title change. It lost its historical
>> truthfulness by such an act.
Outlook is infamous for mangling message headers, making it useless for
archival or forensic (anti-spam) purposes. It's infamous for many other
things too, of course, such as it's ridiculous proprietary message store
that makes conversion a near impossible task, unless one uses IMAP (and
even then the headers are still corrupted).
Back in my Windows days, I used Outlook because I was unaware of any
decent alternative. Gradually I became more and more frustrated with its
inadequacies, until I reached the point where I needed a professional
spam-filtering service and discovered, to my horror, the reason Outlook
was incompatible with that service. That was the final straw for me.
Here's the original thread, in which Mike Easter has to explain RFC
standards to one of the (then) Outlook developers:
.----
| Jeff Stephenson [MSFT]: "When Outlook is asked for a message in
| MIME format, it will re-generate MIME from the MAPI, but that MIME
| it will not be exactly the MIME that was received. If asked to
| generate the message in Plain Text format, it will not have a
| text/html body part, just text/plain, even if the original message
| was text/html. If asked for HTML format, it will generate both
| text/plain and text/html body parts in a multipart/alternative
| message.
|
| It sounds like the SpamCop discussion has a fixation on the
| boundaries used between body parts and is missing some real issue -
| Outlook does not generate bad MIME, which is what the original
| message with the boundaries stripped would be. So what *is* the
| real issue here? Get past the fact that the MIME is not exactly
| the same as what was received - it won't be, and that's that."
|
| ...
|
| Mike Easter: "In the spamfighting world, "Everyone" traditionally
| submits to the appropriate desk the "exact" spam /as received/ in
| the form of standard email client type smtp headers continuous with
| the mime format as described in the RFCs [eg 1521], which also have
| strict rules for what the meanings of the various Content-Type:
| header lines outlined in those RFCs, eg multipart/alternative and
| such and boundary definitions."
`----
http://tinyurl.com/2aj4kb (Google Groups)
Like their greed, Microsoft's arrogance and ignorance knows no bounds.
> 65 Reasons Why Outlook 2007 Will Suck
>
> http://chris.pirillo.com/2006/05/26/65-reasons-why-outlook-2007-will-suck/
Here's another:
.----
| coastaldata: "Hello, I've tried the Microsoft Junk Mail Reporting
| tool, but I still prefer to use SpamCop.net for spam submissions,
| because it is a more technical service that has a lot of
| connectivity (to blackhole lists and the like).
|
| What I can't figure out is why MS insists that it should be so darn
| difficult to extract the *full un-modified source* of a message! It
| gets harder and harder to do with each version.
|
| In Outlook 2003, I used an add-in called "OLSpamCop", which is
| free, but not longer works with 2007.
|
| I would like to find or build an addin for Outlook 2007 which VERY
| SIMPLY opens notepad with the FULL MESSAGE SOURCE for any selected
| message. This should include headers, encoded attachments, and the
| message body.
|
| Does anybody know of such a plugin already in existence, or have
| any tips for code samples to help me on my way?
|
| This should be so simple and obvious, I just can't imagine why MS
| does not already provide this capability."
|
| ...
|
| Dmitry Streblechenko (MVP): "Because Outlook itself (unlike OE)
| never uses the MIME source and it would be a waste of space to
| store both the original data and the MAPI properties created by
| parsing the MIME message. And if a message is sent between two
| Exchange mailboxes, a mesage would never even be converted to the
| MIME format."
|
| ...
|
| coastaldata: "Interesting... If I understand correctly, you're
| saying that the original message source is not saved?
|
| Some how, some way, there MUST be a way to extract all of this
| information in one fell swoop!
|
| It is simply too unthinkable that MS would back a product, in this
| day and age of mega-spam, that is not more friendly to spam
| reduction tools and techniques.
|
| Is the plugin that I suggest still creatable? Or is Outlook in the
| "end game"?"
|
| ...
|
| Dmitry Streblechenko (MVP): "Correct, this is exactly what I am
| saying - the original MIME source is not normally saved because
| that would bring no benefits to an end user and will at least
| double the size of the message. And no user will appreciate that.
| There is a registry entry that will force Outlook to save the
| complete source, but it is only used by debug purposes and is not
| set out of the box. Outlook does save the *headers* portion of the
| MIME message in the PR_TRANSPORT_MESSAGE_HEADERS property. You can
| of course re-create a MIME message from a MAPI message, but while
| it will look exactly the same to an end user, on the binary level,
| it will not be exactly the same as the original message."
`----
http://tinyurl.com/24z4fn (microsoft.com)
As I predicted, Outlook is just as broken as ever - more so in fact.
So Microsoft thinks it is acceptable to arbitrarily alter users'
personal data, break standards, deliberately create non-interoperable
protocols for no justifiable reason, and then dismiss any criticisms out
of hand with arrogant statements.
MAPI is a disease ... as is Microsoft.
--
K.
http://slated.org
,----
| <This sig left intentionally blank>
`----
Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.20-1.2312.fc5
11:36:19 up 44 days, 9:08, 2 users, load average: 0.48, 0.54, 0.46
|
|
