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

[Matthias Andree <ma+balsa dt e-technik uni-dortmund de>]

On Thu, 10 Jan 2002, Brian Stafford wrote:

> 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.

Please save yourself the lengthy explanations. A "localhost.localdomain"
domain part in a Message-ID is not unique. Period.

> 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.

Nope, but your system that emitted this "localhost.localdomain" part is
one of many using this domain, and it will be near impossible to bash
this misbehaviour out of distributors.

> 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 am filtering duplicates, and YOU lose when your Message-ID is not
unique. Someone to send a mail with the same software in the same second
-> one of these mails are lost. Also remember the birthday paradoxon
("what's the probability of two of N > 1 people in a room share the same
birthday"). It's a bet against the localpart. Don't do it. I'm telling
you because I think YOU will understand. Many Winbloze users won't.

> 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.) 

That may well be, but I still think that it will hurt people on desktops
that run e. g. older versions of commercial unices.

> 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 wasn't aware of the dependencies in GNUTLS, didn't yet have a look at
it myself.

> 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 

GNU libtool, or, its libltdl, reeks of bloat. I never used it myself,
but I'd be surprised if it had a small footprint (GNU libc pulls around
1,500 symbols into a simple main(){(void)write(1, "hello!\n",7);}

> gmodule should provide the SUSv2 API rather than their own private APIs.  

glib might get that API for v2.0, asking the developers may be
worthwhile.

> 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!

Good.

> 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.

Seriously, I didn't mean that suggestion as real feature request, and
fetchmail indeed supports ODMR, I only find it strange that ETRN is in
libESMTP in the first place, which - as you yourself said - is somehow
the wrong direction of data flow.

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

Yup.

-- 
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin