I very much like the goals of this document, but I think there's a little
room for improvement and clarification, as follows:
Authentication vs. authorization
The draft mostly talks about authentication (authn) rather than
authorization (authz). I'm not sure whether the aim is to require actual
authn of the person sending the message using modern secure protocols, or
if the aim is simply to ensure that a secure authz check is performed.
Because the draft usually talks about authn it seems to be the former, but
then section 5 mentions IP address ACLs which are an authz not authn
technology. What's more, user authentication isn't practical in many
cases, such as email from web servers.
I think this would be clearer if the first bullet point in section 3 were
to say:
o Operators of MSAs MUST perform a secure authorization check during
mail submission, based on an existing relationship with the submitting
entity. This requirement applies to all mail submission
mechanisms.
Section 5 needs some attention too, particularly in the first paragraph.
The second paragraph has been done to death already :-) If it is within
the document's scope to discuss which authn technologies are recommended,
then due attention should be paid in the Security Considerations section;
otherwise I think it would be OK to point the reader elsewhere.
Open relays
The description of the open relay check in the second bullet point in
section 3 appears to ban secondary MXs. It's better to descibe the check
in terms of the message's recipient addresses as they are presented to the
MTA, and not in terms of the message's destination. I suggest:
o For email being received from the public Internet without special
authorization, email service operators MUST distinguish between
mail domains that they are responsible for and those they are not.
Messages addressed to domains that the service operator is not
responsible for MUST be rejected, so that its MTAs do not act as
"open relays".
Separation of functionality
The third bullet point in section three appears to require MX hosts to act
as MSAs. Although many smaller email systems work in the way it describes,
there are many that don't, and larger systems in particular often have
strictly separated MSA and MX hosts. When I try to come up with
alternative wording to fix the problem, this paragraph becomes redundant
given the contents of the previous two paragraphs. Therefore I suggest it
should be deleted.
Tony.
--
f.a.n.finch <dot@xxxxxxxx> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf