On May 7, 2013, at 1:08 AM, SM <sm@xxxxxxxxxxxx> 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