--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.
I have to disagree with this assessment. The practices this document describes
may not be universal or even widespread, but I don't see anything the document
recommends that isn't currently practiced, in most cases on a fairly large
scale. For example, we now routinely see sites that have port 25 completely
blocked except for inbound relay and which require TLS+SASL on the submit port
to send mail.
A more important question IMO is whether or not what's recommend here is really
the best practice. In almost every case I think the answer is yes. My one
concern is with the recommendation that MSAs by default try the submit port
first and if that fails fall back to port 25. I have no problem with
recommending a submit port configuration - it's the fallback process that
concerns me. The problem I see with this is what happens if the SMTP server is
set to return an error if someone attempts to use it and the submit server gets
overloaded and doesn't respond quickly enough.
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.
John, as you undoubtedly know, the issue of whether or not a BCP status
document can recommmend or require practices that aren't widespread has come up
several times previously, and I believe we've seen both possible outcomes: BCPs
have been issued that recommend practices that had little or not deployment at
the time the document was issued (the obvious example here are our process
BCPs, which more or less by definition aren't "deployed" until after approval)
and documents seeking BCP status have on occasion been shifted to the
three-step standards track.
In regards to the current document, I think this fits better as a BCP but I
would not object to making it a proposed standard instead. But this really
should be up to the IESG to decide.
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.
Hmm. Well, I looked but I don't see any statements along these lines in there.
Regardless, I actually would not object to a SHOULD use credentialed
authentication as this leaves a reasonable loophole for devices that are
incapable of it.
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.
A fair number of them are egregiously incompliant in other more serious ways,
e.g. not having adequate timeouts or sufficient retry logic. But irrespective
of the problems in this area I really don't tnink catering to device breakage
or limitations by compromising compliance language that's urgently needed to
deal with the spam problem is a reasonable tradeoff.
Ned
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf