John C Klensin wrote:
--On Sunday, 01 April, 2007 14:26 -0700 Dave Crocker
...
smtpout.example.com. AAAA ....
example.com. MX 0 smtpin.example.com.
stmpin.example.com. A ....
AAAA ....
> ...
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>
...
>
> ...
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).
With it comes to IPv6, I agree. IPv6 considerations for EHLO/HELO simply
increases the potential for unreliability.
But there is something I am not quite following. Isn't it pretty much
long settled that anyone with an interest in IPv6 including us as long
time SMTP vendors that has done early IPv6 implementation consideration
R&D, that including IPv6 support at this time requires an awful amount
of assumptions to be in place? You cited many of the presumed possible
requirements and needs.
But this is why I lean to removing all the subjective recommendations
and just lay down the technical facts as we known it today and will be
in the future.
Do you even want to mark it "suspicious" before delivering it?
Fortunately, 2821bis takes no position at all on that subject.
Right. I think the point here is that we are wasting time trying to mode
or finesse a policy that IMV shouldn't be there. Laying down the
contemporary technical issues is good enough IMV. Let implementations
decide. Who knows? Maybe tomorrow someone will invent, propose a more
reliable concept for EHLO including IPv6 verification. The problem?
These specific new proposals will need to update 2821bis to remove its
"MUST NOT/SHOULD NOT" restriction.
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.
This is just an opinion. Maybe we should refrain from the terms "reject
mail" or "mail rejection," etc. The SMTP receiver is not rejecting the
mail, it is creating a negative response or condition that prohibits the
continuance of the transaction. Thats a big difference because SMTP
level negative responses are blind to mail content interpretations. Of
course, in a POST SMTP or dynamic DATA "shim" consideration , the mail
is subject to mail content subjective considerations.
But the difference is we are strictly talking about SMTP level state
(machine) validation here I believe.
IMV, there are two areas in SMTP commands that fall under the same
issues and consideration: The client domain (EHLO/HELO) and the return
path (MAIL FROM). IMV, the discussion of MAIL FROM is pretty "near"
perfect:
- We KNOW it must be valid
- We make no statement how we prove that, we have an
inherent presumption that it is valid for Bounce purposes.
- But we also give some excellent technical guidance
for implementations such as checking for RCPT first
before applying any MAIL FROM verification ideas.
But just imagine if back in 2000 when you did 2821, if we had all the
current LMAP generation verification ideas in place? such as DMP,
CALLER-ID, SPF, SENDER-ID, and the growing SMTP based CallBack
verification implementations? I am willing to bet that someone would of
suggested a similar restriction for MAIL FROM for the same reasons you
have for EHLO/HELO with its DNS unreliable lookup issues:
"Return Path Verification Ideas out of scope.....
However, verification failures MUST NOT reject on the
basis of LMAP considerations or any other kind of dynamic
SMTP return path domain DNS lookup methodology."
Isn't that the essentially the same thing we have for EHLO/HELO?
Fortunately, 2821 did not have such MAIL FROM restrictions and new
technology was able to evolve, explored and implemented.
(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?
Objectively, all this is already a reality. Subjectively, the only
remaining question is how long will it take the editors (and WG) to
finally start taking it into account. I think you can add the extra
text to cover the wider range of contemporary realities.
Speaking for myself, I have no feel for these "next text" or "word
count" conflicts being wage between the principles here. :-) I more for
"getting it right, the first time" (a metaphor) and move on. If the
extra text helps, I vote for it.
That said, in general, whether it is this issue or others, in principle
I vote for removing any subjective, technical restrictions, and lay down
what technical realities which isn't a philosophical debate or question.
I think what you have in 7.8 is a good example, for example, to me, you
can remove and move the relay discussion into own 7.x section and add a
forward pointer in the EHLO/HELO section. Then the 7.8 "SCOPE" section
is reduced to:
--
7.8. Scope of Operation of SMTP Servers
It is a well-established principle that an SMTP server may refuse to
accept mail for any operational or technical reason that makes sense
to the site providing the server.
However, cooperation among sites and installations makes the
Internet possible. If sites take excessive advantage of the right
to reject traffic, the ubiquity of email availability (one of
the strengths of the Internet) will be threatened; considerable
care should be taken and balance maintained if a site decides to
be selective about the traffic it will accept and process.
--
The specifics about 550 or other response code was already discussed in
other specific sections.
--
HLS