[Top] [All Lists]

Re: RFC2821bis-01 Issue 3: EHLO parameter

2007-03-31 02:20:42

Robert A. Rosenberg wrote:

At 06:25 -0400 on 03/30/2007, Hector Santos wrote about Re: RFC2821bis-01 Issue 3: EHLO parameter:

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

Raising an issue about EHLO/HELO verification and Port 587/SUBMIT, I have the impression (possibly erroneous) that Port587 use requires a SMTP AUTH handshake.

Yes, RFC 4409 section 3.3 and 4.3 discusses the requirement.

As I understand and have implemented SUBMIT (RFC 4409) authentication is a requirement and SMTP-AUTH is the primary method. But there are other traditional BCP methods that predated SMTP-AUTH and is considered a local policy decision to what authentication method is acceptable.

> If so, then use of HELO on Port587 should IMO be
banned (ie: Any attempt to use it to start the session should be rejected with an invalid command reply) since only EHLO will return the 220 list of supported commands - in particular the AUTH that lists the acceptable Handshake protocols (PLAIN/LOGON/CRAM-MD5/etc.). If I go HELO I am not informed of the valid handshake methods even if I can assume the AUTH is supported. I've seen sites that ONLY offer CRAM-MD5 (but not PLAIN or LOGON) due to PLAIN and LOGON being fake "security by obscurity" that fails to protect if the session is being monitored/recorded (both send a constant reply that just needs to be unBASE64'ed to see the actual USERID/PW Pair).

Isn't this covered with the use SHOULD use EHLO requirement in 2821bis?  Extended HELLO (EHLO) or HELLO (HELO)

   A client SMTP SHOULD start an SMTP session by issuing the EHLO

I guess, maybe another sentence like?

  Please note, when using SMTP under the SUBMIT Protocol [RFC4409],
  the client MUST start a SUBMIT session by issuing the
  EHLO command.

However, hmmmmmmm, that has the potential to break SUBMIT software implementations that don't force SMTP-AUTH and allow legacy HELO only clients but are IP authenticated via port 587.

Our software by default has admin SMTP domain options that include:

  [X] Enable PORT 587 (SUBMIT) Server
      [X] Force SMTP-AUTH

If the "Force SMTP-AUTH" is disabled, the SUBMIT client will not get pass MAIL FROM unless the client is authenticated another way. Under SUBMIT, the client must be authenticated by the time it reaches the MAIL FROM state.

I have to check but I think our software has a global session flag set for "Authenticated" and a MAIL FROM state machine logic has something like:

   if ConnectedViaPort87 and not Authenticated then
      response = 530 Authentication required";

and FWIW, a similar RCPT TO state machine logic that says:

   if Not LocalRecipient and not Authenticated then
      response = 530 Authentication required for Relay";