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.
I think you seriously underestimate the difficulty getting consensus on these
"polishing" issues.
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?
What we have learned and what we are able to reach consensus on are two very
different things.
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.
No doubt because I've seen no consensus whatsoever as to how this (very thorny)
issue needs to be handled. If there is an agreed best current practice here
waiting to be documented I'm unaware of what it is.
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.
It means the backup MX needs to be able to distinguish addresses associated
with the destination environment and addresses that aren't. This functionality
is readily available in most mail software.
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?
But both are discussed within the context of messages being sent between
networks.
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?
IMO it is entirely inappropriate for this to be done in a BCP document of this
sort. If this is done at all it needs to be done in a revision to the SMTP
protocol specification. (And good luck getting agreement on a
mandatory-to-implement scheme.)
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.
That's not what it says at all - the "because" is entirely your own invention.
More specifically, the usual reason it may be impractical to use CRAM-MD5 or
DIGEST-MD5 is that both require cleartext-equivalent or
near-cleartext-equivalent password storage on the server, which may be (a)
Incompatible with existing password stores or (b) Seen as a security exposure.
This has nothing to do with the fact that SASL PLAIN sends passwords in the
clear.
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.
I reallly don't think it is all that unclear. However, I do think that the
prose could benefit from some more detailed discussion of the specific threats
and security issues involved, especially in light of the recent spate of
attacks where the credentials for huge numbers of users have been stolen in one
swell foop. I believe the authors have requested specific information from the
security folks in order to do something along these lines.
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.
Agreed on the RFC 2119 reference. However, I do not believe there is any
requirement for "null" IANA considerations sections. (A scan of recently
published standards track RFCs turned up several that don't have such a section
- 4022, 4015, etc.) Aren't we paddding out our documents with enough useless
boilerplate already without adding yet another useless section to the mix?
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf