Re: RFC2821bis-01 Issue 3: EHLO parameter
2007-03-30 03:40:49
John C Klensin wrote:
Tony's suggestion to move from MUST NOT to SHOULD NOT would
certainly be consistent with changes we could make at this point
(this isn't endorsement, just an observation).
Personally? I would just rather remove it. :-)
In these days, I think you need to have a very good compelling reason
why there would need to exist a legacy "strong" recommendation to accept
a negative condition which is generally view as a very negative and
malicious experience.
In this regard, IMV, a "SHOULD NOT reject" although better, is just as
bad as a "MUST NOT reject." Developers are going to try to provide the
best SMTP system and operators adhere to the rules. They will support
the MUSTs and the SHOULDs, typically by given NO ADMIN choice for MUST
and a ADMIN choice for SHOULD.
Conversely, it would be require a change in thinking here, but in my
view, not breaking the spirit of promoting the primary focus of assuring
delivery, if it was "MAY REJECT", I think it will fit better today
without making developers feel that they are violation specs because
they are not following the MUST NOT recommendation. The difference is
that it delivery should come with proper SMTP compliance. I think that
this breaks the overall spirit of maintaining the email connectivity. I
can understand the old days where there were very good reasons for
seeing EHLO/HELO errors with misconfiguration.
The emphasis in my view, should be to correct these issues, not continue
the propagation of these errors and thus continue given "Spammers" a
reason to exist.
FWIW, I want to show you a snippet of my SMTP log within the last hour
or so:
04:36:01 Invalid HELO 208.247.131.9 client address [125.120.11.247]
04:40:00 Invalid HELO 208.247.131.9 client address [60.16.172.146]
04:40:30 Invalid HELO 208.247.131.9 client address [200.180.22.249]
04:42:23 Invalid HELO 208.247.131.9 client address [124.129.71.74]
04:47:35 Invalid HELO 208.247.131.9 client address [59.92.59.61]
04:47:40 Invalid HELO 208.247.131.9 client address [59.93.207.184]
04:47:43 Invalid HELO 208.247.131.9 client address [59.93.241.121]
04:47:46 Invalid HELO 208.247.131.9 client address [59.93.207.184]
04:48:15 Invalid HELO 208.247.131.9 client address [59.93.54.188]
04:48:22 Invalid HELO 208.247.131.9 client address [211.226.197.15]
Not only it is incorrect syntax, that is our IP address 208.247.131.9.
This is very common. I am just talking about the syntax. The fact that
it is an obvious spoof, I consider that a local policy consideration.
It would be nice to include such insights, but I personally don't think
it is necessary for 2821bis.
We all understand that anything resembling a syntax error in the
EHLO argument (i.e., not meeting the syntax requirements for a
domain name) is an error that lies completely outside the
existing restriction on rejection, don't we?
Does that need to be more explicit?
Not sure.:-) That is why I think it might be better just to remove it
and quite possibly consolidate all rejection ideas into one section
summarizing the generally legitimate, acceptable" (and also possible
acceptable legal, but I understand "some" don't like that) reasons for
rejection. That might allows you to make the other areas more clear
from a technical standpoint.
An SMTP server MAY verify that the domain name argument in
the EHLO command actually corresponds to the IP address of the
client.
Again, for clarification, you mean "one of the IP addresses
of...", don't you?
I believe that is the original sentence. My comments started with the
second sentence "If Verification...". But yes, I think you would be
correct the sentence might need to be reworded.
Do you see cases in the wild in which a client goes to the
trouble to do ESMTP AUTH and get it right and still can't manage
a correct domain name?
Yes John, Thunderbird MUA and I believe, Robert just mentioned the
Eudora MAC version MUA with a similar issue. But Outlook will have the
same issue. It just doesn't see it because it doesn't provide a FQDN
and most systems will just skip the verification in this case. In fact,
any MUA that does not give the end-user the ability to manually define
the EHLO/HELO client domain name or IP address (not a common practice)
will violate this spec.
We talked about this in our last offlist conversation with Randy from
QualComm. This was in regard to the SUBMIT protocol with my request
(suggestion) to consider adding some comments regarding this issue.
Yes, Randy and I ended up doing most of the exchange and I believe you
deferred to Randy's final thoughts. I think he concurred that the
EHLO/HELO verification is less important under SUBMIT (port 587).
I can imagine conditions under which
that might happen, but would hope they would be using Submit and
letting it clean up the EHLO domain name (as you have indirectly
pointed out in another context.
Right, the irony is that the SUBMIT (port 587) is about strong
authentication at all levels. Yet, it can provide an "lesser of all
evils" avenue to help resolve this current issue by relaxing any strong
EHLO/HELO verification that is increasing becoming a wide practice for
anonymous transactions under port 25.
--
HLS
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: RFC2821bis-01 Issue 3: EHLO parameter, (continued)
- Re: RFC2821bis-01 Issue 3: EHLO parameter, SM
- Re: RFC2821bis-01 Issue 3: EHLO parameter, Frank Ellermann
- Re: RFC2821bis-01 Issue 3: EHLO parameter, John C Klensin
- IPv6 (was: RFC2821bis-01 Issue 3: EHLO parameter), Frank Ellermann
- Re: IPv6 (was: RFC2821bis-01 Issue 3: EHLO parameter), John C Klensin
- Re: IPv6, Frank Ellermann
- RFC2821bis-01 Issue 12: IPv6 MX records and transitions (was: Re: IPv6), John C Klensin
- Re: RFC2821bis-01 Issue 3: EHLO parameter, John C Klensin
- Re: RFC2821bis-01 Issue 3: EHLO parameter,
Hector Santos <=
- Re: RFC2821bis-01 Issue 3: EHLO parameter, Hector Santos
- Re: RFC2821bis-01 Issue 3: EHLO parameter, Hector Santos
- Re: RFC2821bis-01 Issue 3: EHLO parameter, Alex van den Bogaerdt
- Re: RFC2821bis-01 Issue 3: EHLO parameter, John C Klensin
- Re: RFC2821bis-01 Issue 3: EHLO parameter, Tony Finch
- Re: RFC2821bis-01 Issue 3: EHLO parameter, Hector Santos
- Re: RFC2821bis-01 Issue 3: EHLO parameter, Dave Crocker
- Re: RFC2821bis-01 Issue 3: EHLO parameter, John C Klensin
- Re: RFC2821bis-01 Issue 3: EHLO parameter, Frank Ellermann
- Re: RFC2821bis-01 Issue 3: EHLO parameter, Hector Santos
|
|
|