Just so I’m clear, this problem does not affect people who use an @ubuntu.com email alias in GMail itself, right? I have an @ubuntu.com alias as an Ubuntu Member, but I’ve not been using it to send mail as of yet, and was thinking of getting it set up. If that’s going to kill my ability to send emails, naturally I’d like to just stick with my GMail address.
2 Likes
It depends on what you mean. With an @ubuntu.com alias in GMail you will indeed be able to send messages to users on GMail and other services which require authentication. OTOH, I won’t be able to send messages from my @ubuntu.com address to you.
4 Likes
Bumpity bump. Does anyone know is there has been any progress on this, because it has just reared its ugly head when I tried to reply to someone using my @ubuntu.com alias on the Forum Council mailing list?
I was trying to help a forum member who was in some distress and I smelt a rat when they wrote again not seeming to have received my first email. A quick test from my @ubuntu.com alias to my own gmail account confirmed the issue - made worse by no bounce notification, nothing, not a dicky bird to tell me my email had disappeared into a black hole. This is the first time I have come across this problem, and a quick google brought me to this thread.
I’m now left wondering how many people have written to the Forum Council ML from gmail accounts and who are wondering why they have apparently been ignored.
2 Likes
When the Forum Council mailing list receives an email, a response should come from SomeGoof @ubuntu.com rather than TheSameGoof @anotherdomain. The former suggests someone in and Ubuntu circle. The latter could be some slob hacker having his fun. A response from @ubuntu.com would be expected by the user.
I certainly am not interested in using the domain name of our family company, nor am I interested in having a gmail, excite, microsoft, etc, domain email. I’m not interested in having a gmail alias. Just having my ubuntu.com account tied to another email account through an ISP is enough.
2 Likes
Totally agree this should be done quickly and I am trying hard. The IS team is doing this, and it is on the stretch roadmap for this cycle. I just recently got an update on this and unfortunately it will more likely happen at the beginning of next cycle (with cycles being aligned to the releases).
In terms of what I need from the IS team this is a top priority, but it is also a large work item given the need for a password reset system that scales.
3 Likes
@kewisch, thanks for the update.
Forum members wishing to send a message to the Forum Council use the “contact us” link at the bottom of any forum page. I’ve added an “URGENT WARNING” to the banner asking members not to use a gmail return address for the time being, and advising them how to achieve this if they have a gmail associated with their forum account. Cynicism born of long experience tells me that this is likely to have only a slight effect though. Despite the first line in that banner clearly stating that forum administrators cannot provide technical assistance via email, we get a steady stream of such requests ending up on our ML.
Ho hum.
Indeed, I’ve seen this in many places, and unfortunately there isn’t a permanent fix. I’ve seen folks reaching out to the press@ alias of a project (not Canonical) asking for technical support, and they were clearly not press.
The only partial solution is to provide a place where they do get answers, and making it very easy to do that. You’d think a forum is the right place for that 
Let me know if there are other ways my team can support you.
Is there no way for IS to implement this into login.u.c? That solves the password reset by tying in emails to SSO and then application passwords that can be issued on the portal for the use for things like IMAP which don’t allow super complex authentication. (Just a suggestion to IS!)
This was considered, though there are some compatibility and complexity issues as well. To tie it to SSO, you’d need to use XOAUTH for authentication, which requires the client to know the client key and secret for the respective domain. This might be easier for us to get into Thunderbird, K9 Mail, or Evolution, but iOS Mail, Outlook and others will be more difficult to impossible. It was also a similar amount of work internally to the password reset solution.
There is the less secure option of “Application Passwords” - application passwords which “just work” as standard passwords - that wouldn’t require XOAUTH2 or OAuth to function, the passwords are just ‘linked’ to an SSO account for username purposes. This is how Google did ‘legacy authenticaton’ for applications that can’t use OAuth or such - that’s still a possibility.
The tricky part here though is how to protect against bruteforcing, so a sufficiently long random application password would be needed if that route was gone under. That’d solve most of the “compatibility” issues I"m aware of (granted I haven’t worked on the SSO system).
Yeah I believe the currently favored approach uses some form of application passwords, which doesn’t require XOAUTH, but does require some infra to reset passwords. We’ll be using existing systems for this that are behind SSO, so it will be self-service in the end.
1 Like
Can we get an update on this? GMail and Yahoo are now instituting hardcore checks and Ubuntu addresses hard fail on the checks for GMail recipients.
6 Likes