Re: Excessive APPENDLIMIT response [Re: Android after Cyrus upgrade]

Ken Murchison <murch@xxxxxxxxxxxx> · Wed, 10 May 2023 09:48:29 -0400

APPENDLIMIT is controlled by maxmessagesize in
      imapd.conf

On 5/10/23 9:10 AM, Nic Bernstein
      wrote:

      Edda,

      Great catch!  Indeed, the APPENDLIMIT extension, defined in
      RFC7889*, was added to Cyrus in 2021:
commit 40793dfde8c96797d86f80e9f461bea61bca3bc9

        Author: Ken Murchison <murch@xxxxxxxxxxxx>

        Date:   Sat Jan 30 09:10:00 2021 -0500

            imapd.c: Advertise APPENDLIMIT= capability

      As noted, this is defined in imap/imapc:
{ "APPENDLIMIT=",          CAPA_POSTAUTH|CAPA_VALUE,         /* RFC 7889 */
      { .value = { "%2$" PRIi64, .i64p = &maxsize } }         },

      So the question becomes, is this a bug in Cyrus or in FairEmail? 
      Given that FairEmail is the only application complaining about it,
      I'd suggest they're the buggy ones.  But I could be wrong.

It's worth noting that there's appears to be no
      configuration option [i.e. imapd.conf(5)] for appendlimit (looked
      for *limit, *maxsize, etc.).  Is this a bug?  The number
      advertised, 18446744071562067968, is the C compiler's maximum
      object size.  This seems awfully large for most mail systems, and
      doesn't serve any legitimate purpose as it currently sits.

      Cheers,

          -nic

      *https://www.rfc-editor.org/rfc/rfc7889

On 5/10/23 07:20, Edda wrote:
Hello Vladas,

FairEmail is complaining about a
            "too long" Long. It's in the source code of FairEmail in
            ./app/src/main/java//eu/faircode/email/EmailService.java at:

    Long
              getMaxSize() throws MessagingException {

                      // https://support.google.com/mail/answer/6584#limit

                      String size;

                      if (iservice instanceof SMTPTransport) {

                          // https://tools.ietf.org/html/rfc1870

                          size =
              getTransport().getExtensionParameter("SIZE");

                      } else if (iservice instanceof IMAPStore) {

                          // https://tools.ietf.org/html/rfc7889

                          size = ((IMAPStore)
              iservice).getCapability("APPENDLIMIT");

                      } else

                          return null;

                      if (!TextUtils.isEmpty(size) &&
              TextUtils.isDigitsOnly(size)) {
            long s = Long.parseLong(size);

                          if (s != 0) // Not infinite

                              return s;

                      }

                      return null;

                  }

String "size" is indeed too long
            for a Long: "18446744071562067968"

Since it's an IMAP Service,
            APPENDLIMIT seems to be the problem.

I just checked at your server:

. CAPABILITY

            * CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL
            ANNOTATE-EXPERIMENT-1 BINARY CATENATE CHILDREN CONDSTORE
            CREATE-SPECIAL-USE ESEARCH ESORT LIST-EXTENDED LIST-MYRIGHTS
            LIST-STATUS MAILBOX-REFERRALS METADATA MOVE MULTIAPPEND
            NAMESPACE OBJECTID PREVIEW QRESYNC QUOTA RIGHTS=kxten
            SAVEDATE SEARCH=FUZZY SORT SORT=DISPLAY SPECIAL-USE
            STATUS=SIZE THREAD=ORDEREDSUBJECT THREAD=REFERENCES UIDPLUS
            UNSELECT URLAUTH URLAUTH=BINARY WITHIN DIGEST=SHA1
            LIST-METADATA NO_ATOMIC_RENAME SCAN SORT=MODSEQ SORT=UID
            THREAD=REFS X-CREATEDMODSEQ X-REPLICATION X-SIEVE-MAILBOX
            XLIST XMOVE AUTH=SCRAM-SHA-512-PLUS AUTH=SCRAM-SHA-512
            AUTH=SCRAM-SHA-384-PLUS AUTH=SCRAM-SHA-384
            AUTH=SCRAM-SHA-256-PLUS AUTH=SCRAM-SHA-256
            AUTH=SCRAM-SHA-224-PLUS AUTH=SCRAM-SHA-224
            AUTH=SCRAM-SHA-1-PLUS AUTH=SCRAM-SHA-1 AUTH=GSS-SPNEGO
            AUTH=GSSAPI AUTH=DIGEST-MD5 AUTH=OTP AUTH=NTLM AUTH=CRAM-MD5
            AUTH=LOGIN AUTH=PLAIN SASL-IR XCONVERSATIONS
            COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE
            X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE APPENDLIMIT=18446744071562067968

APPENDLIMIT is advertised prior
            to login. Therefore it doesn't show up in the telemetry logs
            I think.

I don't have cyrus 3.6.1 anywhere
            yet, but I think you should look at maxmessagesize in
            imapd.conf

Best regards,
Edda

Am 09.05.23 um 14:20 schrieb vladas
          via Info:
I have read the man pages, release and upgrade notes again,  checked
            cyrus.conf and imapd.conf settings, restarted Cyrus imapd
            and saslauthd daemons, verified configuration and spool
            files — and still found no cause.

Then I completely removed my account and all assets from
            FairEmail on my Android Motorola phone, Asus pad, and then
            set them again manually, step by step, with different
            connection modes (SSL/TLS :933, STARTTLS :143, insecure) —
            all of them are accepted, but the sync soon gets stuck and a
            warning message is issued with always the same error code:

For input string: "1844674407152067968"

FairEmail is the best MUA I have ever seen: lean, secure,
            fast, with a clear and convenient user interface — despite
            of being full-featured and standards-compliant, with hundred
            of preconfigured settings of commercial providers, and with
            detailed logs:

My mail is hosted on sala.online.lt [217.147.40.110] and
            serves, among others, the on.lt domain. Faircode.eu is a
            domain of the developer. This log is laid out here from
            bottom to the top. Sorry, I am not a programmer and do not
            understand this log. I guess there is a tiny software bug,
            that only emerged after the upgrade.

-- 
Nic Bernstein                               nic@xxxxxxxxxxxxxxxx
https://www.nicbernstein.com
-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

Cyrus
  / Info / see
discussions
  +
participants
  +
delivery options
Permalink