----- Original Message -----
From: "John C Klensin" <klensin(_at_)jck(_dot_)com>
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.
Its all good here. I'm ready to smoke the proverbial peace pipe.
Let's suppose that a first cut at 2821bis were actually about to
appear.
ok. May I ask what is a "bis" ? Not familar with that term.
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.
I'm not sure if I follow this line of thought but no doubt I want to know
more.
I should also note that I am not bent of a CBV, but I am not that never
waited on the IETF for a solution to the "email problem." To me, the
Return Path is something that is fundamental to the process, and unlike
HELO, it is indeed a candidate for validation, simply because it is a
required item for a normal part of the mail flow - the bounce.
So based on this important framework, the CBV is a very viable idea, not
necessarily as a SMTP based call back, but as a proof of concept.
So in that vain, if I understood your statement, I don't see it is a
violiation to perform a "return path validation" concept. To me, the
different between a CBV and a normal delay bounce action is *time*. A
bounce is basically a "time shifted concept" of return path validation
during the process of performing the bounce.
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.
Shock? You are understanding it. EARTHQUAKE! <g>
Wonderful. I volunteer any services I can offer.
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.
I don't pretend to be an expert of the IETF process, there is no better time
than now to begin a new revamp period. It would the second time in our
history and its abound time. The last time around the industry converge on
a standard. This time the industry will converge to sholve the major
security issues with the email framework. Anything short of an emphasis on
technical legal compliant enforcement or the migration towards technical
legal compliant enforcement will fall short of the goals. Keep in mind, I
am not implying a break down, but instead I think it can down with major
backward compliancy in mind.
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.
I agree. Fighting the spam problem would be a natural benefits of a
stronger SMTP TMS (Transaction Management and Security) specification.
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.
Let me see if I got this right, we should look at 3552 as a framework if we
want a better chance at adoption, but you are afraid that we might be able
to get a concensus of all the considerations in the document?
(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.
It is possible to have multiple workings groups, to split the issues (and
also lower the thread fibers)? This is just off rough breakdown:
- 3821-BCM
Backward Compatibilty (legacy), Migration Considerations
- 3821-TMS
Transaction Management and Security (state machine/ESMTP)
- 3821-PAYLOAD
3822 Considerations
- 3831-SPAM
Integration with new email proposals such as SPF, SENDERID/PRA,
CSV, DKIM, BATV, SRS, including MFA (Mail Filter Agent) considerations
such as Seive, etc.
This way we get the various experts delegated with concentrated focused
efforts and you can probably extract what is gain and purge want is not
necessary to produce your documents. The goal is not to break the system,
but to take what we learned over the last 20+ years and consolidate may of
the ideas already in place, clean up the ambiguity, and begin to offer a
strong optional enforcable system that is design with maximum backward
compatibility and migration in mind.
I'm excited!! I understand that this may be too much, but its better to
look at the total scope and limit it from there, if need be.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com