From: markus schnalke <meillo@marmaro.de>
  To  : <masqmail@marmaro.de>
  Date: Fri, 16 Jul 2010 14:26:39 +0200

Re: [masqmail] What masqmail intends to be

[2010-07-16 12:43] Juergen Daubert <juergen.daubert@t-online.de>
> On Fri, Jul 16, 2010 at 01:05:02AM +0200, markus schnalke wrote:
> > 
> > I thought about masqmail's goal today. But first let me explain my
> > path of thoughts:
> 
> thanks for sharing your thougths, a few remarks below. 

Thanks for sharing *your* thoughts. :-)


> > 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.
> 
> I'd say it the other way around: masqmail delivers mail to the users 
> INBOX mbox or can optionally use an MDA for that. 

I like it your way.


> If masqmail is used as a replacement for a "big" MTA like exim other 
> system daemons like cron are depending on it. Not sure if I want a
> MDA in the delivery chain for that case as a must have. 

Agree. mbox delivery will stay anyway now. This matches to your
sentence from above: masqmail delivers to mbox but can optionally use
an MDA for delivery.

> If the users system INBOX, often /var/spool/mail/<user>, is always or 
> at least in most cases a standard mbox no maildir support is necessary
> IMO. Dunno how the big distris handle this.

Haven't heard of a Unix system that does not have /var/spool/mail (or
/var/mail) containing the users mboxes.

What are other people's optinions and experiences?


> > .. 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?
> 
> I don't see a real reson for it.

That confirms my intend to remove this compilation option.


> > What does masqmail better that other MTAs?
> 
> Nothing, but it's real power is the very flexible handling of delivery 
> to different mailhubs via route files.

``Better'' is not limited to functions. It can also mean ease of
configuration ... or as a friends said: ``A good reason for me to
choose masqmail is that I meet the maintainer every few days at
university.'' :-)

What I actually meant with the question was: Why do people want to
choose masqmail and not some other MTA? That's the ``better'' in their
concret cases.


> I guess masqmail has never
> delivered direct to the recipient of a mail outside the local network. 

I'm not sure what you want to say with this sentence. If you meant the
possibility to do so, you are wrong. See masqmail.route(5):

    mail_host = string

    This is preferably the mail server of your ISP.  All outgoing
    messages will be sent  to  this  host which  will  distribute
    them  to  their  destinations.  If you do not set this mails
    will be sent directly. [...]

(Note: Using a wrapper (e.g. for encryption) is like setting
mail_host in this case.)

> So maping of user -> mailhup(s) -> adresses(s) is one of the important 
> parts of masqmail. Sure, you can do that at least with exim too, but it's
> much more complicated to achieve the same functionality you have with
> route-files and the easy switch to a different mailhub via online_file.

Yes.

I heared that exim is very flexible and often a good replacement for
masqmail if you want ``more''. And yes, it is more complicated to
configure for these cases.


> msmtp is one mail forwarder that works very well and flexible for such
> task too, but it's only a forwarder lacking everything else masqmail has,
> like queueing or delivery to local mailboxes.

Yes. I think it's important to emphasis that masqmail is a ``real''
MTA. Masqmail appears to fill the gap between msmtp and exim.

> But it has build-in TLS
> support ;)

... dududu ;-)

I know that we need to focus on the encryption thing soon. Personally,
I like the use of an external tool. (Actually, I like to use external
tool in general because that's how it should be done.) But at least we
need to support `openssl -starttls smtp' which should not be too
difficult. (Masqmail needs to say `EHLO' without getting a 220
greeting first.)

Maybe STARTTLS support should be built-in too. We'll probably need
that if we want to have it for incoming connections. I have not
defined my opinion on this topic yet.

But yeah, supporting encryption out-of-the-box is important for users.


> > 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.
> 
> Oops, what do you mean with by default? It listen to localhost:25 even
> if not configured to do so in masqmail.conf with listen_addresses?

Yes. I'll introduce this with 0.3.0 (if there isn't one who convinces
me to not do so). The reason is that there are MUAs that submit mail
only via SMTP to localhost:25. Pine seems to be an example for that.
Probably Thunderbird too, if it should use the local MTA. By doing
this change, we have a convenient basic setup that only requires to
set host_name in masqmail.conf. This is appealing IMO.

To the security concerns: I asked several people what they think of
listening on localhost:25 by default; no one saw a security problem.
(btw: is `localhost' guaranteed to be the local address? Otherwise it
could be better to listen on `127.0.0.1:25'.)

If you don't want to listen on any interface, set listen_addresses to
the empty string ("").

Please comment on this.


meillo