Re: bug with the Message-ID ?



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]