Hi Andreas, Thank for your reply.
I can bump up the limit for the next release and also (maybe) make it configurable. We definitely want to keep a limit though. In the meantime, if you make the change locally with a local build, what is the longest string you see IRL? Gary On Sat, Jul 20, 2024, 12:21 PM Andreas Lemke < i...@systementwicklung-lemke.de> wrote: > Hello, > > I have found a possible issue is the IMAPReply class of > org.apache.commons.net.imap. > Starting from Version 3.11.0 the length of the TAGGED_RESPONSE pattern was > limited to 80 chars. In conjunction with m.matches() request at line 107 > of > the class, this leads to a MalformedServerReplyException, if the server > reply exceeds 80 chars. This is because the matches() method returns "true > if, and only if, the entire region sequence matches this matcher's > pattern" > (from JDK API documentation). > I found this issus using OpenJDK 21.0.4. > Maybe it is an option to use lookingAt() instead of matches() because it > does not require the match of the entire region. > > In my case the IMAP server answered to a LOGIN with the following line, > longer than 80 chars: > > AAAA OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT > SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT > MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS > LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN > CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY PREVIEW > STATUS=SIZE SAVEDATE XLIST LITERAL+ NOTIFY SPECIAL-USE] Logged in > > Kind regards, > > Andreas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
