People setting preferred contact address to @ubuntu.com

On Fri, Dec 02, 2005 at 03:11:55AM -0000, Stuart Bishop wrote:
> I suspect we need to special case this somehow

I didn't quite catch why we would need to special-case this.

Is the problem just the fact that the sync is currently broken, and that
if we assume it always works (once we fix it and add tests) we would be
okay?

Christian Reis wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5292
>
> Comment:
> On Fri, Dec 02, 2005 at 03:11:55AM -0000, Stuart Bishop wrote:
>
>>I suspect we need to special case this somehow
>
>
> I didn't quite catch why we would need to special-case this.
>
> Is the problem just the fact that the sync is currently broken, and that
> if we assume it always works (once we fix it and add tests) we would be
> okay?

No - that is a different bug.

This bug is that people can set their preferred email address to their
@ubuntu.com address. Because the preferred email address is used to forward
email to peoples @ubuntu.com email address, this will either create a mail
loop, or be ignored rendering that user uncontactable by email.

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

I think I am starting to understand from these bits and pieces how the ubuntu.com forwarding actually works.

I don't quite understand what the problem is here.

Guilherme Salgado wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5292
>
> Comment:
> I don't quite understand what the problem is here.

Every user who signs the CoC gets an @ubuntu.com email address. Their
Person.$name is used to generate the email address. This email address
forwards emails on to their preferred email address (as we don't provide POP
, IMAP, webmail or even storage facilities).

Currently, you can set your preferred email address to <email address hidden>.
If you do this, you are saying that your <email address hidden> email address
should be forwarded to <email address hidden>, which is very broken.

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Nowadays only Ubuntu members (which need to be accepted by the CC) receive a @ubuntu.com. But apart from that it would be nice if there would be a solution implemented for this problem. I normally add private forward addresses (pkern+foobar@domain), but only expose official ones (like <email address hidden>). My preferred address would thus be <email address hidden>, but Launchpad should send all mail to another address to ease filtering...

 assignee nobody
 subscribe

Need to confirm with IS current rules and processes for @ubuntu.com in case this is no longer a problem.

Possibly related is bug #90150.

Also according to James' comment on bug #62109 - there's some code in place which detects if the user has set their email to something like *@ubuntu* - thus preventing their alias to be created.

Could we possibly make it an option that when you get an @ubuntu.com eMail address, you can hide your primary eMail address, and only display your ubuntu.com eMail address?

Or redo the way the script sets the email address.. Give the Ubuntu Member the ability to set their preferred email address for their @ubuntu.com email address to forward to without regard to the preferred email address in Launchpad. This would then allow an @ubuntu.com email address to be the preferred email address in LP.

There was some discussion on this issue in #launchpad today ( http://irclogs.ubuntu.com/2010/03/07/#launchpad.html ). The conclusion seemed to be that this was not a bug in launchpad, but rather a bug in the way that the @ubuntu.com aliasing was set up. For any number of reasons, launchpad users may want to set a given address as their preferred address, especially because launchpad will use this address on outgoing messages, and this ought be supported.

One solution that was suggested as now feasible would be to have a completely separate webapp that authenticates against LP, verifies membership in ~ubuntumembers via the LP API, and then permits the user to set an address to which @ubuntu.com mail should be forwarded. This address could be checked / confirmed etc. as necessary before being added to the aliases table.

So the conclusion is:
 - the issue still exists (setting preferred email as @ubuntu.com does not work)
 - it may be best fixed by LP not caring and something else controlling where @ubuntu.com mail gets sent
 - or by LP knowing both preferred and second-best email addresses (something we may want with our bounce-handling project).