John C Klensin wrote:
Again, I believe that 5321 is quite clear on this. If someone
believes otherwise, please identify the text that leads you to
believe that RCPT following after RSET with no intervening MAIL
command is valid so we can try to get it fixed.
Reading RSET it says "Any stored sender, recipients, and mail data
MUST be discarded, and all buffers and state tables cleared."
Our code RSET() code will clear the sender address and looking at
Exim's smtp_reset(), it also clears the sender. Looking at Sendmail's
CLEAR_STATE(cmd) macro which has a more complex readability but I see
a dropenvelope() call and that seems to also clear envelope information.
This is what I believe what has always been implemented. I don't
believe it is a "Mulligan" or "Redo" last state concept. If this is
wrong, we need to correct it.
I think we need to clarify "Mail Transaction" where it begins and
where it ends. The spec says it starts with MAIL and I believe it
says it ends with DATA EOD.
So under that basis:
The following is valid because it hasn't started a mail transaction.
C: MAIL FROM:<FOO>
S: 530 User Not Authorized
C: AUTH LOGIN
The following is invalid because it clears the MAIL FROM:
C: RCPT TO:<USER(_at_)REMOTE-HOST(_dot_)COM>
S: 530 Authentication required for relaying
C: RSET
S: 250 OK
C: AUTH LOGIN
The following MAY BE invalid because it has started a mail transaction:
C: RCPT TO:<USER(_at_)REMOTE-HOST(_dot_)COM>
S: 530 Authentication required for relaying
C: AUTH LOGIN
and according to 2554/4954, it is not permitted to issue the AUTH once
a mail transaction has started.
From a practical standpoint, it make sense because authentication is
generally needed to be established before RCPT is issued simply to
determine Local vs Relay authorization at the most fundamental level
of SMTP operations.
However, this could be semantics based on private port 587 (SUBMIT) vs
public port 25 operations.
In other words, for us, under SUBMIT, the MAIL FROM: must be an local
account, under a public port 25, it is not enforced.
However, this was found to be a problem under public port 25 AUTH
operations where the AUTH identity did not have to be associated with
the MAIL FROM and the domain part was a locally hosted domain and the
user-id was illegal. In other words, if there was bounces, the mail
when back to LA-LA land.
S: 220-example-host.com ESMTP Server
C: EHLO client.example.com
S: 250-example-host.com Hello client.example.com
S: 250-AUTH LOGIN
S: 250 AUTH=LOGIN
C: AUTH LOGIN
.....
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<unknown-user(_at_)example-host(_dot_)com>
S: 250 OK
For bounces, if not the return path is verified, the mail is goes to
unknown return path. So what we do is check the user if the return
path domain is local under all auth, non-auth sessions, like if it a
4409 logic.
--
Sincerely
Hector Santos
http://www.santronics.com