A quick follow up to state that https://github.com/linagora/james-project/pull/4110 implemented that ;-)
Cheers, Benoit Le 03/12/2020 à 09:08, btell...@linagora.com (OpenPaaS) a écrit : > Nice to see we are on the same wave length! > > Regarding the upgrade path, I'm in favor of requiring an empty mailQueue. > > Rationals: if there is any sort of retro-compatibility, then an attacker > controlling ie the JMS solution would still be able to control the > deserialized payload (and trigger all sort of not funny stuff!) > > To achieve that, downtime on the SMTP service + MailQueue flush. > > Would it be resonable to people around here? > > Cheers, > > Benoit > > Le 03/12/2020 à 14:58, Matthieu Baechler a écrit : >> Hi Benoit, >> >> On Thu, 2020-12-03 at 11:54 +0700, Benoit Tellier wrote: >>> While working on https://issues.apache.org/jira/browse/JAMES-3431 I >>> discovered that JMS & File mailqueue do still rely on serialization. >>> >>> This is what motivates to re-open this ticket: >>> https://issues.apache.org/jira/browse/JAMES-2578 >>> >>> Please kindly note that all of the MailRepository implementation no >>> longer uses Java serialization. >>> >>> Our AttributeValue adoption is partial; I would like to finish the >>> job. >>> >>> Here are the options we have: >>> >>> Accept DSN feature do not work on tese implementations (not my >>> prefered at all!) >>> Re-implement DSNParameters attribute mapping to not use >>> collection >>> attributeValues. This work around the main issue for this specific >>> use >>> case of attribute values. (I feel okay with that) >>> Try to fix collection attributeValue java serialization is likely >>> hard to do, but also keeps java serialization around for longer in >>> the >>> code base. Likely a dead-end. >>> No longer rely on Java serialization for "JMS" & "File" mail >>> queues. >>> This means either smart fallback code, or at worst an upgrade path >>> with >>> an empty mail queue. That is by far my preferred option, and I will >>> start community discussions in that direction. >>> >>> Do we got consensus around this topic? >> >> This Java serialization compat has been crippling our developpements >> for too long. I'm in favor of complete removal and a migration >> strategy. >> >> Cheers, >> >> -- Matthieu >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org >> For additional commands, e-mail: server-dev-h...@james.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
