ietf-smtp
[Top] [All Lists]

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