Sam, > 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. OK. That's certainly a specific suggestion. Since this exchange is on the public list and since I do not track the fine-grained details of which security algorithms are currently viewed as safe, could you summarize the current state of use and safety (or lack of either) cram-md5. I press for this because I recall some recent stuff about algorithms that have long-term exposures, but not much near-term, practical weakness. > 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. Indeed it is. And I certainly hope my response did not imply otherwise. Rather it was merely seeking to make clear that the document did have quite a bit of broad-based email operations input in its formulation. As we have all seen, there are jillions of clever people, with many more jillions of clever ideas and even more theoretically reasonable ways to resolve issues with those ideas. So my point was that this was very much NOT produced by the whim of yet-another individual clever writer, instead being driven by a diverse group which, in turn, is entirely driven by operational pragmatics. > 1) What the implications of treating out-of-network mail injection as > submission are. Unfortunately, you are asking an entirely open-ended question and I do not know what "implications" you are looking for. What I DO know is that, indeed, we are documenting a common, current practise and that it works well. I can't say that I have heard of any negatives about it, but I don't do line ops so I will leave it to others to cite any real-world problems that are created. I DO know what happens when there is unauthenticated relaying that originates from outside one's network. What happens is that you get blacklisted. It is, after all, what the term "open relay" refers to and what is so popular with mass spammers. > In particular, what would be the difference > between treating this as submission and treating it as relaying > with a requirement for authentication/authorization? The major difference is accountability. When a message is treated as a submission, then the submission agent (MSA) is able to take a reasonable degree of responsibility for the (new) message. For simple relaying, such accountability is essentially impossible. > 2) Why is this the right course for the Internet? See discussion of open relaying, above. If the problem with open relays needs more discussion, please let us know. Simply put, the open Internet's email infrastructure is under attack. The postal mail global infrastructure, and all of the large-scale services that do global transfers, are subject to a high degree of accountability for their activities and they have a significant degree of control they impose at their boundaries. By contrast, Internet mail is entirely open, with no trusted core. The (unfortunately predictable) development of abuses of this service are requiring development of practises that tighten things up. The challenge is to do this in a way that does not create some sort of centralized control. The current document specifies a fairly modest set of steps to increase the legitimate accountability of services that are injecting mail into the open Internet. And, to repeat: it is based on a set of relatively common practises that are intentionally chosen for their lack of controversy in the email operations community. d/ d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf