Hi.
As indicated in an earlier note, I've got considerable
misgivings about this document. Sorry it has taken me this long
to draw my notes together and get them posted.
Metacomment: Many or most of my concerns about this document
would disappear if it were placed on the normal standards track
as a Proposed Standard, followed by a review after some months
of which features and recommendations really had received
considerable implementation and deployment and proven effective
in practice. While use of BCP for IETF procedures and the like
is, IMO, just an unfortunate terminology twitch, use of BCP to
eliminate the multistage process for what is clearly a protocol
document --even one that slides over into the territory of a
somewhat speculative A/S-- seems dubious to me and devalues
those BCPs that really are recommendations based on best current
practices rather than speculation about future ones. As noted
below, this document even appears to update RFC 2821, altering
one of its requirements.
While I wouldn't particularly recommend it, those concerns could
also be satisfied by some rephrasing of comments followed by
Informational publication.
I want to stress that I agree with the intent of every
recommendation in this document. It is the document itself and
occasionally the requirement levels, but not the recommendations
themselves, that are inadequate or inappropriate, especially for
a one-step approval/publication process.
Even the comments below that have nothing to do with status
(possibly modulo the concerns about an inadequate Security
Considerations section) probably fall into the "good enough for
Proposed" category... but not good enough for a one-step model.
I also note that the IETF has experimental protocols (SPF, etc.)
and a standards-track effort (DKIM) about which some fairly
optimistic claims have been made about their ability to limit
spam or control its effects. It would be sad to issue this
document as a BCP and then turn around and issue an update that
contained a different (even if broadly consistent) set of
recommendations were one of those techniques to prove as
successful as their most passionate advocates predict.
Specific remarks:
(1) While this document talks about a "wide variety of email
authentication techniques..." (Introduction, paragraph 3), the
reality is that these are generally not authentication
techniques for email but for the server chain. Their strength
depends on the assumption that the sending endpoint (MUA and
MSA) will have adequately validated the sending user. However,
in most cases with these techniques, the strongest validation
assumes that the mail is valid if it comes from a machine which
is authorized to send mail over a particular path. That would
constitute reasonably strong user (and hence email)
authentication (a "confirmed identity of the originator") if the
sending machine were trusted and known to strongly authenticate
user accesses. But, on an Internet where the most common
practice is to assume that possession of an end-user client
machine constitutes authorization to use it, that assumption is
dubious.
Each time the IETF community has attempted a serious analysis of
"email authentication", the conclusion has been that the only
methods that really work are based on end-to-end message
authentication involving digital signatures and message
integrity checks of some persuasion. While the difficulties
with wide deployment or those methods are well-understood at
this point, the IETF should not be publishing a Best Practices
document that implies that less reliable techniques are
equivalent or even that they are "email authentication".
All in all, there are a series of initial authentication and
authorization and chain of trust assumptions built into the
techniques recommended here whose "security considerations"
analysis is woefully inadequate either directly or by reference.
Rather than discussing these issues, the "Security
Considerations" section merely says that there is a problem and
that these recommendations can help with it.
(2) Section 3.1 contains a MUST requirement for availability of
the message submission port (RFC 4409). While I am a firm
believer in RFC 4409 and look forward to the point at which we
can put out a document that deprecates the use of SMTP (RFC
2821) for message submission by clients that do not support full
SMTP services (for many more reasons than spam mitigation), we
aren't there yet, and a MUST requirement definitely does not
represent current practice.
A subsequent subsection "Submission Authentication" requires
(with a MUST) authentication on the asserted identity ... "even
for a
message having a RCPT TO address that would not cause the
message to be relayed outside of the local administrative
environment". The IETF has historically been very reluctant to
tell people what they are permitted to do within the confines of
their own administrative environments (e.g., local or enterprise
LANs). Even a SHOULD on this one would seem to require much
stronger justification than appears in this document; a MUST
appears to be outside IETF's knowledge and scope, at least in
the absence of a security analysis of the potential issues.
MUST provisions in the next subsection ("Submission
Authorization") raise similar issues: Validation of
authorization is certainly a fine idea but, without some more
specific text about what is intended and required, it is so much
hand-waving. And we should not be hand-waving around a MUST.
Section 5 is apparently intended to address this issue but falls
somewhat short (see (7) below). Editorially, if Section 5 is
actually intended to address the issues of methods, some forward
references/ pointers would be in order.
It seems to me that the provision that the tracing requirement
of "Submission Accountability after Submission" can be satisfied
by examining header information requires a comment, either
inline or in Security Considerations, about the ease or
difficulty of spoofing that information. While the level of
sophistication required to do a good one has risen over time,
"Joe Jobs" are not exactly a recent innovation and, indeed,
several of the other techniques recommended in this document are
presumably intended, at least in part, to make them more
difficult.
By contrast, the last paragraph of the introduction to Section 3
is correct: it is common practice today for MSAs to reject
message postings where no relationship exists with the MUA (or
user, or MUA host). RFC 4409 requires that behavior for
Submission servers. That paragraph goes on to say "...an MDA
can choose to reject all mail to recipients for which that MDA
has no arrangement to perform delivery." Certainly that is
true, since it has been a firm requirement since before RFC 821
was published (and arguably going back to the days of FTP-based
netmail). Now, I think the point the authors are trying to make
depends on a very narrow and precise definition of "reject".
But that term is not defined appropriately in this document: as
far as I know, its only definition and consistent use in a
standards-track document (specification or candidate) for
Internet email is in 2821bis (draft-klensin-rfc2821bis, version
-03 and later).
Interestingly, the "Delivery Authorization" subsection of
Section 4.1 says "MUST NOT accept..." which avoids the problem
of the definition of "reject". But see (6) below.
As a related editorial quibble, the language of the introductory
paragraph of Section 3 implies that initial submission via SMTP
is never authenticated. That is simply not correct (and this
document says so in Section 5).
(3) The provisions of the first paragraph of Section 3.2 seem
odd to me. If we believe that authentication and authorization
of the submission MUA are important (which is what 3.1 appears
to say, with MUST-level requirements), then saying that MSAs
"SHOULD" require authentication on SMTP-based submissions
appears to provide a way to evade that requirement. I can see
good reasons for this provision, including conforming to actual
current practice, but it needs, IMO, considerably more
explanation and rationale of when it it is acceptable to violate
the "SHOULD".
(4) The first paragraph of Section 4 seems to be unnecessarily
obscure to me, especially if it is expected to be read by
someone who is not intimately aware of email protocols,
terminology, and the discussions of the last few years. As the
most glaring example, what is the definition of a "mass-effect
email problem"?
The Section 4 recommendation to use Submit on port 587 rather
than SMTP (on port 25) for initial submission is wonderful, and
consistent with the recommendations in Section 3 and elsewhere.
But there is ultimately nothing magic about Port 587 other than
that most providers who are providing crude blocks on port 25
haven't awakened to Port 587 yet _and_ that Submit requires
authentication and SMTP does not (see comment (3) above).
(5) A MUST NOT requirement on blocking Submit (Section 4.1) is a
bit dubious at this point. Again, I am sympathetic to the
reasons, but there are presumably still implementations of RFC
2476 out there that do not require authentication. An access
provider has no way to be guaranteed that all servers on port
587 authenticate and authenticate adequately (i.e., there is no
trust relationship between an access provider and an arbitrary
port 587 server at all). So, if the access provider believes
that blocking outbound port 25 is an important anti-spam
measure, then blocking port 587 traffic to an open relay on that
port is equally rational. I think that demotes this requirement
to a SHOULD, with as strong an explanation as the authors deem
appropriate.
(6) Section 4.1 "Delivery Authorization". This seemingly mild
and reasonable statement about accepting mail interacts with an
ongoing debate in the rfc2821bis effort and elsewhere. At least
as I read it, it directly contracts text in 2821 which permits
an MTA to "accept" (i.e., respond with 2yz codes) messages for
any address, evaluate the address after acceptance, and then
"bounce" (generate an NDN and return all or part of the message)
if the address is unauthorized or undeliverable. As we have
discovered with 2821bis, eliminating that option requires
consideration of some fairly complex issues with the email
architecture. On the other hand, if the MDA could assume that
the other recommendations and requirements of this document had
been followed, the issues with "bouncing" messages would largely
disappear and this requirement would apparently become a trivial
restatement of the 821-and-earlier requirement that a server
accepting a message take the transfer of responsibility
seriously.
(7) Section 5 refers to SMTP AUTH or TLS as if they are
sufficient solutions to the issues and requirements of this
document. Fortunately or unfortunately, either can be used in
ways that does not satisfy these requirements. In particular
RFC 3207 TLS can be used to provide privacy protection without
any meaningful client authentication at all. I believe that our
norms require that those issues be discussed either in this
section or in Security Considerations if these techniques are to
be given as examples.
thanks,
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf