Re: balsa no-thread crash detected

[Brian Stafford <brian stafford uklinux net>]

On Fri, 24 August 16:11 Timothy Alan Chandler wrote:
> On 2001.08.24 08:10 Brian Stafford wrote:
> 
> > QMTP and QMQP are very similar in their characteristics.  The differences
> > are more semantic than physical. Roughly, QMQP == SMTP on 587, QMTP ==
> > SMTP on 25.
> 
> Actually the standard TCP port for QMQP is 628 and for QMTP is 209, maybe
> we are talking about different things?

I was talking about equivalent functionality, not identity.  SMTP on 25 is for
mail transfer - equivalent to QMTP, SMTP on 587 is for mail submission
(see RFC 2476), roughly equivalent to QMQP.

> They are considered seperate protocols.  Last I checked QMTP was a scaled
> down version of SMTP with a small subset of commands that used netstring
> encoding, but I've never really used it so I'm not all that sure.

QMTP/QMQP are quite unlike SMTP except for their goal.

> IMHO QMQP is really nothing like SMTP, other than the fact that it's a mail
> transfer protocol.

Agreed.

>  It has no subset of commands.

Which cuts both ways.  QM[QT]P lacks flexibility because of this.  But
protocols with subcommands do not necessarily suffer because of this design
feature.  Poor implementations of any protocol, even QM[TQ]P, are crippling.

>  It's doesn't waste time
> looking at the message, it just injects the message into the queue.

Neither should SMTP.  RFC 2821 and RFC 821 before it explicitly prohibit an MTA
from examining or modifying a message, other than prepending it with a Received:
header.  Messages transferred with QM[TQ]P also have Received: headers
prepended.
That is basic MTA functionality to allow for message tracing.

Still, this normative requirement of the standard hasn't stopped sendmail etc.
exhibiting this non-compliant behaviour.  AFAIK, qmail does not piss about with
messages recieved over SMTP just as it doesn't with QM[TQ]P. Unlike sendmail!

>  It
> assumes the MUA is smart enough to build correct and complete messages and
> envelopes.

As does SMTP.  Remember the MTA is not allowed to examine or alter a message.
RFC 2476 relaxes this for the specific case of message submission from an MUA.
Even so, this processing if it happens at all will be performed after the
DATA transfer.  No impact on protocol performance.

> At any rate, I still don't see why balsa can't offer end users the ability
> to send mail using the protocol of there choice.  SMTP is not the only
> protocol available to send email, even if libESMTP proves to be the most
> efficient protocol by which to submit mail.  By not providing this choice,
> balsa may start alienating users and that's the last thing we want.

The only realistic choice of alternative mail transfer protocols is QM[TQ]P
and that is only implemented by qmail.  One assumes that since qmail implements
PIPELINING on SMTP and given D.J.Bernstein's opinions on protocol design, he
will have done a good job of implementing SMTP.  So in conjunction with qmail,
libESMTP should be comparable with QM[TQ]P.  It is certainly *much* better than
the libESMTP + sendmail combo.

Brian