Per RFC 5321, sections 4.1.1.5 and  4.1.4, issuing an RSET command
should not result in the HELO/EHLO domain being removed from the
session.

From section 4.1.1.5:

> It is effectively equivalent to a NOOP (i.e., it has no
> effect) if issued immediately after EHLO, before EHLO is
> issued in the session, after an end of data indicator has
> been sent and acknowledged, or immediately before a QUIT.

And:

> Since EHLO implies some additional processing and response by the
> server, RSET will normally be more efficient than reissuing that
> command, even though the formal semantics are the same.

Based on RFC 5321, section 4.1.4, any stored values should be reset
if a HELO/EHLO command is sent subsequent to the original:

> An EHLO command MAY be issued by a client later in the session.  If
> it is issued after the session begins and the EHLO command is
> acceptable to the SMTP server, the SMTP server MUST clear all buffers
> and reset the state exactly as if a RSET command had been issued.  In
> other words, the sequence of RSET followed immediately by EHLO is
> redundant, but not harmful other than in the performance cost of
> executing unnecessary commands.