From: markus schnalke <meillo@marmaro.de>
  To  : <masqmail@marmaro.de>
  Date: Fri, 16 Jul 2010 01:05:02 +0200

What masqmail intends to be

Hoi,

I thought about masqmail's goal today. But first let me explain my
path of thoughts:

I removed the POP3 stuff (1300 SLOC) today (from 0.3.0). Then I
reasoned about the configure option --disable-resolver,
--disable-smtp-server, and especially --enable-maildir. Let's take the
last one as example


What is the advantage of this --enable-maildir option? My first
thought was security, because if you compile less code into a
security-critical program, then there are less lines that introduce
bugs. Additionally, if you haven't compiled it in, then it is surely
not available. This might be an argument for the smtp server support,
but hardly for 130 lines of maildir code.

Over time, I came to the feeling that oku focused on small executable
size a lot. The reason could be that he developed masqmail for
embedded systems. (That's just a guess.) Again, for 130 lines of
maildir code it doesn't make sense.

What I see is that this configure option makes masqmail more
complicated than neccesary. The #ifdefs make the code less readable,
documentation and install howtos are more complex. But what is gained?
I think nothing. Hence, I want to remove these (almost) unneccesary
configure options.

The question, however, is whether maildir support should be removed
from masqmail (and transferred to the MDA) or if it should always be
compiled in. I'm not sure. I like using an MDA for any non-trivial
delivery. (mbox support will stay as fallback.) Is masqmail's maildir
code correct and secure? By transferring the job onto the MDA, we need
not to care, and they probably do a better job with this anyway. But
if you think that the maildir support is important for masqmail, I
don't care much about the 130 lines. They just will be compiled in
always.


Does anyone know a reason why one would like to --disable-resolver?
I discovered, that BSD have the contents of libresolv inside their
libc, but my NetBSD 4.0 provided a stub libresolv though. Linking it
or not didn't make a difference.


For --disable-smtp-server, I think that it always should be enabled.
If masqmail should not act as SMTP server, you just do not start it as
daemon (-bd) and everthing is fine.


... and here we are at masqmail's goal: Is it important that masqmail
can be built without the SMTP server produce a smaller binary? Do we
want to cover this niche?

What's the niche that masqmail want's to cover?

What does masqmail better that other MTAs?

Where do other MTAs fail, but masqmail not or less?


I think we agree that masqmail is not suited for large mail servers
but for workstations, notebooks, and small home servers. These are
typically not administrated by people who can setup sendmail in an
hour. Other mail servers are difficult to setup too, that's what my
experience showed.

Hence, masqmail should be easier to configure. This for instance means
that it should few configure options, because choice is a problem.

But masqmail's flexibility with the routes is surely a strength that
should be extended.

Simple forwarders already exist in larger number. Masqmail provides a
``real'' MTA, which these don't.

Local delivery will be available by default with 0.3.0. Masqmail will
listen on `localhost:25' by default. This would collide with the
--disable-smtp-server option.

I do much favor clear rules like ``Bcc: headers are always removed''.
The possibility to define the default setup in a few sentences
(without conditions) would be great.



Phew, now I wrote a lot.

To sum it up:
- We should define where are we going to and then aim towards there.
- I like to simplify the configuration and define clear rules how
  things are.


Have a good sleep
... it's already very late here.


meillo