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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf