Re: [xwiki-devs] [xwiki-users] SMTP authentications
Norguir Bellagio wrote:
Hi,
I have crawled the mailing lists and support forums on this but I am unable to figure out the answer.
I am evaluating Xwiki and love Workspaces from what I've seen so far. The one thing that really bogs me down is the inability to register an authenticated SMTP server. I have read there is a patch from Liliane, and the feature is included on 1.6 but I just can't seem to understand how to get is to work. In an evaluation perspective (and very much so as well in production), not being able to use authenticated SMTP server is a no go for me. Could you please point me to a resource that clarifies what the situation is and possibly, the steps to enable it on 1.7.
Thanks !
norguir
Actually I'm still waiting for it :/ I just made a quick check and it looks like that patch was not committed, there's no support for setting username and password in Administration, and 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. As for mail.smtp.starttls.enable=true, AFAIK when used alone it simply does not make sense. _Please_ do something about it :/ If I remember correctly last time the main issue was that the code had to be integrated in core instead of mail plugin, please, can't we have the thing working at all first, worry about module separation later? Basic mail support _is_ core functionality. For me it's a showstopper, and I don't have enough time to maintain a private fork, either smtp auth goes in, or I'm going out :/ And before someone says it's open source and I should stop bitching and submit a patch - I _did_ submit a patch months ago :/ Greetings, Lilianne
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? 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. 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?
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 - 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.
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). -- Sergiu Dumitriu http://purl.org/net/sergiu/
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).
participants (3)
-
Lilianne E. Blaze -
Niels Mayer -
Sergiu Dumitriu