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.
1. You mean that MD5 is not a common, current practise that provides a useful
degree of security?
2. Taking note of the exact language used in the sentence citing MD5 --
specifically the "may be sufficient", please supply alternative language.
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...
....
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
That's right.
The implications you are drawing are exactly what is intended. When the
document said "treat as a submission" it meant exactly that.
In other words, if you are coming from outside the network, you do not get to
"relay" through the network. You can post/submit from within, you can deliver
into the net or you can post/submit from outside.
email--appending disclaimors and doing all sorts of things. I'm not
convinced such is appropriate in this instance.
Well, it certainly is a point that one could imagine deciding in either
direction, in the abstract.
So, yes, it is important that the folks who have been working on this document,
and contributing to discussions about it, have extensive operations experience
and made the choice intentionally.
Are you raising a concern that the specified behavior will not work -- ie, it
has a core, technical or operational flaw? Or are you simply expressing your
concern that it is more strict than you would prefer?
Also, mail relaying
and submission have different protocols defined by different
specifications. For the most part these protocols are interoperable
but the requirement seems overly strict given this situation.
SUBMISSION is relatively recent and it's use is still only for a portion
of the posting traffic on the Internet. From a practical standpoint, port
25 is still heavily used; so that the two types of traffic are still
frequently multiplexed over 25. Hence any BCP concerning initial posting
needs to cover both ports.
That said, it is the presence of the submission port as an alternative to
port 25 that permits the document to be so forceful about both requiring
authentication on the submission port and prohibiting its blockage.
In other words, the strictness of the spec was rather carefully discussed.
It represents a moderately hard-won balance among the authors (and, by the
way, the rest of the folks contributing to discussion during development
of the spec.) There are good arguments for being even more strict, but we
wanted the document to have the widest support possible. So, relative to
much of the email operations community, the strictness you are reacting to
is actually rather moderate...
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