At 12:58 31-05-2011, Hector Santos wrote:
In regards to authentication, in our code, for IP based (Relay Tables,
POPB4SMTP), it can not change the authentication based on IP. For
ESMTP AUTH, once the session authenticated, per RFC2554, section 4, it
will not allow another AUTH to be issued with a 503 response.
Is your implementation compliant with RFC 2554 or RFC 4954?
Our server is compliant with RFC2554 and related AUTH docs in regards
with RFC3207 (TLS) and RFC4409 (SUBMIT), i.e. important sequence to
I don't recall using the update RFC4954 nor searching "4954" in the
source code show any specific references which is normally how we
annotate RFC update related protocol logic changes.
A quick perusal seems to show it combined many of the related docs.
i.e. TLS, SUBMIT.
It seems the same restriction in 2554 was carried over to 4954 in
After an AUTH command has been successfully completed, no more
AUTH commands may be issued in the same session. After a
successful AUTH command completes, a server MUST reject any
further AUTH commands with a 503 reply.
The AUTH command is not permitted during a mail transaction.
An AUTH command issued during a mail transaction MUST be
rejected with a 503 reply.
So a RSET, imv, must not alter this authentication condition because
the client has a protocol design restriction (thus not coded to
re-authenticate) and the server will not allow it anyway. Our server
will issue an AUTH response:
503 Invalid AUTH request. Already Authenticated
Same applies with IP based because there is no way for the client to
change the IP during the same session.
Like Keith indicated, we don't have a "logout" feature.
Anyway, I don't quite see the complication with authentication and
"reset" because there is nothing in SMTP AFAIK that currently allows it.
On a related note, there is one change our SUBMIT server does in
regards to authentication and the growth of NATS usage. This was
noted to Klensin and Resnick to relax the EHLO checking requirements
until the AUTH state is determined.
Since 4409 requires AUTHentication, it can delay the EHLO checking
because depending on the MUAs being used on a private network LAN
going over the wire with a NAT public address, there will be potential
of an IP mismatch.
Connecting client IP: 184.108.40.206 <---- NAT public address
S: 220 host.example.com ESMTP Server ready
E: EHLO [192.168.1.101] <---- IP where MUA is on LAN
This would be an SMTP violation enforceable under port 587 (RFC4409)
So our SMTP server has an option (on by default) that when port 587 is
active, it will relax this EHLO IP literal filter check until the
pending and required AUTH state is determined.
That was the workaround until the popular Thunderbird MUA was updated
and TBIRD now offers MTA options to set the EHLO client domain name or
IP literal since its not easy to detect what will be the NAT public
address. Since it was a quick fix, no user UI was added and it must be
done manually by editing the config file under TOOLS | OPTIONS | ADVANCED.