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
