Good morning Dmitry!

I got this issue atm.
I added an echo with rescan of just ~4000 msgs, and then got this error in the log regarding the bundle size cap. Do we have some limit setting somewhere or it is hardcoded?

That's the session log:

08:05:29 [1] connecting to 1celand1.duckdns.org:24554
08:05:29 [1] resolved 1celand1.duckdns.org: 62.220.162.88 (IPv4); auto: no IPv6 address, IPv4 only
08:05:29 [1] connected to 62.220.162.88:24554 (IPv4)
08:05:29 [1] connected
08:05:29 [1] send M_NUL SYS FidoMailMobile
08:05:29 [1] send M_NUL ZYZ Alexey Matrosov
08:05:29 [1] send M_NUL LOC Skellefteå, Sweden
08:05:29 [1] send M_NUL VER FidoMailMobile/0.1.6+87 (Android) binkp/1.1 08:05:29 [1] send M_NUL OPT NR ND
08:05:29 [1] send M_ADR 2:203/910.1@fidonet
08:05:33 [1] M_NUL OPT CRAM-MD5-0acbe3e6725535184251350846799ee1
08:05:33 [1] M_NUL SYS Rabarber North
08:05:33 [1] M_NUL ZYZ Alexey Matrosov
08:05:33 [1] M_NUL LOC Skelleftea, Sweden
08:05:33 [1] M_NUL NDL 300,300,CM,LO,IBN,INA:1celand1.duckdns.org
08:05:33 [1] M_NUL PHN -Unpublished-
08:05:33 [1] M_NUL TIME Wed, 16 Sep 2026 08:05:33 +0200
08:05:33 [1] M_NUL VER qico-0.60.0-dev/Linux binkp/1.1
08:05:33 [1] remote is 2:203/910@fidonet (SYS Rabarber North, qico-0.60.0-dev/Linux binkp/1.1)
08:05:33 [1] send M_PWD ***
08:05:33 [1] M_NUL OPT MB CHAT NDA
08:05:33 [1] ignoring unsupported OPT MB
08:05:33 [1] ignoring unsupported OPT CHAT
08:05:33 [1] remote supports asymmetric ND
08:05:33 [1] M_NUL TRF 737 14717958
08:05:33 [1] authenticated (cramMd5) as 2:203/910.1@fidonet
08:05:33 [1] binkd ND: send off, receive off (remote: NDA, binkp/1.1)
08:05:33 [1] send M_FILE 6aaa31a8.we0 355 0 0
08:05:33 [1] offered 6aaa31a8.we0 (355 bytes)
08:05:33 [1] send M_EOB
08:05:33 [1] send M_GET 6aaa31ad.pkt 737 1789545894 0
08:05:33 [1] 6aaa31ad.pkt offered NR - requesting from 0
08:05:33 [1] delivered 6aaa31a8.we0
08:05:33 [1] remote M_GOT 6aaa31a8.we0 - delivered
08:05:34 [1] sender repositioned 6aaa31ad.pkt to 0
08:05:34 [1] send M_GOT 6aaa31ad.pkt 737 1789545894
08:05:34 [1] received and acked 6aaa31ad.pkt
08:05:34 [1] send M_GET 95d54ef2.we0 14717958 1789545893 0
08:05:34 [1] 95d54ef2.we0 offered NR - requesting from 0
08:05:34 [1] sender repositioned 95d54ef2.we0 to 0
08:06:03 [1] send M_GOT 95d54ef2.we0 14717958 1789545893
08:06:03 [1] received and acked 95d54ef2.we0
08:06:03 [1] batch carried 12 commands and remote is binkp/1.1 - restarting for a possible same-session reply
08:06:03 [1] send M_EOB
08:06:03 [1] session up: auth=cramMd5, trusted for echo
08:06:04 [1] error: unreadable zip bundle 95d54ef2.we0: decompressed size exceeds the 33554432-byte cap - quarantined
08:06:04 [1] sync complete - 1 received, 1 warning(s)

Mvh,
Alex.

--- FidoMailMobile/0.1.6+87 (Android)
* Origin: Rabarber > Skellefteå > Sweden (2:203/910.1)

Hello Alexey!

In a message of 16 Sep 26 08:27, Alexey wrote to Dmitry:

I got this issue atm.
I added an echo with rescan of just ~4000 msgs, and then got this
error in the log regarding the bundle size cap. Do we have some
limit setting somewhere or it is hardcoded?

That's the session log:

Thanks for detailed report!

It's a problem with old code - it has built-in zip-bomb protection, but based on some questionable design decisions. But I just can't allow the software to consume as much memory as it wants.

The limits are now raised and I unpack zip files incrementally instead, extracting file by file.

Will be in next release (this evening).

See you,
dp.
--- FidoMail v0.1.4-99-g2f594a4
* Origin: livin' on the edge (2:5001/100)

Hello, Dmitry!

Dmitry Protasoff wrote:

It's a problem with old code - it has built-in zip-bomb protection,
but based on some questionable design decisions. But I just can't
allow the software to consume as much memory as it wants.

The limits are now raised and I unpack zip files incrementally
instead, extracting file by file.

Will be in next release (this evening).

Yeah, I was suspecting a kind of filebomb protection thing and looking for a setting related to that haha ;)

Mvh,
Alex.

--- FidoMailMobile/0.1.6+87 (Android)
* Origin: Rabarber > Skellefteå > Sweden (2:203/910.1)

Hello Alexey!

In a message of 16 Sep 26 15:52, Alexey wrote to Dmitry:

Yeah, I was suspecting a kind of filebomb protection thing and
looking for a setting related to that haha ;)

Yeah, some very friendly person was sending me zip-bombs regularly to 2:5001/100 from TOR/proxy ip addresses and this protection was built into my binkp/tosser code from the 1st day :)


See you,
dp.
--- FidoMail v0.1.4-99-g2f594a4
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry,

Wednesday September 16 2026 14:22, you wrote to me:

In a message of 16 Sep 26 15:52, Alexey wrote to Dmitry:

Yeah, I was suspecting a kind of filebomb protection thing and
looking for a setting related to that haha ;)

Yeah, some very friendly person was sending me zip-bombs regularly to 2:5001/100 from TOR/proxy ip addresses and this protection was built
into my binkp/tosser code from the 1st day :)

Yeah, that maybe still a good idea to implement optional smart and simple logic checking the total uncompressed size and/or compress ratio in advance before the actual unzipping..

Do you simply use something like: zipinfo -t archivename ?

Mvh,
Alex.

---
* Origin: Rabarber > Skelleftea > Sweden (2:203/910)