Stephane,
Thanks for posting a comment. I hope that more folks do...
Stephane Bortzmeyer wrote:
It seems that there is not a lof of content left from the first, much
more normative versions of this document, which were issued a long
time ago.
The spamops effort has been dominated by a desire to specify only things that
are UNcontroversial, at this stage.
Many of us -- amongst the authors and certainly amongst the community -- might
wish for more extensive and aggressive normative statements, but we recognize
that the document would very likely not be approved. Even if approved, it
would not be likely to gain widespread adoption.
So the goal, here, is to make a first normative step that is comfortable, in
order to make that first step.
Among what is left, I'm concerned about section 3.1 "Best Practices
for Submission Operation" which says "It is also suggested that
operators standardize on the SUBMISSION port for both external AND
LOCAL users for simplicity." and "MSAs MUST perform authentication on
the identity asserted during all mail transactions on the SUBMISSION
port".
If you have a concern, other than the one you cite in the following text, I
missed it. In other words, I am assuming that your next paragraph is the
explanation of your concern stated in the previous one, but I want to make
sure. No need to comment, if the following covers it:
Since section 5 "Message Submission Authentication/Authorization
Technologies" mentions only SMTP AUTH and TLS, does it mean that
authentication by IP addresses is forbidden? I ask so because it is
currently the most common way to weakly authenticate local users. Is
it covered by "Depending upon the environment, different mechanisms
can be more or less effective and convenient"?
I do not see normative language such as "MUST NOT" or "SHOULD NOT" on this
topic, in the document. So I do understand why you would worry about a method
being "forbidden".
In fact, the latter part of the paragraph says "Depending upon the
environment, different mechanisms can be more or less effective and
convenient. Organizations SHOULD choose the most secure approaches that are
practical" which seems, to me, to clearly state that you are free to use any
technique you deem sufficiently effective.
Authentication is not a particular technique, it is an assurance. Whatever
achieves that assurance -- to a sufficient degree and with sufficiently low
cost -- is fine.
Side note: on Unix, will cron be forced to authenticate to send emails
at 2 am? :-)
Yes. See above.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf