[Sussex] PHPSMTPD - tests anyone?

[Ronan Chilvers]

Hi Steve

On Thu, 15 Sep 2005 13:44:17 +0100
Steve Dobson <steve at dobson.org> wrote:

> > Partly as an exercise in coding it,
> 
> Okay, I understand that.

Great!

> 
> > partly because there's good mileage
> > in having an SMTP interface because its network aware.
> 
> This bit I do not.

Oh, dear!

<snip>
> If you have a system sending e-mails then you *should* be running an
> SMTP daemon of some kind.  Debian (for example) enforce this policy
> and for good reason.  If you don't want a heavy weight like exim or
> sendmail then there is a simple remailer that just passes every
> e-mail it receives to your site's smarthost. [A smarthost being 
> a machine that knows how to route email for your network.]
> 
> CLI MTA's like mail, mailx, mutt and the like, don't send e-mail
> themselves, they just connect to the MTA on the local machine and 
> leave it to it.  This is the way it is suppose to work.
<snip>

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). You then define an alias map which replicates mail to
both the users mailbox and the autoresponder transport.  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.

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.

<snip>
> > > BTW: Looking at you page I would never use this as it uses SMTP
> > > AUTH but only for PLAIN and LOGIN.  I would *never* use either of
> > > these as the passwords are transmitted in clear text.  CRAM-MD5
> > > (RFC-2195) is by far the better option.
> > 
> > Agreed, but if you read a bit further down, you'll also see that the
> > SMTP AUTH requests always succeed.  SMTP AUTH support isn't
> > intended to be used 'in anger'.  Its in there to support client
> > scripts who need to use it and test that its working.  The SMTP
> > AUTH requests are both correctly parsed and handled, but the
> > authentication doesn't actually happen.  So for example, someone
> > using PEAR::Mail can turn on SMTP AUTH in their mail object (the
> > mech is automagic in PEAR::Mail).  The server emulates what the
> > real one should do.  I may add CRAM-MD5 to it but SMTP AUTH is
> > there for convenience in this implementation, not as a main
> > feature.  Bear in mind that this is NOT supposed to be a fully
> > fledged mail server.  Its a test server, designed to accept mail
> > and then expose exactly what happened in the SMTP transaction.  If
> > I was using the SMTP class in an autoresponder I wouldn't be using
> > SMTP AUTH anyway (although you could I guess) - I'd be more likely
> > to develop lookup maps for acceptable email or IP addresses.
> 
> 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! 

;-)

If someone wanted to create a mass mailer, this would not be the way to
do it.  It speaks the wrong end of the SMTP dialogue.

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

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. There is no reason for such software not to
respond to a postmaster@ or webmaster@ address.  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.

<snip>
> This project worries me.
<snip>

Rennies... or aspirin...  always works for me.

Seriously though, I don't think you're grasping what the project is or
does.  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.

The idea behind it is threefold:-

1. Create a PHP class that can speak server side SMTP.

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.

3. Implement an autoresponder system that uses the above SMTP class as
its interface to the MTA.

Hope that is now clearer.  I'll tweak the project page to explain the
purpose more fully.

<snip>
> > Hope that answers the questions.  Cheers for the comments.
> 
> Nope - just created more.
<snip>

And answers to go with them?

:-)

Cheers

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/20050915/97e75c52/attachment.pgp