D351
Public
Seen by 93
I posted this idea to D* moments ago, but thought it a realistic enough idea to also post here. I think it'd be a good idea for every D* account to include a basic email account that operates through the messaging system. This way, one's D* account name (already in email format) could also be an email address, further integrating D* into a user's online activity and allowing for more visibility for D* servers.
D351 Sat 24 Jan 2015 3:48PM
Fair enough... Would it be possible for it to allow a user to receive some form of information when email bounces that was directed to their D* account, or would this still fall under the port problem? Or, alternatively, could a bounced email be auto-responded to that explains that a D* account is not an email account (as opposed to the generic user-does-not-exist message that they're going to receive from their email provider)?
Morgan McMillian Sat 24 Jan 2015 3:50PM
It takes a lot to maintain an email service. SPAM filtering alone can consume a large amount of resources. It's not something I would recommend doing. And as a user I certainly wouldn't want yet another avenue for junk email to find it's way to me.
Jonne Haß Sat 24 Jan 2015 3:56PM
This is simply not possible on most PaaS platforms without deep specific work & integration from the application and the system administrator. The idea came up in the past, I don't think it's feasible as a widespread mainstream feature.
The other argument is that more and more services use the same format, most popular Jabber/XMPP, which exists longer than Diaspora and can live without such an integration just fine.
It occurs easily that such a confusion might come to mind, but I think it's actually a lot rarer than we all assume.
Past discussion for reference:
* https://github.com/diaspora/diaspora/issues/3758
* https://github.com/diaspora/diaspora/issues/1056
Morgan McMillian Sat 24 Jan 2015 3:57PM
@d351mims it's actually entirely up to the podmin how they choose to manage their domain ultimately. If they want to setup the MX records, and manage response, bounces, etc then that's exactly what they can do. However if they choose not to and leave port 25 closed, any email server attempting to deliver will ultimately fail and send the notification back to the sender.
D351 Sat 24 Jan 2015 4:06PM
Well, okay then. I was not aware that this was such a complex subject.
Jason Robinson Sat 24 Jan 2015 6:47PM
It would be cool if someone knowledgeable in the subject could take time to include in the wiki a page for a recipe to create email forwarding to a common linux server so that emails are captured coming to the diaspora handle and forwarded to the users email address they have in diaspora. Then podmins can do that if they want, but it shouldn't and cannot be a part of the core, as explained above.
lub · Sat 24 Jan 2015 3:32PM
Maintaining and operating a email server means a lot more work than a diaspora pod. Also it needs additional ports, which is not possible everywhere (for me it would mean I need to shutdown my own email server running on the machine which is hosting my diaspora pod)