first stab at simple mailer

[Bill Hacker]

Simon 'corecode' Schubert wrote:
Joerg Sonnenberger wrote:
    But you still need to efficiently queue the mail for 
forwarding.  You
    can't just make separate connections to the target for each 
recipient.
qmail does it...
qmail certainly disqualifies as network friendly. For this and other
reasons.
yes, qmail is not a good reference.  nevertheless, I don't think trying 
really hard to save on connections is the objective here.  I'm talking 
about 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.  
underpowered 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 delivery.  if something is feasible, then it could be a 
feature.  if something requires advanced techniques (queue daemon, 
whatnot), then it is not the place to put it.

I know Matt has been doing big provider business since long time, but 
that's not the target.  dead. simple.  like mined vs emacs/vi.  just 
that *something* is there.

cheers
 simon
Amen, and seconded.

BTW - Qmail may now sometimes qualify as the slowest of all MTA for 
multiple-recipient delivery.

More and more of us are limiting our 'real' MTA to as few as 2 
connections-per-sendng IP, so opening multiple, parallel connctions becomes a 
liability.

Two connections at a time per sender is enough for SMTP-compliant MTA who send 
ONE message with many recipients over a single connection, PLUS reply with a 
separate sender-verify if/as/when we do a sender-verify on *their* incoming.

Qmail, by opening a connection per-recipient, looks just like cetain spambots, 
hits a 'DEFER', has to come back after its own retry time - often several 
minutes,  and not always just once.

At the end of the day, a server intended for even small-domain MTA use *will* 
get the MTA installed that the admin or his firm is most comfortable with - not 
the 'unproven' one being developed here - no matter how elegant it mught be.

On which score - I would not even bother replacing sendmail.

It isn't 'broke enough', nor are all of the several lite alternatives so broken, 
to justify diverting scarce coding skills from core and kernel work.

Other than the fact that any 'C' coder needs a change of scenery once in a 
while, just to delay the onset of brain damage!

;-)

Bill