Re: Policy question
** Proposal at the end!
jgoerzen@complete.org (John Goerzen) wrote on 04.02.99 in <[🔎] 19990204114709.B818@complete.org>:
> On Thu, Feb 04, 1999 at 02:07:19PM +0000, Ian Jackson wrote:
>
> > > "most" isn't good enough here. I know from past experience :-)
> >
> > Do you mean the local mail server on a Debian system ? Do we have any
> > MTAs that don't support 8BITMIME ? You could always just tell people
>
> Yes, but unfortunately the bug report listing the specific one has long
> since expired, but here's the changelog:
>
> elm-me+ (2.4pl25ME+39-1) unstable; urgency=low
>
> * New upstream release. Various small bugfixes and Y2K compliance
> updates. See the upstream changelog for details.
> * Updated FTP site in copyright file
> * No longer uses 8BITMIME or BINARYMIME options. It seems that some
> non-sendmail mailers aren't up-to-date enough to handle them, which
> isn't really Elm's fault, but to be compatible with those mailers,
> I have turned off the passing of -B8BITMIME or -BBINARYMIME to mailers.
> Elm now does those conversions internally. This closes bug
> #17103.
Actually, this points out a serious misunderstanding:
There is a RFC for ESMTP 8BITMIME. (Incidentally, that one is an option,
and SMTP clients are *required* to cope with its absence, which can easily
be detected.)
Sendmail has (I gather, I've not actually seen it) a command line option -
B8BITMIME. This must have happened recently; actually, I have never seen
any documentation for it. Aside from that, I believe this is a very silly
"solution"[1]; anyway, I don't know of *any* non-sendmail mailer that
implements it.
The two obviously are only very loosely related. Elm was using the latter.
Elm *also* failed to detect when /usr/sbin/sendmail terminated with an
error because of an unknown command line option; instead of saving the
unsendable mail in, say, dead.letter, it just threw it away. I was bitten
repeatedly by that bug. From looking at the changelog, it seems that this
serious bug WAS NOT fixed.
As for BINARYMIME, I consider using that at this time a bug. While a
growing number of MTAs supports the 8BITMIME ESMTP extension, so you have
at least a chance of it working, I have not yet seen any support
BINARYMIME. Still, I won't recommend using 8BITMIME, and I consider
defaulting to it a serious bug. At the very least, it should be
configurable, preferrably per-recipient and per-message.
Furthermore, BINARYMIME (RFC 1830) is "experimental". 8BITMIME (RFC 1652)
is "draft standard".
I consider the previous state of Elm seriously broken by design. I'm not
so sure about the current state, either.
> > not to run such a braindead MTA.
s/braindead MTA/braindead MUA/.
> I think it does a disservice to people if Debian's default mail reader does
> not work with Debian's mail servers.
Indeed.
[1] IMHO, the correct solution is for the MTA to check if A. the message
calls for Content-Transfer-Encoding: 8bit, binary, or other, and B. if any
char in the 0x80-0xff range is present in the message. Then
A: 8bit binary other
B:yes 8BITMIME reject reject
B:no normal reject normal
However, I know of no MTA to actually implement this, either.
Maybe we should work on a description of the interface to
/usr/sbin/sendmail that is to be guaranteed by all MTAs? The LSB people
would probably like to get that, too. And maybe also authors of MTAs
(other than sendmail) and MUAs.
MfG Kai
Reply to: