Re: bug with the Message-ID ?
- From: Brian Stafford <brian stafford uklinux net>
- To: "M. Thielker" <balsa t-data com>
- Cc: Balsa List <balsa-list gnome org>
- Subject: Re: bug with the Message-ID ?
- Date: Mon, 3 Dec 2001 14:41:52 +0000
On Mon, 3 December 13:37 M. Thielker wrote:
> Hi Brian,
>
> well, people may think you're dogmatic, or just read an RFC and started
> programming... I don't. I know, having had to do some mods to an MTA in the
> past, how quirky internat mail can be and how many things must be taken into
> consideration.
Indeed and this is partly why drums was so controversial.
> However, my ultimate aim in supporting and developing free software is to
> contribute to the great goal of _replacing_ Windows as the most common
> desktop environment.
A worthy goal. Mine is more modest - a robust SMTP client. Unfortunately,
the client cannot make up for errors in the server, though not many people
understand that.
> For that goal to be attainable, Linux software _must_ work in real world
> situations. CIS is one of the worlds biggest providers, not someone you can
> ignore with impunity.
I would be more inclined to accept this, except that libESMTP has been in
Balsa for about 10 months or thereabouts and only now has this come up. Most
of the bug reports I get are to do with portability and since I made libESMTP
compile with "gcc -ansi -pedantic" virtually all those bug reports have
stopped. Interoperability issues are rarely reported to me. So either nobody
uses the Balsa+libESMTP combo or the numbers of Balsa users on CIS aren't that
great. Anyway since I very rarely get interoperability problems reported, I
hope you appreciate my reluctance to break conformance with standards. OTOH,
if my code does not conform, it will be fixed post haste.
> As more people start to migrate to Linux, more people will run afoul of this
> problem. But I know the people at CIS, they're _not_ about to change
> anything. So, the choice really boils down to this: permit a deviation from
> the standard, or exclude possibly millions of users. The former is a
> BadThing, but the latter in _unacceptable_, IMHO.
Hmmm, AOL tried to enforce their own version of HTTP on the world a year or
two ago. Backlash from Apache developers amongst others made them
reconsider. Perhaps the mail community should start petitioning CIS to
conform to standards.
> Microsoft, who spends more than out combined life's earnings per year on
> specialists for GUI development doesn't think that configuration options
> that allow communication with systems that ignore standards are so bad, they
> just place a waring sign there or hide them behind "advanced..." or
> "troubleshooting..." buttons.
Maybe - but I am still very wary of letting users configure out compliance.
> I strongly recommend against having options that need to be edited manually
> because the typical CIS user is scared of a text editor. So it must be in
> the GUI.
Fair enough.
> Microsoft hides these things behind pseudo-protocols. So, they have SMTP and
> they have CIS protocols, where CIS is actually SMTP, but without some
> headers. We could use the same trick to insure that this option would only
> be used to connect to CIS because that typical CIS user doesn't know what
> the difference is, and seeing CIS mail as a protocol, will choose it because
> that is what he wants to use.
> All others may or may not know what CIS is, but will choose SMTP because
> that's what they want to use.
One possible approach.
Another thought, how does conpuserve.de sign on if you "telnet compuserve.de
25" and issue the "ehlo domainname" command. Their publicly referenced server
responds
$ telnet mx.compuserve.de 25
Trying 62.52.27.100...
Connected to mx.compuserve.de.
Escape character is '^]'.
220 Compuserve Office Mail Service (desws061) ESMTP
ehlo compuserve.de
250-Compuserve Office Mail Service (desws061)
250-PIPELINING
250-AUTH=LOGIN PLAIN
250 8BITMIME
which isn't conformant (surprise) - EHLO should respond with a domainname in
the first response line. That will play merry hell with clients that parse
that line. Also the line that reads
250-AUTH=LOGIN PLAIN
is wrong, the '=' should not be present. That was in an early internet draft
and you are not supposed to deploy software based on drafts, i.e. wait for the
RFC.
Anyway, maybe if EHLO responds with "(desws061)" in the first response, auto
deletion of troublesome headers could be enabled. But even if I implement
this, I would add a --enable- option to the configure script and it would
always be off by default - I don't want to make this sort of thing easy.
> If the WIndows monopoly is to be broken, we need to think as users would,
> not as programmers do.
Indeed. And this is why I consider that standards are so important. When
everyone conforms all those niggling little things that need to be manually
configured by confused punters simply just go away.
I'm half inclined to advise CIS users to get a Yahoo! account. Nothing much
special about Yahoo! except that at least they use qmail which works - qmail's
author is even more pedantic about standards than I am. (Qmail even sends
nasty bounce messages back to hosts that send messages with '\n' line endings
instead of the canonic CRLF).
--
BCS
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]