[Sussex] PHPSMTPD - tests anyone?

[Steve Dobson]

Ronan

On Thu, Sep 15, 2005 at 12:58:02PM +0100, Ronan Chilvers wrote:
> On Thu, 15 Sep 2005 12:26:14 +0100
> Steve Dobson <steve at dobson.org> wrote:
> > I have to ask why?
> > 
> > I have configured exim4 (or sendmail or procmail, or ...) to just
> > pipe the incoming email to a php process.  The php process scans
> > the mail text and then works out what to do.  No need to do all
> > that silly TCP streams - it would only need to read from standard in.
> 
> Partly as an exercise in coding it,

Okay, I understand that.

> partly because there's good mileage
> in having an SMTP interface because its network aware.

This bit I do not.

> TCP streams
> aren't so silly if your auto responder is on a different machine
> to your email server :-). Having a script talk SMTP is a very useful way
> of giving it a machine independant interface.  For example amavis
> (general purpose filtering software written in perl) uses an SMTP /
> LMTP (if local) interface to the MTA.  Its cleaner, neater and more
> extendable than the stdin option.

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.

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

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.

This project worries me.

> Hope that answers the questions.  Cheers for the comments.

Nope - just created more.

Steve
-- 
Santa Claus is watching!
-------------- 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/51ea7825/attachment.pgp