[quoted text, click to view]

Took a look at the generated messages off-list and determined the
problem. It's also noted in

http://support.microsoft.com/?id=3D286358

There is insufficient documentation of cdoSendUsingPickup internals
vs. cdoSendUsingPort that clearly invites insufficient code. The two
send options are *not* differentiated solely by the method of mail
submission (dropping into local \Pickup using file I/O alone vs. SMTP
client/server submission).

A more important difference is that Port makes CDOSYS act like an
RFC-compliant SMTP client, which includes automatically making changes
to the message body before submission to prepare it for later SMTP
RFC-required modifications. OTOH, Pickup makes no effort to prepare
the message body for SMTP transmission, assuming (I would say wrongly
in the overwhelming # of cases) that there is some kind of SMTP
pre-processor or SMTP-savvy coder "wrapping" CDOSYS and making such
message body modifications *before* CDOSYS is called. Then IIS acts
ignorant of the use of Pickup (though CDOSYS and IIS would seem
tightly coupled, given that cdoSendUsingPickup is the default when IIS
SMTP is installed!)... makes changes to submitted messages as if
they've been pre-processed... and mangles results.

The Metabase change noted in the KB article changes behavior so that
the IIS side "understands" that CDOSYS is incorrectly (though
understandably, given barebones docs) used as if it were
through-and-through an SMTP client library and *doesn't* make related
changes.

I see little justification for the default behavior, but at least
there is a fix.

Reference RFC 822 4.5.2, Transparency.

I'm not sure I follow completely besides the first step in troubleshooting I
would take is looking at the message formatting to ensure it's ok. 99% of
the time, I use SMTP method of delivery vs. dropping directly into the
pickup folder. The only product I've use to drop directly into the pickup
folder is AspNetEmail, which is a .NET based component.

Good info on the support.microsoft.com site though, one of these days I'll
see if I can reproduce this issue. It looks like an obscure one that can be
easily overlooked if someone is using CDOSYS.

--

Best regards,

Steve Schofield
Windows Server MVP - IIS
http://weblogs.asp.net/steveschofield


[quoted text, click to view]

Took a look at the generated messages off-list and determined the
problem. It's also noted in

http://support.microsoft.com/?id=286358

There is insufficient documentation of cdoSendUsingPickup internals
vs. cdoSendUsingPort that clearly invites insufficient code. The two
send options are *not* differentiated solely by the method of mail
submission (dropping into local \Pickup using file I/O alone vs. SMTP
client/server submission).

A more important difference is that Port makes CDOSYS act like an
RFC-compliant SMTP client, which includes automatically making changes
to the message body before submission to prepare it for later SMTP
RFC-required modifications. OTOH, Pickup makes no effort to prepare
the message body for SMTP transmission, assuming (I would say wrongly
in the overwhelming # of cases) that there is some kind of SMTP
pre-processor or SMTP-savvy coder "wrapping" CDOSYS and making such
message body modifications *before* CDOSYS is called. Then IIS acts
ignorant of the use of Pickup (though CDOSYS and IIS would seem
tightly coupled, given that cdoSendUsingPickup is the default when IIS
SMTP is installed!)... makes changes to submitted messages as if
they've been pre-processed... and mangles results.

The Metabase change noted in the KB article changes behavior so that
the IIS side "understands" that CDOSYS is incorrectly (though
understandably, given barebones docs) used as if it were
through-and-through an SMTP client library and *doesn't* make related
changes.

I see little justification for the default behavior, but at least
there is a fix.

Reference RFC 822 4.5.2, Transparency.

--Sandy

[quoted text, click to view]

The message formatting is perfectly valid for submission to an
RFC-compliant SMTP client library.

But CDOSYS _does not_ operate as an RFC-compliant SMTP client library
when in Pickup mode. It does not add the transport-level failsafe
modifications that an SMTP library (and a SMTP client app such as
Outlook or Thunderbird) adds.

The receiving IIS SMTPSVC, however, erroneously assumes that the
modifications have been made. This is true regardless of whether the
destination of the e-mail is remote or local (it's the local delivery
case that makes this without a doubt an IIS bug). IIS makes
counter-modifications per RFC 822; since the initial modifications
were not made, but the counter-modifications were, the message is
broken.

[quoted text, click to view]

Hmm... anything that drops messages into the pickup folder without
complying with the SMTP client (sender-SMTP) RFCs will break messages,
unless the metabase tweak is in place. I would hope that a 3rd-party
component that offers an "IIS Pickup Folder" option by name would be
aware of the default IIS behavior, but maybe not....

www.aspnetemail.com is the component I'm referring to. I've never used the
pickup folder method with CDOSys. I've turned off the service and viewed
messages both in Notepad and could open in another text editor to see if
'odd' characters are being added.

That is good information to know about the RFC, that is a little over my
head. :)
--

Best regards,

Steve Schofield
Windows Server MVP - IIS
http://weblogs.asp.net/steveschofield


[quoted text, click to view]