From: Juergen Daubert <jue@jue.li>
  To  : <masqmail@marmaro.de>
  Date: Thu, 13 Oct 2011 12:27:47 +0200

Re: [masqmail] RFC: Removal of configure options

On Sun, Sep 04, 2011 at 05:35:23PM +0200, markus schnalke wrote:
> 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.

I'm a bit late with my comments, hopefully they are still useful 
for you.

> 
> 
> (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?

Depends. I've still the hope that masqmail sometimes supports
TLS by itself without using a wrapper script. But if we link 
against openssl/gnutls anyway it's consistent to use the 
supplied crypo functions.

But if we never will have that, I'd agree to remove the option
and use the internal code.

>
> 
> 
> (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?

I don't see a point to disable smtp auth, removing this option
dosn't hurt IMO.

> 
> 
> 
> (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?

Well, if I understand the ident use case correct, ident lookup are
only performed for incoming SMTP calls, meaning masqmail is running
on the remote side of the connection and we have to run an ident
daemon on the sending side. 
Because masqmail will hopefully _never_ run as a SMTP server on a 
public network the whole ident thing is only useful in a local 
network. But who runs a ident daemon on the hosts of his LAN?

I'd remove the ident stuff and leave it up to exim and Co. to have
such options.


HTH and best regards
Juergen