From: justin@PROTECTED

On Aug 24, 2020, at 3:24 PM, webmaster@PROTECTED webmaster@PROTECTED [Dada Mail Developers] dadadev@PROTECTED wrote:From: webmaster@PROTECTED

I think the below settings under MAILING LIST/Options essentially do that.

Well, that's security through obscurity. All that really does is hide what the list short name is, but that can be found easily through the email headers that are sent through the discussion list - it's literally this line:

List: dadadev 

Then since you know the list short name, you can just log in as normal.

Except that nobody has a Dada account, so nobody can log in (as you propose below) other than the admin. But yes, absolutely security by obfuscation. And yes, I’d totally welcome the additional layer of security.

What I'm proposing is not allowing anyone to log in at all. You'd have to flip a global config variable to allow it. When I'm thinking security, I'm not really just thinking of subscribers snooping around looking for a way to log in; I'm thinking bad actors that are going to log in, then send out spam using your mailing list (or steal information, like your subscription list).

The only way we’ve ever seen spam on any of our lists is when someone’s subscribed email account was compromised. I deal with those with immediate unsubscription, which means I have to personally intervene. But no email list is really protected against that.

My Joomla extension interfaces to Dada Mail through MySQL database queries. The only “accounts” are my website member accounts, and those authorize the members to utilize the email lists.

Which is a little dangerous, as it does circumvent all sorts of safety checks like: are you saving a setting that actually exists? Is it a valid value for the setting? Stuff like that. It works - and if it works for your use, fine with me, but it isn't a robust solution - I'm not guaranteeing that method your using will work in the next release (but it has for forever). Your plugin isn't something that's even publicly available atm, is it?

Dangerous? Not so much as it is a tad risky. Of course I carefully studied all of this before I even attempted to integrate Dada Mail in this way. And obviously if you change how you do something it could break my plugin’s abilities. But I would then adapt the plugin to the new method/data and release a new version that is compatible with that version of Dada Mail. And actually, my plugin has always been open source under GPL and available to the public. It used to be published on JoomlaForge, but since they de-funded that and moved to Github, all my stuff is there now. https://github.com/bascherz/Dada-Mail-Subscriptions-CB-Plugin is the plugin being discussed here if anyone is interested.

And that is the part of the application I am wondering if I can safely remove somehow; the templates, the editors, the themes, the Captcha stuff, you know…all the stuff needed to support securely editing and sending emails from a web browser.

Things are written in the opposite way. Bridge is the add-on plugin, not the other way around. So thinking one can just turn things inside out is a little unrealistic.

I get that. But maybe more parts could be written as plugins? Just brainstorming here.

--

Justin J: Lead Dadaist.url: http://dadamailproject.com email: justin@PROTECTED twitter: @dadamail skype: leaddadaist

Dada Mail Announcements:http://dadamailproject.com/cgi-bin/dada/mail.cgi/list/dada_announce/

Dada Mail Developers