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.
Also, I'm a bit concerned about the following requirement:
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. Hence it must be
subjected
to mail submission authorization and validation
checks.
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
email--appending disclaimors and doing all sorts of things. I'm not
convinced such is appropriate in this instance. 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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf