On May 7, 2013, at 1:08 AM, SM <sm(_at_)resistor(_dot_)net> wrote:
At 13:23 06-05-2013, Brian E Carpenter wrote:
I don't that is quite right. The problem in this case is not to do
with linguistic quality. It's due to a lack of formal verification
Quoting from the detective story:
"At [censored] we have changed our mail server configuration in the past few
months, and are now using a mail server from [censored] namely the
[censored] Server."
There isn't any mention of whether the mail server was tested.
I don't know why you censored this, but that particular implementation is used
by a vast majority of corporations. The one good thing about running with the
crowd is that stuff pretty much just works. And it does, unless you do
<heresy> something weird like enabling IPv6 </heresy>.
"Seemingly at random my efforts to send mail just fail."
There would likely be an error code with text providing an explanation. I
would probably follow a different debugging path. Anyway, the session showed:
"EHLO [IPv6:2001:df9::4015:1430:8367:2073:5d0]
501 5.5.4 Invalid domain name"
Yeah, I would also start with the tcpdump. But that part of the story sounded
bogus. 2nd paragraph has this:
To collect my mail I use IMAP, and to
send my mail I use
STMP, both standard protocols. These days security can’t be ignored so we
use TLS for channel
encryption. All pretty standard stuff.
So how did he get to see the server response, or test with telnet?
This is where I go and read RFC 6409 and I find that:
"The MSA SHOULD log message errors, especially apparent
misconfigurations of client software."
And then follow up with RFC 5321 where I find a mention of address literals.
I go and read RFC 4291 which is a Draft Standard. I see an update in RFC
5952 which is a Proposed Standard. As I was told that the Internet runs on
Proposed Standards that update must be right. I see the following:
"The recommendation in this section SHOULD be followed by systems
when generating an address to be represented as text, but all
implementations MUST accept and be able to handle any legitimate
[RFC4291] format."
Gee, you read a lot of RFCs when debugging network problems :-). I only do so
if I'm going to file a bug report / support ticket
Back to the detective story:
"The writing if RFC5952 is incredibly sloppy for a Proposed Standard"
I look at the write-up:
"The 6MAN working group reviewed and discussed this document several
times. There is a strong consensus to move this forward."
"This document has been reviewed by key members of the 6MAN working
group and the chairs."
I look at the IESG evaluation and I see:
"Language & grammar are rough."
Between you and me, these Area Directors are trouble-makers. :-)
So they are. But the hard-to-read parts of this spec are mainly the
motivational sections (everything but 4). It might have been clearer to state
again that the whole point of this spec is "conservative in what you send".
Liberal in what you accept is mentioned in the first paragraph of section 4.
I verify compliance (2010), RFC 2821, RFC 4409; there isn't any mention of
the IPv6 specifications mentioned in the detective story.
There are people out there who have to fix problems like this. There are
people out there who have to read those specifications and figure out where
is the head and where is the tail.
Yup. That's why those people get the big bucks.
Regards,
-sm