[Sussex] PHPSMTPD - tests anyone?

[Ronan Chilvers]

Hiya Steve

On Thu, 15 Sep 2005 21:59:01 +0100
Steve Dobson <steve at dobson.org> wrote:

> > realised that bits of it sounded stonkingly condescending!
> 
> Didn't come across that way to me.

Splendid!

> 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.

Very true.

> 
> > 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! :-)
> 

Neither, I'm a wine drinker, don't you know!!!

> > only done the first two.
> 
> I got what you were doing but not the why until now (from your text
> below).

Gotcha!

> > 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.

Actually, having argued the toss I'm now leaning towards LMTP, rather
than SMTP.  Simpler and designed for local network exchange.  Anyhoo,
your point remains cos its still not a pipe.

So...

Postfix, of course, supports pipes and many autoresponders are built
and work with postfix this way, including ones that are used with
virtual domains.  However, if I use a pipe I'm tied to that single
machine.  If I have 2 mail servers, far better to standardise on
something like LMTP / SMTP and then both servers can use a single
autoresponder service.  Then, lets say I have a web interface that
allows users to turn their autoresponder on and off and customise the
message (which is where I'm heading), you have single point of
reference for your user information.  You can also scale very easily -
if I add a third mail server, I can simply attach it to my
autoresponder LMTP interface and we're off!

> 
> 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.

See above...??

> 
> > 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.

Postfix also uses standard interfaces.  That's why I have the option to
use a pipe/SMTP/LMTP, etc.  The bit that isn't so satisfactory is its
virtual domain support.  Virtual domains work well, except for this one
area.

> > 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".

Right, then!!! MTA's at dawn on Brighton beach and I'll beat your mail
server into submission.

But seriously, lets not get into the whole mine is better than yours...

> 
> > 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.  :-)

Is it?  Its a good one...

> 
> > 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

You can do this in postfix too, but see above about SMTP/LMTP.  What if
someone is using an MTA that doesn't do this?  It might support pipes
but may not allow this level of flexibility...  what then?

Secondly, I'm now communicating with my autoresponder via 2 more
processes (ssh and cat) plus the autoresponder itself rather than a
native standard interface spoken by both sides of the equation which
requires only a couple of sockets in addition to the autoresponder.  I
also have to have a shell account for each user on the remote host
don't I?  What if I haven't?

> 
> 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. 

Absolutely and I'm not chucking them in the junkbin.  I'm thinking of
using network standards rather than *nix black magic...  (Steve, what
are you doing?  PUT DOWN THAT PLATE!!  DON'T THROW IT FOR GOD'S SAKE!!)

> > 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).

Ouch!  Yup, I have to take this one on the chin.  My focus was the rest
of the software and I cobbled the actual server script together very
quickly.  I shall revisit it.

>  
> > 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.

Fair enough and as I said up above I'll revisit the socket server
section...  

Remember the code in the archives on my project page is _not_ the 
autoresponder!!  Its the simple test server which is quite a different
beast and outlined in my last post.

> 
> 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!

Quite so.

> 
> 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.

Again exactamundo!

> 
> 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.

True that spamassassin doesn't but then why does Amavisd-new
(http://www.ijs.si/software/amavisd/) use an SMTP/LMTP interface and not
a pipe?  Precisely because of the scalability advantages I'm discussing
above...

> 
> 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.

Yup, but I've got no user system accounts and no procmail...  Also no
shell users apart from admin shells...

> 
> 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 :-)

Ah, Exchange!!  The slim, trim, jabba the hut of the windows email
world!!  What a pain in that arse it is!

Supporting an SMTP interface doesn't equal autobloat!!  The
autoresponder I have in mind is relatively complex but is in several
bits.  The actual responder is pretty simple and the user interface is
a separate set of scripts to a db table (or whatever the user info is
stored in).  The server script only does

SMTP/LMTP receive -> parse email -> check mysql -> inject response if
appropriate.

Job done!  Yours probably does the same thing just has a pipe at the
front instead...

Cheers for now

Ronan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.lug.org.uk/pipermail/sussex/attachments/20050916/a2db2ef3/attachment.pgp