John W. Baxter wrote:
> On 10/26/06 4:16 AM, "Bill Hacker (by way of Bill Hacker
> <wbh@???>)" <wbh@???> wrote:
>
>> Might not a calling host first HELO and invoke the list of 'advertised'
>> services,
> The only service at this point is SMTP.
>
>> and only then use an EHLO if such were 'advertised', ELSE not?
>
> EHLO isn't advertised;
No - I mean if for example, the banner *did* say 'ESMTP'
but either broken client (they do exist) or a curious human (telnet) were
arriving...
> the connection banner might include "ESMTP" if esmtp
> is supported but it is expected that an EHLO will simply be tried if the
> connecting thing wants to use esmtp extensions, and fall back to HELO if the
> EHLO is rejected.
>
> Part of 3.2 from RFC 2821:
>
> Older SMTP systems which are unable to
> support service extensions and contemporary clients which do not
> require service extensions in the mail session being initiated, MAY
> use HELO instead of EHLO. Servers MUST NOT return the extended
> EHLO-style response to a HELO command. For a particular connection
> attempt, if the server returns a "command not recognized" response to
> EHLO, the client SHOULD be able to fall back and send HELO.
>
> I hadn't remembered the part about modern clients that don't care about the
> extensions, but it makes sense. I don't know whether there are any that
> matter to the OP.
>
Understood, reread that yesterday also.
But if one uses telnet, issues a HELO <hostname> one can then do EHLO <hostname>
*afterwards* as well, and go on from there as if you had arrived with an
*initial* EHLO. Exim doesn't necessarily drop the connection[1].
Yes - it is sequentially 'bass-ackwards' per the extensions RFC w/r what an
*MTA* will (or should) do, but if the poster who said 'impossible' will check
his own server logs, he will find that his own Exim 4.63 server permitted the
very thing he said it *could not*.
Bill
[1] His 4.63 did not disconnect. One of mine did. Ordinary Exim options, but
set to lower fault tolerance.
> <Stream of consciousness>
> And I had never known about the possible 554 code in the banner (part of
> 2821 3.1), and the resulting sequence in which anything but QUIT produces
> 503 bad sequence of commands and the server must wait for the QUIT. I
> wonder why a server would be written to do that? "I'm not going to talk to
> you but I'm going to waste our resources until you give up properly."
> </stream>
>
Legacy behaviour from simplex telegraphy, when turnarounds had to be agreed?
NNNN
