Would it be possible to add support for POP3 (non-s) (ie port 110).
On my server, discourse and the pop server are both on the same server, so there is no need to encrypt the session (anyone with access to the connection already has access to the data at either end). The POP3 server I use is a custom server that doesn’t require unix-level accounts and so is very safe (any security issue would compromise only a minimal permission account).
I added support for POP3 in discourse simply be editing app/jobs/scheduled/poll_mailbox.rb near line 43:
if SiteSetting.pop3s_polling_port.to_i != 110
Net::POP3.enable_ssl(OpenSSL::SSL::VERIFY_NONE)
end
Basically, if the port is 110, don’t use SSL. Now obviously it would be better to have a UI switch for POP3/POP3s, but at least this got me working and proved that the change is trivial at the engine side.
Thanks.
1 Like
Sure a PR to add a setting for this would be great.
OK, so is there a dummies guide to getting started with this?
I can program, and I’m sure I can hack on ruby without problems, but I have no experience with git or docker.
I’ve read discourse/CONTRIBUTING.md at master · discourse/discourse · GitHub which is impressively complex (presumably because I’m not used to git), but it does not explain how to get from at docker install to something I can clone/checkout/fetch/rebase whatever.
I did the git clone git://github.com/discourse/discourse.git into /var/work along side the /var/www inside the docker shell so I could compare them. Other that the git differences, and some probably runtime files, there is the www/discourse/config/discourse.conf file and the log, plugins, and public (like assets) and vendor subdirectories. It’s not clear to me how I get something checked out from git while retaining the rest of the files necessary for the server to run.
I’d also like to know what I need to do after making a change to ensure my server is running the changes (what restart command is needed).
And optionally, it would be nice to know if it is possible to run a second copy of discourse (say on a different port) so that users wouldn’t see any of my hacking until it comes through. I suppose I could set up yet another instance at digitalocean and hack there. Sharing the database and settings would be fine. And for the moment, I can just hack away as I haven’t invited many people to try out discourse yet, but down the tack it would be less than ideal to keep messing up the site.
Anyway, a few hints or some additional explanations in the CONTRIBUTING.md file would certainly make it reduce the barrier to people helping. Thanks.
1 Like