Hello Jerry,
About success, a log is already written in MailDelivrerToHost:
Mail (xyz) sent successfully to a...@other.tld at other.tld from us.tld
for m...@us.tld
More generally, the extension model of James is well design, and from
what you expose there is zero requirement to alter the
If you are using commons-net, I succeeded to write:
https://gist.github.com/chibenwa/abd12fd6c0b06cadd1de591e3ac792b9
That should be helping you!
On 13/09/2019 10:40, Tellier Benoit wrote:
> Wich library are you using?
>
> On 13/09/2019 10:33, Jerry Malcolm wrote:
>> Thanks for the info,
I believe I'm just using the basic javax.mail.* that comes with JDK
1.8. Do I need to move to a later imap implementation package?
On 9/12/2019 10:40 PM, Tellier Benoit wrote:
Wich library are you using?
On 13/09/2019 10:33, Jerry Malcolm wrote:
Thanks for the info, Tellier. I kinda lost
Another mod I had made to v3b5 was to intercept the final result of
success/fail of delivery. I have a requirement to externally log the
"mail was successfully transferred to "
message and also after all of the retries are exhausted, the final
'fail' message.
Back in v3b5 I cloned the
Wich library are you using?
On 13/09/2019 10:33, Jerry Malcolm wrote:
> Thanks for the info, Tellier. I kinda lost you on the mpt tests... I
> was looking for how to change the following code to include an
> administrator id. I only have one field in the store.connect() method
> for a user id,
Thanks for the info, Tellier. I kinda lost you on the mpt tests... I
was looking for how to change the following code to include an
administrator id. I only have one field in the store.connect() method
for a user id, but I have an administrator id and the userid for the
target mailbox. How
Hello Jerry,
With the `administratorId`, you are able to use IMAP impersonation.
IE to log in as another user.
You should define it within usersrepository.xml. To see related "reading
config" code: AbstractUsersRepository is the way to go.
Agree that this needs example and documentation. I
Quick question... does 3.3.0 do any upward migration of an existing
database that burns bridges for accessing it by 3.0.beta5? In other
words, if I start up 3.3.0 using my existing database and I find
problems, can I successfully revert back to using beta5? Or does 3.3.0
do irreversible
Since it appears I'm not going to be able to build James 3.3.0 in the
foreseeable future, I'm now moving to plan d, e, f, or whatever... .I've
lost count.
My goal now is to assess my possibilities of using James 3.3.0 binaries
as-is and discarding the functionality I had hoped to re-add to
