2001-01-14-20:25:41 Wietse Venema:
> Bennett Todd:
> > > If I can make the time I can write a posting agent that uses SMTP
> > > where possible, and that falls badk to /usr/sbin/sendmail style
> > > submission when Postfix is down.
> >
> > How about this one:
> >
> > #!/bin/sh -e
> > tmp=/tmp/`basename $0`.$$
> > trap "rm -rf $tmp" 0
> > umask 077
> > mkdir $tmp
> > cat >$tmp/msg
> > mini_sendmail "$" <$tmp || sendmail "$" <$tmp
>
> This discussion is about speed, so I'll ignore the lack of error
> checking.

I thought I checked for all errors!

> But it is a serious lack.

It certainly would be.

> With the above scheme, mail is lost when /tmp runs out of space.

In that case, I'd look for a cat(1) that correctly reports write
errors. I didn't realize it was normal for cat to fail to do so.

Unless I'm badly off somewhere, a /bin/sh script with "-e" won't
succeed unless every command (or chain, in the case of "||" and
suchlike) succeeds.

> The best-case performance of the above method approximates that
> of the existing /usr/sbin/sendmail submission method. [...] The
> difference is that your intermediate file does not have to be
> fsync()ed like a Postfix queue file.

I'd expect that to normally make all the difference in the world; I
don't expect writes of short files to /tmp, immediately followed by
reads and deletes, to ever have to touch disk.

> At least, that is the case on systems that don't cheat. I
> have this US$500 E-machines tower with a disk drive that can
> create/delete 1000 files a second and I don't believe that is
> possible without buffering all the writes in non-volatile cache
> memory.

As the entire script gets to report error if something goes wrong in
the middle, I think this sort of cheating is fine and appropriate.

> My hack would read the message into memory up to some upper limit
> (configurable, of course; I was thinking of 100kbytes). Mail
> smaller than the upper limit would be sent into Postfix via SMTP.
> If the mail is larger than the upper bound, or if SMTP submission
> failed for whatever reason, then /usr/sbin/sendmail would write
> the message to postfix/maildrop as usual.

That could buy the performance of the above script even on systems
that insist on touching down to disk for short transient visitors to
/tmp. In the interests of portable speed, that'd certainly be nice.

Hmm. Hmm. I just got another idea. Lessee... if mini_sendmail were
changed to establish a successful smtp connection or exit with
nonzero status before attempting to read anything from stdin ---
i.e. hoist the setup through HELO up to the front --- then a
sendmail replacement coded

        #!/bin/sh -e
        mini_sendmail "$" || sendmail "$"

would actually do even nicer, at least for many purposes:
it'd accept and deliver the mail with zero exit status (i.e.
successfully) delivering using SMTP --- no matter how large the
message --- if it were available, and sendmail if it weren't; and
it'd only screw up wickedly if the smtp dialogue failed in the
middle. Of course that circumstance is the nastiest of them all, and
is the one that requires buffering to deal with.

-Bennett

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6YlnKHZWg9mCTffwRAqLlAKCUeEx8zRJnporaHsVGDB8Z90hmbgCgoOY9
vBCoCq0QHiX0HPX3jUtUrV0=
=aQ0Y
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]