Re: [mailop] Best practices for Google Postmaster Tools?

[Paul Kincaid-Smith]

David,

> So that's potentially a huge amount of valuable data I gain if I set up every 
> customer individually. Pitfalls would be if I run into a cap on the number of 
> domains I can add (then we'd likely only want to track our highest volume 
> senders), if a certain volume of web scraping gets us into trouble with Google
> 

That's certainly worth exploring, then. 

If you do set up your systems the way you’ve described, be aware that GPT has 
email volume thresholds which will limit their reporting to only those 
customers of yours that send “enough” mail. For practical reasons, they won’t 
track and report on all senders. 

Paul Kincaid-Smith
EmailGrades

> On Feb 8, 2018, at 23:19, David Carriger  
> wrote:
> 
> We are using a unique customer identifier as one of the fields in the 
> Feedback-ID header, and that's provided some useful data. What I've noticed 
> with Cloudmark, though, is that sometimes they'll fingerprint a customer 
> based on one of the customer identifiers we put in our headers (X-Inf-App). 
> If I notice in my mail logs that Cloudmark considers all of a customer's mail 
> to be spam, obviously there's a problem worth investigating.
> 
> GPT can tell you a similar story with domain reputation, delivery errors and 
> the feedback loop. Their documents indicate that a domain reputation of "Bad" 
> is being rejected at the SMTP layer or filtered to the spam folder almost all 
> of the time. So if every customer has a unique DKIM identifier, then their 
> domain reputation can be tracked separately, so we can make guesses as to 
> inbox placement at Gmail (60% of our average customer's list) at a 
> per-customer level. Similarly, there's a lot more granularity to the delivery 
> error/feedback loop reporting if I do it that way. For example, GPT on our 
> base domain for 2/7 shows a single customer with a spam rate of 0.3%. 
> However, if I drill down into a customer that I set up a separate DKIM 
> subdomain for (not the one reported as having a 0.3% spam rate on the base 
> domain's FBL report), I can see that on 2/7 they had a spam rate of 6.3% when 
> sending to their unengaged recipients on that day.
> 
> So that's potentially a huge amount of valuable data I gain if I set up every 
> customer individually. Pitfalls would be if I run into a cap on the number of 
> domains I can add (then we'd likely only want to track our highest volume 
> senders), if a certain volume of web scraping gets us into trouble with 
> Google, and any deliverability issues we uncover if we suddenly give Google 
> the ability to track every customer's mailing behavior individually with 
> perfect accuracy.
> 
> From: Paul Kincaid-Smith 
> Sent: Thursday, February 8, 2018 10:55:28 PM
> To: David Carriger
> Cc: mailop@mailop.org
> Subject: Re: [mailop] Best practices for Google Postmaster Tools?
>  
> David,
> 
>> the question in my mind is whether it would be worth using a unique DKIM 
>> identifier for every single customer of ours to track all of their 
>> reputation separately
>> 
> 
> Alternatively, are you using a unique customer identifier as one of the 
> fields of Infusionsoft’s Feedback-ID header? Would that give you the level of 
> visibility you need?
> 
> Paul Kincaid-Smith
> EmailGrades
> 
> On Feb 8, 2018, at 22:13, Paul Kincaid-Smith  wrote:
> 
>> David,
>> 
>> I had a conversation with the product manager responsible for Google 
>> Postmaster Tools some time ago, and he said that they had deliberately 
>> chosen a URL structure for GPT’s UI to make it easier for us to construct a 
>> scraper. He encouraged scraping as an alternative to the long-hoped-for API. 
>> Good luck with your project. Let us know how it progresses. 
>> 
>> Paul Kincaid-Smith
>> EmailGrades
>> 
>> On Feb 8, 2018, at 21:47, David Carriger  
>> wrote:
>> 
>>> Thanks for the tips. We're currently doing double DKIM right now, the 
>>> question in my mind is whether it would be worth using a unique DKIM 
>>> identifier for every single customer of ours to track all of their 
>>> reputation separately, and I wasn't sure whether GPT scales to thousands of 
>>> domains in a single account or if they cut you off at some arbitrary number 
>>> like, say, 500.
>>> 
>>> I will be at M3AAWG this year and was definitely planning on attending the 
>>> GPT discussions. Just wanted to make sure our GPT account wasn't going to 
>>> be shutdown if I started scraping the data off of it.
>>> 
>>> From: Benjamin BILLON 
>>> Sent: Thursday, February 8, 2018 9:43:16 PM
>>> To: Ryan Harris; mailop@mailop.org
>>> Cc: David Carriger
>>> Subject: RE: [mailop] Best practices for Google Postmaster Tools?
>>>  
>>> Hey Ryan,
>>>  
>>> I recall that when the errors happened at the end of last year 
>>> (https://www.mail-archive.com/mailop@mailop.org/msg05260.html) I thought to 
>>> myself how the heck of a job that would be to clean the mess for people who 
>>> are scrapping the data.
>>> That, and the not-so-huge need of doing it decreased the p

Re: [mailop] Best practices for Google Postmaster Tools?

[David Carriger]

We are using a unique customer identifier as one of the fields in the 
Feedback-ID header, and that's provided some useful data. What I've noticed 
with Cloudmark, though, is that sometimes they'll fingerprint a customer based 
on one of the customer identifiers we put in our headers (X-Inf-App). If I 
notice in my mail logs that Cloudmark considers all of a customer's mail to be 
spam, obviously there's a problem worth investigating.

GPT can tell you a similar story with domain reputation, delivery errors and 
the feedback loop. Their documents indicate that a domain reputation of "Bad" 
is being rejected at the SMTP layer or filtered to the spam folder almost all 
of the time. So if every customer has a unique DKIM identifier, then their 
domain reputation can be tracked separately, so we can make guesses as to inbox 
placement at Gmail (60% of our average customer's list) at a per-customer 
level. Similarly, there's a lot more granularity to the delivery error/feedback 
loop reporting if I do it that way. For example, GPT on our base domain for 2/7 
shows a single customer with a spam rate of 0.3%. However, if I drill down into 
a customer that I set up a separate DKIM subdomain for (not the one reported as 
having a 0.3% spam rate on the base domain's FBL report), I can see that on 2/7 
they had a spam rate of 6.3% when sending to their unengaged recipients on that 
day.

So that's potentially a huge amount of valuable data I gain if I set up every 
customer individually. Pitfalls would be if I run into a cap on the number of 
domains I can add (then we'd likely only want to track our highest volume 
senders), if a certain volume of web scraping gets us into trouble with Google, 
and any deliverability issues we uncover if we suddenly give Google the ability 
to track every customer's mailing behavior individually with perfect accuracy.


From: Paul Kincaid-Smith 
Sent: Thursday, February 8, 2018 10:55:28 PM
To: David Carriger
Cc: mailop@mailop.org
Subject: Re: [mailop] Best practices for Google Postmaster Tools?

David,


the question in my mind is whether it would be worth using a unique DKIM 
identifier for every single customer of ours to track all of their reputation 
separately

Alternatively, are you using a unique customer identifier as one of the fields 
of Infusionsoft’s Feedback-ID header? Would that give you the level of 
visibility you need?

Paul Kincaid-Smith
EmailGrades

On Feb 8, 2018, at 22:13, Paul Kincaid-Smith 
mailto:p...@emailgrades.com>> wrote:

David,

I had a conversation with the product manager responsible for Google Postmaster 
Tools some time ago, and he said that they had deliberately chosen a URL 
structure for GPT’s UI to make it easier for us to construct a scraper. He 
encouraged scraping as an alternative to the long-hoped-for API. Good luck with 
your project. Let us know how it progresses.

Paul Kincaid-Smith
EmailGrades

On Feb 8, 2018, at 21:47, David Carriger 
mailto:david.carri...@infusionsoft.com>> wrote:


Thanks for the tips. We're currently doing double DKIM right now, the question 
in my mind is whether it would be worth using a unique DKIM identifier for 
every single customer of ours to track all of their reputation separately, and 
I wasn't sure whether GPT scales to thousands of domains in a single account or 
if they cut you off at some arbitrary number like, say, 500.

I will be at M3AAWG this year and was definitely planning on attending the GPT 
discussions. Just wanted to make sure our GPT account wasn't going to be 
shutdown if I started scraping the data off of it.


From: Benjamin BILLON mailto:bbil...@splio.com>>
Sent: Thursday, February 8, 2018 9:43:16 PM
To: Ryan Harris; mailop@mailop.org
Cc: David Carriger
Subject: RE: [mailop] Best practices for Google Postmaster Tools?

Hey Ryan,

I recall that when the errors happened at the end of last year 
(https://www.mail-archive.com/mailop@mailop.org/msg05260.html) I thought to 
myself how the heck of a job that would be to clean the mess for people who are 
scrapping the data.
That, and the not-so-huge need of doing it decreased the priority (and 
increased the innocent hope of the API) on my side.

--
Benjamin


De : Ryan Harris [mailto:r...@sendgrid.com]
Envoyé : vendredi 9 février 2018 12:12
À : Benjamin BILLON mailto:bbil...@splio.com>>
Cc : David Carriger 
mailto:david.carri...@infusionsoft.com>>; 
mailop@mailop.org
Objet : Re: [mailop] Best practices for Google Postmaster Tools?

Hello,

> 1) Is there an upper limit on how many authenticated domains can be added for 
> tracking?

I have 160+ domains and didn't hit a limit so far
Consider also applying dual dkim. It can be helpful to see all of your IPs 
reputation under a single, or handful of domains.


> 2) Does anyone know if an API is planned/in the works for GPT?

Yes

https://wordtothewise.com/2017/10/tell-us-use-gmail-p

Re: [mailop] Best practices for Google Postmaster Tools?

[Paul Kincaid-Smith]

David,

> the question in my mind is whether it would be worth using a unique DKIM 
> identifier for every single customer of ours to track all of their reputation 
> separately
> 

Alternatively, are you using a unique customer identifier as one of the fields 
of Infusionsoft’s Feedback-ID header? Would that give you the level of 
visibility you need?

Paul Kincaid-Smith
EmailGrades

> On Feb 8, 2018, at 22:13, Paul Kincaid-Smith  wrote:
> 
> David,
> 
> I had a conversation with the product manager responsible for Google 
> Postmaster Tools some time ago, and he said that they had deliberately chosen 
> a URL structure for GPT’s UI to make it easier for us to construct a scraper. 
> He encouraged scraping as an alternative to the long-hoped-for API. Good luck 
> with your project. Let us know how it progresses. 
> 
> Paul Kincaid-Smith
> EmailGrades
> 
>> On Feb 8, 2018, at 21:47, David Carriger  
>> wrote:
>> 
>> Thanks for the tips. We're currently doing double DKIM right now, the 
>> question in my mind is whether it would be worth using a unique DKIM 
>> identifier for every single customer of ours to track all of their 
>> reputation separately, and I wasn't sure whether GPT scales to thousands of 
>> domains in a single account or if they cut you off at some arbitrary number 
>> like, say, 500.
>> 
>> I will be at M3AAWG this year and was definitely planning on attending the 
>> GPT discussions. Just wanted to make sure our GPT account wasn't going to be 
>> shutdown if I started scraping the data off of it.
>> 
>> From: Benjamin BILLON 
>> Sent: Thursday, February 8, 2018 9:43:16 PM
>> To: Ryan Harris; mailop@mailop.org
>> Cc: David Carriger
>> Subject: RE: [mailop] Best practices for Google Postmaster Tools?
>>  
>> Hey Ryan,
>>  
>> I recall that when the errors happened at the end of last year 
>> (https://www.mail-archive.com/mailop@mailop.org/msg05260.html) I thought to 
>> myself how the heck of a job that would be to clean the mess for people who 
>> are scrapping the data.
>> That, and the not-so-huge need of doing it decreased the priority (and 
>> increased the innocent hope of the API) on my side.
>>  
>> --
>> Benjamin
>>  
>>  
>> De : Ryan Harris [mailto:r...@sendgrid.com] 
>> Envoyé : vendredi 9 février 2018 12:12
>> À : Benjamin BILLON 
>> Cc : David Carriger ; mailop@mailop.org
>> Objet : Re: [mailop] Best practices for Google Postmaster Tools?
>>  
>> Hello, 
>> > 1) Is there an upper limit on how many authenticated domains can be added 
>> > for tracking?
>> 
>> I have 160+ domains and didn't hit a limit so far
>> 
>> Consider also applying dual dkim. It can be helpful to see all of your IPs 
>> reputation under a single, or handful of domains. 
>>  
>> > 2) Does anyone know if an API is planned/in the works for GPT?
>> 
>> Yes
>> 
>> https://wordtothewise.com/2017/10/tell-us-use-gmail-postmaster-tools/
>> 
>> https://wordtothewise.com/2017/10/google-postmaster-tools-last-chance/
>> 
>> https://wordtothewise.com/2017/11/gmail-survey-rough-analysis/
>> 
>> no ETA, we tried to make some noise to raise priority, and hope to get some 
>> news in the coming weeks, but no guarantee
>> 
>> Every year it sounds like an API is "just around the quarter." At this point 
>> I think it's a story in a backlog that wont see the light of day for a long 
>> time. 
>> 3) Given the current lack of an API, does Google frown on scraping data from 
>> GPT?
>> 
>> Some big ESPs do it. They still seem alive today.
>> 
>> > We'd like to make more use of it, but the support around it is sparse 
>> > right now, and the information I've been able to find on how other ESPs 
>> > are implementing the data is also quite limited.
>> 
>> You might want to consider joining M3AAWG
>> 
>> Scraping is doable and allowed (I assume so long as you don't hammer away at 
>> their site), but it's scraping and can be painful at times. How senders  are 
>> using postmaster.google.com data is a discussion that frequently happens at 
>> MAAWG.
>>  
>>  
>> Ryan
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Best practices for Google Postmaster Tools?

[Paul Kincaid-Smith]

David,

I had a conversation with the product manager responsible for Google Postmaster 
Tools some time ago, and he said that they had deliberately chosen a URL 
structure for GPT’s UI to make it easier for us to construct a scraper. He 
encouraged scraping as an alternative to the long-hoped-for API. Good luck with 
your project. Let us know how it progresses. 

Paul Kincaid-Smith
EmailGrades

> On Feb 8, 2018, at 21:47, David Carriger  
> wrote:
> 
> Thanks for the tips. We're currently doing double DKIM right now, the 
> question in my mind is whether it would be worth using a unique DKIM 
> identifier for every single customer of ours to track all of their reputation 
> separately, and I wasn't sure whether GPT scales to thousands of domains in a 
> single account or if they cut you off at some arbitrary number like, say, 500.
> 
> I will be at M3AAWG this year and was definitely planning on attending the 
> GPT discussions. Just wanted to make sure our GPT account wasn't going to be 
> shutdown if I started scraping the data off of it.
> 
> From: Benjamin BILLON 
> Sent: Thursday, February 8, 2018 9:43:16 PM
> To: Ryan Harris; mailop@mailop.org
> Cc: David Carriger
> Subject: RE: [mailop] Best practices for Google Postmaster Tools?
>  
> Hey Ryan,
>  
> I recall that when the errors happened at the end of last year 
> (https://www.mail-archive.com/mailop@mailop.org/msg05260.html) I thought to 
> myself how the heck of a job that would be to clean the mess for people who 
> are scrapping the data.
> That, and the not-so-huge need of doing it decreased the priority (and 
> increased the innocent hope of the API) on my side.
>  
> --
> Benjamin
>  
>  
> De : Ryan Harris [mailto:r...@sendgrid.com] 
> Envoyé : vendredi 9 février 2018 12:12
> À : Benjamin BILLON 
> Cc : David Carriger ; mailop@mailop.org
> Objet : Re: [mailop] Best practices for Google Postmaster Tools?
>  
> Hello, 
> > 1) Is there an upper limit on how many authenticated domains can be added 
> > for tracking?
> 
> I have 160+ domains and didn't hit a limit so far
> 
> Consider also applying dual dkim. It can be helpful to see all of your IPs 
> reputation under a single, or handful of domains. 
>  
> > 2) Does anyone know if an API is planned/in the works for GPT?
> 
> Yes
> 
> https://wordtothewise.com/2017/10/tell-us-use-gmail-postmaster-tools/
> 
> https://wordtothewise.com/2017/10/google-postmaster-tools-last-chance/
> 
> https://wordtothewise.com/2017/11/gmail-survey-rough-analysis/
> 
> no ETA, we tried to make some noise to raise priority, and hope to get some 
> news in the coming weeks, but no guarantee
> 
> Every year it sounds like an API is "just around the quarter." At this point 
> I think it's a story in a backlog that wont see the light of day for a long 
> time. 
> 3) Given the current lack of an API, does Google frown on scraping data from 
> GPT?
> 
> Some big ESPs do it. They still seem alive today.
> 
> > We'd like to make more use of it, but the support around it is sparse right 
> > now, and the information I've been able to find on how other ESPs are 
> > implementing the data is also quite limited.
> 
> You might want to consider joining M3AAWG
> 
> Scraping is doable and allowed (I assume so long as you don't hammer away at 
> their site), but it's scraping and can be painful at times. How senders are 
> using postmaster.google.com data is a discussion that frequently happens at 
> MAAWG.
>  
>  
> Ryan
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Best practices for Google Postmaster Tools?

[David Carriger]

Thanks for the tips. We're currently doing double DKIM right now, the question 
in my mind is whether it would be worth using a unique DKIM identifier for 
every single customer of ours to track all of their reputation separately, and 
I wasn't sure whether GPT scales to thousands of domains in a single account or 
if they cut you off at some arbitrary number like, say, 500.

I will be at M3AAWG this year and was definitely planning on attending the GPT 
discussions. Just wanted to make sure our GPT account wasn't going to be 
shutdown if I started scraping the data off of it.


From: Benjamin BILLON 
Sent: Thursday, February 8, 2018 9:43:16 PM
To: Ryan Harris; mailop@mailop.org
Cc: David Carriger
Subject: RE: [mailop] Best practices for Google Postmaster Tools?

Hey Ryan,

I recall that when the errors happened at the end of last year 
(https://www.mail-archive.com/mailop@mailop.org/msg05260.html) I thought to 
myself how the heck of a job that would be to clean the mess for people who are 
scrapping the data.
That, and the not-so-huge need of doing it decreased the priority (and 
increased the innocent hope of the API) on my side.

--
Benjamin


De : Ryan Harris [mailto:r...@sendgrid.com]
Envoyé : vendredi 9 février 2018 12:12
À : Benjamin BILLON 
Cc : David Carriger ; mailop@mailop.org
Objet : Re: [mailop] Best practices for Google Postmaster Tools?

Hello,

> 1) Is there an upper limit on how many authenticated domains can be added for 
> tracking?

I have 160+ domains and didn't hit a limit so far
Consider also applying dual dkim. It can be helpful to see all of your IPs 
reputation under a single, or handful of domains.


> 2) Does anyone know if an API is planned/in the works for GPT?

Yes

https://wordtothewise.com/2017/10/tell-us-use-gmail-postmaster-tools/

https://wordtothewise.com/2017/10/google-postmaster-tools-last-chance/

https://wordtothewise.com/2017/11/gmail-survey-rough-analysis/

no ETA, we tried to make some noise to raise priority, and hope to get some 
news in the coming weeks, but no guarantee
Every year it sounds like an API is "just around the quarter." At this point I 
think it's a story in a backlog that wont see the light of day for a long time.

3) Given the current lack of an API, does Google frown on scraping data from 
GPT?

Some big ESPs do it. They still seem alive today.

> We'd like to make more use of it, but the support around it is sparse right 
> now, and the information I've been able to find on how other ESPs are 
> implementing the data is also quite limited.

You might want to consider joining M3AAWG
Scraping is doable and allowed (I assume so long as you don't hammer away at 
their site), but it's scraping and can be painful at times. How senders are 
using postmaster.google.com data is a discussion 
that frequently happens at MAAWG.


Ryan
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Best practices for Google Postmaster Tools?

[Benjamin BILLON]

Hey Ryan,

I recall that when the errors happened at the end of last year 
(https://www.mail-archive.com/mailop@mailop.org/msg05260.html) I thought to 
myself how the heck of a job that would be to clean the mess for people who are 
scrapping the data.
That, and the not-so-huge need of doing it decreased the priority (and 
increased the innocent hope of the API) on my side.

--
Benjamin


De : Ryan Harris [mailto:r...@sendgrid.com]
Envoyé : vendredi 9 février 2018 12:12
À : Benjamin BILLON 
Cc : David Carriger ; mailop@mailop.org
Objet : Re: [mailop] Best practices for Google Postmaster Tools?

Hello,

> 1) Is there an upper limit on how many authenticated domains can be added for 
> tracking?

I have 160+ domains and didn't hit a limit so far
Consider also applying dual dkim. It can be helpful to see all of your IPs 
reputation under a single, or handful of domains.


> 2) Does anyone know if an API is planned/in the works for GPT?

Yes

https://wordtothewise.com/2017/10/tell-us-use-gmail-postmaster-tools/

https://wordtothewise.com/2017/10/google-postmaster-tools-last-chance/

https://wordtothewise.com/2017/11/gmail-survey-rough-analysis/

no ETA, we tried to make some noise to raise priority, and hope to get some 
news in the coming weeks, but no guarantee
Every year it sounds like an API is "just around the quarter." At this point I 
think it's a story in a backlog that wont see the light of day for a long time.

3) Given the current lack of an API, does Google frown on scraping data from 
GPT?

Some big ESPs do it. They still seem alive today.

> We'd like to make more use of it, but the support around it is sparse right 
> now, and the information I've been able to find on how other ESPs are 
> implementing the data is also quite limited.

You might want to consider joining M3AAWG
Scraping is doable and allowed (I assume so long as you don't hammer away at 
their site), but it's scraping and can be painful at times. How senders are 
using postmaster.google.com data is a discussion 
that frequently happens at MAAWG.


Ryan
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Best practices for Google Postmaster Tools?

[Ryan Harris via mailop]

Hello,

> > 1) Is there an upper limit on how many authenticated domains can be
> added for tracking?
>
> I have 160+ domains and didn't hit a limit so far
>
Consider also applying dual dkim. It can be helpful to see all of your IPs
reputation under a single, or handful of domains.


> > 2) Does anyone know if an API is planned/in the works for GPT?
>
> Yes
>
> https://wordtothewise.com/2017/10/tell-us-use-gmail-postmaster-tools/
>
> https://wordtothewise.com/2017/10/google-postmaster-tools-last-chance/
>
> https://wordtothewise.com/2017/11/gmail-survey-rough-analysis/
>
> no ETA, we tried to make some noise to raise priority, and hope to get
> some news in the coming weeks, but no guarantee
>
Every year it sounds like an API is "just around the quarter." At this
point I think it's a story in a backlog that wont see the light of day for
a long time.

> 3) Given the current lack of an API, does Google frown on scraping data
> from GPT?
>
> Some big ESPs do it. They still seem alive today.
>
> > We'd like to make more use of it, but the support around it is sparse
> right now, and the information I've been able to find on how other ESPs are
> implementing the data is also quite limited.
>
> You might want to consider joining M3AAWG
>
Scraping is doable and allowed (I assume so long as you don't hammer away
at their site), but it's scraping and can be painful at times. How senders
are using postmaster.google.com data is a discussion that frequently
happens at MAAWG.


Ryan
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Best practices for Google Postmaster Tools?

[Benjamin BILLON]

Hello,


> 1) Is there an upper limit on how many authenticated domains can be added for 
> tracking?

I have 160+ domains and didn't hit a limit so far



> 2) Does anyone know if an API is planned/in the works for GPT?

Yes

https://wordtothewise.com/2017/10/tell-us-use-gmail-postmaster-tools/

https://wordtothewise.com/2017/10/google-postmaster-tools-last-chance/

https://wordtothewise.com/2017/11/gmail-survey-rough-analysis/

no ETA, we tried to make some noise to raise priority, and hope to get some 
news in the coming weeks, but no guarantee



3) Given the current lack of an API, does Google frown on scraping data from 
GPT?

Some big ESPs do it. They still seem alive today.

> We'd like to make more use of it, but the support around it is sparse right 
> now, and the information I've been able to find on how other ESPs are 
> implementing the data is also quite limited.

You might want to consider joining M3AAWG


Cheers,
--
Benjamin

De : mailop [mailto:mailop-boun...@mailop.org] De la part de David Carriger
Envoyé : vendredi 9 février 2018 11:19
À : mailop@mailop.org
Objet : [mailop] Best practices for Google Postmaster Tools?


The Google Postmaster Tools knowledge base is a bit light on information. I'm 
wondering if any of you have experience with the following:

1) Is there an upper limit on how many authenticated domains can be added for 
tracking?

2) Does anyone know if an API is planned/in the works for GPT?

3) Given the current lack of an API, does Google frown on scraping data from 
GPT?

We'd like to make more use of it, but the support around it is sparse right 
now, and the information I've been able to find on how other ESPs are 
implementing the data is also quite limited.



Small Business Growth Expert
DAVID CARRIGER
Linux Systems Administrator

--
david.carri...@infusionsoft.com

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Best practices for Google Postmaster Tools?

[David Carriger]

The Google Postmaster Tools knowledge base is a bit light on information. I'm 
wondering if any of you have experience with the following:

1) Is there an upper limit on how many authenticated domains can be added for 
tracking?

2) Does anyone know if an API is planned/in the works for GPT?

3) Given the current lack of an API, does Google frown on scraping data from 
GPT?

We'd like to make more use of it, but the support around it is sparse right 
now, and the information I've been able to find on how other ESPs are 
implementing the data is also quite limited.


Small Business Growth Expert
DAVID CARRIGER
Linux Systems Administrator

--
david.carri...@infusionsoft.com

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Issues With the way Google Groups unsubscribe is used in headers..

[Brandon Long via mailop]

On Wed, Feb 7, 2018 at 6:40 PM John Levine  wrote:

> In article  gku4_obdozume9+gy7et-xrw-m4...@mail.gmail.com> you write:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >I'll file a bug.
> >
> >And this is a direct message from the list to the one attempting to
> >unsubscribe?
>
> Yes, it's been like that for a long time.
>
>
I have a vague memory of writing it that way 14 years ago as a stop-gap for
launch (you had to be logged in instead of handling some confirmation
page), and it's possible it's been copied and even degraded through the N
rewrites and expansions (ie, GSuite groups) since then.
At the time, I don't think any mail clients actually supported
List-Unsubscribe, so it was mostly just to encourage eventual adoption
anyways.

In any case, it's way past time that it was made to work correctly, I've
filed a bug against the groups team to that affect, but I would expect a
proper solution to take some time.

The mailto/email based version should work, and it's the one that's used in
the footer.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Seeing connection issues again with Microsoft mail servers

[Tony Maszeroski via mailop]

Hello Michael,

Craigslist is seeing connection errors / timeouts while trying to
deliver messages to Microsoft domains again (see attached).

Nothing is hitting critical limits yet, but just FYI something is amiss.

Cheers!
-tony
Mail stuck in deferred grouped by domain:

 DOMAIN T 510204080   160   320   640  1280 
1280+
 
=
  TOTAL 82309  3200  3145  6567 13605 27808 24903   374   357   516  
1834
hotmail.com 53222  2124  2123  4405  9169 18732 16669 0 0 0 0
outlook.com 12161   462   466  1019  2082  4226  3906 0 0 0 0
   live.com  5909   243   230   481  1028  2124  1803 0 0 0 0
msn.com  5177   233   202   452   878  1805  1607 0 0 0 0

Top Backpressure IPS :

104.47.1.33 7860
104.47.2.33 6408
104.47.32.33 6027
104.47.46.33 5863
104.47.0.33 5567
104.47.5.33 4887
104.47.44.33 4632
104.47.41.33 4472
104.47.42.33 3752
104.47.40.33 3299
104.47.6.33 3233
104.47.45.33 3210
104.47.34.33 3091
104.47.4.33 2850
104.47.33.33 2496
104.47.36.33 2489
104.47.37.33 1639
104.47.38.33 1624
64.233.186.27 1064


Backpressure Reasons :

(delivery temporarily suspended: lost connection with 
hotmail-com.olc.protection.outlook.com[104.47.1.33] while sending RCPT TO) 5792
(delivery temporarily suspended: lost connection with 
outlook-com.olc.protection.outlook.com[104.47.1.33] while sending RCPT TO) 928
(host live-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.101]. (AS843) (in reply to RCPT 
TO command)) 36
(host live-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.100]. (AS843) (in reply to RCPT 
TO command)) 33
(host hotmail-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 
Server busy. Please try again later from [208.82.237.98]. (AS843) (in reply to 
RCPT TO command)) 31
(host hotmail-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 
Server busy. Please try again later from [208.82.237.102]. (AS843) (in reply to 
RCPT TO command)) 26
(host hotmail-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 
Server busy. Please try again later from [208.82.237.96]. (AS843) (in reply to 
RCPT TO command)) 22
(host hotmail-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 
Server busy. Please try again later from [208.82.237.97]. (AS843) (in reply to 
RCPT TO command)) 22
(host eur.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.105]. (AS843) (in reply to RCPT 
TO command)) 21
(host live-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.96]. (AS843) (in reply to RCPT TO 
command)) 20
(host hotmail-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 
Server busy. Please try again later from [208.82.237.101]. (AS843) (in reply to 
RCPT TO command)) 19
(host live-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.104]. (AS843) (in reply to RCPT 
TO command)) 18
(host outlook-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 
Server busy. Please try again later from [208.82.237.102]. (AS843) (in reply to 
RCPT TO command)) 18
(host eur.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.100]. (AS843) (in reply to RCPT 
TO command)) 16
(host live-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.103]. (AS843) (in reply to RCPT 
TO command)) 14
(host outlook-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 
Server busy. Please try again later from [208.82.237.96]. (AS843) (in reply to 
RCPT TO command)) 14
(host eur.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.103]. (AS843) (in reply to RCPT 
TO command)) 13
(host hotmail-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 
Server busy. Please try again later from [208.82.237.100]. (AS843) (in reply to 
RCPT TO command)) 13
(host hotmail-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 
Server busy. Please try again later from [208.82.237.105]. (AS843) (in reply to 
RCPT TO command)) 13
(host eur.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.101]. (AS843) (in reply to RCPT 
TO command)) 12
(host live-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.105]. (AS843) (in reply to RCPT 
TO command)) 12
(host live-com.olc.protection.outlook.com[104.47.1.33] said: 451 4.7.500 Server 
busy. Please try again later from [208.82.237.97]. (AS843) (in reply to RCP

Re: [mailop] Heads Up

[Bill Cole]

On 2 Feb 2018, at 17:18, Michelle Sullivan wrote:


Charles McKean wrote:

On Sat, Jan 20, 2018 at 9:41 AM, Ken O'Driscoll via mailop
 wrote:

On Sat, 2018-01-20 at 11:14 +1100, Michelle Sullivan wrote:
One can only conclude, they either have a leak in their API, or 
they
altered the permissions to give out emails when specifically 
denied, or

they got hacked and didn't disclose it.
They had bug for over a year between ~2012-2013 where contact 
details

(including email) were unintentionally exposed.

Can't your friends see your email address on Facebook? Wouldn't that
mean that literally anybody could be responsible for leaking this
address?



No certain details (like email address) are 'Only Me' permission on my 
Facebook - because it (the email) is only used for Facebook login.


Possibly relevant: 
https://www.josipfranjkovic.com/blog/facebook-partners-portal-account-takeover


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop