Re: first stab at simple mailer

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

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
Description: OpenPGP digital signature