New GNOME components for geolocation, predictive text, and more

Posted Aug 9, 2013 12:43 UTC (Fri) by k3ninho (subscriber, #50375)
In reply to: New GNOME components for geolocation, predictive text, and more by mathstuf
Parent article: New GNOME components for geolocation, predictive text, and more

I don't know about replicating Akonadi, but having a persistent mailer daemon running and having apps send via some service sounds very much like 'those that don't understand Unix are condemned to re-implement it', where we're talking about an MTA and shell pipes. (I step back and say that there's a 'trusted' network of entry into the SMTP network that now needs additional credential information for send/receive, but local caches and separation of client from localstore so you can have a thin does-one-job-well client is The Unix Way, too.)

K3n.

New GNOME components for geolocation, predictive text, and more

Posted Aug 9, 2013 17:28 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

If the dbus API (I'm assuming it will have one) overlaps with Akonadi, then you would only have to run one of the two. Of course, it might also not do everything Akonadi does. I hope a common interface can be agreed upon where they do overlap.

New GNOME components for geolocation, predictive text, and more

Posted Aug 10, 2013 9:20 UTC (Sat) by krake (guest, #55996) [Link]

Whether it would be possible or rather say viable to implement that API on top of Akonadi will mostly depend on how much it assumes Evolution specific knowledge, e.g. paths, data formats, etc.

The other way around potentially be more tricky since all non-email data accessible through Akonadi would somehow have to be encapsulated in emails so that this API could be able to transfer it.

Having that said, this new API is more or less an augmentation or expansion of the Evolution Data Server approach, just using a set of daemons separate from the original EDS.

Akonadi is kind of in-between architecture wise: there is a central service that serves as a uniform data access point with a group of services implementing the actual storage access, mail sending, etc.
A bit like out-of-process plugins if you will.

New GNOME components for geolocation, predictive text, and more

Posted Aug 10, 2013 9:08 UTC (Sat) by krake (guest, #55996) [Link] (10 responses)

"aving a persistent mailer daemon running and having apps send via some service sounds very much like 'those that don't understand Unix are condemned to re-implement it'"

Actually no. It is exactly understanding Unix and using the same principles desktop session infrastructure that have proven so versatile for system infrastructure.

In this case having daemons take care about the outward facing email communication, enabling client developers to concentrate on the user interface instead of having to re-implement all kinds of protocols, exception lists, etc. again and again

New GNOME components for geolocation, predictive text, and more

Posted Aug 10, 2013 9:13 UTC (Sat) by dlang (guest, #313) [Link] (9 responses)

you obviously missed the conversation about Fedora wanting to remove any MTA from the default install.

That MTA was exactly the capability for apps in the system to send mail without having to implement it themselves.

New GNOME components for geolocation, predictive text, and more

Posted Aug 10, 2013 9:35 UTC (Sat) by krake (guest, #55996) [Link] (8 responses)

"you obviously missed the conversation about Fedora wanting to remove any MTA from the default install."

Yes, I wasn't aware of that.

"That MTA was exactly the capability for apps in the system to send mail without having to implement it themselves."

True, but their usefulness has been extremely limited by the rampant spam problem.
E.g. a lot of potential receiver MTAs are configured to not accept mails from MTAs on dynamic IP address ranges.

A stationary system can work around that by sending through the MTA of the ISP, a roaming system like a laptop can not.
A roaming system can work around it by sending to an MTA that accepts "outside" connections that are authenticated.

Unfortunately the common MTAs lack interfaces to make the necessary configurations, e.g. require access to config files that are protected from non-priviledged user access.

Of course those system MTAs might gain the necessary features at some point and be able to serve as a central mail handler for all user sessions again.

New GNOME components for geolocation, predictive text, and more

Posted Aug 10, 2013 19:00 UTC (Sat) by dlang (guest, #313) [Link] (7 responses)

> Unfortunately the common MTAs lack interfaces to make the necessary configurations, e.g. require access to config files that are protected from non-priviledged user access.

Well, if the problem is just the interface to change configs, wouldn't it be easier to change the permissions on the files, or create a nice GUI to configure the files for you rather than to create an entirely new API for sending mail?

New GNOME components for geolocation, predictive text, and more

Posted Aug 10, 2013 19:45 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (2 responses)

"Well, if the problem is just the interface to change configs, wouldn't it be easier to change the permissions on the files, or create a nice GUI to configure the files for you rather than to create an entirely new API for sending mail?"

No. You'd need to write code for every MTA to support per-user configuration, come up with a common format for that and get it all merged upstream. There's no way that that would be easier than creating an entirely new API for the sole purpose of sending email.

New GNOME components for geolocation, predictive text, and more

Posted Aug 11, 2013 0:08 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

no, all you need to do is to produce a GUI tool that works with your distro's default MTA. If this is the critical issue that you think it is, users of the other MTAs/Distros will extend it

I remain unconvinced that the fact that the configuration requires admin privileges is a real problem.

New GNOME components for geolocation, predictive text, and more

Posted Aug 11, 2013 0:32 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

The point of an API is that its behaviour is predictable regardless of the implementation. Tying all the system mail clients to a specific implementation of that API means that they'll all mysteriously break if the admin decides to replace sendmail with, say, exim. So, instead, applications would have to use some other interface than /usr/bin/sendmail, which is where we started in the first place.

"I remain unconvinced that the fact that the configuration requires admin privileges is a real problem."

The modern world considers mail to be per-user configuration, not per-system. If you're maintaining a lab with a bunch of users who want to be able to use Thunderbird with their gmail accounts, are you really suggesting that the appropriate thing to do is for the admin to add their gmail credentials by hand?

New GNOME components for geolocation, predictive text, and more

Posted Aug 11, 2013 0:58 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Ok, let's see.

We live in the post-spam age, so MTAs in their default configurations can't send email much further than the local network. So we just need to add some relay server to MTA, right?

Ok, let's start doing it. How do we allow users to edit configuration files? What about multiple users? Hmm...

Ok, suppose we have managed to force Postfix, Exim and Sendmail to use per-user configuration files somehow (I'm not sure it's possible out-of-box). But where do we store logins and passwords? Are you're saying something about plain-text config files?

Ok, we've added integration with the system keychain using its D-BUS API (well, since we had to patch all the major MTAs to support per-user configs another small patch doesn't matter much).

"But we're using Exchange!" someone cries. Well, no problem. We'll just add appropriate LDAP configuration, integration with centrally-managed certificate system and a couple of other systems that I'm forgetting right now. Those folks maintaining Postfix, Exim and Sendmail surely won't object to a couple of megabytes of patches!

"But how do I see the sent emails to make sure that a malicious script isn't sending lewd emails to my address book?",- a shrewd user asks. We don't have a good answer, so we connect this user to a 10KV mains line, solving this problem BOFH-style.

But we've preserved /usr/bin/sendmail in the true Unix tradition!

New GNOME components for geolocation, predictive text, and more

Posted Aug 11, 2013 9:29 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

if you think per-user authentication prevents spam, you aren't living in the same world that I am.

I'm not saying that the system MTA should have per-user configs, but I'll also point out that the vast majority of systems are single-user, so per-user config and per-system config are the same in most cases.

New GNOME components for geolocation, predictive text, and more

Posted Aug 11, 2013 12:51 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> if you think per-user authentication prevents spam, you aren't living in the same world that I am.
Hmm. Are you living on Mars, perchance?

Authenticated mail submission is pretty much mandatory these days. Of course, in some cases you authentication can be passwordless (send-after-receive or trusted local network). But it's still there, because only specially set up systems can successfully deliver mail these days.

> I'm not saying that the system MTA should have per-user configs, but I'll also point out that the vast majority of systems are single-user, so per-user config and per-system config are the same in most cases.
Sure. But you still have all the other problems I've pointed out.

New GNOME components for geolocation, predictive text, and more

Posted Aug 11, 2013 10:56 UTC (Sun) by krake (guest, #55996) [Link]

I am not sure it would be easier because it requires buy in from a lot of third parties.

It would require that all distributions make their MTA configs world writable or at least group writable and put all user accounts into that group.

It would also require world/group triggerable reload commands.

Then you need buy-in from all MTA projects on the matter of config file format stability, ideally all of them using the same format, but at least guaranteeing that the format will not change.

For multi user systems you will need buy-in from the system administrators who need to ensure that those files are on a filesystem that provides reliably file locking.

On such systems you will also need buy-in from users that their individual mail configs will be inspectable by all other users.

Given those considerations my take would be that it is way harder to solve the problem that way than to provide a user session service.

At least medium term, MTA vendors might at some point offer capabiltities for user mails.