You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 28, 2019. It is now read-only.
I was going to take a stab at implementing AUTH (probably LOGIN first) and wondered if @hanswolff had any suggestions for implementing the announcement and subsequent acceptance of credentials from the client.
I can extend SmtpCommandParser with a new ProcessCommandAuth, which handles the AUTH command along with the username, however this request then requires a subsequent send by the client of the password following a 334 (I think) response. This subsequent send does not contain a command parameter, only the password.
Here is a diff on a feature branch (sorry the commit is such a mess, it is just a spike and I inadvertantly included some superfluous code.
I haven't really looked how the AUTH works for SMTP. But your code looks okay so far. If I find time today I'll read about AUTH and see what is the best way to integrate it.
Thanks. The toughest part is determining how to best handle the response from the client after the auth request, which doesn't actually contain a command, only the credential, so I can't use the standard ProcessCommandX pattern you have in place, so I wondered the best way to wait for that data. I suppose it would be similar to how you handle receiving the mail following the DATA command.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I was going to take a stab at implementing AUTH (probably LOGIN first) and wondered if @hanswolff had any suggestions for implementing the announcement and subsequent acceptance of credentials from the client.
I can extend SmtpCommandParser with a new ProcessCommandAuth, which handles the AUTH command along with the username, however this request then requires a subsequent send by the client of the password following a 334 (I think) response. This subsequent send does not contain a command parameter, only the password.
Here is a diff on a feature branch (sorry the commit is such a mess, it is just a spike and I inadvertantly included some superfluous code.
Link to ProcessCommandAuth
Any preference on how you would like this type of a workflow implemented?
The text was updated successfully, but these errors were encountered: