Menu
▾
▴
#29 Shrink size
Is it possible to significantly shrink size?
The OpenWrt's package contains the following binaries:
393285 /usr/bin/emailrelay*
24613 /usr/bin/emailrelay-filter-copy*
65573 /usr/bin/emailrelay-passwd*
73765 /usr/bin/emailrelay-submit*
384kb is a lot. For a compression the uHTTPd web server is 46kb. So I started thinking how to shrink it. And which functions can be disabled from compilation.
If I understood correctly all extended authorizations like SCRAM or APOP. If we have a TLS then they not needed.
I still don't get what is SASL and if it's really useful but anyway on my router it will be never used.
Can you make conditions to disable them with --configure?
The passwd utility is simple not needed because I going to use plain passwords. Even in md5 it's easy to decode them with rainbow table.
The submit command is sendmail like but more looks like makemime from Courier
https://www.systutorials.com/docs/linux/man/1-makemime/
BusyBox also has it https://git.busybox.net/busybox/tree/mailutils/makemime.c
Probably it's cool for scripting or automation but for a usual proxy/server usage it's not needed.
The filter-copy is also looks like something that only few may need.
Please tell me if my assumptions are correct. If yes then I'll ask OpenWrt maintainer to move this utilities to a separate package like emailrelay-tools
The ~400k does seem a bit heavy. Does it use static linking of the c++ runtime? Have the symbol tables been properly stripped? Is it compiled with -Os?
Supporting only PLAIN authentication is an interesting idea, but POP requires APOP which is a very similar to CRAM-MD5 so the savings might be quite modest. There is almost no cost from supporting CRAM-SHA1 etc in addition to CRAM-MD5 because the hashing functions are provided by the TLS library.
(SASL is just a conceptual framework for defining authentication mechanisms. as per RFC-4422.)
Storing password hashes for CRAM-XXX authentication was a good idea in the 1990s, but it never really caught on. As you imply, its advantages are pretty weak nowadays.
The submit utility is useful as a replacement for /usr/sbin/sendmail so that emails generated by cron (for example) can get forwarded by emailrelay. It is a compiled binary rather than a script so that it can be made group suid (-rwxr-s---) with the same group ownership as the spool directory. That allows any user to submit messages into the spool directory without having any access to the spooled files. On OpewWrt I can imagine other submission mechanisms would be just as good.
The filter-copy utility is to support email forwarding to multiple destinations, ie. a "fan-out" topology, and that includes the 'pop-by-name' use case. It is written as a compiled binary just because it makes things easier on windows. On unix-y systems a script would work just as well.
So yes, a separate tools package would be perfectly reasonable.
Thanks,
Here is a makfile from OpenWrt
https://github.com/openwrt/packages/blob/master/mail/emailrelay/Makefile
On Sun, 2 Oct 2022 at 01:54, Graeme Walker
graeme_walker@users.sourceforge.net wrote:
--
Sergey Ponomarev,
stokito.com
Related
Feature Requests:
#29Last edit: Sergey Ponomarev 2023-08-31
Actually, ~400k is not that bad. My mental processes were out by an order of magnitude.
I have recently done some code-size optimisations in preparation for the 2.4 release and as part of that I reviewed the build-time options in the configure script ("--without-pam", "--disable-interface-names" etc). The only reasonable change I could see was to add "--disable-dnsbl" to exclude the DNSBL functionality and save on the associated DNS protocol code. FWIW that saves about 16k out of 880k on linux x64.
Looking again, perhaps "--disable-admin" would be do-able. That saves ~20k on linux x64.
I guess that some optimizations are missing because even the 400 lines submit takes 73,765 bytes. But it has a lot of includes from the ER i.e. contains the same code. Maybe with some compiler option we can remove code for unused functions. Or make this program internal for the ER like BusyBox applets.
The admin is maybe something that can be disabled for OpenWrt. Not sure how often the feature is used. As far I understood the main feature is to trigger forward. Maybe this can be done by SIGHUP i.e. service reload. The OpenWrt doesn't have the telnet by default so you can't trigger the forward from the router itself. Maybe the admin API can be exposed as JSON-RPC then users may use curl/wget and even make some UI with Ajax. But this is not related to the issue.
The DNSBL is probably not needed for those who just forwards email from localnet. But for the OpenWrt package used for a self hosting this may be the most effective anti spam and anti bot protection. Maybe we can preconfigure it by default to something like https://www.spamhaus.org/
So to summarize the only feature that can be disabled is the obsolete CRAM and APOP but this anyway shouldn't give much space.
Ok, thank you for the clarification. I think the issue can be closed.
Maybe warranty and license strings can be stripped but this again won't save that much space.
BTW you can use writev and sendfile syscalls to optimize speed
So the OpenWRT makefile you linked to doesn't change the compiler optimisation level, but I think the default compiler flags for whole system must surely include code-size optimisations.
I note that it also seems to take the binaries from the src/main directory rather than doing 'make install'. Using the binaries from src/main means that the debug symbol tables have not been stripped, but again I expect the OpenWRT build system will do the right thing and to the 'strip' itself.
FYI in the 2.4 release I have made it easier to do a 'unity' build. It has always been possible to build emailrelay in this way but now you can just do "make -C unity programs". A unity build makes it easier for the compiler to do optimisations, so on linux x64 it reduces the -Os program file size by ~25k out of ~850k. I doubt OpenWRT would want to use a unity build because it stresses the build box.
Using a busybox approach for the submit utility is an interesting idea. I might try that out.
Using a signal to trigger forwarding is a nice idea too, but I avoid using signals in emailrelay. They are quite difficult to use safely and portably. In early unix systems signals were used primarily to terminate programs, so they can be a bit of a blunderbuss. A datagram unix-domain socket might be a better approach (perhaps "--forward-on-datagram=/run/forward.s"). I think busybox netcat (nc) can send unix-domain datagrams.
Unfortunately SMTP does not lend itself to sendfile because the protocol is line-based with dot escaping, so what goes over the wire is different from what is in the content file - and it's not very portable. It might be worth reconsidering if there is an emailrelay release that implements the BDAT/CHUNKING SMTP extension.
The 'unity' build looks impressive! Definitely OpenWrt maintainer should try it.
The same can be done for the filter that splits mail to user's subdirs. The ER may look and if the filter called deliver-to-maildir then it can just execute the function instead of executing a process.
Similarly to how shell executes echo itself instead of calling real echo command.
is this the same for the POP3?
Thank you.
The 2.5 release has #ifndef G_LIB_SMALL preprocessor directives to remove redundant code, which has helped keep the code size similar to v2.4 even with the increased functionality.
I'm preparing OpenWrt package update to the v2.5
https://github.com/openwrt/packages/pull/18536
Currently we have:
CONFIGURE_ARGS += \
--without-doxygen \
--without-man2html \
--without-mbedtls \
--without-pam \
--disable-bsd \
--disable-gui \
--disable-mac \
--disable-testing \
--disable-windows
I'm afraid to enable the G_LIB_SMALL option during the upgrade to a next major version.
It would be better to try it later. I can add it as a TODO.
There is no "--disable-admin" config option. But that's not a big deal.
Now I think that even the ER would be few mb that still should be fine for 16mb routers that have USB. Once the selfhosting of email become a thing then other contributors will join.
There's no risk in using G_LIB_SMALL because it's a build-time optimisation with no run-time effects -- it either links or it doesn't.
BTW there is also a G_SMALL preprocessor switch that mimimises memory usage at run-time (see src/glib/glimits.h). I don't think it is particularly useful, but you might want to consider it.
The --disable-admin option went away in version 2.0. It would be easy enough to put back.