Relabeling the subject because it distracts from the actual discussion.
On Fri, 07 Sep 2001, Peter van Dijk wrote:
> The not being able to bounce it may be a bug, but most definitely not
> in qmail-qmqpd.
Well, qmail takes in mail it cannot always deliver. The system as a hole
may throw away mail. That's a bug no matter where. I consider
qmail-qmqpd to be correct as well, qmail-send or -remote need support
for this particular problem however.
> > On a related issue, qmqp is not faster than smtp. SMTP must be
> > implemented anyhow, two competing protocols just make the testing less
> > thorough.
>
> You are confused. QMQP and SMTP serve different purposes.
No, they share the purpose "local mail injection".
> Furthermore, what makes you think QMQP is not faster than SMTP?
Benchmarks. QMQP vs. SMTP made no difference on a K6-2/300 running
FreeBSD 4.x (The limiting factor is qmail's ineffective queue design,
combined with the unability to use good file systems such as softupdates
ffs or Linux' ext3 or reiserfs which would boost throughput of incoming
mail by a factor of 2 roughly).
In fact, QMQP has more shortcomings: It either requires seekable input
or big buffers -> causes latency.
> > And that's what you get for ignoring RFC-1894 and 2045..2049 for your
> > bounces, they also fail.
>
> I fail to see how supporting such broken standards as DSN and MIME
> would have solved this problem.
MIME allows you to send objects that don't have a finishing LF.
It suffices to send RFC-1894 compliant bounces, that ends up being a
static template just like QSBMF, with the difference that more clients
can handle it.
> Ouch. I actually helped a customer today by making sure a sendmail box
> *wouldn't* encode valid 8bit data into base64. Mailservers shouldn't
> encode, that's the MUA's job.
You can choose to bounce, but you cannot bounce because the trailing LF
is still missing.
I don't know of a single MUA that talks QMQP.
> > There is no way QSMBF can handle truncated final lines across SMTP
> > transports. RFC-1894 can handle that.
>
> So fix QSMBF. Adopting a completely broken standard just because the
> current standard has a flaw is overkill.
It's egocentric to expect all the world to support the proprietary
bounce format of a proprietary, non-open-source qmail-send. You won't
get anywhere, people with rather stick to inefficient VERP
implementations like qmail's.
Bouncing in RFC-1894 format however has MUA support in that the MUA (at
least, recent mutt versions can do it) can extract the failed message
and resend it after edit. You can't do so with QSBMF.
Plus, QSBMF cannot reliably be distinguished from regular non-bounce mail.
> > Time for qmail-1.04, here's the suggested fix. It will change the bounce
> > message, but we must do so to get the mail through SMTP.
>
> A small price to pay, I'd say. Nothing dictates that bounce messages
> should include the original message completely.
Well, you falsify if you add to it. If qmail wrote "possibly modified
copy of..." then that'd be OK.
Matthias
