In
<C6DDA43B91BFDA49AA2F1E473732113E010BEAD9(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
Or an alternative MTA :-)
I'm not sure that is really a joking matter. We aren't supposed to
talk about "hidden agendas", but since you raised the issue, I'll ask
directly:
Is your goal in supporting the SenderID license to get people to use
"an alternative MTA", say the one that Harry and Jim work on?
QMail is not being maintained. The license terms make it impossible
for it to be maintained.
This is incorrect. Qmail *is* being maintained, just not by DJB. As I
mentioned in my first post[1] about possible qmail conflicts with the
SenderID license, the qmail community has to use patches to maintain
the program. This makes life hard, but apparently, enough people like
it that qmail is still one of the most popular MTAs (possibly the second
most popular after sendmail).
I don't think that a standards group should be constrained by the
license terms of an unsupported product that has not been maintained
for years and is unlikely to be maintained in the future.
You are right, we should not be constrained by licensing terms of
packages. We should, however be constrained by deployment issues.
The possibility that requiring every single user of qmail to get a
signed license from Microsoft is a reason for concern. (Yes, this is
orders of magnitude more work than the patches that qmail users have
to do.)
If I had to patch Qmail the way I would do it is as follows:
[ideas snipped]
Your scheme does not match the design of qmail. What you are
suggesting is a major rewrite of the qmail MTA.
Actually not, it is many years since I looked at QMail, but this is
the type of modification I used to do in a day or so.
Making a call out to a sharred library is no different in principle
than making a call out to an object library.
I think you should look at the qmail source again. It makes a several
fork/exec's on each SMTP transaction. Despite the fork/execs, qmail
is still very fast because it doesn't do any expensive operations such
as your suggested dlopen.
While in principle, what you have suggested might work, in practice,
what you have suggested is a non-starter.
In
<Pine(_dot_)LNX(_dot_)4(_dot_)51(_dot_)0408260913060(_dot_)32406(_at_)snoopy(_dot_)smi(_dot_)sendmail(_dot_)com>
Rand Wacker <rand(_at_)sendmail(_dot_)com> writes:
[...], but from what I've learend about Open Source licensing in the
past few weeks it would seem to me that the qmail license itself is
incompatible with the definition of open source [...]
Yes, you are correct, and I said as much in my first post[1] on the
subject of qmail.
I do not like qmail because of this and for all the reasons that PHB
also complained about. However, Arnt is right, this is besides the
point. My concern is not whether the SenderID license causes problems
with any specific program, open source, proprietary, or otherwise, but
whether the SenderID license causes problems with any major MTA and/or
spam filter.
-wayne
[1] http://www.imc.org/ietf-mxcomp/mail-archive/msg03638.html