IIS 6.0 SMTP Gateway Corrupting Mail

I have a problem using the IIS 6.0 SMTP gateway under windows 2003. If a
message is submitted that has a string longer than 72 characters without any
whitespace characters, AND the 71st character is a period, the period is
being removed by the smtp gateway.

I am assuming it has to do with the algorithm for truncating long lines in
accordance with the ietf smtp standards.

I have forced a mail gateway failure by sending to a invalid account to be
able to look at the mail in the badmail directory at the file and can verify
this.

The mail is being sent in HTML format, and the following occurs:

<img
src=http://www.somewhere.xyz/firstlevel/secondlevel/images/thisgraphic.jpg>

becomes

<img
src=http://www.somewhere.xyz/firstlevel/secondlevel/images/thisgraphicjpg>

KL
Mon Oct 23 17:08:54 CDT 2006



I dont belive the SMTP service formats the message at all, the client
however does, try it with other email clients.

KL


"Hans Mueller" <Hans Mueller@discussions.microsoft.com> skrev i meddelandet
news:145A4CAB-0803-48EB-A084-6EDB087EE06B@microsoft.com...
>I have a problem using the IIS 6.0 SMTP gateway under windows 2003. If a
> message is submitted that has a string longer than 72 characters without
> any
> whitespace characters, AND the 71st character is a period, the period is
> being removed by the smtp gateway.
>
> I am assuming it has to do with the algorithm for truncating long lines in
> accordance with the ietf smtp standards.
>
> I have forced a mail gateway failure by sending to a invalid account to be
> able to look at the mail in the badmail directory at the file and can
> verify
> this.
>
> The mail is being sent in HTML format, and the following occurs:
>
> <img
> src=http://www.somewhere.xyz/firstlevel/secondlevel/images/thisgraphic.jpg>
>
> becomes
>
> <img
> src=http://www.somewhere.xyz/firstlevel/secondlevel/images/thisgraphicjpg>
>
>

Steve
Mon Oct 23 17:41:50 CDT 2006

Hmm, never seen this before. Make sure you are not running some type of
Anti-virus product that would cause something to alter the email message.
If so, turn off your AV software and try sending a message. I would also
try writing a small script to generate the message locally to see if the
same behavior happens. If it works, then it is application related.

Tx,

Steve Schofield
Microsoft MVP - IIS


"Hans Mueller" <Hans Mueller@discussions.microsoft.com> wrote in message
news:145A4CAB-0803-48EB-A084-6EDB087EE06B@microsoft.com...
>I have a problem using the IIS 6.0 SMTP gateway under windows 2003. If a
> message is submitted that has a string longer than 72 characters without
> any
> whitespace characters, AND the 71st character is a period, the period is
> being removed by the smtp gateway.
>
> I am assuming it has to do with the algorithm for truncating long lines in
> accordance with the ietf smtp standards.
>
> I have forced a mail gateway failure by sending to a invalid account to be
> able to look at the mail in the badmail directory at the file and can
> verify
> this.
>
> The mail is being sent in HTML format, and the following occurs:
>
> <img
> src=http://www.somewhere.xyz/firstlevel/secondlevel/images/thisgraphic.jpg>
>
> becomes
>
> <img
> src=http://www.somewhere.xyz/firstlevel/secondlevel/images/thisgraphicjpg>
>
>

HansMueller
Mon Oct 23 19:32:01 CDT 2006

There is no antivirus running, and all the mail is being generated by scripts
running under IIS / coldfusion on the server. The HTML message is composed
and sent directly to the SMTP server without any client intervention. If you
compare the message that is sent to the message stored by the SMTP service
you will see the truncation.

It is documented by microsoft at:

http://support.microsoft.com/kb/293852

and the statement is made that the problem lies in the remote smtp service.

Since the message is being submitted directly to the IIS SMTP service, and
examining the output that the badmail message with contains directly on the
server running the smtp gateway with a text editor, I believe that the smtp
service is the culprit.

Also if we configure the script to split the lines in the html message being
sent at less than 70 charcters, the problem does not occur. But other
problems arise with some mail clients not being able to ignore the line
breaks when recomposing the message.

If you create a valid link as i show in my example and send it via the smtp
service, it will arrive without with the period character missing. It is
easily reproducible.



"Steve Schofield" wrote:

> Hmm, never seen this before. Make sure you are not running some type of
> Anti-virus product that would cause something to alter the email message.
> If so, turn off your AV software and try sending a message. I would also
> try writing a small script to generate the message locally to see if the
> same behavior happens. If it works, then it is application related.
>
> Tx,
>
> Steve Schofield
> Microsoft MVP - IIS
>
>
> "Hans Mueller" <Hans Mueller@discussions.microsoft.com> wrote in message
> news:145A4CAB-0803-48EB-A084-6EDB087EE06B@microsoft.com...
> >I have a problem using the IIS 6.0 SMTP gateway under windows 2003. If a
> > message is submitted that has a string longer than 72 characters without
> > any
> > whitespace characters, AND the 71st character is a period, the period is
> > being removed by the smtp gateway.
> >
> > I am assuming it has to do with the algorithm for truncating long lines in
> > accordance with the ietf smtp standards.
> >
> > I have forced a mail gateway failure by sending to a invalid account to be
> > able to look at the mail in the badmail directory at the file and can
> > verify
> > this.
> >
> > The mail is being sent in HTML format, and the following occurs:
> >
> > <img
> > src=http://www.somewhere.xyz/firstlevel/secondlevel/images/thisgraphic.jpg>
> >
> > becomes
> >
> > <img
> > src=http://www.somewhere.xyz/firstlevel/secondlevel/images/thisgraphicjpg>
> >
> >
>

KL327
Mon Oct 23 21:20:18 CDT 2006

> It is documented by microsoft at:
>
> http://support.microsoft.com/kb/293852

Did you in fact look at what was listed there ? Outlook is a client,
not a server. Also, look at the date of that article.

The smtp service does not format your message, I don't care where you
are looking, it is you client that formats it.

You seem to be on a quest and good luck with that, I think it's you
knowledge that is the problem here and you have gotten it into your
head that the smtp service is perfoming formatting on your emails which
it doesnt.

Tim
Tue Oct 24 13:41:01 CDT 2006

Slightly on the rude side, but true. Your e-mail client determines the
format of the message. The SMTP service is merely the protocol used for
transmitting and delivering the message.

"KL327" wrote:

> > It is documented by microsoft at:
> >
> > http://support.microsoft.com/kb/293852
>
> Did you in fact look at what was listed there ? Outlook is a client,
> not a server. Also, look at the date of that article.
>
> The smtp service does not format your message, I don't care where you
> are looking, it is you client that formats it.
>
> You seem to be on a quest and good luck with that, I think it's you
> knowledge that is the problem here and you have gotten it into your
> head that the smtp service is perfoming formatting on your emails which
> it doesnt.
>
>

HansMueller
Wed Oct 25 08:46:01 CDT 2006

I would agree with the tone of the message being crude, and some people have
to show bravado in threads they didn't take the time to understand fully, so
I have learned to ignore them.

The SMTP gateway DOES change the LINE format of messages using chunking and
folding to reformat long lines. If you examine the text of the mail placed
in the drop directory, and compare that to a TCPIP stream capture, you will
see it. The data that is sent is the same data that ends up in the badmail
directory on an unroutable mail address.

The dot before the filename extension is not missing from the file in the
drop directory, but is missing in the file in the badmail directory.

The link that I sent was meant to point out the rfc which specifies
transparency rules. The IIS SMTP service breaks the message into line
lengths of less than 72 characters and issues each line as a seperate SMTP
DATA command statement to the receiving smtp service. It's a standard
process that most smtp gateways adhere to when sending and it usually works
correctly.

The problem is that the IIS SMTP gateway for some reason discards the 71st
character only if it is a period in a string that is unbroken by whitespace.

I can document and reproduce the problem 100% of the time. I wasn't trying
to get help on whether or not it is happening, just hoping that someone ran
into this problem before and could point me to a fix or work-around.

I'm sorry if others thought that I was claiming that the message was being
reformatted.

I will open an incident with microsoft.





"Tim" wrote:

> Slightly on the rude side, but true. Your e-mail client determines the
> format of the message. The SMTP service is merely the protocol used for
> transmitting and delivering the message.
>
> "KL327" wrote:
>
> > > It is documented by microsoft at:
> > >
> > > http://support.microsoft.com/kb/293852
> >
> > Did you in fact look at what was listed there ? Outlook is a client,
> > not a server. Also, look at the date of that article.
> >
> > The smtp service does not format your message, I don't care where you
> > are looking, it is you client that formats it.
> >
> > You seem to be on a quest and good luck with that, I think it's you
> > knowledge that is the problem here and you have gotten it into your
> > head that the smtp service is perfoming formatting on your emails which
> > it doesnt.
> >
> >