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

[Opti Pub via mailop]

Oh sry just saw Emanuel’s response.

On Wed, Feb 28, 2024 at 7:37 AM Opti Pub  wrote:

> I agree on a longer TTL in general if you’re not doing maint but a short
> TTL shouldn’t cause failures by itself… unless you’re maxing a limit on
> lookups or something?
>
> Looks like it’s on cloudflare who claims not to cap/cut off lookups but
> maybe you have some reporting on that end you could check out/confirm
> lookup errors idk. You’d think your DNS monitoring would catch it though.
>
>
> On Wed, Feb 28, 2024 at 2:59 AM Kai Bojens via mailop 
> wrote:
>
>> Am 27.02.24 um 23:30 schrieb Rob Nagler via mailop:
>>
>> > $ dig +short txt nagler.me 
>> > "v=spf1 a mx ip4:139.177.203.52 include:_spf.google.com
>> >  -all"
>>
>> A TTL of just 300 seconds is way too short IMHO. If anything happens to
>> your DNS you just have five minutes to fix the problem. Set the TTL to
>> at least 3600 seconds.
>>
>> ___
>> 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] Gmail.com SPF false negatives?

[Opti Pub via mailop]

I agree on a longer TTL in general if you’re not doing maint but a short
TTL shouldn’t cause failures by itself… unless you’re maxing a limit on
lookups or something?

Looks like it’s on cloudflare who claims not to cap/cut off lookups but
maybe you have some reporting on that end you could check out/confirm
lookup errors idk. You’d think your DNS monitoring would catch it though.


On Wed, Feb 28, 2024 at 2:59 AM Kai Bojens via mailop 
wrote:

> Am 27.02.24 um 23:30 schrieb Rob Nagler via mailop:
>
> > $ dig +short txt nagler.me 
> > "v=spf1 a mx ip4:139.177.203.52 include:_spf.google.com
> >  -all"
>
> A TTL of just 300 seconds is way too short IMHO. If anything happens to
> your DNS you just have five minutes to fix the problem. Set the TTL to
> at least 3600 seconds.
>
> ___
> 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] Gmail.com SPF false negatives?

[Opti Pub via mailop]

Oh sry after rereading yeah looks like you’re impacted by gmail guidelines
(dmarc required)



On Tue, Feb 27, 2024 at 6:04 PM Opti Pub  wrote:

> I’m seeing some (inaccurate) 0% logging on the 26th across some domains.
> I’ve also seen a bunch of others reporting the same so that maybe what
> you’re experiencing.
>
>
>
> On Tue, Feb 27, 2024 at 6:02 PM L. Mark Stone via mailop <
> mailop@mailop.org> wrote:
>
>> I believe you need a DMARC record...
>>
>> Regards,
>> Mark
>> _
>> L. Mark Stone, Founder
>> North America's Leading Zimbra VAR/BSP/Training Partner
>> For Companies With Mission-Critical Email Needs
>>
>> - Original Message -
>> From: "Rob Nagler via mailop" 
>> To: "mailop" 
>> Sent: Tuesday, February 27, 2024 5:30:03 PM
>> Subject: [mailop] Gmail.com SPF false negatives?
>>
>> [ http://gmail.com/ | gmail.com ] started failing messages from domains
>> which are correctly setup for SPF (and have been for some years):
>>
>> 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 [ [ http://nagler.me/ |
>> nagler.me ] ] with ip:
>> [139.177.203.52] = did not pass 550-5.7.26 550-5.7.26
>>
>> $ dig +short txt [ http://nagler.me/ | nagler.me ]
>> "v=spf1 a mx ip4:139.177.203.52 include:_ [ http://spf.google.com/ |
>> spf.google.com ] -all"
>>
>> Sending to (paid) Google Workspace domains works fine. Nothing has
>> changed on our end, and failures only started this morning.
>>
>> Any ideas?
>>
>> Thanks,
>> Rob
>>
>>
>> ___
>> 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] Gmail.com SPF false negatives?

[Opti Pub via mailop]

I’m seeing some (inaccurate) 0% logging on the 26th across some domains.
I’ve also seen a bunch of others reporting the same so that maybe what
you’re experiencing.



On Tue, Feb 27, 2024 at 6:02 PM L. Mark Stone via mailop 
wrote:

> I believe you need a DMARC record...
>
> Regards,
> Mark
> _
> L. Mark Stone, Founder
> North America's Leading Zimbra VAR/BSP/Training Partner
> For Companies With Mission-Critical Email Needs
>
> - Original Message -
> From: "Rob Nagler via mailop" 
> To: "mailop" 
> Sent: Tuesday, February 27, 2024 5:30:03 PM
> Subject: [mailop] Gmail.com SPF false negatives?
>
> [ http://gmail.com/ | gmail.com ] started failing messages from domains
> which are correctly setup for SPF (and have been for some years):
>
> 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 [ [ http://nagler.me/ |
> nagler.me ] ] with ip:
> [139.177.203.52] = did not pass 550-5.7.26 550-5.7.26
>
> $ dig +short txt [ http://nagler.me/ | nagler.me ]
> "v=spf1 a mx ip4:139.177.203.52 include:_ [ http://spf.google.com/ |
> spf.google.com ] -all"
>
> Sending to (paid) Google Workspace domains works fine. Nothing has changed
> on our end, and failures only started this morning.
>
> Any ideas?
>
> Thanks,
> Rob
>
>
> ___
> 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] [E] Contact Google Postmaster

[Opti Pub via mailop]

> The Google Postmaster tool is a joke for me.  Apparently you have to have
10's of millions of messages coming from the server for Google Postmaster
to report anything.

You don’t have to have that much volume for data… this behavior is typical
of GMT if your domain rep is very low (IE bad/dark red) — they will stop
giving you any data at all, bc spammers with data are better spammers :)

If GMT isn’t giving you data that’s a pretty bad sign tbh. And if I had to
guess you prob have list hygiene issues or acquisition issues.

I’d follow Als advice AFTER you are sure you have everything in line. But
be nice ;)

GL



On Fri, Jan 26, 2024 at 3:51 PM John Levine via mailop 
wrote:

> It appears that Scott Mutter via mailop  said:
> >But as it stands now, it's only when our users notify us that their
> >messages are being sent to their Gmail spambox do I realize there's an
> >issue.  There's no rejection or anything from Google's acceptance of the
> >message to indicate that there is any problem.
>
> That's not a bug, you know.
>
> >You have to try to see this from my perspective.  How am I suppose to know
> >that Google is treating messages from this IP poorly?
>
> Why do think it has anything to do with your IP?  Do you send mail from
> other IPs with the same DKIM and SPF domain?
>
> AS people have been hinting, the reason your mail is going into the
> spam folder is most likely that the recipients have been marking it as
> spam or otherwise treating it as mail they don't want. Google's mail
> sorting depends mostly on their own internal data.
>
> R's,
> John
> ___
> 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] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Opti Pub via mailop]

+1

On Wed, Jan 10, 2024 at 6:14 PM Louis Laureys via mailop 
wrote:

> We decided to keep this because I read that some webmail clients are
> planning to support BIMI without checking for certificates, or,
> perhaps, also displaying a little lock icon in the corner of the
> sender's BIMI-style logo image where certification is verified.
>
> This is exactly what I have in mind for my client, thanks for publishing
> your logo in an easily accessible and standard way :)
>
> Groetjes,
> Louis
>
>
> Op woensdag 10 januari 2024 om 21:58, schreef Randolf Richardson,
> Postmaster via mailop :
>
> We looked into it and publish our own default BIMI record even
> though we didn't pay the enormous amount money required to one of two
> Certificate Authorities.
>
> If anyone is curious to see what the record looks, use this command:
>
> dig txt default._bimi.inter-corporate.com
>
> The results should include:
>
> ;; ANSWER SECTION:
> default._bimi.inter-corporate.com. 3600 IN TXT
> "v=BIMI1; l=https://www.inter-corporate.com/images/logo60bimi-iccns.svg;
> a=;"
>
> It basically just links to an SVG version of the logo from our main
> web site (which is also in the same DNS zone).
>
> Note: The "a=" portion normally includes a URI to what's called the
> "VMC/Assertion record" in the form of a typical .pem file. Ours is
> blank because we don't have the needed file for this.
>
> We decided to keep this because I read that some webmail clients are
> planning to support BIMI without checking for certificates, or,
> perhaps, also displaying a little lock icon in the corner of the
> sender's BIMI-style logo image where certification is verified.
>
> The BIMI Group provides an online checking tool that displays our
> logo (just search for "inter-corporate.com" to see ours):
>
> BIMI LookUp & Generator :: Check compliance w/ BIMI standards
> https://www.bimigroup.org/bimi-generator/
>
> Our logo is shown near the end of the report, and for ours there's
> an indication that we comply, but there's also this warning:
>
> "Note: While your BIMI record is compliant, it doesn't include a
> Verified Mark Certificate that may be required by some mailbox
> providers."
>
> What's missing from BIMI in its current form? The option for mail
> server oparators to use the same TLS certificates that we're already
> using for our mail servers (and web servers, and FTP servers, etc.).
>
> It makes less sense to me to involve a different CA just for one
> tiny little image because then that's more technology that has to be
> administered, managed, troubleshooted, implemented, etc., and paid
> for separately. For eMail systems that host mlutiple domains and
> clients, BIMI is not an attractive option in its current state.
>
> If BIMI is to be taken as an open standard, then it needs to embrace
> openness so that the TLS certificates issued by all CAs (including
> commercial and free CAs {e.g., Let's Encrypt}) can contribute to BIMI
> gaining wider adoption.
>
> The "must be a Registered Trademark" requirement is too expensive
> for a lot of small businesses. A copyrighted logo is already
> sufficient to provide legal protections in many scenarios (depending
> on jurisdiction, etc.), so the bar is too high as it is -- DMCA
> violation notices should be taken seriously regardless of whether the
> intellectual property (such as an organization's logo) is protected
> under copyright, servicemark, or trademark property mechanisms.
>
> Another problem with limiting the scope of intellectual property
> protection to a Registered Trademark is that trademark applications
> can also be rejected even though a logo is already copyrighted, and
> the reasons can vary based on a variety of factors, including
> different jurisdictional regulations, local and/or national laws that
> limit free expression, cultural sensitivity policies, delays due to
> fraudulent disputes submitted by intellectual property trolls, etc.
>
> Also: How does BIMI intend to resolve valid Registered Trademarks
> from two different countires that look almost the same? Is there a
> mechanism that will only allow BIMI logos to be displayed in cerrtain
> countries where said Registered Trademark is protected? Will there
> be enforcement to make sure all vendors adhere to implementing BIMI
> correctly in this manner? Or, if a Registered Trademark is only
> registered in one country, will vendors still be able to display it
> in other countries? Or will the source be the determining factor (in
> which case, what reliable solution does BIMI propose for a company
> using service provider in some other country to deliver their eMail)?
>
> Keeping things simpler, open, and lowering the bar to be more
> inclusive are, in my opinion, some of the more important factors in
> BIMI's future success. Otherwise, it just looks like an attempt to
> make money (which is how at least some people who've looked into it
> seem to perceive it at present).
>
> (If BIMI doesn't lower the bar, then perhaps someone 

Re: [mailop] DMARC processing

[Opti Pub via mailop]

https://github.com/domainaware/parsedmarc


On Tue, Dec 19, 2023 at 9:50 AM Scott Mutter via mailop 
wrote:

> If DMARC reports could be sent in JSON format, they would be more easily
> parseable.
>
> At least, that's my opinion.
>
> On Tue, Dec 19, 2023 at 2:47 AM Eduardo Diaz Comellas via mailop <
> mailop@mailop.org> wrote:
>
>> Hi,
>>
>> I'm starting to deploy DMARC records in all our managed domains, but we
>> don't have any specific tool to parse and extract meaningful information
>> from the reports.
>>
>> Do you have any recomendations?
>>
>> Best regards
>>
>> --
>> Eduardo Díaz Comellas
>> Ultreia Comunicaciones, S.L.
>>
>> ___
>> 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] 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] New Validity policy for paid FBL (ARF)

[Opti Pub via mailop]

I do agree with your thoughts. A good platform gives the users the control
to do what they want with FBLs via automation (doesn’t force to unsub
 globally but yes some senders prefer do that).

I think the point though, is whether or not Validity having control over
(or any single entity) is good for the recipient or not.

And also, do inbox providers plan to make any changes in response.




On Mon, Sep 11, 2023 at 3:54 PM Opti Pub  wrote:

> I should clarify I meant it’s irrelevant as far as the topic of the thread
> is concerned (what peoples thoughts are on this new pay to play situation
> with FBL).
>
> I’m curious what others thoughts are on that specific subject (the thread
> topic).
>
>
> On Mon, Sep 11, 2023 at 3:12 PM Scott Mutter via mailop 
> wrote:
>
>> How an FBL is supposed to be used versus how an FBL is used is always a
>> topic for discussion that can be applied to anything.
>>
>> How many of us expect email to be delivered instantly?  But where is it
>> defined that email has to be delivered the second the sender clicks that
>> send button?  But we all get up in arms when that email doesn't arrive in 2
>> minutes.
>>
>> My take on users abusing the "this is spam" button is, if they click the
>> button then they don't want to receive mail from that sender ever again.
>> If 10 years later they wonder why they're not receiving mail from that
>> sender, then maybe they should have rethought clicking that "this is spam"
>> button from that sender.
>>
>> If the recipient server wants to send messages from our server into their
>> users spam folders and report those as spam via the FBL, then obviously
>> that provider doesn't want to receive mail from our server.  If the
>> intended recipient of that message doesn't like it, then talk to the
>> recipient server administrator that's sending the messages into your spam
>> folder and sending it back along the FBL and ask them why they're doing
>> that.  Maybe it's time to consider a different provider?
>>
>> Is all of that the intended function of the FBL?  Probably not.  But
>> there's got to be some end-user education.  End users are going to have to
>> realize that clicking the "this is spam" on a message from a recipient that
>> you clearly at one time wanted to receive messages from, doing that is
>> going to have consequences.
>>
>> On Mon, Sep 11, 2023 at 11:58 AM Support 3Hound via mailop <
>> mailop@mailop.org> wrote:
>>
>>> I agree with you Neil,
>>> let me specify it better even if it's a bit off topic.
>>> The FBL SHOULD NOT be used like that but this is how users act based on
>>> the feedback we collected from end users when we tried to understand why we
>>> was receiving so much FBL on double-optin collected lists and transactional
>>> e-mail.
>>> There is also a worst case: users sometime select the whole list of
>>> weekly e-mail received in years and click "junk" in order to achieve a
>>> "delete all + unsubscribe", often they do it when their mailbox get full
>>> it's a fast cleanup.
>>> So, TRUE! It's not the way it should be used but it's what the end users
>>> is experiencing and expecting.
>>>
>>> Coming back in topic:
>>> Not paying to get ARF FBL (so not unsubscribing anymore FBL) will be
>>> seen as a bad practice?
>>> Maybe this is the final act for the FBL service that is just mis-used
>>> and so no-more useful also for gathering reputation data...
>>>
>>>
>>>
>>>
>>>
>>> Il 11/09/2023 14:05, Neil Jenkins via mailop ha scritto:
>>>
>>> That's a … different perspective on this behaviour. Treating an FBL
>>> report as "unsubscribe" (or rather *proscribe* at the ESP level) is
>>> terrible for user experience and not at all what the feedback loop should
>>> be used for IMO. Users click Report Spam by mistake one time (this happens 
>>> *a
>>> lot)* and suddenly they don't get emails they want. Even worse, as the
>>> proscription is often at the ESP-level, the original sender ban be unaware
>>> of the block and thinks they are still sending correctly. These are a
>>> nightmare for our customer support team to deal with — the sender's support
>>> are saying they are sending the message, our support are telling the
>>> customer there's no logs of it ever reaching our servers. The customer is
>>> stuck in the middle
>>>
>>>
>>> ___
>>> 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] New Validity policy for paid FBL (ARF)

[Opti Pub via mailop]

I should clarify I meant it’s irrelevant as far as the topic of the thread
is concerned (what peoples thoughts are on this new pay to play situation
with FBL).

I’m curious what others thoughts are on that specific subject (the thread
topic).


On Mon, Sep 11, 2023 at 3:12 PM Scott Mutter via mailop 
wrote:

> How an FBL is supposed to be used versus how an FBL is used is always a
> topic for discussion that can be applied to anything.
>
> How many of us expect email to be delivered instantly?  But where is it
> defined that email has to be delivered the second the sender clicks that
> send button?  But we all get up in arms when that email doesn't arrive in 2
> minutes.
>
> My take on users abusing the "this is spam" button is, if they click the
> button then they don't want to receive mail from that sender ever again.
> If 10 years later they wonder why they're not receiving mail from that
> sender, then maybe they should have rethought clicking that "this is spam"
> button from that sender.
>
> If the recipient server wants to send messages from our server into their
> users spam folders and report those as spam via the FBL, then obviously
> that provider doesn't want to receive mail from our server.  If the
> intended recipient of that message doesn't like it, then talk to the
> recipient server administrator that's sending the messages into your spam
> folder and sending it back along the FBL and ask them why they're doing
> that.  Maybe it's time to consider a different provider?
>
> Is all of that the intended function of the FBL?  Probably not.  But
> there's got to be some end-user education.  End users are going to have to
> realize that clicking the "this is spam" on a message from a recipient that
> you clearly at one time wanted to receive messages from, doing that is
> going to have consequences.
>
> On Mon, Sep 11, 2023 at 11:58 AM Support 3Hound via mailop <
> mailop@mailop.org> wrote:
>
>> I agree with you Neil,
>> let me specify it better even if it's a bit off topic.
>> The FBL SHOULD NOT be used like that but this is how users act based on
>> the feedback we collected from end users when we tried to understand why we
>> was receiving so much FBL on double-optin collected lists and transactional
>> e-mail.
>> There is also a worst case: users sometime select the whole list of
>> weekly e-mail received in years and click "junk" in order to achieve a
>> "delete all + unsubscribe", often they do it when their mailbox get full
>> it's a fast cleanup.
>> So, TRUE! It's not the way it should be used but it's what the end users
>> is experiencing and expecting.
>>
>> Coming back in topic:
>> Not paying to get ARF FBL (so not unsubscribing anymore FBL) will be seen
>> as a bad practice?
>> Maybe this is the final act for the FBL service that is just mis-used and
>> so no-more useful also for gathering reputation data...
>>
>>
>>
>>
>>
>> Il 11/09/2023 14:05, Neil Jenkins via mailop ha scritto:
>>
>> That's a … different perspective on this behaviour. Treating an FBL
>> report as "unsubscribe" (or rather *proscribe* at the ESP level) is
>> terrible for user experience and not at all what the feedback loop should
>> be used for IMO. Users click Report Spam by mistake one time (this happens *a
>> lot)* and suddenly they don't get emails they want. Even worse, as the
>> proscription is often at the ESP-level, the original sender ban be unaware
>> of the block and thinks they are still sending correctly. These are a
>> nightmare for our customer support team to deal with — the sender's support
>> are saying they are sending the message, our support are telling the
>> customer there's no logs of it ever reaching our servers. The customer is
>> stuck in the middle
>>
>>
>> ___
>> 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] New Validity policy for paid FBL (ARF)

[Opti Pub via mailop]

I'll chime in.

For me the thing that doesn't sit well for me is that the inbox
providers have adopted the universal fbl and force you to use that (at
least from the available info on their postmaster sites) rather than
being able to set up directly with them like you used to be able to.

Whether FBLs are being used as originally intended or not is probably
irrelevant.

I can't tell that to my customers who want to see the FBL data (and
act on it however they want).

To be fair the inbox providers all adopted the universal fbl knowing
it was free and available to everybody at the time... So I guess the
question I have is, do inbox providers (ex Comcast) plan to update
their FBL/postmaster sites allowing direct FBL set-up again now that
the universal fbl is a paid service?

I think it's a fair statement that the responsibility of ensuring
senders have open-access to ARF reports should fall on the inbox
providers.

Or will a lack of action from inbox providers signal that FBLs are a
dying breed?

Obviously we'll be paying up -- but I do agree it doesn't feel right
only having one option!

I'm also curious what others think.







On Mon, Sep 11, 2023 at 1:01 PM Support 3Hound via mailop
 wrote:
>
> I agree with you Neil,
> let me specify it better even if it's a bit off topic.
> The FBL SHOULD NOT be used like that but this is how users act based on the 
> feedback we collected from end users when we tried to understand why we was 
> receiving so much FBL on double-optin collected lists and transactional 
> e-mail.
> There is also a worst case: users sometime select the whole list of weekly 
> e-mail received in years and click "junk" in order to achieve a "delete all + 
> unsubscribe", often they do it when their mailbox get full it's a fast 
> cleanup.
> So, TRUE! It's not the way it should be used but it's what the end users is 
> experiencing and expecting.
>
> Coming back in topic:
> Not paying to get ARF FBL (so not unsubscribing anymore FBL) will be seen as 
> a bad practice?
> Maybe this is the final act for the FBL service that is just mis-used and so 
> no-more useful also for gathering reputation data...
>
>
>
>
>
> Il 11/09/2023 14:05, Neil Jenkins via mailop ha scritto:
>
> That's a … different perspective on this behaviour. Treating an FBL report as 
> "unsubscribe" (or rather proscribe at the ESP level) is terrible for user 
> experience and not at all what the feedback loop should be used for IMO. 
> Users click Report Spam by mistake one time (this happens a lot) and suddenly 
> they don't get emails they want. Even worse, as the proscription is often at 
> the ESP-level, the original sender ban be unaware of the block and thinks 
> they are still sending correctly. These are a nightmare for our customer 
> support team to deal with — the sender's support are saying they are sending 
> the message, our support are telling the customer there's no logs of it ever 
> reaching our servers. The customer is stuck in the middle
>
>
> ___
> 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] Yahoo placement feeds?

[Opti Pub via mailop]

Hi all,

I've been having a really hard time getting any information on whether
or not gaining access to the  yahoo performance feeds they claim to
offer.

Is anybody from Yahoo on here that can help, or does anybody have any
advice on how to get access?

https://senders.yahooinc.com/email-deliverability-performance-feeds/

Anybody have any information on this? We'd love to get access so we
can provide better insight to our users.

Thanks in advance!

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

[mailop] Microsoft's ticket system 403

[Opti Pub via mailop]

I have a block I'm trying to resolve but I'm getting a 403 when trying
to submit a ticket for a couple days now.

https://olcsupport.office.com/

I also haven't gotten any replies from del...@messaging.microsoft.com either.

Can anybody else confirm this? Any contacts on here that can help me out?

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