[xwiki-devs] [Brainstorming] Changing the Mail configuration algorithm?
Hi devs, I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki. Actually the current algorithm is the following when looking up a mail configuration property: * <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul> We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. " So I can see 2 options. Option 1: Drop support for looking for configuration in subwikis ======== * Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes. Option 2: Continue supporting overriding in subwikis ======== * Stop bundling Mail.Config for subwikis and modify the config algorithm to be: * <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul> I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin). Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it. WDYT? Thanks -Vincent
IMO ideally we should have <current wiki> -> <main wiki> for each configuration property, not all or nothing. Exactly like standard XWikiPreference based configuration properties. As for the 1 vs 2 I really see no reason to forbid overwriting part of the configuration in his own wiki for use cases like myxwiki.org for example. But I don't mind too much getting rid of the two [Backward compatibility] steps. On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki.
Actually the current algorithm is the following when looking up a mail configuration property:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. "
So I can see 2 options.
Option 1: Drop support for looking for configuration in subwikis ========
* Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes.
Option 2: Continue supporting overriding in subwikis ========
* Stop bundling Mail.Config for subwikis and modify the config algorithm to be:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin).
Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 06 Jul 2016, at 10:31, Thomas Mortagne <[email protected]> wrote:
IMO ideally we should have <current wiki> -> <main wiki> for each configuration property, not all or nothing. Exactly like standard XWikiPreference based configuration properties.
This is what we have, it’s already per-property.
As for the 1 vs 2 I really see no reason to forbid overwriting part of the configuration in his own wiki for use cases like myxwiki.org for example.
The question is: Do we really want local admins on myxwiki.org to be able to use their own SMTP servers? I guess with ours we could configure some anti-spamming techniques to prevent myxwiki users from spamming people. At least we would have the mail logs in our SMTP server when some third party decides to blacklist us. Thanks -Vincent
But I don't mind too much getting rid of the two [Backward compatibility] steps.
On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki.
Actually the current algorithm is the following when looking up a mail configuration property:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. "
So I can see 2 options.
Option 1: Drop support for looking for configuration in subwikis ========
* Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes.
Option 2: Continue supporting overriding in subwikis ========
* Stop bundling Mail.Config for subwikis and modify the config algorithm to be:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin).
Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it.
WDYT?
Thanks -Vincent
On Wed, Jul 6, 2016 at 10:36 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:31, Thomas Mortagne <[email protected]> wrote:
IMO ideally we should have <current wiki> -> <main wiki> for each configuration property, not all or nothing. Exactly like standard XWikiPreference based configuration properties.
This is what we have, it’s already per-property.
As for the 1 vs 2 I really see no reason to forbid overwriting part of the configuration in his own wiki for use cases like myxwiki.org for example.
The question is: Do we really want local admins on myxwiki.org to be able to use their own SMTP servers? I guess with ours we could configure some anti-spamming techniques to prevent myxwiki users from spamming people. At least we would have the mail logs in our SMTP server when some third party decides to blacklist us.
1) The SMTP server is not the only thing you can setup there (for example it's interesting to change the default from mail address for you wiki). But you might still want to use your own SMTP server for you wiki (becauseou have a SMTP server which provide some analysis of the mails, storage, etc.). 2) I don't see the relationship with spam. The only thing really important for spam is who is allowed to send mail, not really who is allowed to choose the SMTP server. Allowing someone to configure his own SMTP server actually only decrease the load on the main SMTP server and the chance of it being used for spam in case it's overwritten.
Thanks -Vincent
But I don't mind too much getting rid of the two [Backward compatibility] steps.
On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki.
Actually the current algorithm is the following when looking up a mail configuration property:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. "
So I can see 2 options.
Option 1: Drop support for looking for configuration in subwikis ========
* Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes.
Option 2: Continue supporting overriding in subwikis ========
* Stop bundling Mail.Config for subwikis and modify the config algorithm to be:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin).
Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 06 Jul 2016, at 10:54, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 10:36 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:31, Thomas Mortagne <[email protected]> wrote:
IMO ideally we should have <current wiki> -> <main wiki> for each configuration property, not all or nothing. Exactly like standard XWikiPreference based configuration properties.
This is what we have, it’s already per-property.
As for the 1 vs 2 I really see no reason to forbid overwriting part of the configuration in his own wiki for use cases like myxwiki.org for example.
The question is: Do we really want local admins on myxwiki.org to be able to use their own SMTP servers? I guess with ours we could configure some anti-spamming techniques to prevent myxwiki users from spamming people. At least we would have the mail logs in our SMTP server when some third party decides to blacklist us.
1) The SMTP server is not the only thing you can setup there (for example it's interesting to change the default from mail address for you wiki). But you might still want to use your own SMTP server for you wiki (becauseou have a SMTP server which provide some analysis of the mails, storage, etc.).
So we could easily decide to use the local wiki only for some properties if we want.
2) I don't see the relationship with spam. The only thing really important for spam is who is allowed to send mail, not really who is allowed to choose the SMTP server. Allowing someone to configure his own SMTP server actually only decrease the load on the main SMTP server and the chance of it being used for spam in case it's overwritten.
I explained the relationship in the previous mail. In short: controlling the SMTP server allows you take some actions/monitor mails. Thanks -Vincent PS: I’m playing the devil’s advocate (trying to represent Denis ;)) because I’m also preferring option 2.
Thanks
-Vincent
But I don't mind too much getting rid of the two [Backward compatibility] steps.
On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki.
Actually the current algorithm is the following when looking up a mail configuration property:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. "
So I can see 2 options.
Option 1: Drop support for looking for configuration in subwikis ========
* Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes.
Option 2: Continue supporting overriding in subwikis ========
* Stop bundling Mail.Config for subwikis and modify the config algorithm to be:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin).
Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it.
WDYT?
Thanks -Vincent
On Wed, Jul 6, 2016 at 11:00 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:54, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 10:36 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:31, Thomas Mortagne <[email protected]> wrote:
IMO ideally we should have <current wiki> -> <main wiki> for each configuration property, not all or nothing. Exactly like standard XWikiPreference based configuration properties.
This is what we have, it’s already per-property.
As for the 1 vs 2 I really see no reason to forbid overwriting part of the configuration in his own wiki for use cases like myxwiki.org for example.
The question is: Do we really want local admins on myxwiki.org to be able to use their own SMTP servers? I guess with ours we could configure some anti-spamming techniques to prevent myxwiki users from spamming people. At least we would have the mail logs in our SMTP server when some third party decides to blacklist us.
1) The SMTP server is not the only thing you can setup there (for example it's interesting to change the default from mail address for you wiki). But you might still want to use your own SMTP server for you wiki (becauseou have a SMTP server which provide some analysis of the mails, storage, etc.).
So we could easily decide to use the local wiki only for some properties if we want.
2) I don't see the relationship with spam. The only thing really important for spam is who is allowed to send mail, not really who is allowed to choose the SMTP server. Allowing someone to configure his own SMTP server actually only decrease the load on the main SMTP server and the chance of it being used for spam in case it's overwritten.
I explained the relationship in the previous mail. In short: controlling the SMTP server allows you take some actions/monitor mails.
They don't need XWiki to send mail trough their own SMTP server. And again what would be blacklisted is this other SMTP server so we don't care.
Thanks -Vincent
PS: I’m playing the devil’s advocate (trying to represent Denis ;)) because I’m also preferring option 2.
Thanks
-Vincent
But I don't mind too much getting rid of the two [Backward compatibility] steps.
On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki.
Actually the current algorithm is the following when looking up a mail configuration property:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. "
So I can see 2 options.
Option 1: Drop support for looking for configuration in subwikis ========
* Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes.
Option 2: Continue supporting overriding in subwikis ========
* Stop bundling Mail.Config for subwikis and modify the config algorithm to be:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin).
Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 06 Jul 2016, at 11:15, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 11:00 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:54, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 10:36 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:31, Thomas Mortagne <[email protected]> wrote:
IMO ideally we should have <current wiki> -> <main wiki> for each configuration property, not all or nothing. Exactly like standard XWikiPreference based configuration properties.
This is what we have, it’s already per-property.
As for the 1 vs 2 I really see no reason to forbid overwriting part of the configuration in his own wiki for use cases like myxwiki.org for example.
The question is: Do we really want local admins on myxwiki.org to be able to use their own SMTP servers? I guess with ours we could configure some anti-spamming techniques to prevent myxwiki users from spamming people. At least we would have the mail logs in our SMTP server when some third party decides to blacklist us.
1) The SMTP server is not the only thing you can setup there (for example it's interesting to change the default from mail address for you wiki). But you might still want to use your own SMTP server for you wiki (becauseou have a SMTP server which provide some analysis of the mails, storage, etc.).
So we could easily decide to use the local wiki only for some properties if we want.
2) I don't see the relationship with spam. The only thing really important for spam is who is allowed to send mail, not really who is allowed to choose the SMTP server. Allowing someone to configure his own SMTP server actually only decrease the load on the main SMTP server and the chance of it being used for spam in case it's overwritten.
I explained the relationship in the previous mail. In short: controlling the SMTP server allows you take some actions/monitor mails.
They don't need XWiki to send mail trough their own SMTP server.
I think they do because the mail sender api requires PR and on a farm you don’t get it. And if they want to use java mail they need groovy which also requires PR. Do you see a way for them to send mail without PR?
And again what would be blacklisted is this other SMTP server so we don't care.
Indeed, good point. I was thinking about myxwiki.org being blacklisted but you’re right, there’s no reason for myxwiki.org to be blacklisted; it’s not the one sending the mail. So I’m still in favor of option 2. Anyone strongly in favor of option 1? I’d like to start modifying the code soon so please reply asap. Thanks -Vincent
Thanks
-Vincent
PS: I’m playing the devil’s advocate (trying to represent Denis ;)) because I’m also preferring option 2.
Thanks
-Vincent
But I don't mind too much getting rid of the two [Backward compatibility] steps.
On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki.
Actually the current algorithm is the following when looking up a mail configuration property:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. "
So I can see 2 options.
Option 1: Drop support for looking for configuration in subwikis ========
* Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes.
Option 2: Continue supporting overriding in subwikis ========
* Stop bundling Mail.Config for subwikis and modify the config algorithm to be:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin).
Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it.
WDYT?
Thanks -Vincent
On Wed, Jul 6, 2016 at 11:21 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 11:15, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 11:00 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:54, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 10:36 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:31, Thomas Mortagne <[email protected]> wrote:
IMO ideally we should have <current wiki> -> <main wiki> for each configuration property, not all or nothing. Exactly like standard XWikiPreference based configuration properties.
This is what we have, it’s already per-property.
As for the 1 vs 2 I really see no reason to forbid overwriting part of the configuration in his own wiki for use cases like myxwiki.org for example.
The question is: Do we really want local admins on myxwiki.org to be able to use their own SMTP servers? I guess with ours we could configure some anti-spamming techniques to prevent myxwiki users from spamming people. At least we would have the mail logs in our SMTP server when some third party decides to blacklist us.
1) The SMTP server is not the only thing you can setup there (for example it's interesting to change the default from mail address for you wiki). But you might still want to use your own SMTP server for you wiki (becauseou have a SMTP server which provide some analysis of the mails, storage, etc.).
So we could easily decide to use the local wiki only for some properties if we want.
2) I don't see the relationship with spam. The only thing really important for spam is who is allowed to send mail, not really who is allowed to choose the SMTP server. Allowing someone to configure his own SMTP server actually only decrease the load on the main SMTP server and the chance of it being used for spam in case it's overwritten.
I explained the relationship in the previous mail. In short: controlling the SMTP server allows you take some actions/monitor mails.
They don't need XWiki to send mail trough their own SMTP server.
I think they do because the mail sender api requires PR and on a farm you don’t get it. And if they want to use java mail they need groovy which also requires PR.
Do you see a way for them to send mail without PR?
I don't think you understood what I mean. XWiki is not the only software out there that allows sending mails. If you have your own SMTP server then you can just use any mail client to send mails trough it, not need to request a myxwiki.org wiki for that.
And again what would be blacklisted is this other SMTP server so we don't care.
Indeed, good point. I was thinking about myxwiki.org being blacklisted but you’re right, there’s no reason for myxwiki.org to be blacklisted; it’s not the one sending the mail.
So I’m still in favor of option 2. Anyone strongly in favor of option 1? I’d like to start modifying the code soon so please reply asap.
Thanks -Vincent
Thanks
-Vincent
PS: I’m playing the devil’s advocate (trying to represent Denis ;)) because I’m also preferring option 2.
Thanks
-Vincent
But I don't mind too much getting rid of the two [Backward compatibility] steps.
On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote: > Hi devs, > > I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki. > > Actually the current algorithm is the following when looking up a mail configuration property: > > * <ul> > * <li>Look in Mail.MailConfig in the current wiki</li> > * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> > * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> > * <li>Look in the xwiki properties file</li> > * </ul> > > We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): > “ > Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. > In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. > It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. > " > > So I can see 2 options. > > Option 1: Drop support for looking for configuration in subwikis > ======== > > * Rationale: there are few use cases that require overriding the mail config in a subwiki > * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. > * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes. > > Option 2: Continue supporting overriding in subwikis > ======== > > * Stop bundling Mail.Config for subwikis and modify the config algorithm to be: > > * <ul> > * <li>Look in Mail.MailConfig in the current wiki</li> > * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> > * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> > * <li>Look in Mail.MailConfig in the main wiki</li> > * <li>Look in the xwiki properties file</li> > * </ul> > > > I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin). > > Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it. > > WDYT? > > Thanks > -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 06 Jul 2016, at 11:24, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 11:21 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 11:15, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 11:00 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:54, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 10:36 AM, Vincent Massol <[email protected]> wrote:
> On 06 Jul 2016, at 10:31, Thomas Mortagne <[email protected]> wrote: > > IMO ideally we should have <current wiki> -> <main wiki> for each > configuration property, not all or nothing. Exactly like standard > XWikiPreference based configuration properties.
This is what we have, it’s already per-property.
> As for the 1 vs 2 I really see no reason to forbid overwriting part of > the configuration in his own wiki for use cases like myxwiki.org for > example.
The question is: Do we really want local admins on myxwiki.org to be able to use their own SMTP servers? I guess with ours we could configure some anti-spamming techniques to prevent myxwiki users from spamming people. At least we would have the mail logs in our SMTP server when some third party decides to blacklist us.
1) The SMTP server is not the only thing you can setup there (for example it's interesting to change the default from mail address for you wiki). But you might still want to use your own SMTP server for you wiki (becauseou have a SMTP server which provide some analysis of the mails, storage, etc.).
So we could easily decide to use the local wiki only for some properties if we want.
2) I don't see the relationship with spam. The only thing really important for spam is who is allowed to send mail, not really who is allowed to choose the SMTP server. Allowing someone to configure his own SMTP server actually only decrease the load on the main SMTP server and the chance of it being used for spam in case it's overwritten.
I explained the relationship in the previous mail. In short: controlling the SMTP server allows you take some actions/monitor mails.
They don't need XWiki to send mail trough their own SMTP server.
I think they do because the mail sender api requires PR and on a farm you don’t get it. And if they want to use java mail they need groovy which also requires PR.
Do you see a way for them to send mail without PR?
I don't think you understood what I mean. XWiki is not the only software out there that allows sending mails. If you have your own SMTP server then you can just use any mail client to send mails trough it, not need to request a myxwiki.org wiki for that.
Indeed I had misunderstood :) Good point. Thanks -Vincent
And
again what would be blacklisted is this other SMTP server so we don't care.
Indeed, good point. I was thinking about myxwiki.org being blacklisted but you’re right, there’s no reason for myxwiki.org to be blacklisted; it’s not the one sending the mail.
So I’m still in favor of option 2. Anyone strongly in favor of option 1? I’d like to start modifying the code soon so please reply asap.
Thanks -Vincent
Thanks
-Vincent
PS: I’m playing the devil’s advocate (trying to represent Denis ;)) because I’m also preferring option 2.
Thanks
-Vincent
> But I don't mind too much getting rid of the two [Backward compatibility] steps. > > On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote: >> Hi devs, >> >> I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki. >> >> Actually the current algorithm is the following when looking up a mail configuration property: >> >> * <ul> >> * <li>Look in Mail.MailConfig in the current wiki</li> >> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> >> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> >> * <li>Look in the xwiki properties file</li> >> * </ul> >> >> We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): >> “ >> Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. >> In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. >> It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. >> " >> >> So I can see 2 options. >> >> Option 1: Drop support for looking for configuration in subwikis >> ======== >> >> * Rationale: there are few use cases that require overriding the mail config in a subwiki >> * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. >> * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes. >> >> Option 2: Continue supporting overriding in subwikis >> ======== >> >> * Stop bundling Mail.Config for subwikis and modify the config algorithm to be: >> >> * <ul> >> * <li>Look in Mail.MailConfig in the current wiki</li> >> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> >> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> >> * <li>Look in Mail.MailConfig in the main wiki</li> >> * <li>Look in the xwiki properties file</li> >> * </ul> >> >> >> I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin). >> >> Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it. >> >> WDYT? >> >> Thanks >> -Vincent
On mer., juil. 6, 2016 at 11:21 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 11:15, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 11:00 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:54, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 10:36 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:31, Thomas Mortagne <[email protected]> wrote:
IMO ideally we should have <current wiki> -> <main wiki> for each configuration property, not all or nothing. Exactly like standard XWikiPreference based configuration properties.
This is what we have, it’s already per-property.
As for the 1 vs 2 I really see no reason to forbid overwriting part of the configuration in his own wiki for use cases like myxwiki.org for example.
The question is: Do we really want local admins on myxwiki.org to be able to use their own SMTP servers? I guess with ours we could configure some anti-spamming techniques to prevent myxwiki users from spamming people. At least we would have the mail logs in our SMTP server when some third party decides to blacklist us.
1) The SMTP server is not the only thing you can setup there (for example it's interesting to change the default from mail address for you wiki). But you might still want to use your own SMTP server for you wiki (becauseou have a SMTP server which provide some analysis of the mails, storage, etc.).
So we could easily decide to use the local wiki only for some properties if we want.
2) I don't see the relationship with spam. The only thing really important for spam is who is allowed to send mail, not really who is allowed to choose the SMTP server. Allowing someone to configure his own SMTP server actually only decrease the load on the main SMTP server and the chance of it being used for spam in case it's overwritten.
I explained the relationship in the previous mail. In short: controlling the SMTP server allows you take some actions/monitor mails.
They don't need XWiki to send mail trough their own SMTP server.
I think they do because the mail sender api requires PR and on a farm you don’t get it. And if they want to use java mail they need groovy which also requires PR. Do you see a way for them to send mail without PR?
And again what would be blacklisted is this other SMTP server so we don't care.
Indeed, good point. I was thinking about myxwiki.org being blacklisted but you’re right, there’s no reason for myxwiki.org to be blacklisted; it’s not the one sending the mail. This is a bit over simplistic, there is not just blacklisting of SMTP servers in the arsenal of the anti-spamming tools. There is also analysis of mails themselves, and the originating server is surely a strong evidence for anti-spamming tools. My feeling is that mail routing is the charge of the SMTP server, and that you can configure a SMTP server to do what you need if you ever need a custom dispatching solution. I see no point of an application to have to manage more than one SMTP server unless you are a mass mailing solution provider. Moreover, the SMTP configuration is more the responsibility of the sysadmin that has installed the servlet container for the application than the administrator of that application. So I would see this more in a config file, than in a wiki configuration page. And I am pretty sure this sysadmin would be more peaceful thinking he has the mastery of this configuration than to rely on application administrators to manage it. Of course you can find a lot of test/development cases that may find useful to have a custom independent SMTP server per wiki, but for production, I doubt this is common use case. So, if the effort or resources require to have a perfect fallback solution is much higher than just dropping subwiki support, my feeling is that we can drop it. The actual situation is a pain for the sysadmin, and the worst case. Thanks, -- Denis Gervalle SOFTEC sa - CEO So I’m still in favor of option 2. Anyone strongly in favor of option 1? I’d like to start modifying the code soon so please reply asap. Thanks -Vincent
Thanks
-Vincent
PS: I’m playing the devil’s advocate (trying to represent Denis ;)) because I’m also preferring option 2.
Thanks
-Vincent
But I don't mind too much getting rid of the two [Backward compatibility] steps.
On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki.
Actually the current algorithm is the following when looking up a mail configuration property:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. "
So I can see 2 options.
Option 1: Drop support for looking for configuration in subwikis ========
* Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes.
Option 2: Continue supporting overriding in subwikis ========
* Stop bundling Mail.Config for subwikis and modify the config algorithm to be:
* <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul>
I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin).
Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it.
WDYT?
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 06 Jul 2016, at 11:54, Denis Gervalle <[email protected]> wrote:
On mer., juil. 6, 2016 at 11:21 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 11:15, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 11:00 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:54, Thomas Mortagne <[email protected]> wrote:
On Wed, Jul 6, 2016 at 10:36 AM, Vincent Massol <[email protected]> wrote:
On 06 Jul 2016, at 10:31, Thomas Mortagne <[email protected]> wrote:
IMO ideally we should have <current wiki> -> <main wiki> for each configuration property, not all or nothing. Exactly like standard XWikiPreference based configuration properties.
This is what we have, it’s already per-property.
As for the 1 vs 2 I really see no reason to forbid overwriting part of the configuration in his own wiki for use cases like myxwiki.org for example.
The question is: Do we really want local admins on myxwiki.org to be able to use their own SMTP servers? I guess with ours we could configure some anti-spamming techniques to prevent myxwiki users from spamming people. At least we would have the mail logs in our SMTP server when some third party decides to blacklist us.
1) The SMTP server is not the only thing you can setup there (for example it's interesting to change the default from mail address for you wiki). But you might still want to use your own SMTP server for you wiki (becauseou have a SMTP server which provide some analysis of the mails, storage, etc.).
So we could easily decide to use the local wiki only for some properties if we want.
2) I don't see the relationship with spam. The only thing really important for spam is who is allowed to send mail, not really who is allowed to choose the SMTP server. Allowing someone to configure his own SMTP server actually only decrease the load on the main SMTP server and the chance of it being used for spam in case it's overwritten.
I explained the relationship in the previous mail. In short: controlling the SMTP server allows you take some actions/monitor mails.
They don't need XWiki to send mail trough their own SMTP server.
I think they do because the mail sender api requires PR and on a farm you don’t get it. And if they want to use java mail they need groovy which also requires PR.
Do you see a way for them to send mail without PR?
And again what would be blacklisted is this other SMTP server so we don't care.
Indeed, good point. I was thinking about myxwiki.org being blacklisted but you’re right, there’s no reason for myxwiki.org to be blacklisted; it’s not the one sending the mail. This is a bit over simplistic, there is not just blacklisting of SMTP servers in the arsenal of the anti-spamming tools. There is also analysis of mails themselves, and the originating server is surely a strong evidence for anti-spamming tools. My feeling is that mail routing is the charge of the SMTP server, and that you can configure a SMTP server to do what you need if you ever need a custom dispatching solution. I see no point of an application to have to manage more than one SMTP server unless you are a mass mailing solution provider. Moreover, the SMTP configuration is more the responsibility of the sysadmin that has installed the servlet container for the application than the administrator of that application. So I would see this more in a config file, than in a wiki configuration page. And I am pretty sure this sysadmin would be more peaceful thinking he has the mastery of this configuration than to rely on application administrators to manage it. Of course you can find a lot of test/development cases that may find useful to have a custom independent SMTP server per wiki, but for production, I doubt this is common use case. So, if the effort or resources require to have a perfect fallback solution is much higher than just dropping subwiki support, my feeling is that we can drop it. The actual situation is a pain for the sysadmin, and the worst case.
Right now it would take more time to drop support for subwiki config than to keep it. The only change we need to bring is to add the passing of the current wiki to the mail sender thread (to set it in the context). So I’m going to go ahead and keep the current solution for now and if we have an issue one day we’ll still be able to drop it (I prefer this over breaking backward compat). Thanks -Vincent
Thanks, -- Denis Gervalle SOFTEC sa - CEO
So I’m still in favor of option 2. Anyone strongly in favor of option 1? I’d like to start modifying the code soon so please reply asap.
Thanks -Vincent
Thanks
-Vincent
PS: I’m playing the devil’s advocate (trying to represent Denis ;)) because I’m also preferring option 2.
Thanks
-Vincent
But I don't mind too much getting rid of the two [Backward compatibility] steps.
On Tue, Jul 5, 2016 at 5:56 PM, Vincent Massol <[email protected]> wrote: > Hi devs, > > I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki. > > Actually the current algorithm is the following when looking up a mail configuration property: > > * <ul> > * <li>Look in Mail.MailConfig in the current wiki</li> > * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> > * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> > * <li>Look in the xwiki properties file</li> > * </ul> > > We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): > “ > Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. > In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. > It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. > " > > So I can see 2 options. > > Option 1: Drop support for looking for configuration in subwikis > ======== > > * Rationale: there are few use cases that require overriding the mail config in a subwiki > * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. > * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes. > > Option 2: Continue supporting overriding in subwikis > ======== > > * Stop bundling Mail.Config for subwikis and modify the config algorithm to be: > > * <ul> > * <li>Look in Mail.MailConfig in the current wiki</li> > * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> > * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> > * <li>Look in Mail.MailConfig in the main wiki</li> > * <li>Look in the xwiki properties file</li> > * </ul> > > > I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin). > > Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it. > > WDYT? > > Thanks > -Vincent
participants (3)
-
Denis Gervalle -
Thomas Mortagne -
Vincent Massol