app
app copied to clipboard
simple-login
Send via SMTP support for aliases
This PR add ability to send via SMTP for aliases. With this emails can be sent directly from aliases via SMTP without the need for creation of reverse-alias.
If enabled, Every alias will have a unique password (generated client side) for SMTP access. Username will be same as alias.
This adds a global option in Settings to enable this feature, without enabling this option, SMTP access will remain disabled for the user.
Note: Even after enabling this option in settings, you would still need to enable SMTP individually per alias. This will also disable receiving via reverse-alias for that particular alias. i.e. Sender's original address will be displayed in "From:".
SMTP server address should ideally be the same where your app is hosted (but this depends on your configuration) SMTP port: 465 This would need SSL cert/key file as SMTP would be over (implicit) SSL.
This should resolve #679
The screenshots below will make it more clear on how it would operate:
- First enable "SMTP for Aliases" from Settings Page:
- Then on the Aliases page, select "More" on an alias and a new toggle, to enable SMTP, will have appeared below "Pin this alias":
- After toggling it, SMTP credential will be generated for that alias:
- This will also disable receiving via reverse-alias, for that particular alias. i.e. Sender's original address will be displayed in "From:"
Great job! Thanks @sahilph. I think this is definitely a valuable feature. The only point I currently find somewhat awkward is that each alias would get their own credentials. My thought for this feature is that users should be able to connect to the SMTP server using a generic credential, and the SMTP server would automatically detect which specific alias should be used to send the email by looking at the address the user is replying to, and other information that available. This way, users would only have to add their credentials once to Gmail's send-as feature or local email client, and reply to emails sent to any alias with the generic credentials.
@developStorm Thanks for you feedback.
One of the main reasons I developed this was to use Gmail "Send mail as:" feature. And It requires users to add "From:", and username and password for every alias. So even if there was a single generic credential, users will have to manually add the alias in Gmail anyways. So I thought of adding separate credentials, which would make the authentication handling easier.
Also consider one more scenario. Suppose the aliases are getting generated on-the-fly and I want to give a email to website say [email protected].
Now [email protected] is not the alias which I ever send email from, but for some reason the website needs replying from that email, even if there was generic credential then I would have to again add that alias in Gmail's "Send mail as:" anyways.
In the current scenario, since we can enable SMTP per-alias-basis, a reverse-alias will automatically get generated and replying will be easier as I can just reply via reverse-alias.
Also I'm not sure how to authenticate and validate, if there was only a single generic credential present. If you have any ideas please let me know and I can implement it.
@sahilph The idea is that the SMTP server does not need to honor the From specified in "Send mail as:" feature. So we can just put a dummy From there and let the SMTP server figrue out which From (alias) should be used based on the mail content that is being sent. How to determine right alias to use is a problem though, I'm thinking that we can use the recipent's address but I'm not sure if that's necessarily accurate. Any thoughts on this?
@developStorm While it would be very convenient to have such a feature, I can't really think of a way of implementing this without reading From: field :sweat_smile:.
@sahilph We just have to guess ;-) For example, if the incoming email to SL SMTP server looks like:
MAIL FROM: [email protected]
RCPT TO: [email protected]
Then now SL SMTP server can guess: "hmm the authenticated user has a recent interaction with [email protected] on alias [email protected], so we should change the From to [email protected]". SMTP server then delivers the reply on behalf of [email protected] to [email protected] to example.com's SMTP server.
@developStorm I don't think we should rely on guesswork while sending emails.
Also what about sending to someone who we have never sent before ?
@sahilph Yeah guess is not a perfect idea, but I think it's worse to have user add every single alias they have, when they have let's say 50+ aliases and need to be able to reply as all those aliases.
For new recipients, user can manually add them on SL portal before they proceed, as what they have to do now to obtain reply address.
Yeah guess is not a perfect idea, but I think it's worse to have user add every single alias they have, when they have let's say 50+ aliases and need to be able to reply as all those aliases.
User don't have to add every single alias. They only need to add the ones they usually send from. For other aliases those who dont have SMTP enabled, sending via reverse-alias is still possible
For new recipients, user can manually add them on SL portal before they proceed, as what they have to do now to obtain reply address.
Then what's the point of SMTP? users can do that already do that using reverse-alias.
The whole point of SMTP access (and this PR) is that, if users want to send emails from the aliases they most often send from, there would be no need of creating reverse-alias. Users can just the emails using their aliases via SMTP using their favorite email client. No need to manually login to SL portal and create reverse aliases everytime.
For other non-frequently used aliases, use the reverse-alias method as that would still work.
TL;DR: For sending via most-frequently used alias -> Use SMTP ; otherwise -> use the regular-reverse alias method.
@developStorm Check out #679 as to what I mean. I was facing similar issues. Here are a few comments highlighting the issue: https://github.com/simple-login/app/discussions/679#discussioncomment-1622066 https://github.com/simple-login/app/discussions/679#discussioncomment-1622905
The PR looks really good! I haven't run it though, it'd be great if you can include how to test this new service in the CONTRBUTING file.
I left some comments, lots of them are rather nits though.
@nguyenkims Thanks for the review
I have added how to test this in the CONTRIBUTING file. I have also done some fixes as per you comments. Please check.
Also, It seems like PyCharm does not have a consistent reformatting settings across different versions for html files. I have now guessed and set the reformat settings and they now seem to match with this repo.
Hello @nguyenkims , I was wondering whether you got time to look into this?
Hello @nguyenkims , I was wondering whether you got time to look into this?
@sahilph Yes we have extensively discussed about the PR during our team meeting :). Before enabling this SMTP server, we need to make sure it is scalable and has a good anti abuse system.
Yes we have extensively discussed about the PR during our team meeting :). Before enabling this SMTP server, we need to make sure it is scalable and has a good anti abuse system.
That is good to hear. :)
Scalability wise, I think it should be fine as you already use aiosmtpd, and I believe it works good enough.
For anti abuse system as I mentioned in the above comments, we could use Fail2ban for this port, they allow for creation of custom filters quite easily. Then later we are sending it to postfix anyways, there it can handle SPAM.
So Basically the flow can be like: Port 465 (Protected by Fail2Ban) -> SMTP_Handler.py -> Postfix (SPAM handling) -> Final Recipient
I think we can merge the PR and it can be used as-is for the self hosting.
Oh that's nice.
For SimpleLogin.io version, I think we need to figure out a way to have Postfix protecting this new service.
Yes, if we could figure out a way to make postfix talk to python, that would be great as that is the only thing preventing this from happening.
Hey, nice PR. But as a general comment, there aren't any tests added. I would suggest to add some:
- Creating the SMTPCredentials does what it's supposed to and that passwords can be validated
- The SMTP handler is able to receive connections, authenticate/fail, and deliver the messages to where it's expected.
@acasajus Thanks for the feedback. Yes, I understand that there are no tests, and I can certainly write some if needed, but I believe, ideally, tests should be written by someone else, because if I also write tests for this, it will be highly biased. (I certainly don't want my one code to break now do I ? :grin: )
@sahilph @acasajus Having tests for every PR is indeed a good idea. We actually set a limit in terms of code coverage under which a PR won't pass the CI. And tests should be written by the PR author :). It happens several times that writing tests help discover cases that we don't realize during the development. We are not extreme in terms of test coverage though but there should be enough tests to cover the most frequent cases.
Yeah, I am following this with great interest as well.
I purchased a year of SL and love much about the service and have brought 2 of my domain on board.
After using for a couple of weeks though and mucking with the reverse alias system and clogging my contacts up with extra redundant emails in their profiles, this is the one part that feels clunky.
Really hoping this is solved with this above proposed solution. If no way to "send as" SL aliases from email client arrives in a year when renewal arrives, I would have to consider pulling my domains and finding a service for email support and relegate SL to just throwaway emails on their domains.
I am hoping a way will be found, as I love SL so far and would love for it to fit.
I'm not sure i get the point of this function, seen as SimpleLogin is indeed not meant to be a transactional email service. But if there are other use cases for this function, then i would say, "why not".
What exactly is holding this back? This has been sitting in a completed state for so long, how can we get it over the line?
@nephalemsec @edsimpsons83 the PR isn't complete. We asked for adding tests into it (among other things) and haven't received any news yet. And please keep in mind that this PR is rather for self hosting. To make it available on SL.io, we need to adapt the infra and work on an anti-abuse system first.
@nephalemsec @edsimpsons83 the PR isn't complete. We asked for adding tests into it (among other things) and haven't received any news yet. And please keep in mind that this PR is rather for self hosting. To make it available on SL.io, we need to adapt the infra and work on an anti-abuse system first.
Understood. As @sahilph has stated he believes there would be a bias with the PR author making unit tests is there a plan for SL team to assist?
@nephalemsec providing unit tests should actually be part of the PR and it is up to the author to write tests.
I'm not sure i get the point of this function, seen as SimpleLogin is indeed not meant to be a transactional email service. But if there are other use cases for this function, then i would say, "why not".
Sadly i didn't get a reply from someone explaining the purpose of this function to me. :(
I'm not sure i get the point of this function, seen as SimpleLogin is indeed not meant to be a transactional email service. But if there are other use cases for this function, then i would say, "why not".
Sadly i didn't get a reply from someone explaining the purpose of this function to me. :(
To be able to send from an alias without needing to log into the SL interface comes to mind.
So, is this PR just dead now after 6 months? Is there any intent on supporting this feature? Would be nice to actually be able to use SL as a way to send emails from an alias similar to the way iCloud Plus currently lets you do it.
