first stab at simple mailer

[Matthew Dillon]

:yes, qmail is not a good reference.  nevertheless, I don't think trying r=
:eally hard to save on connections is the objective here.  I'm talking abo=
:ut 5 to 20 mails per day.  seriously, that's *nothing*.  mail servers get=
: more spam than that.  I want to keep the mail agent simple.  underpowere=
:d on purpose.  just for the "install and mail works" thing, not for the "=
:hey, I can also run my mailinglists across this mail agent" thing.  just =
:imagine a blood simple smarthost delivery agent and add queue + local del=
:ivery.  if something is feasible, then it could be a feature.  if somethi=
:ng requires advanced techniques (queue daemon, whatnot), then it is not t=
:he place to put it.
:
:I know Matt has been doing big provider business since long time, but tha=
:t's not the target.  dead. simple.  like mined vs emacs/vi.  just that *s=
:omething* is there.
:
:cheers
:  simon

    Lets create a clear separation.  We know why we want this... we want
    all intra-machine mail to work without having to install sendmail or
    postfix.

    So make it do that, as you have said, and make sure all the hooks
    are there for integrating with an MTA like sendmail or postfix without
    having to deinstall it.  For example, by having an smarthost option for
    inter-machine domains.

    If your mailer is going to take over from mail.local and friends, then
    there *are* a few requirements, and mail aggregation is one of them:

    * It has to properly handle the following standard mail control files:

	/etc/mail/aliases
	/etc/mail/local-host-names
	/etc/mali/virtusertable

    * It must handle command pipes and file redirects in /etc/mail/aliases

    * It must implement at least a smarthost SMTP interface for off-machine
      mail, and it must aggregate multiple recipients (not send individually).

    * You need to write a mail.local (if we are trying to divorce ourselves
      from sendmail :-)).  Your mail.local must handle ~username/.forward
      (including file redirects and command pipes).

      mail.local is a terminus program... it delivers to a resolved username
      on the local machine.

    * You need to write a sendmail binary frontend (i.e. option support
      for -F, -f, -oi, -t), because many programs which send mail pipe
      to what they think is a sendmail binary.

      sendmail (when exec'd as a binary) is an exodus program... it sucks
      new mail into the system.


    What you don't have to worry about:  You don't have to worry about DNS
    lookups or MX lookups or anything like that.  Let the smarthost deal with
    it.  The smarthost could very well just be a sendmail or postfix MTA
    running on the local machine, so the intra-machine mail system doesn't
    really need any DNS smarts beyond a smarthost.

    This is what we need to do in order to be able to have mail in the
    base system without sendmail or postfix installed.


						-Matt