To test @ian-weisser’s theory that the problem may lie with my ISP, I just sent three similar test messages to a Gmail recipient but from different addresses:
gunnarhj@ubuntu.com
That one bounced (again).
gunnarhj@debian.org
gunnarhj@debian.org is an alias just like gunnarhj@ubuntu.com, and also without an SPF record that authorizes the SMTP server of my ISP. But unlike the message from gunnarhj@ubuntu.com this one passed.
ubuntu@gunnar.cc
That’s a real address with an inbox and with an SPF record that authorizes the SMTP server of my ISP. The message from that address passed too.
Since the message from gunnarhj@debian.org was not bounced, I still have a reason to fear that the problem lies with the ubuntu.com domain and Gmail rather than the reputation of my ISP. And @madhens: I think this piece of info is relevant input to the ticket.
Getting in touch with my ISP is a cumbersome exercise which I’m going to wait with for now. If I’d contact the support, they would just tell me: “please use your @telia.com address”. And that’s obviously not the solution I’d like to see. If I’d contact somebody who understands the issue, they would probably ask for evidence that the problem lies with them. And at this time I’m short of such evidence.
Also, below please find the source of the Delivery Status Notification message I got for the bounced message. @madhens: That may also be useful for the ticket (or not).
From - Mon Mar 28 22:23:24 2022
X-Account-Key: account2
X-UIDL: 000704e952d96275
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <MAILER-DAEMON>
Received: from seviper.canonical.com (seviper.canonical.com [91.189.95.10])
by gunnar.cc (8.15.2/8.15.2/Debian-10) with ESMTP id 22SKLXb2012597
for <ubuntu@gunnar.cc>; Mon, 28 Mar 2022 22:21:34 +0200
Received: from ts201-smtpout76.ddc.teliasonera.net (ts201-smtpout76.ddc.teliasonera.net [81.236.60.181])
by seviper.canonical.com (Postfix) with ESMTP id AFDC71A2A81
for <gunnarhj@ubuntu.com>; Mon, 28 Mar 2022 20:21:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telia.com; s=tssemail; t=1648498888;
bh=iX2+rQzJiCrykiyjf8a/t98Pyh2VdIOIOOcWXp/4duE=;
h=From:Subject:To:Date:Message-ID:MIME-Version;
b=LYq4YnfEbYItXoc2WtNDmrjpRkgNiFCAU9nf/YeL4FA1n6AegUca0qHOl3lU6QxrGozDHljPOv8wDd7JwFOLUVVB0JAbRizFHXP//a3p4bIkpSI2R75iHG4oWwwNiAJE8/25dNAiP6QHB1XHnJ/bSZDARw+EcoF5NU4DVlVGzOHu1eVci7rdFmMWk26gZDs9zhMDbbLz/GH/3mK5ehnK8q/YrfwXEJwKdwBRO2r4kUnOnMLOjWafttdsoH5ZGn+ZjbNMd+E9zacfo0r5Y/kLLyJN3LqsoD/ZmYWMAB3ORMheV7uxm3iR9U6mclk02F1LUTzTuVYieV4dpErJ3mtwfQ==
X-RG-Rigid: 61A898DD06E4D80B
X-Originating-IP: [::1]
X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvvddrudehjedgudeglecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfvgffnkfetufghpdggtfgfnhhsuhgsshgtrhhisggvpdfqfgfvnecuuegrihhlohhuthemuceftddtnecupfhothhifhhitggrthhiohhnucdluddttddttddmnecujfgurhephffuvfffkfggtgesphdttdertddtjeenucfhrhhomhepofgrihhlucffvghlihhvvghrhicuufgvrhhvihgtvgcuoefotefknffgtfdqffetgffoqffpsehtvghlihgrrdgtohhmqeenucggtffrrghtthgvrhhnpeejtefhfeeuudejjeduueetteevleeigfdvheeiffeuleefhfeutedtgefffedvheenucffohhmrghinhepghhoohhglhgvrdgtohhmnecukfhppeemmedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepthhsvddtuddqshhmthhpohhuthejiedruggutgdrthgvlhhirghsohhnvghrrgdrnhgvthdpihhnvghtpeemmedupdhmrghilhhfrhhomhepoeeqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepghhunhhnrghrhhhjsehusghunhhtuhdrtghomh
X-RazorGate-Vade-Verdict: clean 10000
X-RazorGate-Vade-Classification: bounce
Received: by ts201-smtpout76.ddc.teliasonera.net (5.8.716) id 61A898DD06E4D80B for gunnarhj@ubuntu.com; Mon, 28 Mar 2022 22:21:27 +0200
From: Mail Delivery Service <MAILER-DAEMON@telia.com>
Subject: Delivery Status Notification
To: gunnarhj@ubuntu.com
Date: Mon, 28 Mar 2022 22:21:27 +0200
Message-ID: <61A898DD06E4D80A@ts201-smtpout76.ddc.teliasonera.net>
X-CP-Transaction-ID: 61A898DD06E4D800
X-CP-For: dsmythies@telus.net
MIME-Version: 1.0
Content-Type: Multipart/Report; report-type=delivery-status; boundary="========/61A898DD06E4D800/ts201-smtpout76.ddc.teliasonera.net"
This multi-part MIME message contains a Delivery Status Notification.
If you can see this text, your mail client may not be able to understand MIME
formatted messages or DSNs (see RFC 2045 through 2049 for general MIME
information and RFC 1891 through 1894 for DSN specific information).
--========/61A898DD06E4D800/ts201-smtpout76.ddc.teliasonera.net
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
- These recipients of your message have been processed by the mail server:
dsmythies@telus.net; Failed; 5.3.0 (other or undefined mail system status)
Remote MTA aspmx.l.google.com: network error
- SMTP protocol diagnostic: 550-5.7.1 [81.236.60.181 12] Our system has detected that this message is\r\n550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,\r\n550-5.7.1 this message has been blocked. Please visit\r\n550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError\r\n550 5.7.1 for more information. p9-20020a2e9a89000000b0024952f7bd13si17651075lji.622 - gsmtp
--========/61A898DD06E4D800/ts201-smtpout76.ddc.teliasonera.net
Content-Type: Message/Delivery-Status
Reporting-MTA: dns; ts201-smtpout76.ddc.teliasonera.net
Received-from-MTA: dns; [192.168.1.3] (213.67.17.18)
Arrival-Date: Mon, 28 Mar 2022 22:21:27 +0200
Final-Recipient: rfc822; dsmythies@telus.net
Action: Failed
Status: 5.3.0 (other or undefined mail system status)
Remote-MTA: dns; aspmx.l.google.com
--========/61A898DD06E4D800/ts201-smtpout76.ddc.teliasonera.net
Content-Type: Message/RFC822
Return-Path: <gunnarhj@ubuntu.com>
Received: from [192.168.1.3] (213.67.17.18) by ts201-smtpout76.ddc.teliasonera.net (5.8.716) (authenticated as u87648615)
id 61A898DD06E4D800 for dsmythies@telus.net; Mon, 28 Mar 2022 22:21:27 +0200
Message-ID: <61a4a629-619d-f0f8-518f-ad94afbc731e@ubuntu.com>
Date: Mon, 28 Mar 2022 22:21:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Content-Language: en-US
To: Doug Smythies <dsmythies@telus.net>
From: Gunnar Hjalmarsson <gunnarhj@ubuntu.com>
Subject: Test message I
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Doug!
Due to my email problem I mentioned the other day, I sent three test
messages to you with similar content but from different email addresses.
Hope you don't mind.
This one from gunnarhj@ubuntu.com
Cheers,
Gunnar
--========/61A898DD06E4D800/ts201-smtpout76.ddc.teliasonera.net--
Sorry, I’m not sure I have much I can add. The Canonical IS ticket (access is limited I think) is #136362. This is the one I raised when I first received a very large number of bounce notifications to ubuntu-devel-owner@. It was closed after adjustments were made. Today I got a very large number of unsubscribe notifications to ubuntu-devel-owner@ and reopened the ticket.
That’s all I know really. It seems to me that there’s a problem with lists.ubuntu.com traffic being accepted by Gmail, resulting in bounces and automatic unsubscribes. But I don’t actually know that for certain. I haven’t investigated in any detail at all, leaving that for Canonical IS.
Thanks @rbasak, that’s still useful. Myself have observed that they seem to bounce any message from ubuntu.com addresses (unless they happen to be sent from some Gmail account). If that’s generally true, I suppose it explains the problem you have seen with the lists.
Just wanted to provide an update. Evidently there was a recent change in how Gmail handles authentication, which either requires SPF or DKIM. The fixes required to solve this will require prioritization by IS management, and this issue has just been escalated.
Evidently, Debian has been using per-user DKIM keys, but according to the support staff, this is dangerous as it means anyone with an at-ubuntu e-mail address could impersonate another. Naturally, the staffer feels this is not a good solution, and I agree.
Thanks again for bringing this up, and we’ll keep you and everyone updated!
Both - the alias problem exists currently to GMail recipients, but it also is wider than just one recipient, because I use MS365 to run my email (yes i know, I’m paying Microsoft for my email, but I’d rather them absorb the security part.)
MS365 won’t let me send as aliases not in the MS365 domain. Barring that, I route my @ubuntu.com outgoing mail via my (now otherwise dead) SMTP server when I ran my own email myself.
IS needs to set up SMTP for us with ubuntu.com emails (hint: i think they’re already working on this?), complete with DKIM sigs and SPF records, and Google needs to make sure they update things.
FYI though: all “aliases” routed through “random mail servers” have always been on the “More heavily regulate this traffic” behaviors list. At GMail, at my own mail gateway, etc. because it’s much easier to spoof @ubuntu.com until we get an SMTP set up and using SPF, DKIM sigs, and a valid DMARC record.
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!
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)
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.
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
@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).
