I made it..
Her is the email bofore run in the remotedelivery mailet:
Return-Path: null
Received: from smtp04.bwc.eu.blackberry.com ([216.9.241.84])
by james.xxx.de (JAMES SMTP Server 2.3-dev) with SMTP ID 130
for <[EMAIL PROTECTED]>;
Wed, 22 Feb 2006 08:25:39 +0100 (CET)
Received: from engine24.bwc.produk.on.blackberry
(engine24.bwc.produk.on.blackberry [172.16.211.216])
by smtp04.bwc.eu.blackberry.com (8.13.1/8.13.1) with SMTP id
k1LC8UX2013974
for [EMAIL PROTECTED]; Wed, 22 Feb 2006 07:25:38 GMT
Message-ID:
<[EMAIL PROTECTED]>
Content-Transfer-Encoding: base64
Sensitivity: Normal
Importance: Normal
To: [EMAIL PROTECTED]
Subject: hallo norman
From: "Katja Eyrich - BlackBerry" <[EMAIL PROTECTED]>
Date: Wed, 22 Feb 2006 07:25:49 +0000 GMT
Content-Type: text/plain; charset="Windows-1252"
MIME-Version: 1.0
dGFjaCBhdWNoDQogDQo9PT0NCmkuQS4gS2F0amEgRXlyaWNoDQpLZXkgQWNjb3VudCBNYW5hZ2Vy
aW4NCiANCkJ5dGVBY3Rpb24gR21iSA0KVGhlIEludGVybmV0IFNvbHV0aW9ucyBDb21wYW55DQpB
dWYgZGVyIEJldW5lIDgzLTg1IJUgRC02NDgzOSBN/G5zdGVyDQogDQp0ICs0OSAoMCkgNjAgNzEg
LSA5MiAxNiAtIDMzDQpmICs0OSAoMCkgNjAgNzEgLSA5MiAxNiAtIDIwDQpoKzQ5ICgwKSAgMSA2
MyAtIDI5IDgzIDAwNA0KQmxhY2tCZXJyeSArNDkgKDApIDE3OCAtIDY2ODQgODUwIGYgKzQ5ICgw
KSAxNzggLSA2Njg5IDg5Mg0KIA0KRS1NYWlsOiBrZUBieXRlYWN0aW9uLmRlDQpJbnRlcm5ldDog
d3d3LmJ5dGVhY3Rpb24uZGUNCj09PQ0KDQo=
Thx for all the help :-)
Am Dienstag, den 21.02.2006, 17:55 +0100 schrieb Stefano Bagnara:
> Anne S wrote:
> > I'm afraid my German is a bit rusty, but this is probably your original
> > message. If you want a Quick Fix, just run Blackberry sent emails through a
> > base64 decoder (you can see one here:
> > http://makcoder.sourceforge.net/demo/base64.php)
> >
> > A long term fix would involve a bit of work. The problem could be RIM's, so
> > you'll have to contact the company and send a bug report, or you could write
> > a mailet to automatically do the conversion.
> >
> > Could you send more information about your situation?
>
> This could be related to the 8bitmime patch I applied a few months ago.
> When we told javamail to support 8bitmime it do change the header
> transfer-encoding to "8bit" when it find 8bit chars in the body.
> This should not happen if the body is handled correctly... Maybe Norman
> is adding 8bit chars to the 7bit (base64) body and javamail
> automatically add the 8bit trasfer encoding (altering the original
> base64) because it should not find 8bit chars.
>
> Norman, can you run a test with a similar message and store the message
> somewhere (ToRepository with a filerepository is a good choice) before
> it runs in the James RemoteDelivery so we can check the actual
> body/headers? (Just add a ToRepository mailet configured with
> passThrough=>true before the RemoteDelivery mailet).
>
> We need to know the exact content of the body before it is passed to the
> remotedelivery: I want to know wether there are ASCII chars with a code
> greater than 127 (they are not allowed in 7bit mime, but if they are
> there then you should look for an early problem)
>
> Stefano
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]