Ok, thanks all!

On 2/18/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Hi Steven,

Steven Azueta schrieb:
> Stefano, thanks for info (and the quick reply!).  I'm going to try the
> clone approach, but have 2 questions about that:
>
> First, how should I create a new unique name for the new MailImpl? I
> just looked at the MailImpl name on a matched message, it's something
> like "Mail1171821374389-11".  Are there rules for the format of a
> name, or it just needs to be unique?
It need just to be unique. But if i remember correctly a new unique name
will be generate automaticly on "cloning".


>
> Secondly, my mailet is operating on a Mail object that matched my
> matcher (of course) -- how should I replace the original Mail with the
> new cloned MailImpl?  If the orginal Mail (passed into the
> Mailet.service method) is a variable named mailOriginal, is it as
> simple as saying mailOriginal = clonedMailImpl after I've crafted the
> clone (and before the return of the service method)?

I think the correct whould be to do something like:

// Drop original mail
mail.setState(Mail.GHOST);

// Add the new mail to the top of the root container
getMailetContext().sendMail(newMail);

>
> Thanks again,
> Steve.
>
> On 2/18/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> Maybe the behaviour you experienced with James 2.2 was a bug.
>> I think what you want to do is to change the sender of the Mail object.
>> Either you cast the Mail to MailImpl to call setSender or *better* you
>> clone the message using new MailImpl(newName, newSender,
>> oldMailObject.getRecipients(), oldMailObject.getMessage()); (it is
>> highly recommended to create a new mailimpl (with a new name) when you
>> change the sender (reverse-path) of an envelope.
>>
>> As per RFC2821:
>> -  a gateway from elsewhere->SMTP SHOULD delete any return-path
>>     header present in the message, and either copy that information to
>>     the SMTP envelope or combine it with information present in the
>>     envelope of the other transport system to construct the reverse
>>     path argument to the MAIL command in the SMTP envelope.
>>
>> The remotedelivery can be considered a gateway from elsewhere->SMTP so
>> it is correct that it loose your custom return-path in favor of the
>> sender of the Mail object you are sending.
>>
>> Stefano
>>
>> Steven Azueta ha scritto:
>> > Greetings,
>> >
>> > With James-2.2/JavaMail-1.3, I was able to set the Return-Path header
>> > in my custom mailet and it would stick. (Using
>> > java.mail.internet.MimeMessage.setHeader("Return-Path",
>> > "[EMAIL PROTECTED]"), I would set it to a value that is different from
>> > Sender and From.)
>> >
>> > I've upgraded to James-2.3/JavaMail-1.4 and that no longer works.
>> > After setting the return-path like so...
>> >
>> > mimeMessage.setHeader(RFC2822Headers.RETURN_PATH,
>> > MimeUtility.encodeText(customAddressString));
>> >
>> > ...a header dump of the message clearly shows that it has been
>> > modified correctly.  However, when it gets sent, the return-path was
>> > set to whatever the Sender (or From?) address was.  I've tried
>> > MimeMessage.addHeader(), and that doesn't work either.
>> >
>> > Looking through the james-2.3 code I see several spots where there's
>> > custom treatment of the Return-Path header, and the james code mucks
>> > with it, but I haven't found exactly where it gets changed from my
>> > custom value to Sender.
>> >
>> > Has anyone found a way to force a setting of Return-Path in a custom
>> > mailet?  I don't see it listed as a bug, or listed as an intentionally
>> > change after james-2.2.  Any clues would be greatly appreciated.
>> >
>> > Thanks.
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]
>
> !EXCUBATOR:1,45d8974539411471918716!


--
Mit freundlichen Grüßen

i.A. Norman Maurer
Systemadministrator

ByteAction GmbH
Auf der Beune 83-85
64839 Münster

Phone:   +49 (0) 60 71 92 16 - 21
Fax:       +49 (0) 60 71 92 16 - 20
E-mail:    [EMAIL PROTECTED]
Internet: www.byteaction.de
AG Darmstadt, HRB 33271
Ust-Id: DE206997247
GF: Thomas Volkert
------------------------------------------------------
Diese E-Mail enthält vertrauliche Informationen und ist nur für den in der 
E-Mail genannten Adressaten bestimmt. Für den Fall, dass der Empfänger dieser 
E-Mail nicht der in der E-Mail benannte Adressat ist, weisen wir darauf hin, 
dass das Lesen, Kopieren, die Wiedergabe, Verbreitung, Vervielfältigung, 
Bekanntmachung, Veränderung, Verteilung und/oder Veröffentlichung der E-Mail 
strengstens untersagt ist. Bitte verständigen Sie den Absender dieser E-Mail 
unter folgender Rufnummer +49 (0) 6071 / 9216-0, falls Sie irrtümlich diese 
E-Mail erhalten haben und löschen Sie diese E-Mail. Der Inhalt dieser E-Mail 
ist nur rechtsverbindlich, wenn er von unserer Seite schriftlich durch Brief 
oder Telefax bestätigt wird. Die Versendung von E-Mails an uns hat keine 
fristwahrende Wirkung.

This e-mail contains information which is privileged and is intended only for 
the Addressee named in the e-mail. In case that the recipient of this e-mail is 
not the named addressee, we would like to inform you that it is strictly 
prohibited to read, to reproduce, to disseminate, to copy, to disclose, to 
modify, to distribute and/or to publish this e-mail. If you have received this 
e-mail in error, please call the sender under following telephone number +49 
(0) 6071 / 9216-0 and delete this e-mail. The content of this e-mail is not 
legally binding unless confirmed by letter or telefax. E-mails which are sent 
to us do not constitute compliance with any time limits or deadlines.
------------------------------------------------------



---------------------------------------------------------------------
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]

Reply via email to