Allow custom EHLO after RSET again #270
Conversation
conn.go
Outdated
| if c.session != nil { | ||
| // RFC 5321: "If it is issued after the session begins | ||
| // and the EHLO command is acceptable to the SMTP server, ..." | ||
| if !c.fromReceived { |
There was a problem hiding this comment.
Hm, I don't quite get why this condition is here. Why do we need to skip reset() when the client has sent MAIL FROM?
There was a problem hiding this comment.
It's what I found in the connection that may be usable for the condition "if it is issued after the session begins".
If I interprete the RFC correctly, then only in this case, EHLO acts like RSET.
It's not stated what should happen if it's issued not at the start of the session (or not after a RSET), though.
Maybe we can find out by examining some example sequences
EHLO // <-- session begins (no buffers and tables to be cleared anyway)
MAIL FROM
RCPT TO
DATA
RSET
EHLO // <-- redundant to previous RSET, but allowed
MAIL FROM
RCPT TO
EHLO // <-- should have not RSET effect
DATA // should then probably be okay (from, rcpt tables still there)
RSET
There was a problem hiding this comment.
"Session begins" just means that a TCP connection is opened no?
There was a problem hiding this comment.
Intersting question. If so, then do you think that an EHLO after RSET should not be passed to the session as Reset()? Then I wonder how the session would become aware of the new EHLO argument.
There was a problem hiding this comment.
My point is that we should probably always call c.reset(), even in the case where MAIL FROM was sent by the client (that's what fromReceived means).
There was a problem hiding this comment.
Okay, I can do that. I'll update the PR.
There was a problem hiding this comment.
But feel free to adapt it to your likings and code style etc.
emersion
force-pushed
the
fix/ehlo-after-rset
branch
from
a56e6c2 to
2a51e89
Compare
Resolves EHLO after RSET #269