--On Sunday, 01 April, 2007 14:26 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:
John C Klensin wrote:
Given the complexities, controversies, and resulting
instability of community consensus about abuse-related
reasons for rejecting mail, anything that touches that space
should be omitted from the document.
Drop the text.
For the record, as editor, I'll do whatever consensus emerges
that I should do.
mais oui.
However, I hope that folks keep in mind that reality tends to
override working group consensus.
As long as we can agree on what the reality is, of course.
However... The specific name != address prohibition
originated, I believe, with 1123 after significant
discussion. It was discussed again in DRUMS and reaffirmed.
Even as recently as DRUMS, the world was a very different
place. And remember that the exercise of 1123 was to
synchronize with reality.
And that's all I am suggesting here, but by a minimizing
approach, rather than trying to create new language.
There isn't much "creating new language" implied in anything
I've seen and understood. There have been some suggestions
about changing a MUST to a SHOULD, which is certainly not new
language; Alex's recent suggestion to insert an explicit "other
rejections are not prohibited" which might be supplemented by a
forward pointer, which would normally fall into the category of
editorial smoothing and clarification rather than substantive
new language; and suggestions to somewhat tune the language of
7.8 (the "... may refuse to accept mail ...reason that makes
sense" material), again, something we would normally consider an
editorial matter rather than "creating new language".
Note also that removing text that provides very strong guidance
that a particular test is not especially useful is not, IMO, a
"minimizing approach", unless your definition of minimizing is
the trivial one of simply reducing the word count. In all that
has changed in the last several years, I've heard no suggestions
that the value of this test _as a criterion for rejecting a
message_ has significantly increased. I note that neither the
comments about that test, nor anything else in 2821 or 2821bis,
affect criteria for quarantining an message or assigning a
positive or negative statistical probability as to whether it is
wanted or unwanted traffic or whether it falls into some
particular category. Under the "deliver or reject" model that
has been a property of Internet mail since the FTP days, those
classificatory or folder routing options all lie
post-final-SMTP-delivery.
There are many policy-related issues that rfc2821/821 could
have chosen to make normative statements about, but didn't.
That it chose to make a normative comment about the action to
take, or not take, regarding a particularly validation
exercise, steps into territory that was reasonable at the
time, but now sits rather wildly in the middle of a very
message, unstable, very energized/polarized topic.
The prohibition went into 1123 because, for a number of reasons
related to how the Internet worked, this was an expensive test
and tricky test that was subject to false positives for
rejecting mail. As discussed above, no evidence has been
offered for that having changed.
If the statement has said "this test is so bad that one should
not even use it to try to classify a message, or to contribute
to a score as to whether it is likely evil" then, certainly, it
would be desirable to remove it. But it doesn't say that.
While it doesn't go into this much detail (maybe it should, but
that would require "creating new language") that simply trying
to forward-map DNS names and compare IP addresses is not a
useful test to enable message rejection. In a way, that advice
is more useful today than it was when 2821 was completed.
Consider the separate discussion we have been having about IPv6.
Now, remembering that it has become common for administrative
domains to use different servers for sending and receiving mail,
suppose that such a domain has DNS records as follows:
smtpout.example.com. AAAA ....
example.com. MX 0 smtpin.example.com.
stmpin.example.com. A ....
AAAA ....
suppose also that the network that supports these hosts has a
network layer IPv6-IPv4 conversion gateway, a gateway that makes
its conversions at the packet layer, invisible to SMTP.
Now assume a mail transaction that looks something like:
EHLO smtpout.example.com
MAIL FROM:<someuser(_at_)example(_dot_)com>
RCPT TO:<joe(_at_)bogus(_dot_)domain(_dot_)name>
...
and assume the simple case (the common one today): there are no
relays involved and the mail server for bogus.domain.name
doesn't support IPv6 even to the extent of looking up AAAA
records. Assume that both the forward and reverse-pointing
addresses given are deliverable without difficulties. Now what
happens:
The receiving server does a DNS lookup, type=A, on
"smtpout.example.com". It fails. Do you want to _reject_ this
message or encourage anyone to do so based on that information?
Or suppose it does do the type=AAAA lookup as well as the type=A
one. It gets back the IPv6 record but, because of the
packet-level address remapping gateway, that address is not the
same as the address of the TCP connection to the SMTP port. Do
you want to _reject_ the message on that basis?
Bad idea, IMO. Probably a worse idea than it was in the simpler
world of 2000 (RFC 2821) or 1989 (RFC 1123).
Do you even want to mark it "suspicious" before delivering it?
Fortunately, 2821bis takes no position at all on that subject.
It need not be anywhere near that territory, in order to do
its basic job.
So I'll merely stress for the group:
As folks consider what to do with the text, they should
a) make sure it creates no new violence in the document, of
course, and b) reflects reality by virture of matching
existing practise.
That's why I suggest completely dropping the text,
rather than trying to tweak the normative status.
I think I agree with your principle, but not with the
application to this text, for the reasons above.
Two added comments:
(1) It does seem to me that it might be useful to add, possibly
to the Security Considerations section, a comment to the effect
that the tests required or prohibited by SMTP in order to
determine whether to reject or deliver mail and questions about
how far to push the robustness principle in terms of what to
accept and whether deviations that are still considered
deliverable should be evaluated in message classification, are
outside the scope of 2821bis. That would, of course, require
making up new text, so it would be useful to think about whether
such text would be welcome before we start thinking about how to
craft it.
(2) It seems to me that the text of 7.8 should be clarified to
include something like "unless otherwise constrained above or by
extensions that are in use" to eliminate any possible confusion
about apparent contradictions and that this should be done
regardless of what changes are made, if any, to the specific
EHLO text. Are there objections to my doing that, in spite of
the fact that it is "new text" and adds to the word count?
john