On Thu, Feb 26, 2026 at 10:54 AM Patrick O'Callaghan <[email protected]> wrote: > > On Thu, 2026-02-26 at 06:44 -0600, Roger Heflin wrote: > > > Curiouser and curiouser. My Gmail filters already had the list, > > > keyed > > > as 'list:(<users.lists.fedoraproject.org>)', as not to be treated > > > as > > > spam. I've added a "to: [email protected]" explicitly. > > > > > > > At the point the mail server declares the message spam and rejects > > it, > > it has almost certainly not accessing anything related to any of your > > user contacts. > > I always assumed that the receiver's rules would override, but on > asking Gemini I get this: > > In the hierarchy of Gmail's logic, a personal filter that has "Never > send it to Spam" checked is generally considered a "force-to-inbox" > command. It is designed to override Gmail’s automated spam > classification. > However, there are a few "fine print" reasons why you might still > see an email where it doesn't belong: > > 1. The "Safety Banner" Exception > Even if the filter forces the email into your Inbox, Gmail might > still distrust it. In these cases, you’ll see the email in your > Inbox, but it will have a large gray or yellow warning banner at the > top saying, "Gmail couldn't verify that [Sender] actually sent this > message." The filter kept it out of the Spam folder, but Gmail is > still "quarantining" its links and images until you click "Looks > safe." > > 2. Workspace Admin Overrides > If you are using a Google Workspace account (for work or school), > your organization’s Administrator can set global routing and spam > rules. These admin-level settings can sometimes supersede your > personal filters. If your IT department has a strict policy against > a certain domain or file type, your "Never send to Spam" rule might > be ignored. > > 3. Outright Rejection (SMTP Level) > In 2024 and 2025, Google implemented stricter requirements for bulk > senders (like SPF, DKIM, and DMARC authentication). If an email is > so poorly authenticated that Gmail considers it a "hard fail" or a > malicious spoof, it might be rejected entirely before it even > reaches your account. In this case, the email doesn't go to Spam or > the Inbox—it simply never arrives. > > 4. Filter Specificity Issues > Sometimes a filter fails because it’s looking for the wrong thing. > * The "From" name vs. Email address: If you filtered the name "John > Doe" but he sends from a different email address than the one you > saved, the filter won't trigger. > * Hidden "via" addresses: Many newsletters use third-party senders > (like Mailchimp). If the "Reply-to" address doesn't match the > "Sender" address, a simple filter might miss it. > Pro Tip: To make your filter "bulletproof," instead of just > filtering by email address, try filtering by the domain (e.g., > from:*@company.com) or a unique word that always appears in those > emails. > > I wouldn't expect any of those things to apply in this case. > I don't know why you think none of those apply.
This is a #3 rejection. SMTP decided something was wrong with the message and outright rejected--that is exactly what this rejection message is. So clearly gmail has a few more (half-assed) rules of some sort than Gemini knows about, which is not a shock since no AI will know about what Gmail is doing since Gmail almost certainly does not document it any place public that Gemini(or any other public AI) would have been able to scrape. -- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
