[Sussex] PHPSMTPD - tests anyone?

Fri Sep 16 20:29:11 UTC 2005

Hiya Steve

On Fri, 16 Sep 2005 12:32:23 +0100
Steve Dobson <steve at dobson.org> wrote:

> > wrote: Neither, I'm a wine drinker, don't you know!!!
> 
> Red I hope!

Defo!!  White is for girly girlies and children!!  Sometimes I even
have a second glass!!!

<snip>
> > easily - if I add a third mail server, I can simply attach it to my
> > autoresponder LMTP interface and we're off!
> 
> Okay, I now see where you are going with the SMTP (maybe LMTP)
> interface. But pipes don't exclude you from that either.  I am going
> to assume that your autoresponder extracts content from the e-mail -
> it would appear stupid to send an e-mail with that 1.5M word
> attachment over the network just to look at the "From" header.

Yeah, that is a real problem.  Even if I crop off and discard the body
on receipt at the autoresponder interface, that's still 1.5M of traffic
for nothing.

> A pipe interface would work better here.  The pipe command running on
> the SMTP server could just extract the information from the mail
> needed and just transmit that over the wire to your autoresponder
> daemon.

Maybe... I like this idea but things are starting to get complex.  I
might as well compress the system down to a central MySQL server and
have a pipe script on every server.  I lose my simple scalability.  But
yes, this would help with the memory efficiency problem.

There is an alternative system in postfix called policy hooks which I
might be able to use. Essentially you can define a policy daemon which
is passed a simple set of parameters about each email such as sender,
recipient, helo, client IP, etc.  Here's an example:-

request=smtpd_access_policy
protocol_state=RCPT
protocol_name=SMTP
helo_name=some.domain.tld
queue_id=8045F2AB23
sender=foo at bar.tld
recipient=bar at foo.tld
client_address=1.2.3.4
client_name=another.domain.tld
reverse_client_name=another.domain.tld
instance=123.456.7
sasl_method=plain
sasl_username=you
sasl_sender=
ccert_subject=solaris9.porcupine.org
ccert_issuer=Wietse Venema
ccert_fingerprint=C2:9D:F4:87:71:73:73:D9:18:E7:C2:F3:C1:DA:6E:04
size=12345
[empty line]

Notably no headers so I couldn't check for list headers, etc and would
be dependant on the addresses to filter out inappropriate replies.

Its most commonly used for greylisting where you can pass
back a policy decision on whether to process the email or not to the
MTA during the SMTP session and before the DATA stream (after RCPT TO
as you can see in the example above). Very useful but not really
designed for an autoresponder hook. However it would work I think.  If
the autoresponder always passed back a DUNNO response (which passes
filtering on to the next filter rather than OK which forces acceptance)
it wouldn't interfere with the rest of the SMTP transaction and would
have enough information to create an autoreply.

Its a possibility, but I'm not convinced it supplies enough info to be
completely useful... Its not really intended to do this.  But it would
get rid of the annoying duplication of mail.

> 
> But as you pointed out, you autoresponder is expected to have a low
> hit rate on e-mails that it should generate a response from.  Your
> SMTP/LMTP interface requires that *all* e-mails get transfered over
> the network (which maybe local to a single machine, but on on the
> scaled version).  This is not good system design.  You need to filter
> out as early as possible those e-mails that don't need responses.

Absolutely.

> 
> > > > 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.
> 
> As I have never used Postfix I can't comment on whether it's virtual
> domain support is better or worse that exim4.  I had a little problem
> configuring virtual domains to work - but that was my silly mistake.
>  

Don't know exim... had a brief flirtation with it on my way to postfix
from sendmail.  Its a good MTA.

<snip>
> I was not trying to get into a "mines better than yours" debate.  I'm
> just pointing out that using a different MTA may make the problem
> you're trying to solve easier.  Of course it may make other areas
> more difficult, so there is a balance to be found.

Apart from this one thing I'm very happy with Postfix.  Its fast,
secure, efficient, and _very_ configurable, _very_ easily.  The virtual
domain support is very good and very flexible BUT there is an annoying
glitch with the virtual MDA, as you've seen!

> > > > Since I'll probably be defining a second transport, my
<snip>
> > (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...
> 
> Okay, scalability is the one big advantage of the SMTP/LMTP interface.
> But you can't use it.  You're using PHP which doesn't scale because of
> the way it handles sockets sequentially.  As most *nix MTAs can handle
> multiple e-mail transports at a time to scale you're system you would
> have to have multiple autoresponders running to handle the load.
> 

It was only my hacked up implementation of the socket server that was
sequential :-( .   PHP tcp streams can quite happily run concurrently -
PHP has full support for functions like socket_select and if you
compile the PCNTL module you get signal handlers and fork() functions.
There's actually a Net_Server class in the PEAR repository which
automagically creates socket servers, (either sequential or concurrent
forked) with a few lines of code.  I don't really want to get into
forking new processes for this - don't think I need anything more
complicated than an array of sockets using socket_select to manage them.

<snip>
> > Supporting an SMTP interface doesn't equal autobloat!!
> 
> Yes it does, because of the extra complication of protocol which is
> designed to allow MTAs to accept/reject/defer e-mail deliveries.
> Your autoresponder only wants good e-mails, the pipe interface only
> gets good e-mails.  If the MTA rejects or defers the e-mail you're
> autoresponder never gets to see it.

For me, bloatware is stuffed with unnecessary features that are rarely
used.  Exchange running in an office of 10 people for example. Or even
Exchange just running!

;-)

I would be using the SMTP/LMTP interface with every transaction. But
yes, I don't need the full feature set of SMTP, which is where the idea
for using LMTP came from. Or a subset of SMTP, but that's a rather nasty
route - a broken implementation is more annoying than none at all!!

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/20050916/9ce8e53e/attachment.pgp 