Hector,
--On Tuesday, 26 February, 2008 03:21 -0500 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
It continues to be reasonable to have some instructions in
2821bis about interoperation between 2821/2821bis
implementations and 821 ones, but we shouldn't expect the
latter to change their behavior without also becoming
2821-conforming.
John, I know you and tony made a decision, which is fine, so
none of this is to change your mind, but just as extra
comments on the subject.
Thanks.
I agree, but I think the matter is with active, contemporary
SMTP clients who will read the specs and might come across
those legacy systems who will not, can not change or can take
MONTHS for an update.
Lets consider what might be a BCP for a client initiation and
fall back logic. To do it right based on what we all know
today, to have automation, support cost reduction logic, the
code would be close to the following:
//--------------------------------------
// Client Initiation and Fall back Logic
//--------------------------------------
...
But this logic an only be extracted from 2821bis if the
insights existed in the specs.
So you have 3 scenarios for a BCP:
1) EHLO/HELO sequence (run into potential fallback issues
per 1869),
2) EHLO/RSET/HELO sequence honor all response codes (like
we have in our code currently),
3) EHLO/RSET/HELO sequence honoring all response codes
except
any RSET 503 possible response per 1869.
All are correct (or allowed) per specs, but which one offers
the better success across the board?
I think that would be #3.
I don't think anyone is disagreeing with you about the general
substance of this, only about the odds of the folks who are
responsible for the problems reading 2821bis carefully to
extract the information and guidance you want them to have. One
way of looking at it is that anyone who wanted to conform to
2821, has read all of it carefully, and wants to get things
right already has this in reasonable shape -- the information is
there, although not organized optimally for this purpose. The
fact that 2821bis is pushing toward 100 pages (so much for
"simple" :-( ) doesn't help much with that. The problem is
that many of the folks you are dealing with, _especially_ the
providers of firewalls with SMTP proxies and mail-filtering
appliances, have a long history of being sloppy about SMTP
implementations and not caring very much. I think that
situation has gotten gradually better over time, but...
This leads me to the conclusion that, if one wants to have high
leverage on the situation with which you are concerned, the best
solution would be assemble a draft that specifically addresses
interoperability between "old" (821 conforming) and
"contemporary" (2821/2821bis conforming) email systems and stays
short and to the point. One might even address interoperation
between those systems and various partial implementations (that
is a charitable way to say "broken") of 2821.
Such a document would need to be consistent with 2821bis, of
course. But it seems to me that it could be quite compact and
very focused and hence much more likely to be read and
understood by someone who is willing to bring their applications
into conformance if they can figure out what they should be
doing without too much effort. If properly written and
community consensus established, it could presumably be
processed as a BCP and would be a useful contribution.
It is almost certainly too late for 2821bis but, if such a
document were produced and published, 2821ter (if we ever get
around to that) could easily contain an informative reference to
it, thereby tying everything together.
The only problem I see with going down that path is that the
document would have to be assembled by someone current access to
logs and knowledge of client and server behavior. I don't have
that any more (even if I had the extra cycles available, which I
don't), so this is something for which you, or someone similarly
positioned, would have to take the lead.
john