[resending to list]
On Fri, 10 Oct 2003, Eric S. Raymond wrote:
And, unless the "mda" option is fixed by the time, also:
* refuse the mda option for multidrop configurations unless it contains
the substring "sendmail"
* refuse the mda option always if it contains the substrings "sendmail"
and "-t".
The last two are meant to avoid mail loops by some ignorant trying to
inject into sendmail in "parse-headers-for-addresses" mode (-t), which
must not happen.
Your intentions are good, but I find this proposal intolerably ugly.
I will document the fact that the mda must accept multiple addresses.
Thesis first: It is of PARAMOUNT importance to PREVENT To:/Cc: guessing
and reinjection into software that parses headers such as sendmail -t.
The only software that may parse the header is the injecting agent
(sendmail -oi -t) which fetchmail will NEVER be. Any other software
parsing headers for recipients is fundamentally broken. We're
discouraging sendmail -t, but not enforcing this.
Some points worth recalling:
* All traditional MDAs (deliver, procmail) and modern MDAs (maildrop)
take at most one recipient. Running an MDA for some other recipient
also needs root privileges.
* "Multidrop" requires that either
- a protocol preserving the envelope be used (ODMR), or
- the upstream saves one copy of the mail per recipient.
Note: any "bandwidth compression" CAN NOT work with mail retrieval
protocols such as POP3 or IMAP because the envelope is unavailable
separately.
Delivered-To:, X-Envelope-To: or X-Original-To: headers aren't useful
- IF they'd list multiple recipients (which they don't do), they
defeat Bcc:.
NOTE: this effectively means that the common POP3 "multidrop" will be
"singledrop with variable recipient".
* If we however have a reliable way to retrieve the envelope and still
have multiple recipients (ODMR perhaps?), we must run the MDA once
for each recipient, requires root privileges.
* If we want the previous option as unprivileged user, we indeed need a
command that takes multiple recipients, but IT MUST TAKE THESE FROM
COMMAND LINE. Specifically, we must disallow sendmail -t,
qmail-inject -h, qmail-inject -H (and I'd have to check what we must
disallow about nullmailer).
I'd suggest that we ask an "MTA" option instead, to distinguish it
from the "MDA" option. MDA will be single-recipient.
Going one or two steps back, we're having these configuration options:
- singledrop. works with all protocols, mda works.
- multidrop with one-copy-per-recipient in the mail box. works with all
protocols when envelope is found, mda works. (because it's still
single-recipient). This is always the case when the upstream uses
qmail to deliver to mailboxes, as qmail will always split mail so it
contains only one recipient.
- multi-recipient-multidrop. works only with protocols that preserve
envelope information outside the header, such as ODMR.
* either use an MTA (but avoid sendmail -t as above) or SMTP
* or have root privileges and iterate over recipients, i. e. if we
have three recipients joe john and foo, we'll need three forks and
run $MDA -d joe, then $MDA -d john, then $MDA -d foo.
I am totally ignorant about LMTP and how it treats multi-RCPT.
I'd also like to discourage injecting into custom programs such as
qmail-inject, because qmail _has_ a "good enough" /usr/sbin/sendmail.
That's useful to know.
I wonder what makes people recommend qmail-inject in the first place.
It serves no _useful_ purpose and takes up the user's time, unnecessarily.
Qmail's sendmail wrapper execv()'s qmail-inject, without tampering with
the environment, so any qmail-inject environment-variable configured
features are exposed by sendmail as well - some of which we have found
to be disastrous (QMAILINJECT=i) and which we now disallow for safety.
The switch to qmail-inject - to me - only serves the purposes:
* make the user feel as though qmail was something special
(it is not, other than specially broken and unmaintained,
http://mandree.home.pages.de/qmail-bugs.html)
* lock the user in, by making all his applications fail if he chooses
to deinstall qmail.
After all that, the bouncing needs to be cleaned up. Only sendmail
really supports -oem, other MTAs (Postfix, qmail) won't support that
option and expect the software that calls "sendmail" to handle a failure
instead.
Best regards,
Matthias