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.

Note: This discussion was imported from Loomio. Click here to view the original discussion.

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)

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)?

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.

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:

@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.

Well, okay then. I was not aware that this was such a complex subject.

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.