Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]