first stab at simple mailer

[Simon 'corecode' Schubert]

Matthew Dillon wrote:
    * Background the process using the daemon(3) function
that's in the code.

    * Wrap calloc, malloc, strdup, etc.
I wouldn't know how to gracefully handle failures, especially concerning queue business etc.

    * I didn't quite undersand what the link() business was about.  When
      processing queues, it is best to avoid all unnecessary namespace
      manipulation (rename, link primarily).
The queue works like this:

- create a temp file
- this queue file has a "header" prepended
- read the mail from stdin and write to the temp file
- each recipient gets assigned a queue id, which is the filename at the same time
- the temp file gets linked to the queue ids
- when a recipient was processed, the link gets removed
this way I only have one instance of the mail on disk and I don't need additional files to track for one mail.

    * Remote delivery, which you have as 'XXX implement me'...  you need
      to be able to sort by the target domain's MX lookup and you need to
      do MX backoff & forwarding for any remote delivery.  It isn't too
      bad but DNS lookups can be difficult to implement efficiently.
I don't really care about efficiency.  This mailer is supposed to be a low-end thing, just able to enable a base system to deliver common day mail loads (by periodic, cron and users).  This is *NOT* supposed to be a high-performance mail server.  Anybody who needs any sort of sophisticated mail processing can use the mailer they want.

    * Configuration file. Yup. you need one :-).
Not sure what I want to configure.  Maybe a smart/relayhost, but nothing more.

    How serious are you about this?  There are a number of issues that
    would have to be addressed, even for a simple mailer.  Handoffs for
    .forward files (including processing exit codes properly),
What do you mean with handoff?  I want to support .forward, but only for file and address forwards, not for command forwards.

    supporting
    /etc/mail/aliases and /etc/mail/virtusertable,
yes, aliases is in work.  I've never heard about virtusertable before, and I don't see where this might be necessary in a simple mail setup.  This mailer accepts only local mails.  No listening on port 25.  As soon as you need mail rewriting, a "big" mailer should be installed.

    and handling a more
    sophisticated local delivery check (using a DNS lookup on the target 
    domain to see if its a CNAME to the actual host, or something similar)....
I thought about this, but I decided to go down the easy road for now.  This shouldn't be much of an issue.  Again, the mailer is not designed to act as an MX.  How do I find out if an IP address is local?  This check would basically be the only important check.

    There are many other issues as well, including mail size limitations,
    smarter queueing mechanisms (sorting by target recipient to prevent a
    stalled target host from stalling the entire queue), handling
    out-of-disk-space issues gracefully, etc.
There is no global queue manager.  Each mail gets processed on its own.  Yes, I am aware of the fact that this might open two connections to a destination mailer for two mails.  However, this is a simple mailer and for simple mail loads, this won't be a problem.

Out of disk space is being handled:  if the mail can be queued, everything is fine.  If not, the mailer errors out (nothing else it can do).

I don't think I want to care about mail size limitations.  That's the job of a "real" mail server.

    If you intend to build the daemon side as well then there are many
    other issues as well including limiting the memory used to hold headers,
    proper string parsing, hand-off security, MIME issues, and other things.
No, I don't want to accept mails except from the command line.

    please, no more SGID binaries.  Just make the front-end connect to 
    the back-end over a localhost socket and pass creds with sendmsg() 
    and SCM_CREDS (with regards to a mail.local equivallent).
I don't really want to split this into backend daemon and frontend tool.  Besides, where is the difference?  One of them always needs to run with elevated privileges.  I do *not* want to make it setgid wheel.  Just setgid mail, where mail may write to /var/spool/mqueue and to /var/mail/*.  It's really supposed to be simple.  No running daemons required.

cheers
 simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00017.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20070321/d4028aef/attachment-0018.obj>