We have an automated system sending mail from an oracle database / application. It all works, and has done for several years on Exchange 2003. On Exchange 2007, any text in the message body which contains the = character is corrupted. It appears to translate the next 2 characters as an ascii reference, for example a reference to a phone number such as '= 44116305' will get changed to 'D116305'. Any spaces in the characters following the = are ignored. Any non-numeric characters are lost eg =fred will be received as =ed Testing by sending a telnet port 25 message from the oracle server works correctly, as does sending mail from exchange 2007 mailboxes to exchange 2007 mailboxes, and receiving mail from external sources to the exchange 2007 mailboxes. It only appears to be a problem sending mail from within oracle, and only with Exchange 2007. Any help would be appreciated

You could change all equal signs to =3D. That's probably the easiest way to deal with this. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "Steve_At_Leicester" wrote in message news:a5a1ff50-8e46-439c-96c7-f4bb16b82664... We have an automated system sending mail from an oracle database / application. It all works, and has done for several years on Exchange 2003. On Exchange 2007, any text in the message body which contains the = character is corrupted. It appears to translate the next 2 characters as an ascii reference, for example a reference to a phone number such as '= 44116305' will get changed to 'D116305'. Any spaces in the characters following the = are ignored. Any non-numeric characters are lost eg =fred will be received as =ed Testing by sending a telnet port 25 message from the oracle server works correctly, as does sending mail from exchange 2007 mailboxes to exchange 2007 mailboxes, and receiving mail from external sources to the exchange 2007 mailboxes. It only appears to be a problem sending mail from within oracle, and only with Exchange 2007. Any help would be appreciated Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Ed Thanks, Tested that out and it works OK as a temporary fix. Question is why does it do it and is there a more permanent fix. Our developers won't always remember to put in =3D whenever they mean =. What has changed between Exchange 2003 and 2007? Steve

On Wed, 7 Jul 2010 12:27:02 +0000, Steve_At_Leicester wrote: >We have an automated system sending mail from an oracle database / application. It all works, and has done for several years on Exchange 2003. > >On Exchange 2007, any text in the message body which contains the = character is corrupted. It appears to translate the next 2 characters as an ascii reference, for example a reference to a phone number such as '= 44116305' will get changed to 'D116305'. Any spaces in the characters following the = are ignored. Any non-numeric characters are lost eg =fred will be received as =ed > >Testing by sending a telnet port 25 message from the oracle server works correctly, as does sending mail from exchange 2007 mailboxes to exchange 2007 mailboxes, and receiving mail from external sources to the exchange 2007 mailboxes. It only appears to be a problem sending mail from within oracle, and only with Exchange 2007. > >Any help would be appreciated From the description it sounds like the application is using 8bitmime and those equal signs are being interpreted as "quoted-printable" representations of 8-bit data that are not able to be represented in a 7-bit transmission. http://en.wikipedia.org/wiki/Quoted-printable Had you surpressed the '8bitmime' keyword on your Exchage 2003 server? Have you done the same to your Exchange 2007 receive connector? set-receiveconnector <connectorname> -EightBitMimeEnabled:$false Alternatively, you could have the application send HELO instead of EHLO to begin the SMTP transaction. Depending on the sending clinet, you could also try using a customized SMTP banner on your receive connector so "ESMTP" doesn't appear in it. Some clients will skip the initial EHLO and start the conversation with HELO when they don't find the ESMTP in the banner. I wouldn't depend on that behavior, though. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP