incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <d...@brondsema.net>
Subject Re: mount_point character restrictions and repositories
Date Fri, 19 Apr 2013 14:27:12 GMT
Not that we have to get into the weeds on email address syntax, but I re-found
http://www.remote.org/jochen/mail/info/chars.html which is a nice reference for
what characters are valid and/or safe in the local part of email addresses.

On 4/19/13 10:23 AM, Dave Brondsema wrote:
> . and _ are the most common characters but there are others like = or , that
> would be valid in a folder name for a repo, but not as a subdomain.
> 
> Right now we don't have any functionality to send an email to a repo, so nothing
> would break yet.  But it's likely that we'd want make replying to a merge
> request email work some day.  I think we probably could determine a different
> routing mechanism at that point.  E.g. something like
> my_repo/merge123@allura.p.sf.net would be plausible (moving the mount point
> before the @ and using a separator that would never be a valid mount point
> char).  Or even allura/my_repo/merge123@p.sf.net so there are no dynamic
> subdomains, which would make mail server configuration easier for anyone
> deploying Allura.
> 
> Current email routing code is at
> https://sourceforge.net/p/allura/git/ci/master/tree/Allura/allura/tasks/mail_tasks.py
> and
> https://sourceforge.net/p/allura/git/ci/master/tree/Allura/allura/lib/mail_util.py#l77
> for the interested.
> 
> Overall I'd prefer keeping mount points and their email addresses simple (as
> opposed to complex and powerful) and also human-friendly.
> 
> -Dave
> 
> On 4/18/13 6:58 PM, Cory Johns wrote:
>> Allura currently restricts the use of . and _ (period and underscore) in
>> the mount_point when installing a tool / app.  This was originally done to
>> enable to routing emails to to the app via the form (e.g.)
>> new@tickets.allura.p.sourceforge.net.  However, this has become a sticking
>> point for some users, specifically with regards to repository names (and in
>> particular with repositories migrated from other systems, such as
>> SourceForge's classic system which already allowed those characters).
>>  Dave, Tim and I started discussing possible options for opening up these
>> characters, and we wanted to open up the discussion here.
>>
>> Initially, we were thinking that we could just have a flag that an app
>> could set that removed the restriction for these characters for the
>> mount_point of that app when installed on a project, with the understanding
>> that this would break email routing for that app.  Tim also had the idea of
>> adding an additional "sanitized" version of the mount_point that could
>> still be used for routing in place of the normal mount_point.  However,
>> there would be the potential for conflicts, albeit manageable, if the
>> sanitized version of one tool's mount_point matched the non-sanitized
>> version of another tool's mount_point.  I floated the idea of going all the
>> way and using a guaranteed unique identifier, such as the app_config's _id,
>> but then the email address' domain would not be human-friendly.
>>
>> Is it worth coming up with a more complicated system to try to both
>> preserve email routing and allow the characters in the mount_point, or
>> should we just go with a flag and let the tools break their routing?  Are
>> there any other ideas that strike a better balance?
>>
> 
> 
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Mime
View raw message