3 ms·

You're extracting one sentence out of several paragraphs. The following paragraph restricts the permissible rewriting, and Google is going beyond what is permi

You're extracting one sentence out of several paragraphs. The following paragraph restricts the permissible rewriting, and Google is going beyond what is permitted. If your interpretation differs from mine, that's fine. I don't think you need to support your view by selective quotations and accusing me of not being aware of what I explicitly dealt with. The meaning of the whole section is clear, and I stand behind what I wrote.

ebikelaw 9y ago
Again, the only thing that seems clear here is that you don't know how to read an RFC. The only "must not" in 8.8 is the prohibition of changing the destination local parts. "must not" appears nowhere else in section 8, and 8 is not strongly prescriptive as it "describes a number of such modifications that are often considered useful". The described modifications are not thought to be exhaustive. Moreover, 5321 describes MSA as "arrangements are private and fall outside the scope of this specification, they are not described here." 5321 does not control MSA and 4409/6409 do not defer to 5321 on any point. 4409/6490 do _refer_ to 5321, of course. There are only 5 MUST NOTs in 6409 and there are zero SHOULD NOTs. The standard permits the MSA to do pretty much anything it wants to do. I think you should begin by reading 2119 "Key words for use in RFCs to Indicate Requirement Levels".
- leephillips 9y ago
  'The only "must not" in 8.8 is the prohibition of changing the destination local parts.' That's not even true. If anyone cares about this they should just read the texts. I'm certainly not going to argue this any further. We're looking at the same page and seeing different words. It actually says this: "However, only addresses, local-parts, or domains that match specific local MSA configuration settings should be altered" In other words, the opposite of what you claim. You can keep banging on this if you find it useful, but I'm not going to read any more of your comments.
  - cortesoft 9y ago
    "should be" is not the same as "must be"
  - frankchn 9y ago
    According to RFC2119, which defines these terms, "should" and "should not" are recommendations with the caveat that individuals not following said recommendations need to understand the full implications what they are doing. On the other hand, the words "must" and "must not" specify absolute requirements and prohibitions of the standard, respectively.
    - shkkmo 9y ago
      I think the confusion comes from parsing the poorly worded "only X should be altered" which doesn't really make it clear how the "should" applies. The clear wording would be "... should only alter X" which makes it clear that altering things other than X needs be be done with full understanding of the implications.
  - deleted 9y ago
    [deleted]
  - sanderjd 9y ago
    I know nothing about these RFCs, but this seems trivial to clear up with a reference to the text. Here's RFC6409 section 8.8: https://tools.ietf.org/html/rfc6409#section-8.8 https://tools.ietf.org/html/rfc6409#section-8.8. There is exactly one "MUST NOT" and it looks like it only prohibits what your parent said it does.
    - leephillips 9y ago
      There seems to be an idea floating around that anything at all is permitted under the RFC for MSAs unless it is specifically prohibited using the phrase "must not", regardless of context and other guidance in this RFP and the other RFPs that refer to it. Perhaps this is true. I have a sincere question for anyone holding this opinion: would Google be in compliance if their software altered the message body by adding the sentence "Google is the best search engine ever." here and there, at random? If not, why not, exactly?

ebikelaw 9y ago

Again, the only thing that seems clear here is that you don't know how to read an RFC. The only "must not" in 8.8 is the prohibition of changing the destination local parts. "must not" appears nowhere else in section 8, and 8 is not strongly prescriptive as it "describes a number of such modifications that are often considered useful". The described modifications are not thought to be exhaustive. Moreover, 5321 describes MSA as "arrangements are private and fall outside the scope of this specification, they are not described here." 5321 does not control MSA and 4409/6409 do not defer to 5321 on any point. 4409/6490 do _refer_ to 5321, of course. There are only 5 MUST NOTs in 6409 and there are zero SHOULD NOTs. The standard permits the MSA to do pretty much anything it wants to do. I think you should begin by reading 2119 "Key words for use in RFCs to Indicate Requirement Levels".

leephillips 9y ago
'The only "must not" in 8.8 is the prohibition of changing the destination local parts.' That's not even true. If anyone cares about this they should just read the texts. I'm certainly not going to argue this any further. We're looking at the same page and seeing different words. It actually says this: "However, only addresses, local-parts, or domains that match specific local MSA configuration settings should be altered" In other words, the opposite of what you claim. You can keep banging on this if you find it useful, but I'm not going to read any more of your comments.
- cortesoft 9y ago
  "should be" is not the same as "must be"
- frankchn 9y ago
  According to RFC2119, which defines these terms, "should" and "should not" are recommendations with the caveat that individuals not following said recommendations need to understand the full implications what they are doing. On the other hand, the words "must" and "must not" specify absolute requirements and prohibitions of the standard, respectively.
  - shkkmo 9y ago
    I think the confusion comes from parsing the poorly worded "only X should be altered" which doesn't really make it clear how the "should" applies. The clear wording would be "... should only alter X" which makes it clear that altering things other than X needs be be done with full understanding of the implications.
- deleted 9y ago
  [deleted]
- sanderjd 9y ago
  I know nothing about these RFCs, but this seems trivial to clear up with a reference to the text. Here's RFC6409 section 8.8: https://tools.ietf.org/html/rfc6409#section-8.8 https://tools.ietf.org/html/rfc6409#section-8.8. There is exactly one "MUST NOT" and it looks like it only prohibits what your parent said it does.
  - leephillips 9y ago
    There seems to be an idea floating around that anything at all is permitted under the RFC for MSAs unless it is specifically prohibited using the phrase "must not", regardless of context and other guidance in this RFP and the other RFPs that refer to it. Perhaps this is true. I have a sincere question for anyone holding this opinion: would Google be in compliance if their software altered the message body by adding the sentence "Google is the best search engine ever." here and there, at random? If not, why not, exactly?