Re: Licence issues for libESMTP (and Balsa) - long (was Re: NTLM authentication)

[Brian Stafford <brian stafford uklinux net>]

On Thu, 10 January 01:37 Matthias Andree wrote:
> Brian, your domain is hosed: localhost.localdomain is in your
> Message-ID.  Please take the time to work around my duplicate filter and
> avoid collisions.

Since you make this point, let me first explain why examining Message-Id's 
structure is wrong.

Message-ID: is an opaque token that happens to have the same syntax as a 
mailbox address.  Its only purpose is to distinguish one message from another, 
or conversely to show that two messages received via different paths are, in 
fact, the same message.

 From RFC 2822

    The "Message-ID:" field provides a unique message identifier that
    refers to a particular version of a particular message.  The
    uniqueness of the message identifier is guaranteed by the host that
    generates it (see below).  This message identifier is intended to be
    machine readable and not necessarily meaningful to humans.  A message
    identifier pertains to exactly one instantiation of a particular
    message; subsequent revisions to the message each receive new message
    identifiers.

Also

    The message identifier (msg-id) itself MUST be a globally unique
    identifier for a message.  The generator of the message identifier
    MUST guarantee that the msg-id is unique.

It then goes on to suggest an algorithm for generating the Message-Id, however 
the following point is made

    Though other algorithms will work, it is
    RECOMMENDED that the right hand side contain some domain identifier
    (either of the host itself or otherwise) such that the generator of
    the message identifier can guarantee the uniqueness of the left hand
    side within the scope of that domain.

It is very important to note that there is *no normative requirement* that the 
right hand side is the domain name of the generating host.

In conclusion, if you are filtering based on the "domain" in the Message-Id 
you should fix your filter, its wrong.  Message-Id cannot be used to infer 
information about the source of a message.

I see no reason to change the configuration on a machine I use only 
occasionally for mail on the offchance that someone else misuses Message-Id.


> On Wed, 09 Jan 2002, Brian Stafford wrote:
> 
> > Lately I've been watching the GNU TLS library which seems to be
> > undergoing rapid development just now and which looks promising.  From
> > what I've seen of the API it is cleaner than the OpenSSL one which
> > suits my sense of aesthetics.  The downside is that it is GPL which is
> > problematic for use within LGPL code (as I understand things).
> >
> > If I adopt the GNU TLS code in place of OpenSSL, I'd probably need to
> > change libESMTP's licence from LGPL to GPL.  That would likely please
> > debian bods but it might lead to a code fork.  Commercial users
> > (honest souls of the highest probity) will continue to use the older
> > LGPL releases + OpenSSL.  If I didn't maintain the LGPL version
> > someone else might step into the breach.  On the other hand, for NTLM
> > authentication, it would eliminate the problem of using GPL code from
> > Samba within an LGPL project.
> 
> Without doing into dynamic link detail issues which are always prone to
> portability issues as well and take one or another excluded platform,

dlopen/sym/close are in the Single Unix Specification v2 (I don't know about 
v1).  Presumably the portability issues will ease off in future.  (It would be 
nice if they made it into Posix too.) 
> one way might be to persuade the GNU people to release their stuff as
> LGPL. After all, the reasoning for LGPL has always been and still is (as
> per http://www.gnu.org/philosophy/why-not-lgpl.html) to license
> non-exclusive material: "There are reasons that can make it better to
> use the Library GPL in certain cases. The most common case is when a
> free library's features are readily available for proprietary software
> through other alternative libraries. In that case, the library cannot
> give free software any particular advantage, so it is better to use the
> Library GPL for that library." [ibidem]
> 
> Since OpenSSL is a strong competitor to GNUTLS, it may be best to talk
> the copyright holders into degrading their GNUTLS license to LGPL --
> that will make it an even stronger competition for OpenSSL, and in the
> end, both may profit from that licensing change.

Perhaps.  However, I doubt that much progress is likely on such a change.  The 
GNU TLS code depends on other projects to provide some of its functionality, 
such as some crypto code and the big number library.  If these other packages 
are under GPL the authors' hands are tied - they either LGPL and develop from 
scratch or they GPL and use existing, tested code.  My own experience of 
choosing the Lesser GPL for libESMTP is that the choice of third party code I 
can incorporate is quite restricted, lots of the good stuff is GPL.

> > I suspect that this approach would solve the debian dilemma for apps
> > or libs using it.  libESMTP would be unambiguously LGPL (Balsa
> > unambiguously GPL) regardless of how configured when built and modules
> > with iffy licences can be safely omitted from picky distributions.
> > I'd really appreciate some feedback on this concept from those who
> > know about licensing and runtime dynamic loading.
> 
> Your reasoning looks sound. However, dynamic linking, as written above,
> is prone to portability issues, especially when it comes to dlopen.
> Choose for yourself if you want to take the extra maintenance work to
> get the stuff portable to every platform that Debian and NetBSD cover,
> and to the commercial unices found on desktops or servers, Solaris,
> IRIX, HP-UX, AIX, BSDI, to name the first ones that come to my mind.

I take the view that the dlopen/sym/close approach is the correct one, since 
SUSv2 describes the interface and semantics.  Regarding portability, there is 
always libltdl distributed with GNU libtool to fall back on if the dlopen 
functions are not available.  An alternative fallback might be the gmodule 
interface from glib.  However, my own feeling is that libltdl and gmodule 
should provide the SUSv2 API rather than their own private APIs.  Using them 
would then be easy, even if the platform's native dlopen... implementation is 
broken.  A further benefit is cleaner #ifdef free code.  (GNU libiconv is an 
example of this sort of replacement approach for the iconv functions provided 
by some libc implementations.)

In any case, libESMTP has used dynamic loading for a while now when doing SMTP 
AUTH.  Originally it used libltdl and more recently it uses dlopen with 
libltdl as a fallback.  Other than a few complaints about having to install 
libltdl, I've had no complaints that dynamic loading of modules is broken in 
any way.  To the best of my knowledge it works as expected on all platforms 
that libESMTP works on at all!

> 
> > Incidentally, its the lack of closure on the TLS code - e.g. finishing
> > off the certificate management and peripheral issues - that is the
> > major barrier to releasing a libESMTP 1.0.  The rest of the code seems
> > solid enough and hasn't changed so much in the last 4 months or
> > thereabouts.  The only experimental feature is ETRN, other than that,
> > I feel that libESMTP is pretty much feature-complete.
> 
> When you say ETRN, you must also say ODMR (ATRN). Check RFC-2645. :^)

Hmmm... I've been through *all* the mail related RFCs ad nauseum - I know all 
about RFC 2645.

The reason ETRN is there is that it is a feature request for at least one user 
and it was easy to implement.  I am less likely to implement ATRN.  The reason 
is that
as well as a client, an SMTP server is needed too.  I could create the 
connection, authenticate turn the connection and then fork/exec a helper 
program which connects to a local SMTP server and pipes the reversed 
connection to it.  This is quite a bit more work than ETRN and nobody has 
asked for it.  Besides, this sort of thing is probably better in a program 
like fetchmail or one of its imitators.

> Just to prevent you from running out of feature requests. :-)

Havent had so many of those lately - I figure the feature set must be about 
right!

--
Brian