>>>>> "Dave" == Dave Crocker <dhc2@xxxxxxxxxxxx> writes:
Dave> Sam,
>> First, in section 5, please do not list cram-md5 as a secure
>> authentication technology. Today I think we'd require a
>> security layer from a SASL mechanism to consider it secure.
>> Also cram-md5 suffers from other defects.
Dave> 1. You mean that MD5 is not a common, current practise that
Dave> provides a useful degree of security?
No.
Dave> 2. Taking note of the exact language used in the sentence
Dave> citing MD5 -- specifically the "may be sufficient", please
Dave> supply alternative language.
That sentence recommends both cram-md5 and digest-md5. I think
digest-md5 is fine; I think cram-md5 is not. I'd like to ask that you
simply drop the word cram-md5 and appropriate conjunctions.
>> o Mail coming from outside an email operator's local
>> environment, and having a RCPT-TO address that resolves to a
>> destination that is also outside the local environment, MUST be
>> treated as mail submission, rather than mail relaying...
Dave> ....
>> The good part of this requirement seems to be to subject such
>> mail to authorization (and in many cases authentication).
>> However I think that saying mail must be treated as submission
>> rather than relaying may have effects significantly beyond
>> authorization/authentication. For example MSAs are given
>> significant freedom to modify submitted
Dave> That's right.
Dave> The implications you are drawing are exactly what is
Dave> intended. When the document said "treat as a submission" it
Dave> meant exactly that.
Dave> In other words, if you are coming from outside the network,
Dave> you do not get to "relay" through the network. You can
Dave> post/submit from within, you can deliver into the net or you
Dave> can post/submit from outside.
>> email--appending disclaimors and doing all sorts of things.
>> I'm not convinced such is appropriate in this instance.
Dave> Well, it certainly is a point that one could imagine
Dave> deciding in either direction, in the abstract.
Dave> So, yes, it is important that the folks who have been
Dave> working on this document, and contributing to discussions
Dave> about it, have extensive operations experience and made the
Dave> choice intentionally.
As you are no doubt aware, this document is an individual submission
for a category requiring IETF consensus. It's perfectly reasonable
for experts in operating the mail system to propose this initial
position. It's also reasonable for members of the community
(including myself) to ask those experts to justify their position.
Ultimately, the AD sponsoring this individual document will need to
determine what the informed community consensus is.
I'm asking for that review. I'd like to know:
1) What the implications of treating out-of-network mail injection as
submission are. In particular, what would be the difference
between treating this as submission and treating it as relaying
with a requirement for authentication/authorization?
2) Why is this the right course for the Internet?
As you are aware, 2119 musts are fairly strong; we use them only when
we have sufficient security, operational or interoperability reasons
to do so. It's not obvious to me what the operational justification
of this must is. Fortunately, since the issue has been discussed by a
group of experts, it is obvious to someone and they can tell us all.
Thanks,
--Sam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf