#71Allow paying users to send email from an alias

A great feature for paying users would be the ability to send/receive emails from a custom domain. I hope that I haven’t simply made a mistake during my configuration, though hopefully others are interested in this being a more apparent feature as part of having a premium membership.

I’ve attempted to configure a domain of mine to facilitate email, though have only be able to receive email. When attempting to send an email with a configured alias, I get a cryptic ‘can’t send message’ notification. Naturally, since I don’t have access to the email logs, I assumed that this may be due to improper SPF records though making this change did not allow me to send a message. I’ve attempted to look for a solution via Rainloop’s documentation though it appears that sending from another domain would be enabled/disabled during the configuration. While the addition of enabling use of external domains via aliases, if this is indeed the problem I’m running into, is most likely disabled to prevent issues with spamming or triggering various blacklists for many of the more stringent organizations.

A great feature for paying users would be the ability to send/receive emails from a custom domain. I hope that I haven't simply made a mistake during my configuration, though hopefully others are interested in this being a more apparent feature as part of having a premium membership.
I've attempted to configure a domain of mine to facilitate email, though have only be able to receive email. When attempting to send an email with a configured alias, I get a cryptic 'can't send message' notification. Naturally, since I don't have access to the email logs, I assumed that this may be due to improper SPF records though making this change did not allow me to send a message. I've attempted to look for a solution via Rainloop's documentation though it appears that sending from another domain would be enabled/disabled during the configuration. While the addition of enabling use of external domains via aliases, if this is indeed the problem I'm running into, is most likely disabled to prevent issues with spamming or triggering various blacklists for many of the more stringent organizations.

I’m positive this worked at some point in Teknik’s history, since you led me to confirm that I still have an identity configured in Teknik’s webmail (served by Rainloop) and clearly remember sending emails from it, although only teknik.io domains can be set as extra accounts.

The reasoning for not allowing this, is usually service abuse by spam senders.

I'm positive this worked at some point in Teknik's history, since you led me to confirm that I still have an identity configured in Teknik's webmail (served by Rainloop) and clearly remember sending emails from it, although only `teknik.io` domains can be set as extra accounts.
The reasoning for not allowing this, is usually service abuse by spam senders.

Thank you for clarifying. I am under the impression that if this were restricted to those who make monthly payments to dissuade misuse, it may be an interesting feature to offer. I’m sure that this wouldn’t stop those who send spam so maybe this simply isn’t feasible for the time being due to the increased amount of work (and therefore labor costs) that this would introduce.

I will close this issue for now so that I do not add clutter to the issue tracker though I hope this is something that might come under review in the future.

Thank you for clarifying. I am under the impression that if this were restricted to those who make monthly payments to dissuade misuse, it may be an interesting feature to offer. I'm sure that this wouldn't stop those who send spam so maybe this simply isn't feasible for the time being due to the increased amount of work (and therefore labor costs) that this would introduce.
I will close this issue for now so that I do not add clutter to the issue tracker though I hope this is something that might come under review in the future.

No problem, but please re-open it. You’re far from cluttering, in my opinion.

@Uncled1023 (admin) is on vacation right now but I’m sure he’ll take a look at it when he’s back.

Also, I don’t think spammers donate for premium accounts to send out spam (actually most spam is script-automated) so it might be a good idea, since premium accounts already have a couple of benefits over standard ones.

No problem, but please re-open it. You're far from [cluttering](https://git.teknik.io/Teknikode/Teknik/issues/68), in my opinion.
@Uncled1023 (admin) is on [vacation](https://blog.teknik.io/uncled1023/p/382) right now but I'm sure he'll take a look at it when he's back.
Also, I don't think spammers donate for premium accounts to send out spam (actually most spam is script-automated) so it might be a good idea, since premium accounts already have a couple of benefits over standard ones.

I think if there is a one-time payment system that provides this feature it might cause an interest with certain types of spammers, but if it was tied in with a monthly subscription or 1-year payment this could work as a deterrent. I suppose if email for this type of system was isolated to a VPS (or another dedicated server) that had a block of IP’s to rotate through after the problem users were identified this could be rather reliable.

Noted, I have reopened this issue.
I think if there is a one-time payment system that provides this feature it might cause an interest with certain types of spammers, but if it was tied in with a monthly subscription or 1-year payment this could work as a deterrent. I suppose if email for this type of system was isolated to a VPS (or another dedicated server) that had a block of IP's to rotate through after the problem users were identified this could be rather reliable.