[Sussex] PHPSMTPD - tests anyone?

[Ronan Chilvers]

Hiya Steve

Firstly, I must apologise.  After re-reading my last email I realised
that bits of it sounded stonkingly condescending!  This wasn't my
intention at all and I apologise for it!  If I ever do make it to a
moot, you have my full permission to pour a pint over me (but don't get
it on the shoes - they're new).  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!!??!!

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.

1. Build a server side SMTP class which is capable of speaking enough
SMTP to receive a message.  This is done, to a point and was initially
an exercise in coding.

2. Build a small test server (PHPSMTPD), using the class built in [1]
which would accept mail from a 'remote' host and dump it to the
filesystem. The purpose of this was first to test the SMTP class and
second, because its a tool that I would have found handy in the past and
will in the future.  This software is intended to run on a workstation
as a local process, probably in the foreground in a terminal or as a
background job, started by the developer and able to expose the full
SMTP transaction without requiring a knowledge of how to get the same
from a proper MTA.  Once their development work is finished they could
then change their software config to point to a real MTA and be
reasonably assured that the behaviour will be the same.  This is the
software that I've called PHPSMTPD and that I've asked you guys to have
a butchers at. (Incidentally, I'd appreciate any comments on the coding
logic if anyone has time to trawl through it... :-) )

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. 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.  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.  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).  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.  Not a great solution since most
emails won't require an automatic response so its a lot of work for a
small gain.  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.

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?

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.

Cheers

Ronan


On Thu, 15 Sep 2005 16:07:31 +0100
Steve Dobson <steve at dobson.org> wrote:

> Hi Ronan
> 
> On Thu, Sep 15, 2005 at 02:35:34PM +0100, Ronan Chilvers wrote:
> > But the idea behind this software is NOT to be an MTA, its to allow
> > it to speak SMTP so it can take advantage of the interface.
> > 
> > A common way for autoresponders to work is to define a transport
> > from the MTA to the autoresponder interface, whatever way you do it
> > (in my case via SMTP which is incidentally, nothing new in the
> > world of autoresponders).
> 
> I agree that autoresponders have a transport from the MTA to their
> interface.  I'm thinking of mailman and the like here, systems which
> are designed to work via email but where you don't "talk" to a human.
> 
> But I disagree that using SMTP for an MTA to talk to an autoresponder
> is logical.  If you're listening on port 25 (the SMPT port) then no
> other process, i.e. a real MTA, can be.
> 
> If you're listening on a non-standard port (which having just read
> your page suggest that this is the way you plan on using it) then
> this makes a little more sense, but it still isn't, IMO, a good way
> to do things. Think about it, at some point you'll have two copies of
> the e-mail in memory, the one in the MTA and the one being passed on
> to PHPSMTPD - not very efficient.  Two copies of the mail in memory,
> three extra sockets and a whole separate process running, just to
> copy an incoming e-mail to a file.  I can do that in about a dozen
> lines in exim config.
> 
> > You then define an alias map which replicates mail to
> > both the users mailbox and the autoresponder transport.
> 
> Well if this autoresponder is designed to respond to e-mails sent to
> humans then why not use procmail or vacation to do the same thing?
> 
> > The
> > autoresponder can then look up the user in whatever backend it uses
> > to decide whether a response is necessary or not.  The
> > autoresponder does not speak to the Big Bad Internet (tm) only to
> > designated MTA(s).  It then passes back any response email to the
> > MTA for processing and the MTA is free to accept or reject that
> > email depending on configuration.
> 
> Sending e-mails in php is easy, the mail()
> (http://uk.php.net/function.mail) function has been available since
> PHP3.  So if I set up a pipe from the MTA to my PHP3 program then I
> could do the same thing. 
> > Just because a system wants to speak SMTP doesn't mean it has to be
> > a fully fledged mail server. This particular use of the SMTP class
> > is not intended to implement an MTA, only to look like an MTA.  It
> > does not have the facility to pass email on to anywhere - it just
> > stores the mail on disk.
> 
> This is true, but most people say that if it looks like a duck and it
> quaks like a duck it will get treated like a duck.  So some are going
> to assume that it can be used in very way a duck can.
> 
> > > This worries me.  Have you written a SPAM remailer here?  If any
> > > email sender can connect from anywhere then haven't you created a
> > > way for spammers to spread their evil seeds?
> > <snip>
> > 
> > No because, again, its not an MTA, it only looks like an MTA.  As
> > mentioned above and evil seeds notwithstanding, this particular
> > project has no facility to do anything with email it receives apart
> > from store it on disk.  Neither does it speak client side SMTP.  It
> > only has the facility to receive mail and dump it to a file,
> > exposing the SMTP transaction.  Not sure if you read the project
> > page fully, or maybe it doesn't say what I think it says! 
> 
> Hang on, hang on.  You said that this is an autoresponder.
> Autoresponders send e-mails, THIS IS HOW THEY RESPOND.  Is your
> system just sending bounce replies?  To send an email the system must
> "speak client side SMTP" or, to put it another way, "sender side
> SMTP". 
> > <snip>
> > > Also what do you do with email for postmaster@<local-machine>
> > > (and if you're running a web server webmaster@<local-machine>)?
> > > The RFCs for e-mail processing *require* that you accept all mail
> > > for postmaster, even spam, as mostly this is used to report
> > > problems with e-mail configuration.
> > <snip>
> > 
> > I know the RFCs require functional system addresses but.... this is
> > not an MTA! It is not intended for use as an MTA and never will
> > be.  No domain will ever terminate at this software, simply because
> > it does not have the facilities to deal with incoming email, apart
> > from to store it on disk.
> 
> I would say that *any* email that is (incorrectly) routed via you
> system *will* *end* because all your system does is store it to disk
> - regarless if it is for that machine or not.
> 
> > It is not intended and cannot receive email destined for
> > someone's mailbox and it never will do that.  The tcp streams
> > implementation is sequential, not concurrent, meaning that it is of
> > little use if more than one client is using it.  This is a
> > 'feature'. As a test server, that's all it needs.
> 
> I don't understand what you're saying here.  If the TCP stream in PHP5
> is sequenctial that may just mean that a second connection will block 
> until the one currently being processed has completed.
>  
> > In the case of an autoresponder using the base SMTP class, its up
> > to the software to have some intelligence about the envelope email
> > address and mail headers. For example, a decent autoresponder won't
> > respond to mailing list addresses.
> 
> Very true.
> 
> > There is no reason for such software not to
> > respond to a postmaster@ or webmaster@ address.
> 
> True, but those two email address should resolve to a mailbox read by
> a human, probably the mail and web admin staff.
> 
> > Likewise it would not
> > block email from reaching those addresses as local recipients,
> > because that is not its function and it has no ability to access
> > the local mailboxes - that's the MTA's job.
> 
> But an MTA that has handed over the email message to your system *has*
> passed on the responsability of delivering that e-mail to your system.
> That is implessit in the SMTP protocol.  If the original sender didn't
> take a copy of that e-mail when it was first sent then your copy may
> be the *only* copy in the universe.
>  
> > I don't think you're grasping what the project is or
> > does.
> 
> You're right - unless it was to teach you how to use sockets in PHP.
> 
> > I am not building a PHP MTA, the main goal of the project is
> > to write a server side SMTP interface in PHP.  That does not
> > constitute anything different from the interfaces available in
> > Perl, Ruby, C, etc.
> 
> Well the only interfaces/libraries I'm aware of there are senders of
> e-mail, those are clients.
>  
> > The idea behind it is threefold:-
> > 
> > 1. Create a PHP class that can speak server side SMTP.
> 
> Which is used only to receive e-mails.
>  
> > 2. Use the above class to create a test server that can receive
> > email and dump it to a file that exposes the SMTP session, for use
> > in testing.  This project is mainly intended to test the
> > functionality of the SMTP class built in point 1.
> 
> As a development step this is fine.
>  
> > 3. Implement an autoresponder system that uses the above SMTP class
> > as its interface to the MTA.
> 
> At which point you are sending e-mails back out.
>  
> > Hope that is now clearer.
> 
> Not at all.
> 
> > I'll tweak the project page to explain the
> > purpose more fully.
> 
> The purpose of the autoresponder would be a start.  It it a vacation
> like program telling senders that the user is out of the office today
> because of holiday, bank holidays or sickness?
> 
> Or is it an autoreponder for doing remote processing (like mailman)
> with out a human operator being involved?
> 
> Steve
-------------- 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/20050915/b8f0f227/attachment.pgp