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?
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
....
A client SMTP SHOULD start an SMTP session by issuing the EHLO
command.
.....
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";
--
HLS