Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
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 (subscriber, #55996)
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.
Posted Aug 10, 2013 19:00 UTC (Sat) by dlang (✭ supporter ✭, #313)
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?
Posted Aug 10, 2013 19:45 UTC (Sat) by mjg59 (subscriber, #23239)
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.
Posted Aug 11, 2013 0:08 UTC (Sun) by dlang (✭ supporter ✭, #313)
I remain unconvinced that the fact that the configuration requires admin privileges is a real problem.
Posted Aug 11, 2013 0:32 UTC (Sun) by mjg59 (subscriber, #23239)
"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?
Posted Aug 11, 2013 0:58 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
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!
Posted Aug 11, 2013 9:29 UTC (Sun) by dlang (✭ supporter ✭, #313)
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.
Posted Aug 11, 2013 12:51 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Aug 11, 2013 10:56 UTC (Sun) by krake (subscriber, #55996)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds