Herewith my "review" comments on marid-core-01. Given the history
Quoted text, from the specification, is indented)
My comments follow the quoted text and begin at the margin.
MTA Authentication Records in DNS
The described mechanism does MTA authorization, not authentication.
If this is an authentication mechanism, it needs to explain how and
what it authenticates.
Given the confusion on the mailing list, this specification needs to
list an acronym for referencing it. I assume that this is the
document folks mean when they say Sender-ID, but whatever the right
acronym, please list it.
1. Introduction
In order to avoid further fragmentation of the Internet email
system,"
There is nothing in the document that makes a case that Internet mail
has become "fragmented" or that this particular technique will freeze
the fragmentation (though I suspect you mean "eliminate" or somesuch.)
The goal of the technique is to detect certain kinds of forgery and
those kinds of forgery are popular right now. This is an inherently
legitimate goal, so the disaster language is not needed.
I think the document, as a specification, is better if the entire
paragraph is dropped.
However, as noted above, the document seems to confuse authentication
and authorization. It should separate these constructs and deal with
them in some detail.
2.1 Positive Problem Statement
...
When a message is transferred via SMTP between two UNRELATED parties,
does the SMTP client host have permission to send mail on behalf of
the mailbox that allegedly caused the most recent introduction of the
message into the mail delivery system?
The phrasing and scope of the problem statement question is excellent.
It describes a concern for author/sender authorization of the MTA
path that a message follows.
2.2 Negative Problem Statement
This section describes alternate questions, which this document makes
no attempt to solve.
This section is rather different from what it purports to be. In
reality, it attempts to comment on related techniques.
Given that this is a specification document, no such comparison is
really needed. Worse, I know that the CSV description is flawed, and
suspect that others are.
The section is not needed for the coherence or correctness of the
specification, so I suggest removing it.
Given an email message, and given an IP address from which it has
been (or will be) received, is the SMTP client at that host address
authorized to send that email message?
I suggest:
Given an email message, and given the IP address of the sending
SMTP client, from which it has been (or will be) received, is the
SMTP client at that host address authorized by the Purported
Responsible Address to transmit that email message.
Because of the store-and-forward nature of email, there are lots of
senders and receivers for a message, so it is best to be quite
explicit that this is the latest-hop SMTP client that is being
evaluated by the latest-hop receiving SMTP server, and that
authorization comes from the RS. (The caps show that it is a formal
term.)
(3) Find the E-mail Policy Document for the purported responsible
domain. Section 5.1 below describes the semantics of an E-mail
Policy Document. Section 5.2 below describes how to find the
document for a domain. The E-mail Policy Document contains a
description of a "client authorization function". This function
<<<< computational cost/complexity, dos exposure, etc >>>
4. Determining the Purported Responsible Address
I am skipping over direct evaluation of the contents of this section
in favor of a 'strategic' suggestion for it.
I believe this section is a pure clarification to RFC2821/RFC2822 and
stands independent of the current specification. I suggest breaking it
out into a separate document and, especially, circulating it through
the 2821/2822 community (ietf-smtp and ietf-822 mailing lists).
Let me state this differently: marid-core does not innovate the
construct of responsible sender. Its purpose is to use that construct
in some specific ways. However you have noticed that existing Internet
mail specifications leaves the construct fuzzy and you have
contributed text that seeks to clarify it. All of this is goodness.
What is not so good is to bury this clarification of a basic email
construct in an MTA authorization specification.
(I know we went over this in my comments on the Submitter document;
but I'm trying to be complete, here. Plus I'm phrasing the basis for
the suggestion a bit differently.)
5. E-mail Policy Document
An E-mail Policy Document is modeled by an XML infoset that contains,
among other things, a definition of the function ...
I have always understood that a "function" has operators. In the
definition of the infoset, I do not see any operators.
So isn't this is really something akin to a macro-based access control
list?
(By the way, the IESG is going to ask about the computational
complexity and load of this mechanism, and of the exposure to DOS
attacks. I've just had them challenge a rather more modest spec on
these grounds.)
7.2 TCP Attacks
This mechanism is designed to be used in conjunction with SMTP over
TCP. A sufficiently resourceful attacker might be able to send TCP
packets with forged from-addresses, and thus execute an entire SMTP
TCP has segments, not packets, and it has no "from-addresses", so I am
not sure what sort of TCP Attack is being described here. My guess is
you mean "SMTP Attack" or, rather "Email Sender Forgery Attack" but
the rest of the section appears to be about a replay attack based on
predictable SMTP and TCP content from the server.
blind û the attack will be unable hear any of the server's side of
note the problem character after 'blind'.
Attacks of this sort can be ameliorated if IP gateways refuse to
forward packets when the source address is clearly bogus.
what "IP Gateway" are you referring to and what do you mean by
gateway, here? How is the gateway to know that the source address is
bogus?
7.3 Forged Resent-From Attacks
...
In order to avoid this attack, MUAs will need to start displaying at
least the header that was verified.
This section highlights that this specification is about
accountability and not accreditation.
The suggestion about displaying the Resent-From header presumes that
this is a useful technique for detecting forgery. It presumes some
human factors that do not match empirical evidence.
9.2 E-mail Forwarders
A program that forwards received mail to other addresses MUST add an
appropriate header that contains an email address that it is
authorized to use. Such programs SHOULD use the Resent-From header
for this purpose.
Resent-From is a pretty interesting choice to suggest. At the least,
it is worth noting that this is a change from existing mailing list
behavior, since they usually set Sender. I'm not saying that
Resent-From is a bad choice, but merely that the fact of changing
mailer behavior is probably worth noting.
I'm also not sure whether I think that Resent-Sender is better than
Resent-From. Mumble.
Oh... You distinguish email forwarders from mailing list systems. I do
not understand this. what, then, is an email forwarder?
d/
-----
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel: +1.408.246.8253>; <fax: +1.408.850.1850>