--On Sunday, June 10, 2007 07:31 -0700 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:
trust. Given the prohibitions in this document, where are
those devices left? Am I correct in assuming that this
document would intend to prohibit those devices as
non-conforming?
No.
If the devices (or cron, or whatever) are indeed sending valid
mail by virtue of having been configured properly and not
having been compromised, then it sounds to me as if the mail
is very much authentic (and authenticated.)
Dave,
I am working on a more comprehensive review, which I will get
posted in the next day or so. However, while I agree with most
of the suggestion in the draft and certainly with its good
intentions, it contains a great deal of very strong conformance
language ("MUST"s and "SHOULD"s) that considerably exceed
current practice. While I have quibbles, that would be fine as
a target. In particular, it would be entirely appropriate if
this were going for Proposed Standard, subject to subsequent
review as to which of the mandates had been followed in practice
and adjustments as needed. But, as a BCP with no multi-stage
review process, it seems to me that some of those requirements
simply do not reflect current practice, best or otherwise.
"Desired good practices" or "really strongly recommended
practices" or "best current wishes", possibly, but we haven't
adopted those categories.
The devices that prompted my note show up because they are,
typically, incapable of authenticating themselves to an SMTP
server at all. If there is any indication of authorization, it
is by IP address, but the document strongly discourages using.
Their SMTP clients are typically very weak (several are
notorious for not even managing to include a date header, which
has been a requirement for, at you, know, a few decades) and are
in firmware that I'd guess is rarely updated within the life
expectancy of the device. On the other hand, the devices are
pretty safe and need not be blocked: compromising them to send a
message of the attacker's choice would be fiendishly difficult
and they are usually configured in a way that makes them even
safer.
There are other cases as well; more soon.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf