Folks,
I've been quietly watching this thread and a few others. I'd
like to encourage people to stop, not only the aspects of this
that are pretty close to name-calling, but the whole discussion
for a bit and take things up one abstraction level.
Let's suppose that a first cut at 2821bis were actually about to
appear. The existing 2821 takes a pretty hard line on
approaches like "well, if the return-path looks like X, then it
is plausible to impose restrictions A, B, or C on the number of
recipients". Basically, unless you invoke the loophole, the
minimum number of RCPT commands to be accepted is 100, and any
implementation that cannot do so is non-conformant. Of course,
there is the loophole, and the loophole permits almost anything
plausible to be enabled, at configuration time, in the name of
security generally and repelling attacks in particular.
From the perspective of the standard, all of these discussions
about tricky address verifications, sender-receiver command
relationships, and so on, are not about conformance. Instead,
they are about whether it is a good or bad idea to violate the
standard in various ways for operational purposes.
At the risk of causing shock all over the email community, I
expect to have draft-klensin-rfc2821bis-00 posted late this week
or, at worst, early next week. Tony Hansen has done a
superhuman job of converting the format in which the document
has been maintained and worked on for the last four years into
an XML2RFC format that can be used to generate I-Ds in an
acceptable form. Unless I slipped up, the -00 draft reflects
all of the clear errors and substantive corrections identified
in the last four years. It does not reflect a number of
proposed "this will make it more clear but does not change the
definition" changes, especially when those changes, in my
opinion, are just confusing in a different way.
There is a small, ad hoc, evaluation committee looking at those
groups of changes with the intent of providing some evaluations
for the list to look at: the decisions as to which marginal
clarifications are worth making are not going to be made by the
contributor and myself alone.
In addition to all of the little details, there are a few
strategic issues that will need to be addressed. They include:
(i) The style and tone with regard to operational or security
(including spam-fighting) issues as outlined above. It is my
personal belief that there is ample room for a "best practices
in mail system configuration to resist spam" document, but its
content does not belong as part of the transport spec. So my
proposal is to leave the present structure of 2821 unchanged. I
would note that, if we start considering major changes in
restrictions and directions about them, the odds of going down
ratholes are very high and the odds of needing to recycle at
Proposed are probably even higher.
(ii) RFC 3552 contains, as an example, what is essentially a
rewritten Security Considerations section for 2821. My personal
belief is that sample section is sufficiently unrealistic with
regard to operational Internet mail systems that a system that
followed all of the recommendations of that text would be quite
secure because it would not be able to communicate with anyone
else and no one would communicate with it. I've started to
raise that issue with the IAB (from whence the RFC originated) a
couple of times, but have always gotten sidetracked. While
there is some new material in the Security Considerations
section of 2821bis, the additional recommendations of 3552 have
essentially been ignored. People should start thinking about
that situation and what you/we want to do about it: I believe
that, if the IESG insists on replacing that section with one
that is 3552-conformant, it will be impossible to get an
informed consensus for moving 3821bis forward.
(iii) 2821bis is rather thoroughly intertwined with 2822bis. At
a minimum, it is clear that neither one can go to Draft without
the other, at least until the procedures of RFC 3967 are
invoked. We need to think through the implications and
relationships between these two documents and how they should be
processed.
(iv) More generally, we need to figure out, somehow, whether it
is possible to progress this document without reactivating DRUMS
or the equivalent and make a recommendation to the ADs on that
matter. I fear that everyone who is critical-path for this is
too busy to make opening the WG a good idea. On the other hand,
without the structure of a WG, it will take a good deal of
self-discipline on all of our parts to avoid the long message
threads about irrelevant or unimportant issues that could make
getting consensus on a revised document (or pair of documents)
largely impossible.
Thoughts welcome, either before or after the I-D goes up.
john