proposal for invite.owner with auth

[taggart]

I would like to have a version of the "invite" scenari for owner but with authentication. Currently "invite.owner" could be abused by someone forging mail from the owner address, and having an auth version would prevent this.

It could maybe be argued that "invite.owner" should require auth by default. I think that is probably a good idea, but that may come as a surprise to users not expecting it (and automation/form processing people may have written taking advantage of it). Also depending on naming some migration might be required between releases. There may also be use cases where this auth is not required and just adds extra steps (non-public email systems?)

We have the examples of {add,del}.owner vs {add,del}.auth, but also send.owner vs send.ownerauth to use as reference. I think this new scenari could be named either "invite.auth" or "invite.ownerauth", I guess I would lean toward the former. Based on the others, here is probably what it should look like:

title.gettext invite perform by list owner with authentication       

is_owner([listname],[sender])  smtp -> request_auth
is_listmaster([sender])        smtp -> request_auth
is_owner([listname],[sender])  md5,smime -> do_it     
is_listmaster([sender])        md5,smime -> do_it
true()                         smtp,md5,smime -> reject(reason='invite_ownerauth')

(I left "perform" like it is in invite.owner, but they could both be changed to "performed").
Let me know what you think of this, or if I can help in any way.
Thanks!

[taggart]

Thinking about this more...

Does sympa have any policy about scenari changes? Looking at the default scenari it seems they don't change very often, so maybe it has not come up much?

If sympa were to decide to start requiring auth for things like add/del/invite, what would the potential migration look like?

If users provide their own version of a scenari in the etc/scenari directory with an identical name, sympa will prefer that version over the default/scenari version. So I can think of a couple ways this could be handled:

modify existing scenari

Using invite.owner as an example, if we add the auth requirement to the existing file:

• new installs would get the new default/scenari/invite.owner and new behavior
• existing installs that did not provide their own etc/scenari/invite.owner file were relying on the existing default and upon upgrade would get the new behavior (which is good, but might surprise them)
• existing installs that provided their own etc/scenari/invite.owner file got whatever behavior that custom version specified and would continue to get that custom behavior after upgrade.
• Any changes in the defaults could be documented in the release notes, explaining the changes and what admins need to do.
• Sympa::Upgrade could check for the existance of etc/scenari/invite.owner and issue an extra warning that the default changed and they may want to review the changes and update their custom version.

introduce scenari changes with new files, migrate to them

In the case, for our example invite.owner with auth, we would create a new file named something like invite.ownerauth.

• if this will be the new default, the invite.default symlink can be adjusted
• any templates in create_list_templates that should use this new default could be adjusted to use that new type
• if the non-auth version is being phased out at the same time, invite.owner would be removed from default/scenari/ and no longer installed on new installs or upgrades (but if it is already there it should remain for existing lists that reference it, assuming upgrading in place and the upgrade process leaves it CHECK THIS)
• new installs
  • would get the new invite.ownerauth have it available as an option for lists (subject to edit_list.conf restrictions)
  • potentially have it be the default for all or some new lists
  • potentially might not get the old invite.owner if it's being deprecated by upstream
• existing installs
  • because it's a new name, existing installs would not already have it in default/scenari
  • after upgrade they will have both invite.owner and invite.ownerauth available, existing lists could continue to use the old one or switch
  • after upgrade, they may have a new default. existing lists that do not specify would potentially get a new default
  • if they had a custom etc/scenari/invite.owner that would continue to work as expected
  • it's unlikely they would have an etc/scenari/invite.ownerauth already, but I suppose the installer should check for that
  • Sympa::Upgrade could check for custom version of the old type, but also let them know about the new type and explain the plan for the old one
• a new type could be introduced and the old one deprecated in the same release, but these could also be spread out if there was a reason to do so

This is all using my example for invite, but probably you can tell I am trying to think about this generically because I think it's probably time that sympa move away from some of this older scenari behavior that is now a problem. In particular many of the public scenari should no longer be options on new installs and need a migration path for existing installs. So sorry if this is an abuse of the issue tracker, free free to make it a separate issue or move it some place else. Thanks

[ikedas]

I +1 to add invite.ownerauth.

• Existing scenarios should not change their behaviors.
• Conflict between existing user-defined scenarios and newly added one may be warned in release annuncements or such.

Having too many scenarios is troubling. I think it is a flaw in the current design that we have to have as many options as there are all possible conditions, but we have to live with this for the time being.