[Sussex] PHPSMTPD - tests anyone?

[Steve Dobson]

Hi Ronan

On Thu, Sep 15, 2005 at 08:03:16PM +0100, Ronan Chilvers wrote:
> Hiya Steve
> 
> Firstly, I must apologise.  After re-reading my last email I realised
> that bits of it sounded stonkingly condescending!

Didn't come across that way to me.

> This wasn't my
> intention at all and I apologise for it!

Well I never get offended at e-mail - inflamed to write a response
sometimes, but never offended.  E-mail is such a poor communication
system that what is meant and what is perceived are almost never the
same.

> If I ever do make it to a
> moot, you have my full permission to pour a pint over me

If you drink bear (ale) then I wouldn't waste a good pint.

If you drink larger (fizzy nats piss) then:
  a). WHY?!?!?!?!?!
  b). Okay then, it's either pour it over you or down the sink.
      Okay, the sink wins, I would wish lager on my worst enemy! :-)

> In my defence I can tell you that I
> had a line manager breathing down my neck who is a rising star on my
> people-I'd-most-like-to-stuff-down-the-toilet list which led to a
> certain tension in my emails!!??!!

I've had mine one day-fighting-PHP-and-I-need-a-ale day, so worry not.
 
> Secondly, I think I've misrepresented what I'm doing here.  We seem to
> have some heftily crossed wires going on!  Let me have another crack at
> it.  The idea is in three chunks of which I have currently only done
> the first two.

I got what you were doing but not the why until now (from your text
below).

> 3. (Not done yet!) Build an autoresponder similar to procmail+vacation
> (ie: to send 'Sorry! I'm on the beach in Hawaii' type messages) that
> would (and this is the key bit) work with Postfix style virtual
> domains / mailboxes. That is, it needs to work with mailbox accounts
> that are not system accounts.

Okay, this was the bit I was missing.

> This in itself doesn't mean that an SMTP
> interface is required.  However the reasoning behind the SMTP interface
> was that it would gain me a lot of flexibility.

I'm curious to know what the advantages of an SMTP interface are over a
pipe interface - I can't see that it gives you anything.

> There are of course a
> lot of security concerns implicit in this (eg: controlling relaying,
> host access, memory usage, etc) but these can be addressed with a bit
> of thought.

I'm not suggesting that they can't be solved, I just don't see the 
SMTP interface advantages to make dealing with these problems worth
the effort.

> The primary one is, as you rightly point out, the
> efficiency of the system.  Don't know if you know Postfix, but it uses
> its own virtual MDA and I'm not sure how hookable it is (am reading
> about it as we scribble).

This is probably why I've never used Postfix.  Exim and SendMail use
standard interfaces and are thus easy to write standalone programs
that work with them.

> It may be that I can use a pipe via the MDA
> which would be great, but from looking at other solutions, the usual
> method is to define a second transport and duplicate at least the
> headers off to the autoresponder.

I;m not saying that you're wrong, but my gut reaction is "Get a better
MTA".

> Not a great solution since most
> emails won't require an automatic response so its a lot of work for a
> small gain.

That's my point, not yoursr.  :-)

> Since I'll probably be defining a second transport, my
> feelings were that to allow some scalability (ie: across hosts) an SMTP
> interface is going to be most flexible.

While that is true for a single binary, in exim you could configure
a pipe transport that tunnels across SSH for example:

   remote_pipe:
     driver = pipe
     command = ssh user at remote.host cat > /var/autoresponder/file

If /var/autoresponder/file is a fifo then your autoresponder program
on the other end could just be sitting there waiting for the next
e-mail to hit.

The really, really, really nice thing about *nix are the pipes - you can
do just about anything with them if you just think outside the box.
 
> The point about the sequential sockets is not to do with PHP5 itself,
> only with my implementation of the socket server in PHPSMTPD.  There's
> no requirement for lots of concurrent connections since the software is
> intended as a development tool for 1 user (at the moment).  The current
> implementation does mean that the sockets will block (as you point out)
> but this isn't important at the moment because the load is _very_ low.
> Does that make sense?

It make sense, but I think you've designed you system the "wrong way(tm)"
(see below).
 
> Anyhoo, hope that clears up the confusion.  I would appreciate any
> comments on the code - its a somewhat raw but the logic is roughly
> there.

I'm sorry, I won't be looking at the code, because I believe that the
design logic is where the bigest problem is.

There is one golden rule that all *nix programmers should think at
*all* times: Keep it small, keep it simple.  In other words every
program on a *nix box should do one job, but do it right!

Sendmail, exim and postfix are MTAs.  Let them do the work of transferring
email around the system.  As you've said, that is a complex business and
must be done correctly or the e-mail system can break.

I know Postfix supports pipes - I've just googled and found questions/
examples of plugging in spamassissin that way.  So ask yourself this
question:  If spamassissin doesn't need an SMTP interface why does
your autoresponder?  Unless there is something in the SMTP protocol
itself (not the e-mail content) then the answer has to be that it
doesn't.

Also your autoresponder has to be installed by root as the MTA has
to forward the e-mails onto it.  So a user that hasn't root access
can't use your system.  If it used a pipe interface then procmail
(if configured) would allow him to use your system.

For my final point I would like to point out that your autoresponder
is trying to do two jobs:
   1). receive email, and
   2). process email.
This way leads to bloatware, and bloatware is bad.  There will always
be the temptation to had just one more feature, until the system is
so feature rich that iti's bugs have unforeseen side effects.  The system
becomes unmanageable, can only handle e-mail for hundreds (not
thousands) of users and needs it's own system just to do it's job.
At that point you may as well re-name it to Exchange2 :-)

Steve
-- 
Hanson's Treatment of Time:
	There are never enough hours in a day, but always too many days
	before Saturday.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.lug.org.uk/pipermail/sussex/attachments/20050915/b8d21b1e/attachment.pgp