Hello Matt, Glad to hear that.
Tags are used to capture the history at a point in time. We use it for releases. They are like immutable branches, which we use to maintain different version of the project. To respond to your other question there is a 3.3.x branch for James on github. Hope it helped. On 2019-05-15 13:58, cryptearth wrote: > Hello Rémi, > > thanks for your reply. I quickly tested the current master branch and as far > as I can tell spooling works correctly again now. > > A quick related question: Why isn't there a 3.3.0 branch on github? All > that's listed is a tag. I don't know git very well, are branches and tags > somewhat equivalent? > > Matt > > Am 15.05.2019 um 10:22 schrieb Rémi KOWALSKI: Hi, > > The issue is fixed on the master branch and will be included in the 3.4 > release of James. > > Thanks a lot for reporting it ! > > For more information about it, you can have a look here : > > https://issues.apache.org/jira/browse/JAMES-2754 > > Cheers, > > On 2019-04-19 14:52, cryptearth wrote: > > Issue still persist on master-branch from 19.04.2019 11:44 UTC. Here some > logs: > > telnet smtp mail drop > > vm@vm:~> telnet localhost 25 > Trying ::1... > Connected to localhost. > Escape character is '^]'. > 220 vm JAMES SMTP Server Server (JAMES SMTP Server ) ready > EHLO localhost > 250-vm Hello localhost [0:0:0:0:0:0:0:1]) > 250-PIPELINING > 250-ENHANCEDSTATUSCODES > 250 8BITMIME > MAIL FROM:<h...@cryptearth.de> > 250 2.1.0 Sender <h...@cryptearth.de> OK > RCPT TO:<t...@cryptearth.de> > 250 2.1.5 Recipient <t...@cryptearth.de> OK > DATA > 354 Ok Send data ending with <CRLF>.<CRLF> > From: h...@cryptearth.de > To: t...@cryptearth.de > Subject: Test5 > > Test5 > . > 250 2.6.0 Message received > quit > 221 2.0.0 vm Service closing transmission channel > Connection closed by foreign host. > > ./james console > > jvm 1 | INFO 14:15:38,372 | > org.apache.james.protocols.netty.BasicChannelUpstreamHandler | Connection > established from 0:0:0:0:0:0:0:1 > jvm 1 | INFO 14:16:22,597 | org.apache.james.smtpserver.SendMailHandler | > Successfully spooled mail > Mail1555676182563-d3ad8bc4-9749-4196-97e7-d4d6c2bc7e04 from > MaybeSender{mailAddress=Optional[h...@cryptearth.de]} on > localhost/0:0:0:0:0:0:0:1 for [t...@cryptearth.de] > jvm 1 | INFO 14:16:26,294 | > org.apache.james.protocols.netty.BasicChannelUpstreamHandler | Connection > closed for 0:0:0:0:0:0:0:1 > > I also tested via IPv4 from vm-host - but also no spooling. Looking into > activemq dir I get this: > > file: ID_vm-36549-1555676098039-5_1_1_1_1 > cat ID_vm-36549-1555676098039-5_1_1_1_1 > Received: from localhost (EHLO localhost) ([0:0:0:0:0:0:0:1]) > by vm (JAMES SMTP Server ) with ESMTP ID 1872727156 > for <t...@cryptearth.de>; > Fri, 19 Apr 2019 14:16:08 +0200 (CEST) > From: h...@cryptearth.de > To: t...@cryptearth.de > Subject: Test5 > > Test5 > > So the SMTP obvious receives the mail - but it doesn't deliever it to the > inbox although it exists. As only the RecipientIsLocal matcher and the > LocalDelievery mailet are responsable for this - and the last change was back > in April 2018 - I guess something other went wrong ... > > Matt > > Am 19.04.2019 um 10:15 schrieb cryptearth: Hey Matthieau > > Well, it took me a bit, but here's how I found out somethings went wrong: > > I just cloned the mentioned branch, build it, set up the confings as I always > do (only disable pop3, replace localhost with my domain and set database > parameters), started it up, added a test-user via james-cli.sh and tried to > drop a test-mail via telnet. I expected the usual behaviour that when > connecting via IMAP I should see the mail I dropped via telnet in the inbox. > Well, but I didn't. The logs only shown the usual message "mail <id> spooled > for <address>" - but there was no mail in the inbox. So I dug through the > database - nothing. Then I looked through the directories and found the > dropped mail stuck in the <james-root>/var/store/activemq/blob-transfer/<some > index number>/ sub-folder. No matter how often I re-started james, the stuck > message didn't got spooled into the inbox. Also by dropping more incoming > mails they built up in the mentioned directory but never got further to the > user inbox. The logs didn't provide any help as they only show in the smtp > log that the dropped message got received but no exception nor stacktrace. I then cloned the mentioned older branch - did all the same - and it worked as expected. So I can only tell: There seems something worng in the master branch from April 3rd wich doesn't produce log output about the failure. Maybe it's a locked up thread so the queued mails didn't even got processed, maybe this thread is never created or started. Sorry I can't provide any more information. > > Matt > > Am 19.04.2019 um 09:59 schrieb Matthieu Baechler: Hi, > > Could you tell me a bit more about how you see that it fails ? > > Cheers, > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
