Content-Transfer-Encoding Header missing?

Hello,
our Exchange 2013 CU 6 won't send "Content-Transfer-Encoding" Header when sending Mails to external Domains. (This Header is present if Mail stays within our Org)
Already tried to set different Encodings - but without luck ... Exchange just won't generate this Header ...
[PS] C:\Windows\system32>Set-RemoteDomain -Identity Default -ByteEncoderTypeFor7BitCharsets Use7Bit
[PS] C:\Windows\system32>Set-RemoteDomain -Identity Default -ByteEncoderTypeFor7BitCharsets UseBase64
[PS] C:\Windows\system32>Set-RemoteDomain -Identity Default -ByteEncoderTypeFor7BitCharsets UseQP
Hope someone here can help me with this!?
Thank you, bye from Austria
Andreas Schnederle-Wagner

Hi,
I suggest try to re-start the Transport service after running the commands you mentioned.
Please try to refer following KB to change the encoding type. I suggest make a backup before changing the value.
How to change the method for transfer encoding after you apply Exchange 2007 SP1 to the Exchange 2007-based server that is running the Hub Transport role
https://support.microsoft.com/kb/946641?wa=wsignin1.0
Thanks
If you have feedback for TechNet Subscriber Support, contact
[email protected]
Mavis Huang
TechNet Community Support

Similar Messages

Five days ago I received an email from an anonymous sender with the subject: Your Apple ID was just used to buy full album Elton John 312.99. Your receipt No. 37930343160405752. the content began: Content-Transfer-Encoding: base64 From (my email add

Five days ago I received an anonymous email with the subject:
Your Apple ID was just used to buy full album Elton John £12.99.Your receipt No.37930343160405752
The content started: Content-Transfer-Encoding: base64 From:(my email address) followed by a very,very,very long stream of gobbledygook. There is no record of it in my i-tunes purchases or my credit card statement but that might only be because I have not updated my credit card details. Should I be worried that my account has been compromised? Does anyone know how I can get through to the right section of Apple to deal with this - all the emails I get say no-reply so I don't have an email address to contact them on.
I would be most grateful if anyone could help me with this.
Thanks in advance
Walwal

It's a phishing attempt to try and get your account and payment details - forward it to Apple : [email protected] , and then delete it
Phishing emails : Identifying fraudulent "phishing" email - Apple Support
Genuine emails : Identifying legitimate emails from the iTunes Store - Apple Support

How to change Content-Transfer-Encoding for mail sending

Hello Experts,
I need to send some documents through mail which i am doing with the help of cl_output_service=>document_output method. Mail is been send succesfully.
But in the payload content which got from Exchange server:
   X-Mailer: SAP Web Application Server 7.10
   Content-Type: text/plain;
    charset="us-ascii"
   Content-Transfer-Encoding: quoted-printable
Can any one help me, how i can change Content-Transfer-Encoding field to some other format which is not 'quoted-printable'.
Thanks & Regards,
Dheeraj

Do you documents contain an XML Declaration like this at the top?
<?xml version="1.0" encoding="ISO-8859-2"?>
If not, then they need to. The XML 1.0 specification says that if an XML declaration is not present, the processor must default to assume its in UTF-8 encoding.

I want to convison the mail body 's Content-Transfer-Encoding to base64

Return-Path: <[email protected]>
Received: from tobacco ([130.130.160.76]) by webapp.tobacco
(Netscape Messaging Server 3.6) with ESMTP id AAA70AC;
Tue, 6 Nov 2001 18:26:28 +0800
type: �� intra@ius_center 1670
subject: ��gggggg��
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 6 Nov 2001 18:26:28 +0800
Message-ID: <[email protected]>
From: [email protected]
<center><h1>��</h1><TABLE BORDER=1 CELLPADDING=5 width=90%%>
<TR><TD BGCOLOR=#CCCC99 width=74 valign=top><STRONG>��</STRONG></TD><TD BGCOLOR=#EEEEEE>gggggg</TD> </tr>
<TR><TD BGCOLOR=CCCC99 VALIGN=TOP><STRONG>�� </STRONG></TD><TD BGCOLOR=#EEEEEE>�� </td></tr>
<tr><TD BGCOLOR=#CCCC99 VALIGN=TOP><STRONG>�� </STRONG></TD><TD BGCOLOR=#EEEEEE >�� </td></tr>
<tr><TD BGCOLOR=#CCCC99 VALIGN=TOP><STRONG>��</STRONG></TD><TD BGCOLOR=#EEEEEE >fdsf</td></tr></TABLE>

Me too. I want to find out what encoding a particular $INPUT_FILE part is when I need to parse it in my conversions script.

How to change the Content-Transfer-Encoding for the fmddataa.fmd from base

Dear all,
When I using this SO_DOCUMENT_REPOSITORY_MANAGERto send email,I find the fmddata.fmd file have been changed to binary file attachment. I don't hope so.any one have good idea to avoid this case occur?
Can you tell me how to change the Content-Transfer-Encoding for the fmddata.fmd from base64 to quoted-printable. The quoted-printable is the Content-Transfer-Encoding for text file with extension .txt
Best Regards,
Merry

Thank you

Content-Transfer-Encoding is possible to change of received mail?

Its possible change Content-Transfer-Encoding 7bit to 8bit in received mail?
If yes please let me know how?
Thanks
Sanjay kashyap

Hi Sanjay Did u get any answer to ur problem as i also have problem with encoding problems and would like to change the encoding of the email message in the case when it is not specified with the email itself
Thanks

Content-Transfer-Encoding for mail from Portal

Hi,
I work on Portal 7.0 SP 12.
Do You know how to change encoding (Content-Transfer-Encoding) for mails send from portal by users (ex. from Collaboration Launch Pad) ?
Regards,
Jarek

Thank you

Running mac OS 10.5.8, Using Mail 3.5, Text encoding set to Automatic. messages arrive, but the message is 200 lines of alphanumerics. Top says Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64.

I use Mail 3.6 and some incoming email messages start with
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: base64
then go on to 200+ lines of alphanumerics (mostly upper and lower case letters).
What causes this problem, how can I fix it?
Text encoding is set to Automatic, and I'm not using any fancy fonts. Senders are usually
sending from PCS that may well use Outlook.
Rosemary C. Chicago

Does it look something like this...
JVBERi0xLjYNJeLjz9MNCjMyNCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9M
ZW5ndGggMTU4L04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQohx6hAp7lMT4WVkGpP6z3UpIQfO4eN
QRbgjhTqX5mfaabWcvQk/hLnUX6MpKiXwist+RiaiGrzj8XGSNFXuvETWsnoPoV687Exvzo1KYV4
jIuPmKXlRJvESTE/K2htJihPMS/o6fo3i+nHbTBRWpyrXSfmCPVEgsAzcyECvSU0Rz4MJsEXpdu6
6u/hg1hlPkb2gpkUQJv50YtWhkD/Jg0KZW5kc3RyZWFtDWVuZG9iag0zMjUgMCBvYmoNPDwvRmls
Check Mail>View>Message, does it say View Raw Source, Long Headers, or Default Headers?
See if view Plaintext version helps.

Email Prob - Content-Transfer-Encoding: base64

Using APEX to send an email to a CA product. We are doing this successful with another source (not Apex). The email that is sent opens a Help Desk ticket in the CA tool.
Another development tool has the this in the mime.822 file:
Content-Transfer-Encoding: 8 bit
The email send from APEX has Content-Transfer-Encoding: base64.
The look of the emails are different, this is why it is not working correctly when sent from APEX.
Does anyone know about base64 versus 8-bit?

Steve,
>> Yes, I am sure. This all being done inside our firewall and domain.
For an e-mail message to get from point A to point B, it must go through some message transfer agent somewhere, regardless whether it's all within the same firewall, domain, or otherwise.
>> Is there a work-around for this?
There can only be a workaround when the definitive problem has been identified. That has not been done.
I just sent myself a message from apex.oracle.com, which is running APEX 3.0.1. I examined the entire message source in Thunderbird. I found no occurrence of Content-Transfer-Encoding in my message whatsoever. Hence, I believe this is not APEX which is injecting this into your message.
My suggestion - take a look at what your SMTP server settings are for your APEX instance. Ensure that you are routing your e-mail to the SMTP server which works from the other "source" which is done successfully.
Joel

OSB - Content length http header missing from business service out message

Hi all,
I am having some diffuclty with a business service in OSB. I created the business service from the wsdl and created a regular proxy service that just routes to the business service. When i run the test console i get the below fault.
<faultcode>soapenv:Server</faultcode>
<faultstring>BEA-380000: Length Required</faultstring>
<detail>
After some debugging i find that the content length http header is missing from the outbound message the business process creates and sends to the acutal web service which sends back the http 411 fault.
Does anyone know how to configure the message flow of my proxy service to ensure that the outbound message sent from the business service contains that content length http header or any suggestions on how to fix this issue will be appreciated.
Thanks

Disable the "Use Chunked Streaming Mode" property in HTTP Transport Configuration of your business service. By default it remains enabled.
Regards,
Anuj

Apache Tomcat Transfer-Encoding Header Vulnerability

My most recent Nessus report gave the following risk warning. Apparently I need to upgrade my BO XI deployment to Tomcat 5.5.30 from 5.5.20. Has anyone else undertaken this effort? Can someone tell me what's involved? Thanks!
Synopsis:
The remote Apache tomcat service is vulnerable to an information disclosure or a denial of service attack.
Description:
The remote Apache Tomcat service is vulnerable to information disclosure or a denial of service attack due to a mishandling of invalid values for the 'Transfer-Encoding' HTTP header as sent by a client.
Risk factor:
Medium
CVSS Base Score:6.4
CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:P
See also:
http://tomcat.apache.org/security-5.html#Fixed_in_Apache_Tomcat_5.5.30
See also:
http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.28
Solution:
Upgrade to version 5.5.30 / 6.0.28 or greater.
Plugin output:
Nessus was able to verify this issue using the following request : GET / HTTP/1.1 Host: omiprm043 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, / Date: Wed, 25 Aug 2010 21:34:52 GMT User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0) Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1 Pragma: no-cache Transfer-Encoding: NESSUS Accept-Language: en Connection: Close
Plugin ID:
47749
CVE:
CVE-2010-2227
BID:
41544
Other references:
OSVDB:66319, Secunia:39574

Hi,
According to my experiences if you update tomcat where you can , BO XI platform might have problems. My suggestion is for you is to full backup system before anything you do, Also you can update BO XI where you can have a new version of tomcat embeeded.
Regards.

Accept-Encoding header missing

Hi,
we'd like to provide gzipped and packed200 jar of our application.Everything worked fine, we compressed our jar into .jar.gz and .pack.gz, achieved the usual checks.
They are all in the same directory.
But the problem is that our 1.5.0_04 jws never achieve a HTTP request with the Accept-Encoding header. So our application transfers the basic .jar file.
Is there a flag to set in our deployment file for the jws to ask the request with the header ?
Thanks in advance

Hi Andy,
I finally found that the problem was the symbolic jar URL into the JNLP descritption. It seems that the jar URL must end with ".jar"
I changed my servlet mapping from /myURL/jar to /myURL/some.jar and the 1.5 clients provided the accept-encoding header.
Thanks for your response by the way.

MIME header missing "filename=" results in BAD messages

I've been trying to track down several issues involving what appear to
be MIME handling issues. We are running GroupWise v7.01 (we have not
installed the "interim release" yet), and all components on the server
are at that release level (MTA, POA, GWIA, WebAccess).
One of the issues I am currently working on involves problems receiving
attachments from an outside sender. Their attachments are readable if
sent to an outside test account (i.e. - we've tested it with Yahoo
web-based mail, and a RoadRunner POP3 account using Outlook as the client).
The problem is that these e-mails either get dumped by the GWIA to the
GWPROB directory, or the e-mails go through, but the attachments are
corrupted (they do show up as attachments to the e-mail, but are
unreadable).
I haven't looked at why some e-mails go through and some don't, but I
did find out why the attachments are unreadable on the delivered
e-mails, and why the rest are just undeliverable. For whatever reason,
the sender's mail server (or AV gateway or whatever else had a chance to
touch the e-mail) is either not inserting, or is stripping out the
"filename=" from the MIME header just before the encoded attachment.
Adding this back into the message (by editing the original e-mail
w/header, and dropping the modified message into the GWIA "RECEIVE"
directory) fixes the attachment AND makes the e-mail deliverable.
Below I have an example of a bad e-mail which was originally sent to our
GWPROB directory, but was successfully delivered with a readable
attachment through a separate POP3 account (RoadRunner). Following this
"bad" e-mail example is the "fixed" version of that same e-mail, which
was delivered successfully to our user, with the attachment also being
readable.
*************** This is the original "BAD" e-mail ***************
MAIL From:<[email protected]> SIZE=73686
RCPT To:<[email protected]>
Received: from test.rr.com ([65.xx.xx.xx])
by smtp.ourhost.com with ESMTP; Wed, 21 Feb 2007 15:28:27 -0500
Received: from local.com (rrcs-24-xx-xx-xx.central.biz.rr.com [24.xx.xx.xx])
by test.rr.com (8.13.6/8.13.6) with ESMTP id l1LKSFTm009106
for <[email protected]>; Wed, 21 Feb 2007 15:28:24 -0500 (EST)
Message-Id: <[email protected]>
From: [email protected]
To: [email protected]
Date: Wed, 21 Feb 2007 15:25:54 -0500
MIME-Version: 1.0
X-Mailer: Telexis Gateway
Content-Type: multipart/mixed;
boundary="Mark=Num1_Lev1_2007221202554265_Tlx"
X-Virus-Scanned: Symantec AntiVirus Scan Engine
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: text/plain
Content-Transfer-Encoding: Quoted-Printable
This is a test
-Test Sender
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: application/vnd.ms-excel;
name="1st Q 2007 Income to Budget.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
"1st Q 2007 Income to Budget.xls"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAZgAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAGUAAAD/////////////////////////////////////////////
--Mark=Num1_Lev1_2007221202554265_Tlx--
************** END OF BAD E-MAIL **************
*************** This is the "fixed" e-mail ***************
MAIL From:<[email protected]> SIZE=73686
RCPT To:<[email protected]>
Received: from test.rr.com ([65.xx.xx.xx])
by smtp.ourhost.com with ESMTP; Wed, 21 Feb 2007 15:28:27 -0500
Received: from local.com (rrcs-24-xx-xx-xx.central.biz.rr.com [24.xx.xx.xx])
by test.rr.com (8.13.6/8.13.6) with ESMTP id l1LKSFTm009106
for <[email protected]>; Wed, 21 Feb 2007 15:28:24 -0500 (EST)
Message-Id: <[email protected]>
From: [email protected]
To: [email protected]
Date: Wed, 21 Feb 2007 15:25:54 -0500
MIME-Version: 1.0
X-Mailer: Telexis Gateway
Content-Type: multipart/mixed;
boundary="Mark=Num1_Lev1_2007221202554265_Tlx"
X-Virus-Scanned: Symantec AntiVirus Scan Engine
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: text/plain
Content-Transfer-Encoding: Quoted-Printable
This is a test
-Test Sender
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: application/vnd.ms-excel;
name="1st Q 2007 Income to Budget.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="1st Q 2007 Income to Budget.xls"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAZgAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAGUAAAD/////////////////////////////////////////////
--Mark=Num1_Lev1_2007221202554265_Tlx--
************** END OF "FIXED" E-MAIL **************
The only change I made, which both allowed the above e-mail to be
delivered and made the attachment readable, was the addition of the
"filename=" just before the file name on the line after the
"Content-Disposition: attachment;".
I did the same test with an e-mail that had the same "filename="
missing, but somehow was successfully delivered to our user (again, the
attachment was unreadable). Adding the "filename=" into the resent
message did make the attachment readable.
I haven't looked to see if the sender's system is actually non-compliant
for excluding the "filename=" (I will be doing that later this evening),
or whether this is a GWIA problem for not being able to handle this. I
just wanted to throw this out there to see if anyone else has seen this.
Does the "interim release" update by chance fix this?
Thanks,
Greg Niese

Does this email come in directly to GWIA (or do you have a relay host in
between)? I must say I've never experienced this problem on any of the GW
systems I administer. Could you tell us what domain this is coming from?
Ted Kumsher
>>> On 2/23/2007 at 8:21 AM, in message
<[email protected]>, Greg
Niese<[email protected]> wrote:
> I agree that this shouldn't be accepted as a valid "filename parameter"
> line. There are two ways to "not accept" this invalid parameter: "stop
> processing" the e-mail because of the problem (discard the e-mail), or
> discard the bad parameter and continue processing the rest of the e-mail
> (this could only work when the parameter is optional, as in this case).
> The GWIA seems to take the route of "stop processing", and then moving
>
> the resultant "bad" e-mail to the GWPROB directory.
>
> I say "seems" because in many cases where this occurs the e-mail doesn't
> get sent to the GWPROB directory, but instead still gets through the
> GWIA to the user. The attachments are corrupted, but still show up
> correctly in the attachment window, so everything seems OK with the
> e-mail & attachment - until you try to open the attachment.
>
> If there is a semi-colon after the "Content-disposition" type, the GWIA
> should see a valid disposition parameter following. But if it sees an
> invalid parameter, as in this case, what is the GWIA doing? It must
> either be discarding the invalid parameter, or "uses" it by either
> incorrectly parsing it as part of the header, or lumping it in as part
> of the attachment. If it "uses" in any way the invalid line of data -
> that sounds like the definition of "accepting" it, isn't it?
>
> To test whether the GWIA is actually using, and therefore "accepting",
> this bad parameter, I simply removed the malformed parameter (having the
>
> line in or out shouldn't matter if the GWIA's not using it), and I tried
>
> this both with the semi-colon removed from the end of the
> "content-disposition" type, and with that semi-colon left in place. In
> both cases the GWIA properly processed the e-mail and the attachment was
> readable! What does that mean? If the GWIA was truely NOT
> using/accepting that invalid header parameter (i.e. - the GWIA discards
> it), then the e-mail and attachment should go through OK. Since this
> isn't what happens when the bad line is left in place (the attachments
> DO NOT come through OK, but the e-mail often does get to the user's
> mailbox), then the GWIA must be accepting that bad parameter as either a
>
> part of the header, or a part of the attachment.
>
> I suspect that in those cases that these e-mails are sent to the problem
> directory, instead of being delivered with a corrupt attachment, the
> GWIA isn't really recognizing that the optional disposition parameter is
>
> "bad". The reason for the e-mail going to the problem directory is
> probably due to an error while trying to decode the attachment if the
> bad parameter is treated as part of the attachment, or if part of the
> attachment is being lumped in with the malformed parameter as it is
> parsed.
>
> I agree that how the GWIA should go about "not accepting" bad header
> parameters may be debatable (assuming that the GWIA were actually
> halting processing of the e-mail when this type of problem is found, and
> then sending the e-mail to the problem directory every time). But in
> cases such as this, since the parameter itself is optional, it would
> seem that the better route would be for the GWIA to discard the
> parameter and continue processing, instead of "discarding" the whole
> e-mail (to the problem directory). "Discarding the bad parameter" seems
> to be what is being done by at least a few other competing SMTP agents,
> since the other mail systems I tested with did get the e-mail through
> without corrupting the attachment.
>
> I may suggest that the sender's company fix whatever is going on at
> their server, but it probably won't do any good (I've already been told
> that they don't experience this problem with anyone else). In the
> meantime, my user (yes...he is the CEO), will have to continue to have
> some important e-mails sent to one of his personal accounts, because
> those e-mail systems receive these e-mails fine, but our GroupWise
> system can't.
>
> :-(
>
> -Greg
>
>
>
> Michael Bell wrote:
>> No it shouldn't, IMO.
>>
>> It's a matter of interpretation, of course. But GWIA is 100% right in
> not
>> accepting this as vaid (that part is beyond any debate - it's in the
> RFC).
>>
>> The only part that can be debated is "should GWIA then pass the buck"?.
> In
>> olden days, many would have said yes.
>>
>> But In general, no. Moving away from Postel's law, which was formulated
> in a
>> pre-malware age, is pretty much needed. Tight specifications and
> pickiness
>> is good. Collateral damage is unfortunate, and of course one needs to be
>
>> flexible if this is a widespread issue (which frankly, it is not in this
>
>> case), but otherwise it is up to to sender to fix their issue.
>>
>> 90% of viruses and malware in the last 6 years (and I'm well aware of
> them,
>> working in the email security field) are from MALFORMED e-mail, that the
>> gateway and client misinterpreted. Many of these were MS issues, but
> that's
>> another point. Point is you have to be STRICT.
>>
>> In this case this violates the generic MIME RFCs which state that if you
> do
>> have parameters, they all gotta be separated with semicolons (PASS), and
>
>> have to be name=value pairs (FAIL).
>>
>>
>> "Greg Niese" <[email protected]> wrote in message
>> news:[email protected]...
>>> Well, according to RFC 2183, the "filename=" string has to be present if
>
>>> the Filename parameter is going to be used. So the sending host seems
> to
>>> be "broken" in that regard.
>>>
>>> My next question then is: Should the GWIA ignore the "stray" file name
> in
>>> these e-mail headers, instead of allowing it to be lumped in with the
>>> attachment (I'm assuming that's why the attachment is trashed)? It
>>> appears that other systems are able to do this.
>>>
>>> -Greg
>>>
>>> Greg Niese wrote:
>>>> I haven't looked to see if the sender's system is actually
non-compliant
>>>> for excluding the "filename=" (I will be doing that later this
evening),
>
>>>> or whether this is a GWIA problem for not being able to handle this. I
>>>> just wanted to throw this out there to see if anyone else has seen
this.
>>>>
>>>> Does the "interim release" update by chance fix this?
>>>>
>>>> Thanks,
>>>>
>>>> Greg Niese
>>>>
>>
>>

TS3276 Content-Transfer-Encodong: quoted-printable?

Does anyone know why I'm receiveing emails that look like this? Is it a setting on my end or the sending emailer?
Thanks in advacne for your help.
--Apple-Mail-425-337390284
Content-Type: multipart/mixed;
boundary=Apple-Mail-426-337390286
--Apple-Mail-426-337390286
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Here are the adjustments from 3/4 through =
3/10.</div><div><br></div><div><font class="3D""Apple-style-span" =
size=3D"4"><b><u>I huge kudos to Los Gatos and San Jose for having spot =
on bike inventories! Great =
work!!!</u></b></font></div><div><br></div><br><div>
<span class="3D""Apple-style-span" style=3D"border-collapse: separate; =
color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><span class="3D""Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: 2; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class="3D""Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: 2; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><span class="3D""Apple-style-span" =
style=3D"font-size: 13px; =
"></span></span></div></span></span></div></body></html>

How exactly are you accessing the original attachment data? If you use getInputStream to read the original data store it, then the data is going to be decoded when you read it. When you attach it to the new message, that data is going to be re-encoded when the message is sent (or saved). JavaMail may not be encoding it in exactly the way the original sender did, although in most cases that shouldn't make a difference. Depending on the content of the PDF file, quoted-printable might not be the best choice for encoding.
You might be better off storing the encoded original data, using getRawInputStream, then using PreencodedMimeBodyPart when you construct the new message.

Transfer-Encoding is set depending on server

Hi everyone!
I have a serious problem concerning message encoding on different machines. On my development machine (running WinXP) I can send email messages perfectly with this code:
MimeMessagePreparator pwMessagePreparator = new MimeMessagePreparator() {
    public void prepare(MimeMessage mimeMessage) throws MessagingException {
    mimeMessage.setHeader("Content-Transfer-Encoding", "8bit");
    MimeMessageHelper message = new MimeMessageHelper(mimeMessage, false, "ISO-8859-1");
    message.setSubject("Engineering-Days - Neues Passwort");
    message.setTo(address);
    String messageText = "Hallo!\n\n" +
        "Dein Passwort wurde neu gesetzt. Es lautet jetzt: " + newPw + "\n" +
        "Logge Dich damit bitte auf der Homepage ein und �ndere unter \"Mein Konto\" das Passwort.\n\n" +
    try {
        message.setText(new String(messageText.getBytes("ISO-8859-1")));
    } catch (UnsupportedEncodingException ex) {
        logger.error(ex);
        try {
            mailSender.send(pwMessagePreparator);
        } catch (MailException e) {
            logger.warn("Senden der Mail f�r User " + address + " nicht erfolgreich: " + e.getMessage());
        }The text is German, never mind its meaning, what counts is that there are umlauts in it. The message is displayed correctly, the header is also correct:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bitI set mail.smtp.allow8bitmime to true.
As soon as I deploy the code on my production machine, the header looks like this:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bitNo matter what I do, it is always set to 7bit. Therefore, the umlauts are not transmitted correctly. I also tried lots of different things, including setting the charset to different values, using MimeUtility and so on. Nothing worked.
Any suggestions are highly appreciated.
Best regards,
Jan-Philipp Stegh�fer

I now set the Tomcat Locale to de_CH. This had no effect on the encoding. I also changed the code and removed the MimeMessageHelper. It now looks like this:
MimeMessagePreparator pwMessagePreparator = new MimeMessagePreparator() {
     public void prepare(MimeMessage mimeMessage) throws MessagingException {
          //mimeMessage.setHeader("Content-Transfer-Encoding", "8bit");
          mimeMessage.setSubject("Engineering-Days - Neues Passwort", "ISO-8859-1");
          mimeMessage.addRecipient(RecipientType.TO, new InternetAddress(address));
          mimeMessage.setFrom(new InternetAddress("[email protected]"));
          mimeMessage.setText("Hallo!\n\n" +
               "Dein Passwort wurde neu gesetzt. Es lautet jetzt: " + newPw + "\n" +
               "Logge Dich damit bitte auf der Homepage ein und �ndere unter \"Mein Konto\" das Passwort.\n\n" , "ISO-8859-1");
try {
     mailSender.send(pwMessagePreparator);
} catch (MailException e) {
     logger.warn("Senden der Mail f�r User " + address + " nicht erfolgreich: " + e.getMessage());
}The problem remains. Is it possible that the switch from a Windows to a Linux machine causes this effect?
On the other hand, most e-mails are encoded with "quoted-printable". In this encoding, the special signs are encoded as a sequence of characters starting with '='. Can I force JavaMail to use this transfer encoding?
Message was edited by:
Jan-Philipp.Steghoefer

Content-Transfer-Encoding Header missing?

Similar Messages

Maybe you are looking for