[Top] [All Lists]

Re: RFC2821bis-01 Issue 3: EHLO parameter

2007-04-03 04:12:09

John C Klensin wrote:
--On Sunday, 01 April, 2007 14:26 -0700 Dave Crocker

... AAAA ....         MX 0  A  ....
                         AAAA ....

> ...
Now assume a mail transaction that looks something like:
    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
"".  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.


<Prev in Thread] Current Thread [Next in Thread>