If you want to see all messages you can just search for a starting date of 2022
why did that not work when I last tried?
this should work for what I need; I just need an API I can call from another app to check if a message was delivered
A set period. Not entirely sure but from the top of my head it's 30 days
Not sure! I know the log entries are stored in mongodb, so they probably have a date there
And then they're periodically purged
so I'm gunna guess..... =]
Yeah that seems logical haha
(the one I'm looking at was added yesterday and has a date of Mar 3)
so it'd be easy to change the index if you wanted to make them last longer
the app most likely doesn't recreate it if it exists, only adds it if it is missing
I may not know a lot about email or be great at most front-end frameworks, but if you need help with typescript, node.js, or mongodb let me know :-P
I mostly am as well, but this is just not a trade I've needed before =] and the frontend libraries I can figure out, but it took me almost two hours to understand the wildduck-ui react project well enough to figure out the issue was caused by a stupid typo =] just lack of experience with that particular thing. I tend to focus on integration between systems, backends, databases, etc, but since I run some full stack projects I can work anywhere... it's just a question of where I'm most likely to be helpful
but it took me almost two hours to understand
tbh that's better than most haha
About that acme config issue. Well, yeah, that was an accident. The current config system merges production config with the default so the assumption is that if a default is set, then it always exists. Turned out to be not 100% correct. The config system needs an overhaul anyway as it does not support environment variables. Everybody doing docker is complaining all the time that they can't pass container-specific config easily and if they use command-line arguments then secrets are visible in the process listing.
7 replies
Regarding tracking message delivery info. The identifier to look for is not message_id, but queue_id. Message-id is not known in each delivery step. Unfortunately, this means multi-step log digging (first search by message_id, which gives you queue_id to see the entire processing flow).
the screenshot is from the following search:
queue_id:17ebea748c9000fd13
this is the "happy path" result. first there is a SMTP session in the MSA server that queues the message. and then MTA succeeds to deliver the message on the first attempt. If there would be any issues, or here would me more recipients than 1, then there would be more log lines
also thanks =]
I did finally find that I needed to use the queue id -- while I was in the process of looking to see if I could add message id to every event =]
For duckyapi I just put json into a env var
For a more complicated setting
One config I came across recently while implementing oauth for my employer is this:
https://www.ory.sh/hydra/docs/reference/configuration/
https://www.ory.sh/hydra/docs/reference/configuration/
They have nested variables in a yaml file, but each can be set as an env var as well
NB! Gitter has become quite unstable lately, so I'm testing Discord as an alternative. I already have a room for EmailEngine there and it has worked well. (I know there's also Matrix and whatnot but Discord is something I've already been using for other stuff and I have no issues with it).
Link to join: https://wildduck.email/discord