Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-03-06 Thread John Levine
In article 

Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-03-06 Thread David Hofstee
I am against scanning everything in order to protect. Because every method
an ESP needs to do to "fix" these bad unsubscribes can just as easily be
spoofed by bad actors (e.g. redirect url to non-malicious content for first
10 minutes). And not all ESPs are even aware of this scanning process (if
they are even that capable*).

The bottom line is that spamfilters cannot pretend to be humans (and act
accordingly). It will be only a short moment until the malicious payload
will be behind the "unsubscribe button" instead of the "unsubscribe page".
What is next, spamfilters pushing the button? This is not the technical
innovation we are looking for. It does not improve the signal to noise
ratio by much.

Just looking at recipients who would be behind the engagement-filter
doesn't do the trick either. You counter the ESPs methods *and *it can only
work if the filter will actually unsubscribe too.

Maybe it is a shifting definition of spamtrap (a content verifying
trap/spamtrap).

Yours,


David

* not trying to badmouth others here ;-)

On 3 March 2018 at 00:53, Dave Warren  wrote:

> On 2018-03-01 16:26, David Carriger wrote:
>
>> Yes, I'm still seeing this. So, an open question:
>>
>> As an ESP, how am I supposed to tell my users to practice good list
>> hygiene and remove unengaged recipients from their lists when my data is
>> being tainted by Google/Microsoft/etc triggering all of my engagement
>> mechanisms (open tracking pixel, tracked links, etc)? These show up as
>> their /most/ engaged recipients.
>>
>> Obviously there are things that can be done on my end (look for all URIs
>> in the email being triggered with a short time frame from IP ranges that we
>> know do this behavior and don't count those as engagement), so I'll tread
>> down that path with our developers. Still, I find it frustrating, and
>> wonder how other people are dealing with this issue.
>>
>
> I don't know if this has already been discussed, but what's the
> User-Agent? Any clues there?
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>



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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-03-02 Thread Dave Warren

On 2018-03-01 16:26, David Carriger wrote:

Yes, I'm still seeing this. So, an open question:

As an ESP, how am I supposed to tell my users to practice good list 
hygiene and remove unengaged recipients from their lists when my data is 
being tainted by Google/Microsoft/etc triggering all of my engagement 
mechanisms (open tracking pixel, tracked links, etc)? These show up as 
their /most/ engaged recipients.


Obviously there are things that can be done on my end (look for all URIs 
in the email being triggered with a short time frame from IP ranges that 
we know do this behavior and don't count those as engagement), so I'll 
tread down that path with our developers. Still, I find it frustrating, 
and wonder how other people are dealing with this issue.


I don't know if this has already been discussed, but what's the 
User-Agent? Any clues there?


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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-03-02 Thread Vick Khera
On Thu, Mar 1, 2018 at 6:26 PM, David Carriger <
david.carri...@infusionsoft.com> wrote:

> Yes, I'm still seeing this. So, an open question:
>
> As an ESP, how am I supposed to tell my users to practice good list
> hygiene and remove unengaged recipients from their lists when my data is
> being tainted by Google/Microsoft/etc triggering all of my engagement
> mechanisms (open tracking pixel, tracked links, etc)? These show up as
> their *most* engaged recipients.
>
Build in some intelligence to the tracking to detect a single remote IP
tripping every single link in your message within a few seconds, and ignore
it. Over time you will start to learn the IPs to just ignore up front. I'm
sure you can come up with some more intelligent methods too, using neural
networks or some such fancy pants trendy technology. :)
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-03-01 Thread Steve Atkins

> On Mar 1, 2018, at 3:26 PM, David Carriger  
> wrote:
> 
> Yes, I'm still seeing this. So, an open question:
> 
> As an ESP, how am I supposed to tell my users to practice good list hygiene 
> and remove unengaged recipients from their lists when my data is being 
> tainted by Google/Microsoft/etc triggering all of my engagement mechanisms 
> (open tracking pixel, tracked links, etc)? These show up as their most 
> engaged recipients.
> 
> Obviously there are things that can be done on my end (look for all URIs in 
> the email being triggered with a short time frame from IP ranges that we know 
> do this behavior and don't count those as engagement), so I'll tread down 
> that path with our developers. Still, I find it frustrating, and wonder how 
> other people are dealing with this issue.

In a fairly ad-hoc manner. Automated clicks aren't too painful to deal with, 
but you have to have the infrastructure to do it. Image loads are hard, but 
treating those as an "open" has always been a pretty fuzzy metric anyway.

Cheers,
  Steve


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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-03-01 Thread Michael Wise via mailop

You forgot to mention ... nevermind.
Yeah, completely understand the frustration, sticks have been sharpened, people 
have been poked, will get back to you as soon as I have something.

And here I thought it had been addressed ... :'(

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?

From: David Carriger [mailto:david.carri...@infusionsoft.com]
Sent: Thursday, March 1, 2018 3:26 PM
To: Michael Wise <michael.w...@microsoft.com>; mailop@mailop.org
Subject: Re: Microsoft IPs automatically unsubscribing recipients?


Yes, I'm still seeing this. So, an open question:

As an ESP, how am I supposed to tell my users to practice good list hygiene and 
remove unengaged recipients from their lists when my data is being tainted by 
Google/Microsoft/etc triggering all of my engagement mechanisms (open tracking 
pixel, tracked links, etc)? These show up as their most engaged recipients.

Obviously there are things that can be done on my end (look for all URIs in the 
email being triggered with a short time frame from IP ranges that we know do 
this behavior and don't count those as engagement), so I'll tread down that 
path with our developers. Still, I find it frustrating, and wonder how other 
people are dealing with this issue.


From: Michael Wise 
<michael.w...@microsoft.com<mailto:michael.w...@microsoft.com>>
Sent: Monday, February 26, 2018 6:34:45 PM
To: David Carriger; mailop@mailop.org<mailto:mailop@mailop.org>
Subject: RE: Microsoft IPs automatically unsubscribing recipients?


Is this still on-going?
I had heard that it had been addressed week before last...?

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fdownload%2Fdetails.aspx%3Fid%3D18275=04%7C01%7CMichael.Wise%40microsoft.com%7Cf3cf4b2682454ae21c0e08d57fcbd740%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636555435840588353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=0MjXPOAt0DGd7vF8%2FagiXbyqzErxjM234SYINyinbdY%3D=0>
 ?

From: mailop <mailop-boun...@mailop.org<mailto:mailop-boun...@mailop.org>> On 
Behalf Of David Carriger
Sent: Friday, February 23, 2018 11:29 AM
To: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: [mailop] Microsoft IPs automatically unsubscribing recipients?


I've just received an interesting escalation from our support team. We have a 
customer sending mail to recipients at the following domains:


andromeda.rutgers.edu
apsu.edu
barry.edu
bsu.edu
ccsnh.edu
clarion.edu
cofc.edu
dcccd.edu
gsu.edu
hofstra.edu
king.edu
letu.edu
mail.barry.edu
mansfield.edu
mercycollege.edu
mssu.edu
oldqueens.rutgers.edu
queensu.ca
rci.rutgers.edu
rutgers.edu
salemstate.edu
trevecca.edu
uncfsu.edu
usi.edu
vanderbilt.edu
wcsu.edu


With the exception of Rutgers, these are all hosted on Office 365. Once the 
mail has delivered, I'm seeing all of the links inside the email hit within a 
span of time varying between 1-10 seconds. For example, here's an unsubscribe 
in our database for @mssu.edu:

List Unsubscribe Mon Feb 19 08:45:54 EST 2018 by 40.107.217.27



If I pull my web access logs for that, I've got the following timeline of 
events (all times are EST):



2018-02-19 08:45:55 /app/optOut/noConfirm/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:55 /app/optOut/8/bf58b2859105b738/994494/72f6f3b025bfa2a1  
   40.107.217.27

2018-02-19 08:45:55 /app/emailOpened/994494/924 40.107.217.27

2018-02-19 08:45:56 /app/optOut/noConfirm/994494/%3Cimg%20src= 
40.107.217.27

2018-02-19 08:45:57 /app/hostedEmail/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:59 /app/emailOpened/994494/924 40.107.217.27



So, for this example, within a span of four seconds we've hit the one-click 
opt-out link we use in our List-Unsubscribe header, the user-visible 
unsubscribe link within the message body, the open tracking pixel, the tracking 
link we provide for our customer's call-to-action...that's not human behavior. 
That's machine behavior.



It's the same story for all of the other recipients I've looked at. This 
behavior is occurring from the following IPs/ranges, all owned by Microsoft:



104.47.61.250

40.107.217.0/24

40.107.218.0/24

40.107.222.0/24

40.107.234.0/24

40.107.238.0/24

40.107.242.0/24



Are we the only ones experiencing this, or are others seeing this as well?



Small Business Growth Expert
DAVID CARRIGER
Linux Systems Administrator

--
david.carri...@infusionsoft.com<mailto:david.carri...@infusionsoft.com>

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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-03-01 Thread David Carriger
Yes, I'm still seeing this. So, an open question:

As an ESP, how am I supposed to tell my users to practice good list hygiene and 
remove unengaged recipients from their lists when my data is being tainted by 
Google/Microsoft/etc triggering all of my engagement mechanisms (open tracking 
pixel, tracked links, etc)? These show up as their most engaged recipients.

Obviously there are things that can be done on my end (look for all URIs in the 
email being triggered with a short time frame from IP ranges that we know do 
this behavior and don't count those as engagement), so I'll tread down that 
path with our developers. Still, I find it frustrating, and wonder how other 
people are dealing with this issue.


From: Michael Wise <michael.w...@microsoft.com>
Sent: Monday, February 26, 2018 6:34:45 PM
To: David Carriger; mailop@mailop.org
Subject: RE: Microsoft IPs automatically unsubscribing recipients?


Is this still on-going?
I had heard that it had been addressed week before last…?

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?

From: mailop <mailop-boun...@mailop.org> On Behalf Of David Carriger
Sent: Friday, February 23, 2018 11:29 AM
To: mailop@mailop.org
Subject: [mailop] Microsoft IPs automatically unsubscribing recipients?


I've just received an interesting escalation from our support team. We have a 
customer sending mail to recipients at the following domains:


andromeda.rutgers.edu
apsu.edu
barry.edu
bsu.edu
ccsnh.edu
clarion.edu
cofc.edu
dcccd.edu
gsu.edu
hofstra.edu
king.edu
letu.edu
mail.barry.edu
mansfield.edu
mercycollege.edu
mssu.edu
oldqueens.rutgers.edu
queensu.ca
rci.rutgers.edu
rutgers.edu
salemstate.edu
trevecca.edu
uncfsu.edu
usi.edu
vanderbilt.edu
wcsu.edu


With the exception of Rutgers, these are all hosted on Office 365. Once the 
mail has delivered, I'm seeing all of the links inside the email hit within a 
span of time varying between 1-10 seconds. For example, here's an unsubscribe 
in our database for @mssu.edu:

List Unsubscribe Mon Feb 19 08:45:54 EST 2018 by 40.107.217.27



If I pull my web access logs for that, I've got the following timeline of 
events (all times are EST):



2018-02-19 08:45:55 /app/optOut/noConfirm/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:55 /app/optOut/8/bf58b2859105b738/994494/72f6f3b025bfa2a1  
   40.107.217.27

2018-02-19 08:45:55 /app/emailOpened/994494/924 40.107.217.27

2018-02-19 08:45:56 /app/optOut/noConfirm/994494/%3Cimg%20src= 
40.107.217.27

2018-02-19 08:45:57 /app/hostedEmail/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:59 /app/emailOpened/994494/924 40.107.217.27



So, for this example, within a span of four seconds we've hit the one-click 
opt-out link we use in our List-Unsubscribe header, the user-visible 
unsubscribe link within the message body, the open tracking pixel, the tracking 
link we provide for our customer's call-to-action...that's not human behavior. 
That's machine behavior.



It's the same story for all of the other recipients I've looked at. This 
behavior is occurring from the following IPs/ranges, all owned by Microsoft:



104.47.61.250

40.107.217.0/24

40.107.218.0/24

40.107.222.0/24

40.107.234.0/24

40.107.238.0/24

40.107.242.0/24



Are we the only ones experiencing this, or are others seeing this as well?



Small Business Growth Expert
DAVID CARRIGER
Linux Systems Administrator

--
david.carri...@infusionsoft.com<mailto:david.carri...@infusionsoft.com>

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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-27 Thread John Levine
>> Then, I guess, why not POST (or GET) the unsubscribe link anyway?  If 
>> the user indicated a desire for a facilitated unsubscribe, why not try?
>
>The major issue in this situation is that the users *didn't* indicate 
>desire.
>
>Moving forward, when there's actual user involvement...having mail readers 
>take indirect action might be OK as a "privacy guard" proxy, subject to 
>standard "you're intentionally introducing a MitM" caveats.

We covered all this in RFC 8058.  If you GET a one-click unsub link,
it doesn't unsubscribe you but it may send you to a confirmation page
with an are-you-sure button.  If you POST it, you unsubscribe the
person.

The best known place this is used is the Gmail spam button, which will
ask you if you also want to unsubscribe if it sees an unsub link.  I
gather other webmail services plan to add something like it.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-27 Thread Jesse Thompson

On 2/27/2018 4:34 PM, Aaron Richton wrote:

On Tue, 27 Feb 2018, Jesse Thompson wrote:

Then, I guess, why not POST (or GET) the unsubscribe link anyway?  If 
the user indicated a desire for a facilitated unsubscribe, why not try?


The major issue in this situation is that the users *didn't* indicate 
desire.


Moving forward, when there's actual user involvement...having mail 
readers take indirect action might be OK as a "privacy guard" proxy, 
subject to standard "you're intentionally introducing a MitM" caveats.


Agreed.  I was assuming it was based on the users' clicking the 
unsubscribe button.


Jesse

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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-27 Thread Aaron Richton

On Tue, 27 Feb 2018, Jesse Thompson wrote:

Then, I guess, why not POST (or GET) the unsubscribe link anyway?  If 
the user indicated a desire for a facilitated unsubscribe, why not try?


The major issue in this situation is that the users *didn't* indicate 
desire.


Moving forward, when there's actual user involvement...having mail readers 
take indirect action might be OK as a "privacy guard" proxy, subject to 
standard "you're intentionally introducing a MitM" caveats.


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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-27 Thread Jesse Thompson

On 2/23/2018 3:25 PM, Grant Taylor via mailop wrote:

On 02/23/2018 12:28 PM, David Carriger wrote:
Can you tell if the URL accesses are GETs or POSTs?

Do you action on your one-click-unsubscribe based on GETs?  -  I thought 
one-click-unsubscribe was purposefully supposed to require POSTs to 
avoid inadvertent activation by things like link scanners.


Office 365 Outlook on the Web does show the user a button to 
unsubscribe.  I think it's triggered by the existence of a 
List-Unsubscribe header, but I'm not certain.  Every time I have clicked 
on the button, they give a message indicating that it's not safe to 
process the request (possibly due to an internal reputation model) and 
recommend the user instead mark the message as spam (causing the sender 
to be added to Blocked Senders)


The dilemma is that users are (or should be) afraid to click unsubscribe 
links due to security concerns.  They don't want their browser loading 
the payload behind the URL.  Furthermore, legitimate email senders have 
been increasingly aggressive at sending unsolicited mailings.  This 
leads to a VERY high level of frustration among users.


I support the idea of a server-side facilitated unsubscribe process.  It 
seems that using the List-Unsubscribe-Post header as the indicator for 
the server to know that they can POST unsubscribe requests on behalf of 
the user is ideal.


But, what if not enough email senders adopt List-Unsubscribe-Post or 
accept some other FBL mechanism for server facilitated unsubscribes? 
Then, I guess, why not POST (or GET) the unsubscribe link anyway?  If 
the user indicated a desire for a facilitated unsubscribe, why not try?


Jesse @ UW-Madison

(I'm kind of sad to see wisc.edu isn't on the list because I know that 
our users would love to see this happen.)


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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-26 Thread Michael Wise via mailop

Is this still on-going?
I had heard that it had been addressed week before last...?

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?

From: mailop <mailop-boun...@mailop.org> On Behalf Of David Carriger
Sent: Friday, February 23, 2018 11:29 AM
To: mailop@mailop.org
Subject: [mailop] Microsoft IPs automatically unsubscribing recipients?


I've just received an interesting escalation from our support team. We have a 
customer sending mail to recipients at the following domains:


andromeda.rutgers.edu
apsu.edu
barry.edu
bsu.edu
ccsnh.edu
clarion.edu
cofc.edu
dcccd.edu
gsu.edu
hofstra.edu
king.edu
letu.edu
mail.barry.edu
mansfield.edu
mercycollege.edu
mssu.edu
oldqueens.rutgers.edu
queensu.ca
rci.rutgers.edu
rutgers.edu
salemstate.edu
trevecca.edu
uncfsu.edu
usi.edu
vanderbilt.edu
wcsu.edu


With the exception of Rutgers, these are all hosted on Office 365. Once the 
mail has delivered, I'm seeing all of the links inside the email hit within a 
span of time varying between 1-10 seconds. For example, here's an unsubscribe 
in our database for @mssu.edu:

List Unsubscribe Mon Feb 19 08:45:54 EST 2018 by 40.107.217.27



If I pull my web access logs for that, I've got the following timeline of 
events (all times are EST):



2018-02-19 08:45:55 /app/optOut/noConfirm/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:55 /app/optOut/8/bf58b2859105b738/994494/72f6f3b025bfa2a1  
   40.107.217.27

2018-02-19 08:45:55 /app/emailOpened/994494/924 40.107.217.27

2018-02-19 08:45:56 /app/optOut/noConfirm/994494/%3Cimg%20src= 
40.107.217.27

2018-02-19 08:45:57 /app/hostedEmail/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:59 /app/emailOpened/994494/924 40.107.217.27



So, for this example, within a span of four seconds we've hit the one-click 
opt-out link we use in our List-Unsubscribe header, the user-visible 
unsubscribe link within the message body, the open tracking pixel, the tracking 
link we provide for our customer's call-to-action...that's not human behavior. 
That's machine behavior.



It's the same story for all of the other recipients I've looked at. This 
behavior is occurring from the following IPs/ranges, all owned by Microsoft:



104.47.61.250

40.107.217.0/24

40.107.218.0/24

40.107.222.0/24

40.107.234.0/24

40.107.238.0/24

40.107.242.0/24



Are we the only ones experiencing this, or are others seeing this as well?



Small Business Growth Expert
DAVID CARRIGER
Linux Systems Administrator

--
david.carri...@infusionsoft.com<mailto:david.carri...@infusionsoft.com>

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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-23 Thread Paul



On 23 February 2018 21:44:20 Grant Taylor via mailop  wrote:


This almost sounds like automated link content scanning.


Probably

That's a great mechanism for confirming active email addresses to spammers 
using tracking links...




Sent with AquaMail for Android
http://www.aqua-mail.com




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


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-23 Thread David Carriger
Good catch, Grant. They are GET requests. Our developers implemented the 
List-Unsubscribe HTTP method a long time ago and it appears that it was never 
updated to comply with RFC 8058. I'm still curious as to why I'm only seeing 
this with .edu domains hosted on Office365 and not Office365 in general 
(perhaps different filtering techniques are used for Universities?), but the 
fix is clearly to have our developers fix the header.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-23 Thread Grant Taylor via mailop

On 02/23/2018 12:28 PM, David Carriger wrote:
With the exception of Rutgers, these are all hosted on Office 365. Once 
the mail has delivered, I'm seeing all of the links inside the email hit 
within a span of time varying between 1-10 seconds. For example, here's 
an unsubscribe in our database for @mssu.edu:


This almost sounds like automated link content scanning.

So, for this example, within a span of four seconds we've hit the 
one-click opt-out link we use in our List-Unsubscribe header, the 
user-visible unsubscribe link within the message body, the open tracking 
pixel, the tracking link we provide for our customer's 
call-to-action...that's not human behavior. That's machine behavior.


Can you tell if the URL accesses are GETs or POSTs?

Do you action on your one-click-unsubscribe based on GETs?  -  I thought 
one-click-unsubscribe was purposefully supposed to require POSTs to 
avoid inadvertent activation by things like link scanners.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-23 Thread Aaron Richton

On Fri, 23 Feb 2018, David Carriger wrote:


I've just received an interesting escalation from our support team. We have a 
customer sending mail to recipients at the following domains:

[...]
With the exception of Rutgers, these are all hosted on Office 365. Once 
the mail has delivered, I'm seeing all of the links inside the email hit 
within a span of time varying between 1-10 seconds. For example, here's 
an unsubscribe in our database for @mssu.edu:


And although the Rutgers MX listed aren't (.*)outlook.com, the underlying 
mail stores (especially within the domains you listed) are frequently, but 
not always, O365. If you have any recipients at e.g. sas.rutgers.edu 
that's IN MX 10 sas-rutgers-edu.mail.protection.outlook.com. and I'd 
expect you to find similar behavior.


Are we the only ones experiencing this, or are others seeing this as 
well?


Nope, we're seeing it as well, can easily replicate it, have a case open 
with MS about it, and contacted one particular ESP who apparently worked 
with MS on some sort of workaround that, in light of your message, may 
have been specialized to that explicit ESP. And this isn't 0day; I think I 
first heard rumors along these lines at least 3 weeks ago.


I'll toss your details over to the O365 side of the postmaster team here 
to append to our case...thanks for the additional data points, I suppose.


-Aaron Richton
Rutgers University, Office of Information Technology___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


[mailop] Microsoft IPs automatically unsubscribing recipients?

2018-02-23 Thread David Carriger
I've just received an interesting escalation from our support team. We have a 
customer sending mail to recipients at the following domains:


andromeda.rutgers.edu
apsu.edu
barry.edu
bsu.edu
ccsnh.edu
clarion.edu
cofc.edu
dcccd.edu
gsu.edu
hofstra.edu
king.edu
letu.edu
mail.barry.edu
mansfield.edu
mercycollege.edu
mssu.edu
oldqueens.rutgers.edu
queensu.ca
rci.rutgers.edu
rutgers.edu
salemstate.edu
trevecca.edu
uncfsu.edu
usi.edu
vanderbilt.edu
wcsu.edu


With the exception of Rutgers, these are all hosted on Office 365. Once the 
mail has delivered, I'm seeing all of the links inside the email hit within a 
span of time varying between 1-10 seconds. For example, here's an unsubscribe 
in our database for @mssu.edu:

List Unsubscribe Mon Feb 19 08:45:54 EST 2018 by 40.107.217.27


If I pull my web access logs for that, I've got the following timeline of 
events (all times are EST):


2018-02-19 08:45:55 /app/optOut/noConfirm/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:55 /app/optOut/8/bf58b2859105b738/994494/72f6f3b025bfa2a1  
   40.107.217.27

2018-02-19 08:45:55 /app/emailOpened/994494/924 40.107.217.27

2018-02-19 08:45:56 /app/optOut/noConfirm/994494/%3Cimg%20src= 
40.107.217.27

2018-02-19 08:45:57 /app/hostedEmail/994494/72f6f3b025bfa2a1 
40.107.217.27

2018-02-19 08:45:59 /app/emailOpened/994494/924 40.107.217.27


So, for this example, within a span of four seconds we've hit the one-click 
opt-out link we use in our List-Unsubscribe header, the user-visible 
unsubscribe link within the message body, the open tracking pixel, the tracking 
link we provide for our customer's call-to-action...that's not human behavior. 
That's machine behavior.


It's the same story for all of the other recipients I've looked at. This 
behavior is occurring from the following IPs/ranges, all owned by Microsoft:


104.47.61.250

40.107.217.0/24

40.107.218.0/24

40.107.222.0/24

40.107.234.0/24

40.107.238.0/24

40.107.242.0/24


Are we the only ones experiencing this, or are others seeing this as well?


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