Single linefeeds in OS/2-Sendmail ?
Jonathan de Boyne Pollard
MF> to remote sendmail servers.
One instance of "sendmail" (unwisely) accommodating the protocol errors made
by another instance of "sendmail" is not grounds for terming a different MTS
"picky".
Jonathan de Boyne Pollard
Your humble opinion is wrong. Checking for and rejecting
protocol errors is in general rarely worse than heuristically
trying to convert erroneous data into non-erroneous data,
and isn't in this particular case. "Auto-correcting" heuristics
have the propensity of introducing many more new problems, and
also serve to increase the number of faulty implementations by
removing the negative feedback mechanisms that would otherwise
weed them out.
BM> From RFC1123 (which I am sure he is quite familiar with):
BM> 1.2.2 Robustness Principle
BM> [...]
Gresham's Law trumps Postel's Principle, and the explicit
requirements in the RFCs prohibit an SMTP Relay server from
behaving as you imply it should.
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/qmail-myths-dispelled.html#MythAboutBareLFs>
BM> Writing buggy software can to some extent be excused, but writing
BM> and using software that deliberately causes interoperability
BM> problems, like qmail, is just plain stupid.
The cause of the interoperability problems is the clients that don't
speak the protocol correctly, not the server that requires that the
protocol be spoken correctly.
Mark Crispin
> Checking for and rejecting
> protocol errors is in general rarely worse than heuristically
> trying to convert erroneous data into non-erroneous data
Truer words are rarely spoken.
I have fought against sendmail's deplorable practice of "fixing" perfectly
good headers into garbage for 20 years.
> Gresham's Law trumps Postel's Principle, and the explicit
> requirements in the RFCs prohibit an SMTP Relay server from
> behaving as you imply it should.
Actually, Postel's principle is misstated. I knew Jon personally. He
*never* advocated forcing implementations to accept bogus protocol, and it
is a perverson of Jon's legacy to claim otherwise.
"Be liberal in what you accept" referred to accepting a wide range of
valid protocol, as opposed to accepting only the most common form. If you
consider the early protocols, such as Telnet and FTP, it was all too easy
to create two compliant and non-interoperable implementations due to each
implementation choosing a different subset.
Modern protocol design pays much more attention to guaranteeing
interoperability in the minimum implementation, and this is less of an
issue than it was in the 1970s.
> BM> Writing buggy software can to some extent be excused, but writing
> BM> and using software that deliberately causes interoperability
> BM> problems, like qmail, is just plain stupid.
> The cause of the interoperability problems is the clients that don't
> speak the protocol correctly, not the server that requires that the
> protocol be spoken correctly.
Indeed. As the author of the TOPS-20 SMTP server, which has always
insisted upon CRLF newline as the one true newline, I have been pleased to
discover that the TOPS-20 server is non-interoperable with the SMTP
engines in popular spamware.
The only negative thing about qmail insisting upon proper CRLF newlines is
that the spammers may fix their SMTP engines and thus this natural
immunity to spam will become less potent over time.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Jonathan de Boyne Pollard
MC> Actually, Postel's principle is misstated. I knew Jon
MC> personally. He *never* advocated forcing implementations
MC> to accept bogus protocol, and it is a perverson of Jon's
MC> legacy to claim otherwise.
MC>
MC> "Be liberal in what you accept" referred to accepting a
MC> wide range of valid protocol, as opposed to accepting only
MC> the most common form. [...]
Well, if "be liberal in what you accept" _is_ a mis-statement of his
principle, then he himself - as the editor of RFC 793 where those are the very
words - was responsible for that. And I've read other people claiming that
they spoke to him about RFC 791 and RFC 1122 and that he was actually quite
happy with the various wordings. So I'm not entirely convinced that that
wording _is_ a mis-statement of his principle.
Of course, even if it isn't a mis-statement, that doesn't mean that it
supports the contention that an SMTP Relay server should recognize bare
linefeeds as line terminators. (And it would certainly be good to say that it
actually didn't.) It all depends from what his definition of being "liberal"
actually was. If being liberal was intended to only extend only up to and no
further than the boundary of validity, then its use to support the contention
is, indeed, a perversion of the principle.
It's a pity that there's little to no explanation of the principle next to
where it is stated in the RFCs.
MC> The only negative thing about qmail insisting upon proper CRLF
MC> newlines is that the spammers may fix their SMTP engines and
MC> thus this natural immunity to spam will become less potent over
MC> time.
Ah well. No technical defence mechanism against unsolicited bulk mail that
relies upon an incidental, that is unrelated to the "unsolicited" and "bulk"
qualities of the mail, remains effective forever.