Sergiu Dumitriu wrote: > Niels Mayer wrote: >> On Tue, Mar 10, 2009 at 2:53 AM, Lilianne E. Blaze < >> [email protected]> wrote: >> >>> And before someone says it's open source and I should stop bitching and >>> submit a patch - I _did_ submit a patch months ago :/ >>> >> Is this the patch: >> http://www.lilianne-blaze.net/temp_downloads/xwiki-mailsender%20patch%20v3/ >> Have you submitted it as an enhancement at http://jira.xwiki.org/ adding >> your patches as attachment? Does this patch work with 1.8RC2? > > The patch is attached to a JIRA issue. I was the one that rejected most > of the patch (I applied the authentication part), my motivation being that: > - the core needed to access the plugin > - the plugin depends on the core > - thus, in order to avoid cyclic dependencies which is a no-no for > maven, the plugin had to be moved back in the xwiki-core module, from > where it was just removed
Ok, how about rewriting the code in xwiki-core part to access the plugin via reflection with a fallback to current behavior? It will be ugly but it will work with no cyclic dependencies. And yes, I am volunteering to do it. > - the solution that was needed was to turn the plugin into a component, > independent of the core, and make the core depend on this component, > which has been the general strategy for upgrading code to the new > architecture > - the problem was that at the moment there was no way to access the data > from the wiki (the model component that we're postponing a lot), but now > the situation has improved with the addition of the model bridge, an > intermediate step between the current core and the future component model. > >> IMHO, there's so much going on at Xwiki.org JIRA is the only reasonable way >> they can get a handle on all the enhancements, fixes, bugs and figure out a >> roadmap to include them in future releases. >> >> Also, I was thinking, until your patch gets integrated, it might be simpler >> to let XWiki talk unauthenticated to SMTP bound only to localhost (not >> public): Then have sendmail/exim/qmail running locally, listening to inbound >> smtp connections. The localhost mail daemon would then relay messages from >> localhost to an authenticated external SMTP server (e.g.. gmail) by >> customizing the local mail sending daemon to jump through whatever hoops is >> needed. e.g. TLS, auth, passwords, etc. That way xwiki can concentrate on >> being a wiki, and let the vagaries of connecting to different mail daemons >> be a system administration task for whoever is admining the server. > > Indeed, this is why this change wasn't considered critical. You're completely overlooking the scenario where web server and mail server are physically or logically separated. Also many hosting providers simply refuse to have open smtp, even when it's bound to 127.0.0.1 only, and they're perfectly right about it - such configuration makes _any_ weakness in _any_ part of the server a potential spam relay. And once your server gets on any of the spam blacklists, it's very hard to get it removed. Greetings, Lilianne > >> Perhaps that is the logic behind not including more elaborate mail-sending >> functionality in XWiki -- it can be handled by an external program.... >> However, I must agree that authenticated email is pretty much the defacto >> standard and that XWiki needs to support this directly in the future. >> >> Also, you said: >> >>> registration mails still go via deprecated XWiki.sendMessage, which is >>> using Apache Commons SMTPClient (made obsolete by JavaMail ages ago) and >>> has no support for username/password and extra properties. >> >> This seems to contradict Sergiu's statement from a previous mail: >> >> The mailsender plugin uses JavaMail as the internal mail sender. Reading a >>> bit about the SSL/TLS support in it, I found that basically what you need >>> to do is define mail.smtp.starttls.enable=true. >>> >>> http://java.sun.com/products/javamail/javadocs/com/sun/mail/smtp >>> /package-summary.html >>> also lists mail.smtp.ssl.protocols and mail.smtp.ssl.ciphersuites as >>> SSL-related properties. >>> >>> Also, in order to be able to use secure sockets, the JSSE library must >>> be present in the classpath (I think it is with standard JDKs), and the >>> host must be able to accept the server's certificate. >>> >>> About the configuration part, the mailsender uses the >>> javamail_extra_props property in your global XWikiPreferences as a >>> standard .properties file (you will need to define it in the >>> XWikiPreferences class, as a TextArea property). >>> >>> So, basically what you need to do is: >>> >>> 1. Edit the XWiki.XWikiPreferences class and add a TextArea property >>> named javamail_extra_props >>> 2. Edit the XWiki.XWikiPreferences object and enter in it: >>> mail.smtp.starttls.enable=true >>> 3. Find out what else needs to be done on the JVM side to make TLS work. >>> >> So which approach will work best? > > Clarification: the mailsender plugin can be configured to use > authentication, but this plugin is not used for all mail sending > purposes. Specifically, there's the mail sent for activating an account > that still uses the deprecated XWiki.sendMessage method, which isn't > using the plugin (see above about the cyclic dependency). > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
