On Sat, 08 Sep 2001, I wrote:
> > False. qmail-send creates a bounce message in the extended format only
> > if the original message was in the extended format.
>
> So it does, and my claim is not "false". qmail cannot reliably bounce
> "extended format" (whatever that is), that's a fact you acknowledged.
> That IS a reliability problem no matter what YOU call it.
Let's revisit the issue. Since it's not a common problem one will
encounter, it deserves a _simple_ fix.
Facts (none of that is new, and they may be incomplete):
- It's not qmail-send's fault someone sent "extended format" in.
- It's qmail-qmqpd's purpose to take arbitrary data in.
- The set of delivery backends that qmail-send can choose from is limited to
the local delivery agent and the qmail-remote SMTP client. Neither is
able to transfer "extended format" under all circumstances:
- qmail-remote can only send ASCII, possibly extended by 0x80...0xff,
and requires a CRLF terminated mail with constraints on the line
format (length in particular).
- qmail-local cannot deliver unterminated mail to mbox format spools.
- qmail-local cannot deliver mail that contains (regexp) "^From " to
mbox format spools.
I assume that "extended format" still requires RFC-822 headers.
Here's my suggestion:
* Strip the mail _body_ from the undeliverable bounce when copying it
into the doublebounce.
Reasons:
1/ Under the assumption (1), the double bounce will be deliverable
across SMTP.
2/ The double bounce defaults to postmaster who has no business with
getting the users' mail bodies.
3/ Since the bounce format is fixed, stripping the mail body can be done
safely.
Consequences:
- Postmaster (or whoever is configured) is immediately notified of the
failed mail + bounce.
- The doublebounce recipient no longer sees private user mail bodies.
- Mail need no longer be discarded because the doublebounce will be
deliverable locally to mbox and across SMTP links.
Comments solicited.
