Hi Quan
Yes I agree it's the default date when messages are first added to the
sendQueue, but to my mind that should trigger immediate processing to
MailDelivrerToHost, whereas these messages were sat with that timestamp for
over 48 hours.
When messages are retried the next delivery date gets upda
Hi,
IMO, there is nothing harmful about the delivery date of 1969.
I guess you get it from the mail queue route. It was likely the result
of Unix epoch plus -1 millisecond (the -1 default delay, which means there
is no delay) cf
https://github.com/apache/james-project/blob/master/server/queue/qu
Hi all, a follow up on this.
After enabling debug on the remote delivery mailet I can see that a number
of messages are failing for various different reasons but the main reason
I'm seeing is "unable to find valid certification path to requested target".
2025-08-01 15:30:42.575 [DEBUG] o.a.j.t.m.r
Hi Quan, that webadmin feature doesn't seem to exist:
{"statusCode":404,"type":"notFound","message":"GET /metrics can not be
found","details":null}
As an aside after restarting James those messages with delivery date of
1969 were immediately picked up and sent, but looking through the logs it
see
Hi Matt,
Can you share the remote delivery timer metric?
*curl **localhost:8000/metrics*, then you can search for the
*RemoteDeliveryTrial* metrics.
Quan
On Mon, Aug 4, 2025 at 3:45 PM Matt Pryor
wrote:
> Thanks Quan.
>
> The delays I'm seeing are between initial spooling and the very first
>
Thanks Quan.
The delays I'm seeing are between initial spooling and the very first
delivery attempt.
Currently seeing a number of messages in the outgoing mailQueue with next
delivery of
1969-12-31T23:59:59.999Z
They do not seem to be progressing.
I've noticed that when a message is first queued
