Re: [mailop] Google rate limiting (UnsolicitedRateLimitError) for DKIM domain

[Emanuel Schorsch via mailop]

FYI that the missing domain in the tempfail message should now be fixed
(thanks to Wei)! Please let me know if you are not seeing it.

On Thu, Feb 15, 2024 at 11:50 PM Stefano Bagnara via mailop <
mailop@mailop.org> wrote:

> On Fri, 16 Feb 2024 at 05:02, Evan Burke  wrote:
>
>> It sounds like you're looking for a technical solution to a non-technical
>> problem. This bounce code is quite rare, occurring for a fraction of a
>> percent of the senders in my dataset. When it happens, it's a pretty strong
>> sign the sender has a spam problem and needs to do some cleanup; adding
>> rate limiting on your end won't change that.
>>
>
> No, your conclusions don't match my experience. It's weird somehow people
> think the only cause for issues is spam :-)
>
> Turns out the issue occours also to very good senders the first time they
> authenticate their flow with their own domain, so the first time their
> email pass from being signed with the ESP dkim to being signed with both
> the ESP dkim and their own domain dkim (and being aligned).
>
> So, it is not about unsolicited, but about "new flow" that Google does not
> recognize (they probably don't get the double dkim signature to keep track
> of the reputation in this change).
>
> In fact the very same senders after a first time they get this error
> starts sending without any issue: if it was about "a spam problem" the
> issue would occour every time (or multiple times).
>
> This is happening to us a lot because in the past months (after the
> Yahoogle announce) we forced many of our customers in the 3-20K daily email
> to authenticate so to pass DMARC. Previously they passed SPF and DKIM but
> with a shared ESP domain, and not DMARC because there was no alignment, but
> this worked fine (and still works fine, even for big senders, even if we
> don't know how long: maybe this is because of the established good
> reputation of our shared domain).
>
> Considering the error from Google is not recognized as "special" our mta
> retries sending to every google mx every 10 minutes and the whole email
> (the error occours at ".") is transmitted 5 times per attempt.
> So sometimes a single email is transmitted hundreds of times before it
> finally gets delivered.
>
> We also have indicators that even if the emails are delayed for hours at
> the end they land the inbox and not the spam folder (open rates at gmail
> are in the 40%).
>
> Now we implemented a special MTA code that will recognize the specific
> error and will delay for 1 hour every email with the same auth domain of
> the email that received the error and we are fine: this way we still have
> delays in sending that email flow, but we have almost zeroed
> retransmissions (temp fails): this means many millions temp fail. And it
> was a technical solution to a technical problem :-)
>
> Also, Google acknowledged the missing domain indication in the refuse
> message is not expected: who knows, maybe the fact they are not able to
> handle the reputation transition from the shared DKIM to the additional
> sender dkim is somehow related to this. Another technical problem.
>
> Stefano
>
>
>> On Tue, Feb 13, 2024 at 9:30 AM Stefano Bagnara via mailop <
>> mailop@mailop.org> wrote:
>>
>>> On Tue, 13 Feb 2024 at 18:09, Matus UHLAR - fantomas 
>>> wrote:
>>>
 On 05.02.24 14:56, Stefano Bagnara via mailop wrote:
 >we are a small ESP and every email sent from our system has SPF+DKIM
 >authentication from our system and most email also have a second DKIM
 >signature (one signature with our domain, one with the domain of the
 >sender).

 is bago.org that domain?

>>>
>>> No, it's not :-) bago.org is my personal domain and does not send bulk
>>> emails.
>>>
>>> A Google person already contacted me and identified the logs with the
>>> missing dkim domain indication. I guess they consider it (the missing
>>> domain indication in the error) a bug but I had no updates since then.
>>>
>>> Considering the email are signed with 2 different DKIM signatures they
>>> told me which one the error is about, and it is the "customer one" and this
>>> is enough for me.
>>>
>>> Unfortunately when I move a customer from "not authenticated" to
>>> "authenticated" seems like Google is not able to recognize the consistent
>>> DKIM signature on my own domain and starts rate limiting the new additional
>>> DKIM signature for the customer. This is creating delay issues for some
>>> customer in the first days after the authentication, but I understood
>>> there's nothing I can do to improve this.
>>>
>>>
 - it does not have DMARC, perhaps this is you problem?

>>>
>>> No
>>>
>>> - it has some redundant SPF records:

>>>
>>> I'm not aware of issues with redundant SPF records, as long as I stay in
>>> the 10 lookup: what are you talking about?
>>>
>>>
 I'm just not sure if I should advise you to drop
 "include:spf.mailvox".it or
 replace "include:spf.void.it" with "include:_spf.google.com"

>>>

Re: [mailop] Gmail.com SPF false negatives?

[Emanuel Schorsch via mailop]

This was caused by a temporary issue reaching the DNS servers. Let me pass
this along to see if it can be turned into a temporary (4xy) error.

On Tue, Feb 27, 2024 at 9:56 PM Marco Moock via mailop 
wrote:

> Am Tue, 27 Feb 2024 16:54:31 -0600
> schrieb Jarland Donnell via mailop :
>
> > Is it plausible that Google had a temporary issue reaching your DNS
> > servers?
>
> If so they should give an error message that says that.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anybody having trouble with gmail not recognizing valid SPF records?

[Emanuel Schorsch via mailop]

Thanks for flagging this. Looks like it was because the message had a
temporary error resolving SPF. I'll see if I can improve the behavior here.

On Thu, Feb 15, 2024 at 11:54 AM Eric J Esslinger via mailop <
mailop@mailop.org> wrote:

> Still getting bounces. Trying to engage with Google through the bulk
> sender escalation (even though we're not a bulk emailer we probably don't
> generate as many emails in a week as a spammer does in an hour)
> Someone also recommended ~all, though I don't think that will have any
> effect, I've gone and set that temporarily.
>
>
> Eric Esslinger (eesslin...@fpu-tn.com)
> Information Services Manager
> Fayetteville Public Utilities (http://www.fpu-tn.com/)
> 408 College St W
> Fayetteville, TN 37334-2914
> 1-931-433-1522 x 165 <(931)%20433-1522>
> 1-800-379-2534 x 165 <(800)%20379-2534>
> Fax: 1-931-433-0646 <(931)%20433-0646>
>
> -Original Message-
> From: mailop  On Behalf Of Eric J Esslinger
> via mailop
> Sent: Thursday, February 15, 2024 1:02 PM
> To: mailop@mailop.org
> Subject: Re: [mailop] Anybody having trouble with gmail not recognizing
> valid SPF records?
>
> WARNING: This message originated from outside Fayetteville Public
> Utilities. Please take appropriate care clicking on any links or opening
> any attachments.
>
>
> I'm still testing I have not gotten a bounce yet but it's inconsistent and
> comes in spurts as well.
>
> Eric Esslinger (eesslin...@fpu-tn.com)
> Information Services Manager
> Fayetteville Public Utilities (http://www.fpu-tn.com/)
> 408 College St W
> Fayetteville, TN 37334-2914
> 1-931-433-1522 x 165 <(931)%20433-1522>
> 1-800-379-2534 x 165 <(800)%20379-2534>
> Fax: 1-931-433-0646 <(931)%20433-0646>
>
> -Original Message-
> From: mailop  On Behalf Of Al Iverson via
> mailop
> Sent: Thursday, February 15, 2024 12:54 PM
> To: mailop@mailop.org
> Subject: Re: [mailop] Anybody having trouble with gmail not recognizing
> valid SPF records?
>
> WARNING: This message originated from outside Fayetteville Public
> Utilities. Please take appropriate care clicking on any links or opening
> any attachments.
>
>
> I saw you've since cleaned up the SPF record a bit to remove the IPv6 a/mx
> entries. Did that fix it?
>
> If not, this might actually be worth submitting to them to point out that
> they may be parsing it wrong:
> https://support.google.com/mail/contact/gmail_bulk_sender_escalation
>
> Regards,
> Al Iverson
>
> On Thu, Feb 15, 2024 at 12:21 PM Eric J Esslinger via mailop <
> mailop@mailop.org> wrote:
> >
> > My SPF records have been valid for... oh 10 years or so, and haven't
> changed, but the last two days I'm getting intermittent bounces sending to
> gmail.com addresses from our customer domain.
> > I've sent a couple of emails to postmas...@gmail.com but I'm not sure
> it's monitored. Anyone else seeing such issues?
> >
> > Hi. This is the qmail-send program at mail.fpunet.com.
> > I'm afraid I wasn't able to deliver your message to the following
> addresses.
> > This is a permanent error; I've given up. Sorry it didn't work out.
> >
> > :
> > 142.250.105.27 failed after I sent the message.
> > Remote host said: 550-5.7.26 This mail has been blocked because the
> sender is unauthenticated.
> > 550-5.7.26 Gmail requires all senders to authenticate with either SPF or
> DKIM.
> > 550-5.7.26
> > 550-5.7.26  Authentication results:
> > 550-5.7.26  DKIM = did not pass
> > 550-5.7.26  SPF [fpunet.com] with ip: [104.171.208.42] = did not pass
> > 550-5.7.26
> > 550-5.7.26  For instructions on setting up authentication, go to
> > 550 5.7.26
> > https://support.google.com/mail/answer/81126#authentication
> > t8-20020a25f60800b00dcbcc921879si776036ybd.61 - gsmtp
> >
> >
> > dig @8.8.8.8 txt fpunet.com
> >
> > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.10 <<>> @8.8.8.8 txt
> > fpunet.com ; (1 server found) ;; global options:  printcmd ;; Got
> > answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43644 ;; flags: qr
> > rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;fpunet.com.IN  TXT
> >
> > ;; ANSWER SECTION:
> > fpunet.com. 900 IN  TXT "v=spf1 +mx a:
> mail.fpunet.com ip4:104.171.208.42 ip6:2602:FD43:0:2::42 -all"
> >
> > ;; Query time: 38 msec
> > ;; SERVER: 8.8.8.8#53(8.8.8.8)
> > ;; WHEN: Thu Feb 15 11:59:10 2024
> > ;; MSG SIZE  rcvd: 115
> >
> >
> > Eric Esslinger (eesslin...@fpu-tn.com) Information Services Manager
> > Fayetteville Public Utilities (http://www.fpu-tn.com/)
> > 408 College St W
> > Fayetteville, TN 37334-2914
> > 1-931-433-1522 x 165 <(931)%20433-1522>
> > 1-800-379-2534 x 165 <(800)%20379-2534>
> > Fax: 1-931-433-0646 <(931)%20433-0646>
> >
> > This message may contain confidential and/or proprietary information and
> is intended for the person/entity to whom it was originally addressed. Any
> use by others is strictly prohibited.
> > ___
> > mailop 

Re: [mailop] Authentication Bounces by Gmail

[Emanuel Schorsch via mailop]

ARC trust is not just a binary. There are also ways that the ARC headers
can be used even if the ARC sealer is not 100% trusted. In this case,
adding ARC headers would help solve this particular issue (assuming the
original message was authenticated with at least one of SPF or DKIM).

You can see Google's advice for forwarders here
 with the relevant
section being "Add ARC headers to messages".

On Wed, Sep 13, 2023 at 9:27 AM Jason R Cowart  wrote:

> Hi Emanuel,
>
>
>
> Thanks very much for the suggestion.  ARC would seem to offer exactly what
> we need for this scenario, but I wasn’t sure of the level of trust the
> major providers place in it at this point.  Some Microsoft documentation (
> https://techcommunity.microsoft.com/t5/microsoft-defender-for-office/improving-defense-in-depth-with-trusted-arc-sealers-for/ba-p/3440707
> ) suggests their level of trust is limited, as tenant owners need to add
> trust for specific ARC sealers.
>
>
>
> Are you saying that if our service that does this forwarding were to add
> ARC headers then Gmail would authenticate the message based on the ARC
> chain?  Or is there an additional layer of trust you would need to extend
> to us?
>
>
>
> Our current message routing and hygiene vendor doesn’t currently offer an
> option to write ARC headers, although I did file an enhancement request
> with them over a year ago on this and am prepared to push them on this if
> it would solve this particular issue.
>
>
>
> Thanks,
>
> Jason
>
>
>
> *From: *Emanuel Schorsch 
> *Date: *Wednesday, September 13, 2023 at 12:24 AM
> *To: *Jason R Cowart 
> *Cc: *Brandon Long , mailop@mailop.org <
> mailop@mailop.org>
> *Subject: *Re: [mailop] Authentication Bounces by Gmail
>
> Hi Jason,
>
>
>
> One additional thing worth investigating is adding ARC headers for the
> forwarding cases. That has the potential to help with both downstream DMARC
> evaluation as well as unauthenticated bounces. This is particularly
> important if the DKIM signature is breaking or wasn't present in the first
> place.
>
>
>
> Best,
>
> Emanuel
>
>
>
> On Tue, Sep 12, 2023, 11:48 PM Jason R Cowart via mailop <
> mailop@mailop.org> wrote:
>
> Hi Brandon,
>
>
>
> Thank you for the responses.  I’ll send you some examples off list of
> successes and failures from the exact same sender and final recipient, both
> Gmail users.  I’d very much like to understand why we are seeing what
> appears to be an increase in DKIM validation failures in order to determine
> what can be done to improve the situation.  We are aware of DKIM signatures
> using the strict canonicalization option failing validation after
> forwarding, but in these examples the relaxed canonicalization was used.
>
>
>
> We do not rewrite the envelope sender as we forward. I’m not convinced the
> non-trivial effort needed to shift to rewriting the sender would yield a
> durable solution to this problem, as it would not help with a DMARC check
> since the resulting SPF pass will be out of alignment with the sender in
> the From: header.  It would seem we’re dependent on the initial DKIM
> signature passing validation.  I’d welcome any other perspectives on the
> topic.
>
>
>
> Best,
>
> Jason
>
>
>
>
>
> *From: *Brandon Long 
> *Date: *Tuesday, September 12, 2023 at 8:29 PM
> *To: *Jason R Cowart 
> *Cc: *mailop@mailop.org 
> *Subject: *Re: [mailop] Authentication Bounces by Gmail
>
> Looking at the messages from that IP getting that rejection message, I'm
> seeing a lot of DKIM body hash did not verify, I'd also verify that your
> system isn't modifying the messages that it is forwarding.
>
>
>
> Brandon
>
>
>
> On Tue, Sep 12, 2023 at 8:20 PM Brandon Long  wrote:
>
> That message did not have a DKIM header ... or was so garbled that we
> didn't extract it.
>
>
>
> Due to DKIM replay, we may spam reject forwarded messages that DKIM verify
> but not SPF, but those would not have that rejection message.
>
>
>
> And yes, we are continuing to ramp no auth, no entry.
>
>
>
> I'm sure I've had a long explanation on here in the past year, but the
> short answer is if the message is not DKIM valid and you're forwarding, you
> should rewrite
>
> the MAIL FROM to a domain you own that will SPF authn the message... and
> try not to forward spam.
>
>
>
> Brandon
>
>
>
> On Tue, Sep 12, 2023 at 6:00 PM Jason R Cowart via mailop <
> mailop@mailop.org> wrote:
>
> We are seeing an increasing number of bounces by Gmail related to failed
> authentication checks.  The bounces include language like:
>
> <<< 550-5.7.26 This mail is unauthenticated, which poses a security risk
> to
> the
> <<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender
> must
> <<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this
> message,
> <<< 550-5.7.26 DKIM checks did not pass and SPF check for [mcn.org
> 

Re: [mailop] Authentication Bounces by Gmail

[Emanuel Schorsch via mailop]

Hi Jason,

One additional thing worth investigating is adding ARC headers for the
forwarding cases. That has the potential to help with both downstream DMARC
evaluation as well as unauthenticated bounces. This is particularly
important if the DKIM signature is breaking or wasn't present in the first
place.

Best,
Emanuel

On Tue, Sep 12, 2023, 11:48 PM Jason R Cowart via mailop 
wrote:

> Hi Brandon,
>
>
>
> Thank you for the responses.  I’ll send you some examples off list of
> successes and failures from the exact same sender and final recipient, both
> Gmail users.  I’d very much like to understand why we are seeing what
> appears to be an increase in DKIM validation failures in order to determine
> what can be done to improve the situation.  We are aware of DKIM signatures
> using the strict canonicalization option failing validation after
> forwarding, but in these examples the relaxed canonicalization was used.
>
>
>
> We do not rewrite the envelope sender as we forward. I’m not convinced the
> non-trivial effort needed to shift to rewriting the sender would yield a
> durable solution to this problem, as it would not help with a DMARC check
> since the resulting SPF pass will be out of alignment with the sender in
> the From: header.  It would seem we’re dependent on the initial DKIM
> signature passing validation.  I’d welcome any other perspectives on the
> topic.
>
>
>
> Best,
>
> Jason
>
>
>
>
>
> *From: *Brandon Long 
> *Date: *Tuesday, September 12, 2023 at 8:29 PM
> *To: *Jason R Cowart 
> *Cc: *mailop@mailop.org 
> *Subject: *Re: [mailop] Authentication Bounces by Gmail
>
> Looking at the messages from that IP getting that rejection message, I'm
> seeing a lot of DKIM body hash did not verify, I'd also verify that your
> system isn't modifying the messages that it is forwarding.
>
>
>
> Brandon
>
>
>
> On Tue, Sep 12, 2023 at 8:20 PM Brandon Long  wrote:
>
> That message did not have a DKIM header ... or was so garbled that we
> didn't extract it.
>
>
>
> Due to DKIM replay, we may spam reject forwarded messages that DKIM verify
> but not SPF, but those would not have that rejection message.
>
>
>
> And yes, we are continuing to ramp no auth, no entry.
>
>
>
> I'm sure I've had a long explanation on here in the past year, but the
> short answer is if the message is not DKIM valid and you're forwarding, you
> should rewrite
>
> the MAIL FROM to a domain you own that will SPF authn the message... and
> try not to forward spam.
>
>
>
> Brandon
>
>
>
> On Tue, Sep 12, 2023 at 6:00 PM Jason R Cowart via mailop <
> mailop@mailop.org> wrote:
>
> We are seeing an increasing number of bounces by Gmail related to failed
> authentication checks.  The bounces include language like:
>
> <<< 550-5.7.26 This mail is unauthenticated, which poses a security risk
> to
> the
> <<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender
> must
> <<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this
> message,
> <<< 550-5.7.26 DKIM checks did not pass and SPF check for [mcn.org
> ]
> did not
> pass
> <<< 550-5.7.26 with ip: [67.231.157.125]. The sender should visit
> <<< 550-5.7.26 https://support.google.com/mail/answer/81126#authentication
> 
>
> for
> <<< 550 5.7.26 instructions on setting up authentication.
> z6-20020a05622a028600b00403a8e58423si1377805qtw.448 - gsmtp
> 554 5.0.0 Service unavailable
>
>
>
> This is occurring in situations where our users forward their mail to a
> personal Gmail account.  SPF checks will of course fail in the scenario,
> but DKIM checks should pass.  In fact, they most often do pass—users
> impacted by this are only seeing a small subset of their mail from a given
> sender bounced (which often times will be a Gmail sender).  In cases where
> the user retains a copy locally we’ve been able to verify that the DKIM
> signature was present and was successfully validated by our system.
>
> Is anyone else experiencing this?
>
> Is anyone from Google could reach out to me off-list to discuss that would
> be much appreciated.
>
>
>
> Best,
>
> Jason Cowart
>
> Stanford University IT
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> 
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org