From: markus schnalke <meillo@marmaro.de>
  To  : <masqmail@marmaro.de>
  Date: Sun, 04 Sep 2011 17:35:23 +0200

RFC: Removal of configure options

Hoi,

I revived development on masqmail these days, thus preparing a next
release (0.3.4). (The long planned rework of the route concept had
already taken place. See repo.)


Now I want to simplify the configuration of masqmail. Before I go on,
I'd like to hear your comments.


(1) --with-libcrypto

Does anyone of you use it? Does anyone know why it had been introduced
in 0.2.3? As far as I found out, it's there only for the rare case
when you need to strip masqmail down to the smallest size possible,
and have libcrypto.so already in memory. The INSTALL document writes:

	--with-libcryto
	instead of using the md5 and hmac functions within the package,
	link dynamically with libcrypto. This applies only if you have
	SMTP AUTH enabled. Only makes sense if your resources are
	limited and you have libcrypto installed. Untested.

Additionally, this option might cause a problem if we link with
libcrypto: The OpenSSL license and the GPL are incompatible. This
problem seems to not affect us directly, but OS distributors could be
affected. Solving this by adding an OpenSSL-exception to masqmail's
license would require Oliver's okay. For explanations, see:
http://people.gnome.org/~markmc/openssl-and-the-gpl.html

As masqmail already ships md5 and hmac-md5 code and libcrypto aims
only on one rare use case (which is even rare in embedded systems
today), I suggest that we drop this `--with-libcrypto' option.

Opinions?



(2) --enable-auth

This switch enables SMTP AUTH for outgoing connections. Again, the
only reason I see is for compiling tiny binaries. Probably anyone
specifies this option at the configure call. I like to remove the
switch and enable it always. At least it should be enabled by default.

Opinions?



(3) --enable-ident

The ident protocol has general limitations. The mail sending hosts
need to run identd or we cannot receive any ident information.
Additionally, any information received is only as trustable as the
remote host itself. What we gain is that Received headers and log
messages include remote account name. And a user can remove queued
mail (-Mrm) if it had been sent from a remote machine's account with
the same name as his local account. All in all ident doesn't bring us
much. But it doesn't cost us much neither.

Having Received headers and log files augmented (with forgable)
information isn't very valuable. Because identds are rarely running,
no augmentation at all happens. IMO there is no need to keep ident
support for this use case.

The other one (removing queued messages) seems to be more interesting.
But I guess that there exist few setups that really require this
functionality. This is the setup in question:

	User bob sends mail from host neptun to the smart host jupiter
	for relay. Neptun has an ident server running. The message
	gets queued on jupiter because some route isn't available. Bob
	decides to withdraw the message. He logs into jupiter (where
	he's named `bob' too) and runs `masqmail -Mrm ...'.

Is there any more need to support ident? Had Oliver been the only one
who had really used it? Or should we remove the `--enable-ident'
switch and have ident support always enabled? Masqmail provides
libident itself, thus it will not demand new dependencies.

But actually, I don't have strong opinions on the ident case. We could
just leave it as is.

Opinions?



I am one of those who don't believe in improved security by
conditional compilation; in contrast, I believe in improved security
by missing corner cases. Hence I like to remove options. This also
makes the code simpler, which again matches my image of good software.

But anyhow, comments are always welcome!


meillo


P.S.
For those who care about executable size, here are the sizes of
masqmail on my system:

+auth +ident: 407724 (108868 stripped)
+auth -ident: 385683 (104740 stripped)
-auth +ident: 386154 (100836 stripped)
-auth -ident: 363902 ( 96548 stripped)