Gmail blocking email from @ubuntu.com address

I think @gunnarhj will also be happy to know this is the long-term solution being considered. Fingers crossed, and again, I will keep on top of this matter for everyone involved!

1 Like

Yep.

But for the world at large, here’s an example of ‘spoofed’ ubuntu.com maliciousness in emails that SPF, DKIM, and DMARC via a dedicated SMTP would help defend against. This is caught by my system and tossed into the abyss but. New SMTP server will help fix this stuff too with proper rules in place. (IS knows this already)

2 Likes

FWIW a mail I just sent to a gmail address from gunnarhj@debian.org via my ISP’s SMTP server was bounced.

SMTP protocol diagnostic:
550-5.7.26 This message does not have authentication information or fails to
550-5.7.26 pass authentication checks. To best protect our users from spam, the
550-5.7.26 message has been blocked.

So a lack of authentication is no longer just a criterion for spam detection, but a direct blocker.

And we can take comfort knowing that it’s not only @ubuntu.com. :frowning:

2 Likes

Btw @madhens: Any chance that Ubuntu and Debian can collaborate on an SMTP server?

1 Like

I’m going to tag @jbicha @teward and @seb128 in on this question. Do you all think this could work?

2 Likes

Tollef Fog Heen let me know in a private Debian list:

We’re working on getting an SMTP submission service set up.

So also Debian have similar intentions.

3 Likes

Sorry but that’s not really- my domain, I had issues with email to gmail being rejected and filed a RT in march, they did tweaks to the SPF policy for ubuntu.com emails and said it should help and I haven’t hit the issue again but I don’t contact gmail addresses from my ubuntu email often. I did mention the current discussion on the Canonical RT ticket now though, let’s see if that helps

3 Likes

@madhens If there’s some way to integrate the SSO systems and do OAuth configurations, or to allow for application passwords to be generated (the “Old School” way for GMail stuff) then we can generate authentication passwords that tie to parts of the DB for specific SMTP authentication.

There’s ways to do that in the DB side if Postgresql or MySQL or such backends are used for the SASL auth backend (read: dovecot backed for example). But it would need to have a Debian and Ubuntu IS teams collaboration and would have to have a unified Single Sign On solution tied together.

It’d be easier to do separate SMTP servers - one for Debian and one for Ubuntu - with different SASL auth backends. Even if they’re on the same server cluster it could be done.

Do you want to set up a call between Canonical IS and Debian IS on analyzing whatever SSO system exists on each side and determine best ways to go about this in the SSO system to have a table that could be reached containing individual application keys (randomly generated by the SSO system when adding an application password) that would be SMTP auth passwords tied to a specific SSO account?

Because I don’t know how to integrate the OpenID/SSO into postfix/SMTP currently, but I know the other way to use a DB table to feed passwords into Postfix/Dovecot SMTP authentication (it’s how my own SMTP server works to some level).

2 Likes

This then subsequently broke with more changes for canonical.com -> ubuntu.com addresses which breaks things too.

Gmail’s been under enormous scrutiny to tighten the security levels, so they not only went deep to SPF checks but they also want DKIM where possible now, and also where possible a DMARC policy set up.

We ran into this with testing our personal emails at FT job when we migrated to MS365, and it took a while to get it all functioning right.

2 Likes

I noticed this too recently.

Since I run my own submission server, for Debian I was able to take advantage of their ability to publish DKIM keys and now I can send mail to Gmail from my debian.org email address properly.

It’s definitely not the most user friendly solution though. I think ultimately it’s going to have to be something like what Tollef says here, & then it’ll be a matter of users configuring their client to use that server.

If I remember correctly there’s something already set up like this internally at Canonical: every employee can access personal credentials and you configure your client to use the submission server with these when sending from canonical.com. So maybe it won’t be starting from the ground. (This applies only if you’re not using Gmail, which most Canonical staff are. :slight_smile: )

1 Like

I know that Canonical IS has been working on figuring out a solution for ubuntu.com as well, this is one of the cases that I was touching on. The SSO integration is going to be a little harder though so this isn’t a “Small Project”

1 Like

It doesn’t require SSO on the mail side the way the existing stuff happens, it works like this

  • Log into SSO protected webpage
  • Get credentials for ubuntu.com submission server for your user from there (static username/password)
  • Use these
2 Likes

a me too !

Attempting to post to ubuntu-news@lists.ubuntu.com from my bashing-om@ubuntu.com account renders:
“Authentication failed:
535-5.7.8 Username and Password not accepted.”

I await a solution to authenticate for those of us that do not have cell phones to enable Google’s proposed authentication method.

-ouch-

2 Likes

Hello all - just an update from IS. The SMTP fix is on their queue, but it has been delayed, as of last week, due to some even more urgent matters. Our IS team is amazing, and unfortunately they’re also some of the busiest people at Canonical! :muscle:

I’ll check in again with IS on July 18 if I haven’t heard back from them by then. Thank you all for your patience through some very real frustration - the good news is that this solution seems much more like a long-term fix and not a shorter term solution. :white_check_mark:

6 Likes

Thanks madhens - both for the continued effort and that you take the time to keep us apprised of the situation.
-moar patience-

4 Likes

@gunnarhj
For Debian members/developers

https://lists.debian.org/debian-devel-announce/2022/07/msg00003.html

1 Like

It’s now August with no further work on this.

Does IS need an extra set of hands? I am happy to coordinate with them and assist them in getting auth-smtp with application passwords (fed from SSO login.u.c for instance) over to the backend side of things to start getting things set up. (the SSO auth parts I can’t do, but getting the SMTP part set up is more easily doable)

3 Likes

As part of my handover the Community Team at large assumed responsibility for checking for Status Updates with IS. And IS, when I left, thought they were getting closer to availability to implement this. Even though Im no longer a Canonical employee, I am a member who is going to assume good faith - and who knows the IS team is keeping many, many things going, things that sometimes have to come before this because they keep the lights on for everyone. I will gently ping @kewisch to see if IS can accept outside help - but if they’re not able to, for reasons beyond their control, then we’ve all done our part.

tl:dr: patience, young padawan

2 Likes

No worries, Phillip has said he’ll check it, but I caught hold of Mauro as well. :slight_smile:

3 Likes

For the record, I’ve taken measures to speed this up a bit, but indeed it will be a matter of patience. I know this has been open for a while. If I am optimistic we might see a solution in 1–2 months, but I also don’t want to overpromise because I don’t yet have a confirmed timeline.

2 Likes