Hey Joe (I guess?),
thanks for participating. I'm currently setting up a fresh VM and try to
do some testing myself - but it could very well be an overall issue that
james-3.4 is broken in a way it doesn't store any incoming mails at all,
no matter of the type of storage.
Matt
Am 05.03.2020 um 10:25 schrieb joe:
Sorry for injecting myself to this thread, but I have the same
issue going on. There is NO mail physically stored in ANY directory.
Switching over to a DB config, same, nothing ever gets into the DB.
There are no stack traces that come out during an elevated debug.
On Thu, 2020-03-05 at 10:13 +0100, cryptearth wrote:
Hi David,
well - does the mail show up in the maildir directory? So, is it
actually physically stored? It's possible that it's just not saved
and
hence never "delivered". Also, as mentioned, have a look into the
<james>/var/mail/ directories if it get's somewhere sorted out for
some
error.
I also ever tried James with using a MySQL/MariaDB database, never
the
local derby or maildir.
Matt
Am 05.03.2020 um 10:08 schrieb [email protected]:
Hi Matt
starting of james 3.4 so I wasn't aware of this screw up. So,
according
to the current master branch the prefered way is to just comment
it out.
Neither doing that nor changing the tag to <priority> fixes the
problem I see though. As already said, everything looks fine - I
can log in and my webmail client behaves as expected, including
interacting with the SMTP side of things.
To rule out any oddness from my webmail client (which there should
not be), I can test by telnet to port 25. James says
250 2.6.0 Message received
and just as when sending from webmail, the message is spooled
according to the logs, but never delivered; no errors or warnings
in the logs, so no clue where to look next. If something in the
smtpserver config needs a tweak it's not obvious what that is and
much of the docs seem to be inapplicable to this version of james.
The one thing that occurs is that maybe maildir storage has not
been well tested; I'll revert the configs to use the default Derby
database and if I see anything better with that, I'll post an
update.
--
David Matthews
[email protected]
-----------------------------------------------------------------
----
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]
---------------------------------------------------------------------
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]
