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

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

 



On Fri, 3 Jun 2005, The IESG wrote:
The IESG has received a request from an individual submitter to consider the
following document:

- 'Email Submission Between Independent Networks '
  <draft-hutzler-spamops-04.txt> as a BCP

This seems a good document, but could probably still use a bit of polishing.

A practical issue I have with this doc is that the recommendations are relatively few, and most of them are rather generic or vague. Haven't we learned more on email BCPs by now? For example, this document says nothing on backup MX's accepting mail for accounts which do not exist, just a very generic:

  o  MDAs SHALL NOT accept mail to recipients for which that MDA has no
      arrangement to perform delivery.

One generic question: what about the case where an organization X has backup MX at ISP Y? How will that reflect to:

   o  For email being received from outside their local operational
      environment, email service operators MUST distinguish between mail
      that will be delivered inside that environment, from mail that is
      to be relayed back out to the Internet.  This allows the MTA to
      restrict this operation, preventing the problem embodied by "open"
      relays.

Mostly editorial comments:

1) Is the scope of the title, "Email Submission Between Independent Networks", too narrow, as the document discusses relaying and delivery BCPs as well?

2) The document specifies in a couple of places that authentication MUST be performed, but does not specify _what_ kind of authentication. This is then discussed a bit in Section 5. I note that there is no mandatory-to-implement authentication mechanism (or at least it isn't spelled out), so interoperability may be hampered. Should this document try to specify such?

3) The following text:

   For example, SMTP AUTH using a secure authentication method like
   CRAM-MD5 or DIGEST-MD5 may be sufficient.  However, in some
   environments, it is impractical to use one of the secure methods,
   meaning that SMTP AUTH would be transmitting the username and the
   password in clear text over insecure networks.

.. seems to be confusing. First you say "a secure authentication method", but then you say using such would be impractical because the password would be sent in the clear text.

This is not good.

I doubt the IETF is OK with calling such authentication methods "secure". Secure authentication methods _don't_ send stuff in the clear text, period. I think this paragraph, and maybe more, needs some serious editing.

4) As process nits:

7.2  References -- Informative

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

.. RFC2119, when used, must be a normative reference. Likewise, you'll need to add a "null" IANA considerations section.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________

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]