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 AR
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
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 G
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.
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-o
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
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
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
Va
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
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
> positi
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 metho
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 Goo
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
> 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
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 th
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/answe
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
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 firs
18 matches
Mail list logo
