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]

Reply via email to