11 Mar
2009
11 Mar
'09
2:07 a.m.
Sergiu Dumitriu wrote:
Niels Mayer wrote:
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.
On Tue, Mar 10, 2009 at 2:53 AM, Lilianne E.
Blaze <
lilianne(a)lilianne-blaze.net> wrote:
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 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 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.
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
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:
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).
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?