Re: [mailop] Authentication Bounces by Gmail

[Grant Taylor via mailop]

On 9/13/23 12:07 PM, Emanuel Schorsch via mailop wrote:
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.


Thank you for making that comment.

That helps partially elide what I consider to be a priming problem with ARC.

I'll re-consider my use of ARC.  --  I had it for a while, but stopped 
for various reasons, most of which revolved around my perception of the 
priming problem.




--
Grant. . . .
unix || die

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Scott Mutter via mailop]

Going from the list provided at:

https://www.isipp.com/blog/validity-fbl-charging-how-much-cost/

The only one that I really get any feedback from is Comcast, maybe
Synacor.  And those are few and far between.  What's going to be the
incentive to pay for these ARF reports?

Sure, other people may be in a different boat than I am, and they may get a
lot of reports from those various providers.  But you've got to think that
it's a very small subset of Validity users that get enough feedback
messages from those providers, enough to warrant spending money for the ARF
reports.

Perhaps Validity is just exhausting all methods of trying to make money
before folding up shop.  But I can't see this as being a major money maker
for them.

On Wed, Sep 13, 2023 at 11:40 AM Opti Pub via mailop 
wrote:

> I think that’s the point, mostly all of them used to allow direct setup
> but don’t anymore (when universal fbl became widespread). Seznam is one of
> 20+.
>
> Now that you have to pay for it maybe more vendors will start allowing
> direct setup again? That’s what I’m wondering about.
>
> I guess we will see.
>
> On Wed, Sep 13, 2023 at 11:18 AM Gellner, Oliver via mailop <
> mailop@mailop.org> wrote:
>
>> On 13.09.2023 at 16:06 Scott Mutter via mailop wrote:
>>
>> > I also think one thing that Validity may not be understanding with this
>> move, and may lead to shooting themselves in the foot, the list of email
>> service providers that Validity provides feedback for isn't exactly major
>> players.
>> > We get more feedback from Yahoo and Outlook's FBL system than we do
>> Validity and Validity covers what?  21 different providers?  There's no
>> incentive there for me to pay for access to Validity's ARF feeds.  When
>> Validity stops sending ARF reports, I will simply no longer receive
>> Validity ARF reports - it won't be a major loss.
>>
>> On top of that some of the providers like Seznam also offer feedback
>> loops directly, so you don't need Validity for forwarding the reports.
>>
>> --
>> BR Oliver
>> 
>>
>> dmTECH GmbH
>> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
>> Telefon 0721 5592-2500 Telefax 0721 5592-2777
>> dmt...@dm.de * www.dmTECH.de
>> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
>> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
>> 
>> Datenschutzrechtliche Informationen
>> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
>> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
>> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
>> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
>> Informationen unter anderem zu den konkreten Datenverarbeitungen,
>> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
>> Datenschutzbeauftragten finden Sie hier<
>> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
>> >.
>> ___
>> 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
https://list.mailop.org/listinfo/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] New Validity policy for paid FBL (ARF)

[Opti Pub via mailop]

I think that’s the point, mostly all of them used to allow direct setup but
don’t anymore (when universal fbl became widespread). Seznam is one of 20+.

Now that you have to pay for it maybe more vendors will start allowing
direct setup again? That’s what I’m wondering about.

I guess we will see.

On Wed, Sep 13, 2023 at 11:18 AM Gellner, Oliver via mailop <
mailop@mailop.org> wrote:

> On 13.09.2023 at 16:06 Scott Mutter via mailop wrote:
>
> > I also think one thing that Validity may not be understanding with this
> move, and may lead to shooting themselves in the foot, the list of email
> service providers that Validity provides feedback for isn't exactly major
> players.
> > We get more feedback from Yahoo and Outlook's FBL system than we do
> Validity and Validity covers what?  21 different providers?  There's no
> incentive there for me to pay for access to Validity's ARF feeds.  When
> Validity stops sending ARF reports, I will simply no longer receive
> Validity ARF reports - it won't be a major loss.
>
> On top of that some of the providers like Seznam also offer feedback loops
> directly, so you don't need Validity for forwarding the reports.
>
> --
> BR Oliver
> 
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
> Informationen unter anderem zu den konkreten Datenverarbeitungen,
> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
> Datenschutzbeauftragten finden Sie hier<
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
> >.
> ___
> 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] Authentication Bounces by Gmail

[Jason R Cowart via mailop]

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 
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 
mailto: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 mailto:bl...@google.com>>
Date: Tuesday, September 12, 2023 at 8:29 PM
To: Jason R Cowart mailto:jcow...@stanford.edu>>
Cc: mailop@mailop.org 
mailto: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 
mailto:bl...@google.com>> 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 
mailto: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 

Re: [mailop] New Validity policy for paid FBL (ARF)

[Gellner, Oliver via mailop]

On 13.09.2023 at 16:06 Scott Mutter via mailop wrote:

> I also think one thing that Validity may not be understanding with this move, 
> and may lead to shooting themselves in the foot, the list of email service 
> providers that Validity provides feedback for isn't exactly major players.
> We get more feedback from Yahoo and Outlook's FBL system than we do Validity 
> and Validity covers what?  21 different providers?  There's no incentive 
> there for me to pay for access to Validity's ARF feeds.  When Validity stops 
> sending ARF reports, I will simply no longer receive Validity ARF reports - 
> it won't be a major loss.

On top of that some of the providers like Seznam also offer feedback loops 
directly, so you don't need Validity for forwarding the reports.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Grant Taylor via mailop]

On 9/13/23 6:04 AM, Jaroslaw Rafa via mailop wrote:
If someone forwards mail to his/her account, they obviously know 
*from where* they forward mail.


Aside:  I originally thought you were referring to which senders would 
be sending messages that would get forwarded.  But after reading you 
next statement, I realized that you were referring to the (intermediate) 
system(s) doing the forwarding.


So allow your user to specify a list of IP addresses of servers 
from where the mail is forwarded.


I don't buy it.

Even if people did know the IP address of their (former) forwarding 
inbox provider server(s) at one point in time, things change.  Often 
this change is unbeknownst to the end users.  Maybe it's simply a change 
within the providers network.  Maybe the provider outsourced to a 3rd 
party.  Maybe the provider insourced from a 3rd party.  Maintaining this 
list is going to be untenable for most end users.


Email from these servers to that particular user will be exempt from 
SPF/DKIM/DMARC checks.


I see that as more complicated than likely desired and potential to be 
abused.  Especially with the complication of multiple recipients per 
message, one of whom might have more such allow listing.


(If the user doesn't know the IP address from which the mail is sent, 
he/she can probably easily find someone who knows, at the site from 
where the forward originates.)


That's an example of trouble / needing help to do what you suggest from 
the word go.




--
Grant. . . .
unix || die

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Scott Mutter via mailop]

I also think one thing that Validity may not be understanding with this
move, and may lead to shooting themselves in the foot, the list of email
service providers that Validity provides feedback for isn't exactly major
players.

We get more feedback from Yahoo and Outlook's FBL system than we do
Validity and Validity covers what?  21 different providers?  There's no
incentive there for me to pay for access to Validity's ARF feeds.  When
Validity stops sending ARF reports, I will simply no longer receive
Validity ARF reports - it won't be a major loss.

On Mon, Sep 11, 2023 at 6:24 AM Support 3Hound via mailop 
wrote:

> Dear list,
> I would like to understand what the community think about the new Validity
> universal feedback loop service that is switching to a paid service
> starting 21 September 2023.
>
> As Validity worked in the the last years to achieve the management of the
> FBL service from all the "main" country-level and international mailbox
> providers (as the "universal" word suggest), I think that this new policy
> is unfair and a very bad news for the mail operators community.
>
> During years the FBL became a kind of "safe feature" for users that prefer
> to click "junk" or "spam" and be sure they will not receive anymore.
>
> The "one click unsubscribe/ List-unsubscribe header" should be the right
> way to do that... true! But this is not the focus, everyone know that FBL
> are -de facto- used like that from users and that they are honored from
> correct sender.
>
> FBL generates also a good data flow for the mailbox provider that may
> filter the "next e-mail" from a sender that don't honor the FBL (or can't
> act realtime the unsubcribe) generating a better service for the end user
> and a way to identify good player and bad ones.
>
> Switching to a paid service bring these metrics to fails; rich spammer may
> easily honor them getting a better reputation than a little correct player.
>
> It also means that it's needed to buy a paid service from a private
> company to follows best practices, something that seems to be unfair.
>
> But... as any collaborating service it's based on other
> peers/nodes/players so my question is: how mail players will act in this
> scenario?
>
> For example, if every mailbox is going to reactivate his own service to
> get back the control of their FBL, it will not have just a short term
> impact...
>
> ___
> 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] Authentication Bounces by Gmail

[Mike Hillyer via mailop]

The financial incentives can be even more skewed: I watch the little email 
marketing subreddits regularly, and one thing you see all the "cold email" 
people telling each other (amidst a bunch of outdated deliverability tips that 
show that whole community is one big echo chamber with very little true 
understanding) is that Google Workspace inboxes get better deliverability.

So the more paying mailboxes being used for spam, the more revenue they get.

Mike

-Original Message-
From: mailop  On Behalf Of Jaroslaw Rafa via mailop
Sent: Wednesday, September 13, 2023 7:18 AM
To: mailop@mailop.org
Subject: Re: [mailop] Authentication Bounces by Gmail

Dnia 13.09.2023 o godz. 13:54:01 Atro Tossavainen via mailop pisze:
> > Might be convinced with this if it weren't for gmail being the 
> > source of ~40% of the spam we receive.
> 
> And that's after all of the botnets and so on have been blocked 
> through the use of DNSBLs, I suppose?

I guess Google doesn't care about the spam they send, because this doesn't give 
them financial losses (if someone would start suing them for spam they send, 
things may change). On the other hand, they are *convinced* (even if this might 
not be completely true), that accepting anything that *might
be* spam (even if it isn't actually) may harm them financially. So they are 
over-filtering. By "over-filtering" I mean they are focused more on minimizing 
the number of errors of the first kind (mistakenly accepting a spam mail) than 
on minimizing the number of errors of the second kind (mistakenly rejecting, or 
filing to Spam folder, a non-spam mail). The two goals are a bit contrary to 
each other - if you try too hard to minimize one, the other goes up. But my 
opinion is - and always was - that for any decent spam filtering system the 
second goal should be more important than the first, ie. you should make sure 
that users miss as little non-spam mails as possible, even at the cost of 
slight increase on number of spams that go through. However, Google seems to 
think the other way - they want to filter as much spams (and probable spams) as 
possible, at the cost of increase in rejected non-spam mails. And probably 
their users are happy with losing mail anyway as they are not going away (and 
remember, Google is not only free Gmail, it is also paid tier that many 
corporations use, and that suffers the same problem...).
--
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there was 
a Hushpuppy, and she lived with her daddy in the Bathtub."
___
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] New Validity policy for paid FBL (ARF)

[Jaroslaw Rafa via mailop]

Dnia 13.09.2023 o godz. 12:35:15 Gellner, Oliver via mailop pisze:
> Other than that, I'm with you and Bill Cole: If your infrastructure is not
> being used to send spam, newsletters or other marketing messages, feedback
> loops provide no benefit. 100% of all reports are going to be false
> positives of people who either accidentally hit the wrong button or are
> generally confused about the difference between the report spam button and
> the delete button. But this doesn't matter, email providers know this as
> well and if one out of thousands of emails is accidentally reported as
> spam it doesn't change anyones reputation.

Asking out of curiosity: what happens in case of small senders? If one of
not thousands, but - say - five emails sent in total is mistakenly reported
as spam?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Gellner, Oliver via mailop]

On 12.09.2023 at 22:30 Mark Fletcher via mailop wrote:

> Thank you for writing this up, it's been confusing. We only receive 
> individual reports and not the aggregated data (or if we do it's not sent to 
> us). We received a slightly different email from Validity. It includes the 
> 'login method update' but it makes no mention of upgrading our account; 
> instead this was included:

>> Product Enhancement: You will now have access to aggregated data insights 
>> within the application, enabling you to gain a broader understanding of 
>> overall trends, patterns, and customer sentiments.
>> You will receive an additional reminder one week before the launch with 
>> additional information to ensure that you are well-prepared for the 
>> transition and have all the information you need to securely log in to your 
>> account.

> So maybe we won't be subject to the new fees? Like I said, it's been 
> confusing.

The mentioned aggregated data insights are part of the free service and 
accessible through Validitys website. If you want to continue to receive 
individual ARF reports by email, you will have to become a paying customer one 
way or the other. The email is just confusing as the change from a free to a 
paid service is described as an enhancement, but this is just marketing lingo.

Other than that, I'm with you and Bill Cole: If your infrastructure is not 
being used to send spam, newsletters or other marketing messages, feedback 
loops provide no benefit. 100% of all reports are going to be false positives 
of people who either accidentally hit the wrong button or are generally 
confused about the difference between the report spam button and the delete 
button. But this doesn't matter, email providers know this as well and if one 
out of thousands of emails is accidentally reported as spam it doesn't change 
anyones reputation.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Jaroslaw Rafa via mailop]

Dnia 13.09.2023 o godz. 13:54:01 Atro Tossavainen via mailop pisze:
> > Might be convinced with this if it weren't for gmail being the source of
> > ~40% of the spam we receive.
> 
> And that's after all of the botnets and so on have been blocked
> through the use of DNSBLs, I suppose?

I guess Google doesn't care about the spam they send, because this doesn't
give them financial losses (if someone would start suing them for spam
they send, things may change). On the other hand, they are *convinced* (even
if this might not be completely true), that accepting anything that *might
be* spam (even if it isn't actually) may harm them financially. So they are
over-filtering. By "over-filtering" I mean they are focused more on
minimizing the number of errors of the first kind (mistakenly accepting a
spam mail) than on minimizing the number of errors of the second kind
(mistakenly rejecting, or filing to Spam folder, a non-spam mail). The two
goals are a bit contrary to each other - if you try too hard to minimize
one, the other goes up. But my opinion is - and always was - that for any
decent spam filtering system the second goal should be more important than
the first, ie. you should make sure that users miss as little non-spam
mails as possible, even at the cost of slight increase on number of spams
that go through. However, Google seems to think the other way - they want
to filter as much spams (and probable spams) as possible, at the cost of
increase in rejected non-spam mails. And probably their users are happy with
losing mail anyway as they are not going away (and remember, Google is not
only free Gmail, it is also paid tier that many corporations use, and that
suffers the same problem...).
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Jaroslaw Rafa via mailop]

Dnia 13.09.2023 o godz. 02:52:59 Jarland Donnell via mailop pisze:
> 
> It's my finding that at scale, there's no silver bullet to ensure
> that 100% of emails you forward are going to be accepted by Google,
> or anyone really. That's why anyone who considers their inbox
> mission critical needs to rely on their inbox provider, and not a
> third party accepting email from their inbox provider.

There's one simple solution that can be quite easily adopted by mailbox
providers.
If someone forwards mail to his/her account, they obviously know *from
where* they forward mail.
So allow your user to specify a list of IP addresses of servers from where
the mail is forwarded. Email from these servers to that particular user will
be exempt from SPF/DKIM/DMARC checks.
(If the user doesn't know the IP address from which the mail is sent, he/she
can probably easily find someone who knows, at the site from where the
forward originates.)
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Atro Tossavainen via mailop]

> Might be convinced with this if it weren't for gmail being the source of
> ~40% of the spam we receive.

And that's after all of the botnets and so on have been blocked
through the use of DNSBLs, I suppose?

Mail subject lines seen in our test/dev spamtraps from Google outbounds
over the past two weeks:

For more details please reply
Buy STRONG SMTP Cyber Weapon
Come over to local moms home
common bedtime habit skyrockets dementia risk.
Milf Available for Free Hookups
Come to my place & bang me tonight!
Separated women looking for men
The Ultimate Cure for Urination Frequency at Night

The rate at which our production spamtraps get stuff from Google
outbounds is more or less 1% of all mail, all of the time. This iso
low tens of thousands of spam every day (yes, we're small, with only
low thousands of domain names feeding this). It's mostly fake
dating/hookup crap, with 419 a strong #2 contender and pharma #3.

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, https://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Rob Kendrick via mailop]

On Tue, Sep 12, 2023 at 08:20:32PM -0700, Brandon Long via mailop wrote:
> 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.

Might be convinced with this if it weren't for gmail being the source of
~40% of the spam we receive.

B.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Jarland Donnell via mailop]

SRS is usually fairly trivial these days, but DMARC changes things. 
While SRS is doing fine for our users when forwarding email to Gmail, 
when auth fails and DMARC = reject Google will tell you pretty plainly 
that they're probably not going to accept it: 
https://support.google.com/mail/answer/2451690


"For example, eBay and PayPal publish a policy requiring all of their 
mail to be authenticated in order to appear in someone's inbox. In 
accordance with their policy, Google rejects all messages from eBay or 
PayPal that aren't authenticated."


It's my finding that at scale, there's no silver bullet to ensure that 
100% of emails you forward are going to be accepted by Google, or anyone 
really. That's why anyone who considers their inbox mission critical 
needs to rely on their inbox provider, and not a third party accepting 
email from their inbox provider. Most users won't have a complaint about 
this, they won't even notice what wasn't accepted when forwarding (and 
often didn't really want whatever it was anyway). But that's because 
most users don't consider their personal inbox to be mission critical, 
and most users with a mission critical inbox use their work email system 
rather than forward everything from c...@fortune500company.tld to 
babybearbobca...@gmail.com.


On 2023-09-13 01:44, 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 
 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 [1]] 
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 [2]

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

Re: [mailop] Authentication Bounces by Gmail

[Jarland Donnell via mailop]

https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme

On 2023-09-13 01:19, Atro Tossavainen via mailop wrote:


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.


That's not how forwarding works, Brandon.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

Re: [mailop] Authentication Bounces by Gmail

[Jason R Cowart via mailop]

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 
mailto:bl...@google.com>> 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 
mailto: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

Re: [mailop] Authentication Bounces by Gmail

[Atro Tossavainen via mailop]

> 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.

That's not how forwarding works, Brandon.

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, https://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop