Re: [mailop] I Need someone from AOL and/or Yahoo to contact me

[John Stephenson via mailop]

Somebody may see this from Yahoo, but below I've included their support
request URL and their broader Postmaster site which is the default path for
things like this.


*Yahoo's Support Request : *
https://senders.yahooinc.com/contact#sender-support-request
*Yahoo's Postmaster site*: https://senders.yahooinc.com/faqs

On Sun, Jul 23, 2023 at 5:49 PM Ken Robinson via mailop 
wrote:

> Last Friday two email addresses on my server with weak passwords were
> discovered and used to send thousands of spam messages. By the time I
> discovered the problem (it happened when I was asleep and I discovered it a
> few hours after), my server was getting blocked by spam lists.  This is
> affecting mailing lists that run on the server. Both AOL and Yahoo don't
> bounce the message, but they end up in the Spam mailboxes. If they had
> bounced, I could have reached out sooner.
>
> Ken Robinson
> ___
> 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] "header is missing" at Gmail

[John Stephenson via mailop]

I appreciate the feedback from you both!  I'll see if this is something we
can confirm/exclude.

J

On Tue, Nov 8, 2022 at 3:15 PM Brandon Long via mailop 
wrote:

> Another one I've seen is an extra newline which ends the headers, ie:
>
> Subject: foo
> To: b...@example.net
>
> From: campa...@example.org
>
> I don't recall how annoying our parser is, whether something like this
> would also cause early end of headers:
>
> Subject: foo
> To: bar@
> example.net
> From: campa...@example.org
>
> Brandon
>
> On Tue, Nov 8, 2022 at 2:15 PM Mary via mailop  wrote:
>
>>
>> I've seen this before, when the header above the From header is broken:
>>
>> Authentication-Results: server;
>> dkim=blah reason="blah";
>> From: "Valid" 
>> To: mailop 
>>
>>
>> The parser thinks that the From: header is part of the previous header,
>> thus ignoring it and ending with a missing header error.
>>
>>
>>
>> On Tue, 8 Nov 2022 13:41:57 -0800 John Stephenson via mailop <
>> mailop@mailop.org> wrote:
>>
>> > We've seen the below failure for two different clients (each in one
>> > specific campaign) which resulted in lots of these failures at Gmail for
>> > those respective campaigns.  Our Support/Ops team continue to insist
>> that
>> > we sent these campaigns with the same exact from address/header/domain
>> set
>> > up as all of the other campaigns launched on this day and that the issue
>> > must be on Gmail's side.
>> > I'm praying that somebody here has had experience with this failure and
>> > tracked down some subtle/quirky reason why an otherwise reliable sending
>> > MTA would encounter this failure?
>> >
>> > Best,
>> >
>> > John
>> >
>> >
>> > 550-5.7.1 [142.54.247.27] Our system has detected that this message is
>> not
>> > RFC\r\n550-5.7.1 5322 compliant:\r\n550-5.7.1 'From' header is
>> > missing.\r\n550-5.7.1 To reduce the amount of spam sent to Gmail, this
>> > message has been\r\n550-5.7.1 blocked. Please visit\r\n550-5.7.1
>> > https://support.google.com/mail/?p=RfcMessageNonCompliant\r\n550 5.7.1
>> and
>> > review RFC 5322 specifications for more information.
>> ___
>> 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

[mailop] "header is missing" at Gmail

[John Stephenson via mailop]

We've seen the below failure for two different clients (each in one
specific campaign) which resulted in lots of these failures at Gmail for
those respective campaigns.  Our Support/Ops team continue to insist that
we sent these campaigns with the same exact from address/header/domain set
up as all of the other campaigns launched on this day and that the issue
must be on Gmail's side.
I'm praying that somebody here has had experience with this failure and
tracked down some subtle/quirky reason why an otherwise reliable sending
MTA would encounter this failure?

Best,

John


550-5.7.1 [142.54.247.27] Our system has detected that this message is not
RFC\r\n550-5.7.1 5322 compliant:\r\n550-5.7.1 'From' header is
missing.\r\n550-5.7.1 To reduce the amount of spam sent to Gmail, this
message has been\r\n550-5.7.1 blocked. Please visit\r\n550-5.7.1
https://support.google.com/mail/?p=RfcMessageNonCompliant\r\n550 5.7.1 and
review RFC 5322 specifications for more information.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] WhatCounts/Costco silliness

[John Stephenson via mailop]

>From memory, I believe the sender needs to explain the available mechanism
for unsubscribe which must be internet-based and remain online for 30 days
(likely some other rules as well, like no password requirements).  So most
senders have the traditional unsub at the bottom of the body and they have
text that says, "Click here to unsubscribe."  The unsub header should work
for ease of use, but I don't think that can be the primary unsub mechanism
because then the sender would have to describe how people can unsubscribe
using it, and the user experience changes depending on the website/software
where the mail is viewed.

J

On Tue, Oct 26, 2021 at 11:12 AM Dave Crocker via mailop 
wrote:

>
>
> On 10/26/2021 9:56 AM, John Levine via mailop wrote:
> > On the one hand, historically the opt-out has been in the body of the
> message, but a whole
> > lot of mail programs now recognize List-Unsubscribe and give you an
> option in the frame of
> > the message which is easier to recognize
>
> 1. But others do not
>
> 2. And many/most/all hide fields they don't recognize
>
> 3. Which means that while the information is in the message, it isn't
> normally visible to some/many recipients.
>
> Which would seem to violate the intent of the requirement.
>
> d/
> ___
> 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] Thanks Lili !

[John Stephenson via mailop]

Absolutely agree with Dave and Al, but I'll offer a very quick PSA to what
I'm sure is a very small percentage of lurkers here who are looking for a
quick fix to sneak crappy email into inboxes.  You're better off staying
off Lili and Marcel's radar.  While they have proven helpful in addressing
unintended consequences that affect good senders, they will fiercely defend
the experience of their users.  If you misrepresent what type of mail
you're sending to get into the Yahoo/Verizon inbox--they will see it in
their metrics and they will remember you ;-)  Choose wisely!

J

On Fri, Jul 16, 2021 at 7:01 PM Al Iverson via mailop 
wrote:

> Hey, I'd like to second this! Lili Crowley at Verizon is a great person
> and very helpful when it comes to helping us great unwashed masses resolve
> email delivery issues. It doesn't hurt that she is super smart and very
> insightful as well. Verizon is chock full of good people here. Not all
> large B2C webmail providers lean into the community aspect of email as a
> sort of industry or group like Verizon does, and it is very much because of
> the good people at the company like Ms. Crowley and also Marcel Becker.
>
> Cheers,
> Al Iverson
>
> On Fri, Jul 16, 2021 at 4:53 PM Dave Holmes via mailop 
> wrote:
>
>> This has been a great mailing list to be a part of, most posts are people
>> seeking to resolve issues.
>>
>> I thought I would post a massive thank you to Lili Crowley and the team
>> at Verizon helping to resolve a problem we were having, it's such a
>> refreshing change to be able to speak with people and not hop through a
>> million and one postmaster forms - just to get a canned response days later!
>>
>> Have a great weekend from a sunny UK
>>
>> --
>>
>> [image: Instiller Logo] 
>> Dave Holmes
>> Technical Director
>>
>> d...@instiller.co.uk
>> T 0333 939 0013  |  M 07966 013 309
>> 1 Park Farm Barns | Packington Lane | Stonebridge | CV7 7TL
>>
>>
>> Instiller is a trademark of Instiller Limited, registered in England
>> 5053657.
>>
>> This email contains proprietary information, some of which may be legally
>> privileged. It is for the intended recipient only.
>> If an addressing or transmission in error has misdirected this email,
>> please notify the author by replying to this email.
>> If you are not the intended recipient, you must not use, disclose,
>> distribute, copy, print or rely on this email.
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>>
>
>
> --
> Al Iverson // Wombatmail // Chicago
> Deliverability: https://spamresource.com
> DNS Tools: https://xnnd.com
> ___
> 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] Yahoo and AOL slow delivery

[John Stephenson via mailop]

We aren't seeing anything abnormal today/yesterday.

On Wed, Feb 17, 2021 at 9:33 AM Michael E. Weisel via mailop
 wrote:
>
> Hi Mailop group, I hope everyone is well.  I was wondering if others are 
> seeing much higher mail queues to @yahoo and @aol then normal that started 
> late yesterday but got progressively worse this morning?  I wasn’t seeing any 
> TSS errors or backoffs, just very, very slow delivery.  After a while I saw a 
> few timeout errors but not a lot of them.  I know that sometimes VMG makes 
> changes that can cause this but I haven’t seen it this slow in quite some 
> time.  I was wondering if maybe it could be weather related with ice and snow 
> across the US?  Any others seeing similar issues over the last 12-18 hours or 
> so?  Any insight would be super helpful.
>
>
>
>
>
> Thanks,
>
>
>
> Michael
>
>
>
> Michael E. Weisel
>
> CTO / Deliverability Lead
>
> Gold Lasso
>
> (301) 990-9857 Corporate
>
> (240) 813-0174 Direct Dial
>
>
>
> ___
> 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] Optonline contact?

[John Stephenson via mailop]

In my experience, optonline seems perfectly content with blocking lots of
valid mail--or perhaps they are content to not put themselves in a position
to hear that they are blocking lots of mail.  I tried to work through their
process for a few months because a client's password reset emails on a
dedicated transactional IP were blocked fairly consistently--not
successfully.  Most people I've talked to have noted that they were not
able to resolve their issues.  One or two said they were able to break
through but that seems to be the exception to the rule.

I sincerely wish you the best of luck!

J

On Wed, Jun 10, 2020 at 7:37 AM Brett Schenker via mailop 
wrote:

> We've been having some issues delivering to optonline, is there anyone
> from there on here or anyone have suggestions on how to reach them?
>
> --
> Brett Schenker
> Man of Many Things, Including
> 5B Consulting - http://www.5bconsulting.com
> Graphic Policy - http://www.graphicpolicy.com
>
> Twitter - http://twitter.com/bhschenker
> LinkedIn - http://www.linkedin.com/in/brettschenker
> ___
> 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] [ext] Change at Microsoft on September 4th

[John Stephenson via mailop]

After my last email, I did talk with another esteemed deliverability
professional and he also saw a recent, positive improvement for one of his
clients.  I'm not sure if that timing is coincidental, or if somebody just
gave their Anti-Spam system good Etch A Sketch style shake up.
Also to be fair, I don't see most of my clients impacted at all, but I have
seen a negative shift for a number of senders where I would not expect to
see any shift.

On Fri, Sep 13, 2019 at 12:45 AM Ralf Hildebrandt via mailop <
mailop@mailop.org> wrote:

> * Caitlin Brodie via mailop :
>
> > We also saw issues starting on September 4th, but our IPs' reputation in
> > SNDS hasn't recovered yet, and neither has our open rate to Microsoft
> > domains.
> >
> > Has anyone else continued to see deliverability issues to Microsoft
> domains
> > after September 4th? We're trying to gauge whether this is related to
> those
> > more widespread problems or not.
>
> I'm seeing the opposite. We (mail.python.org) went from months of
> status "red" to green between 9/1 and 9/3 -- although the complaint
> rate has risen significantly.
>
> --
> Ralf Hildebrandt   Charite Universitätsmedizin Berlin
> ralf.hildebra...@charite.deCampus Benjamin Franklin
> https://www.charite.de Hindenburgdamm 30, 12203 Berlin
> Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
>
> ___
> 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] Change at Microsoft on September 4th

[John Stephenson via mailop]

I'm seeing it as well.  I'm seeing it manifest in a significant rise in
temp fails for some clients who haven't had any significant volume or
reputation changes and I'm seeing the Green/Yellow/Red status in SNDS
fluctuate significantly as well, along with inbox placement.

Good luck out there!

J

On Thu, Sep 12, 2019 at 3:23 PM Michael Wise via mailop 
wrote:

>
>
> I’m not in a position to comment …
>
>
>
> If anyone is still seeing issues, I’d strongly suggest opening a ticket:
>
>
>
>   http://go.microsoft.com/fwlink/?LinkID=614866
>
>   (Max CIDR range is a /24; if you have more, break them up.
> Sorry, it’s a requirement currently)
>
>
>
> More general information can be found here:
>
>
>
> https://sendersupport.olc.protection.outlook.com/pm/
>
>
>
> You should get a response from the Robot more or less immediately.
> If you don’t get either the first response, or a Mitigation decision,
> within 24 hours, I’d suggest opening another ticket just in case.
>
> After that robot Mitigation decision, if there are still issues, please
> reply to the decision email, and state your case.
> You will then be talking to a real human (won’t be me, sorry).
>
> I am not in a position to bypass the Suppport Funnel process described
> above; I don’t scale.
>
> If for some reason the process is not working currently, I may be able to
> bring issues to the attention of others, but cannot make promises on their
> behalf.
>
> As for the Abuse@ issues John is seeing, I’m poking around finding who
> best to address that.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* mailop  *On Behalf Of *Caitlin Brodie
> via mailop
> *Sent:* Thursday, September 12, 2019 2:05 PM
> *To:* mailop@mailop.org
> *Subject:* [mailop] Change at Microsoft on September 4th
>
>
>
> Hey Mailop,
>
>
>
> It sounds like a lot of senders saw issues with Microsoft on September
> 4th, and open rates dropped but then recovered the next day.
>
>
>
> We also saw issues starting on September 4th, but our IPs' reputation in
> SNDS hasn't recovered yet, and neither has our open rate to Microsoft
> domains.
>
>
>
> Has anyone else continued to see deliverability issues to Microsoft
> domains after September 4th? We're trying to gauge whether this is related
> to those more widespread problems or not.
>
>
>
> Thank you!
> ___
> 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] list submission

[John Stephenson via mailop]

Not one that works.   I tried to get a little crafty.  If you go to
https://www.optimum.net/support/livepage/chat you can start a chat with
support.  it asks for the phone number associated with your account, but
they don't verify that part.  Anyway, they'll document the issue--in my
case, they said they passed it on to the Engineering team and they'd call
me back within 48 hours.  They also gave me a ticket # which was helpful.
A week later, somebody called me and gave me a phone number ((800)
593-4614) I could call for any updates.  A few times, they told me that the
engineers fixed it and after that, Support said they couldn't get any
response from the engineers.  Then, I just stopped trying after that.

My problem was a purely transactional email stream sending from a dedicated
IP--it was being aggressively temp failed to the point where our MTA would
give up on delivery after about 20 hours.  Most of the traffic was password
resets for an account the intended recipients had with our client.  I
explained this in depth to Optimum Support and asked for any type of
escalation and they just said I could keep calling back the same phone
number and/or wait.  I ended up telling the client that when they get a
customer support inquiries about this form Optimum addresses, they should
advise their customers to get another email account.  Very last resort type
advice.

I wish you luck!

On Thu, Sep 12, 2019 at 11:44 AM anthony piccirillo via mailop <
mailop@mailop.org> wrote:

> Does anyone have a contact at Optimum|Optonline?
>
> KR,
>
> Anthony Piccirillo
> Selligent
> ___
> 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] SmartScreen weirdness

[John Stephenson]

Stefano, as all of our clients send off of dedicated IP pools, I see
this a lot.  As an example, we will send identical streams of mail
over 4 IPs, and 2 of them will be consistently in the inbox and
accepted on the first attempt, and 2 will experience bulk foldering
and/or excessive temp fails.  Repeated requests to escalate to have
these IPs reviewed doesn't seem to solve it.  Compounding this issue,
I've experienced issues where Support confirms they are moving ahead
with mitigation but we don't see anything change after that.  Repeat
cycle, same results.  This is, of course, only for clients that I
believe are worth advocacy.  It looks like something is stuck in their
system--this doesn't affect all clients, but those that it
affects...there doesn't seem to be an end.
On Thu, Aug 30, 2018 at 8:48 AM Stefano Bagnara  wrote:
>
> Hi all, or I should probably say Hi Michael, :-)
>
> I manage a pool of 5 IPs shared by the same group of senders (>100
> small senders).
> IPs are 188.165.188.85..188.165.188.89. (please no OVH-flames)
>
> They are low volume and they sends the same things (emails are
> roundrobin-ed between the IPs). They share the same reputation of
> public reputation providers (99 on senderscore, good on Talos). They
> haven't been blacklisted recently (AFAIK).
>
> One of those IPs is RED on SNDS (188.165.188.85) and in fact, emails
> sent by that IP to new email addresses ends up in the Junk folder. The
> other 4 IPs are GREEN and have always been GREEN and an email sent to
> a new recipient is sent to inbox. I say "new recipients" because if I
> send an email to an "old recipient" that is already reading that email
> flow the email is inboxed by both. It's hard to "debug" this from the
> outside because I need reports from "new users" or I'd have to create
> new hotmail accounts.
>
> In the last 2 months I received only 1 FBL for that IP, and a total of
> 12 FBL from the other 4 IPs (not daily, 3 in the whole 2 months). SNDS
> doesn't report a single spamtrap hit. The volume recorded by SNDS is
> between 500 and 1000 messages per day from each IP. Complaint Rate is
> "< 0.1%" Trap Hits is 0.
>
> I filled the Microsoft Form (SRX1437934126ID ). They told me it's
> because of "SmartScreen" and that they are unable to offer mitigation
> for that IP.
> The conversation included the "usual" template-based (telling me to
> use JMRP/SNDS) answers: got 4 of them until they stopped answering me
> begging for "details" or "escalation".
>
> I'd like to identify the issue (if there is a bad sender I'd like to
> simply kick him), but I don't have data to use to do my "homework". I
> also can't get why 1 IP is "so bad" while the other 4 in the same pool
> are pretty good, while they simply send the same stuff.
>
> I saw in past Microsoft IP based reputation have a very long memory,
> so I guess it must have something to do with very old sending history
> from that IP (I can't be sure if something bad happened years ago.. I
> don't think so, but I can't exclude it).
>
> I also don't understand what could be the reason behind the answer
> "the IP cannot be mitigated": is it because it is not blocked and
> mitigation happens for blocks that are not depending from SmartScreen?
> Or is it because they are actively seeing bad inbound flow from the IP
> and the reputation is "so bad" that they can't mitigate it?
>
> Michael, do you have an answer for this "scenario" or this specific case?
> Others: did anyone else see similar issues? How did you fix them?
>
> --
> Stefano Bagnara
> Apache James/jDKIM/jSPF
> VOXmail/Mosaico.io/VoidLabs
>
> ___
> 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] Problem with the new Microsoft's support form

[John Stephenson]

Same.  One lucky team member must have had the old website cached, but
now we are all only getting the new form.
On Tue, Jul 24, 2018 at 12:30 PM Thiago Rodrigues
 wrote:
>
> Hello Michael,
>
> For me its redirecting  for the newer version.
>
> Until yesterday, some people in the office could access the older version in 
> their PC (strange, maybe cache or something). Today everyone are redirected 
> to the new one.
>
> Best.
>
> Em ter, 24 de jul de 2018 às 16:12, Michael Wise  
> escreveu:
>>
>>
>>
>> Internally Escalated.
>>
>> I am told the older version of the form is still working?
>>
>>
>>
>>   https://go.microsoft.com/fwlink/?LinkID=614866
>>
>>
>>
>> Or is that just redirecting to the new form?
>>
>>
>>
>> Aloha,
>>
>> Michael.
>>
>> --
>>
>> Michael J Wise
>> Microsoft Corporation| Spam Analysis
>>
>> "Your Spam Specimen Has Been Processed."
>>
>> Got the Junk Mail Reporting Tool ?
>>
>>
>>
>> -Original Message-
>> From: mailop  On Behalf Of John Stephenson
>> Sent: Tuesday, July 24, 2018 10:26 AM
>> To: undersoft.c...@gmail.com
>> Cc: mailop 
>> Subject: Re: [mailop] Problem with the new Microsoft's support form
>>
>>
>>
>> We are seeing this (or not seeing this) behavior as well.  When a ticket is 
>> submitted to the new form, we don't receive anything back.
>>
>> No automated response nor any reply from Support.
>>
>> On Tue, Jul 24, 2018 at 10:17 AM Thiago Rodrigues  
>> wrote:
>>
>> >
>>
>> > Hello Guys,
>>
>> >
>>
>> > Anyone else not getting response from the outlook's support request
>>
>> > form
>>
>> > (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupp
>>
>> > ort.microsoft.com%2Fen-us%2Fsupportrequestform%2F8ad563e3-288e-2a61-81
>>
>> > 22-3ba03d6b8d75data=02%7C01%7Cmichael.wise%40microsoft.com%7C497d
>>
>> > abcb6669442b19a708d5f18b73ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
>>
>> > 0%7C636680503603788358sdata=aoeUycH%2Fowo0WFN51lnAHwO0hdu9n4wKr0x
>>
>> > J0uhlXIk%3Dreserved=0)
>>
>> >
>>
>> > We recently verify that this forward for a new page with a different form.
>>
>> >
>>
>> > However all request through this form don't generate the automated 
>> > response or receive any replies neither.
>>
>> >
>>
>> > Regards.
>>
>> >
>>
>> > --
>>
>> > Thiago Rodrigues
>>
>> > undersoft.c...@gmail.com
>>
>> >
>>
>> > ___
>>
>> > mailop mailing list
>>
>> > mailop@mailop.org
>>
>> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchill
>>
>> > i.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%7C0
>>
>> > 1%7Cmichael.wise%40microsoft.com%7C497dabcb6669442b19a708d5f18b73ca%7C
>>
>> > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636680503603788358sdat
>>
>> > a=fBdmg1sKOTl5L%2BLJg7W4aXwI2rJVpyMpi%2F70OhS9nd4%3Dreserved=0
>>
>>
>>
>> ___
>>
>> mailop mailing list
>>
>> mailop@mailop.org
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%7C01%7Cmichael.wise%40microsoft.com%7C497dabcb6669442b19a708d5f18b73ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636680503603788358sdata=fBdmg1sKOTl5L%2BLJg7W4aXwI2rJVpyMpi%2F70OhS9nd4%3Dreserved=0
>
>
>
> --
> Thiago Rodrigues
> undersoft.c...@gmail.com
> Mobile: (11)9333-5283
> Skype: thiago.rfr
>

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

Re: [mailop] Problem with the new Microsoft's support form

[John Stephenson]

We are seeing this (or not seeing this) behavior as well.  When a
ticket is submitted to the new form, we don't receive anything back.
No automated response nor any reply from Support.
On Tue, Jul 24, 2018 at 10:17 AM Thiago Rodrigues
 wrote:
>
> Hello Guys,
>
> Anyone else not getting response from the outlook's support request form 
> (https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75)
>
> We recently verify that this forward for a new page with a different form.
>
> However all request through this form don't generate the automated response 
> or receive any replies neither.
>
> Regards.
>
> --
> Thiago Rodrigues
> undersoft.c...@gmail.com
>
> ___
> 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] Gmail Internal mail delay Issues

[John Stephenson]

I am sorry, I missed the original examples.

That said, while I definitely believe that Gmail likely does not
intend to have any deliberate delays on inbound, but we have seen a
very consistent change in reception at Gmail over the past few months.
This has been consistent across our outbound infrastructures in
different locations and this has been identified by other networks
sending into Gmail as well.
On Thu, May 31, 2018 at 8:38 PM Brandon Long  wrote:
>
> His examples are outbound mail from Gmail.
>
> Pretty sure we have no deliberate delays on inbound mail, nor any limits on 
> allowed number of connections.  Any pushback is done with smtp response codes.
>
> Brandon
>
> On Thu, May 31, 2018, 11:32 AM John Stephenson  
> wrote:
>>
>> Yes.  I at least one other ESP has acknowledge to me that they are
>> seeing this.  I've also seen this change apparent in some gmail
>> headers which show the time to delivery.  It appears that Gmail
>> started to make this change in February.  We became aware of it in
>> April and things only seem to be getting worse in May.
>>
>> It looks like they have  slowed the acceptance messages they will
>> receive in a connection and they will refuse new connections from
>> being opened.  As this is pre-SMTP and we are using Momentum, we do
>> not see a temporary failed attempt--we just see delays in sending out.
>> This does not target any specific IP or IP group--this appears like a
>> universal speed limit.  This can result in significant delays--I'm not
>> sure if these effects are known or considered at Gmail.
>>
>> - J
>> On Thu, May 31, 2018 at 7:38 PM Jaren Angerbauer
>>  wrote:
>> >
>> > On Wed, May 30, 2018 at 10:53 AM, Paul Witting 
>> >  wrote:
>> >>
>> >> All,
>> >>
>> >>
>> >>
>> >> We’ve been getting complaints of slowness receiving mail and undelivered 
>> >> mail since last Saturday; all involve Gmail. Just checked on another one, 
>> >> submitted to Gmail at 5/29 11:28 PDT, but the next hop server didn’t get 
>> >> it until 5/30 02:10 PDT; our serer got it 3 seconds later. We’ve had 
>> >> another client’s delayed oer 24 hours, and we are pretty sure another 
>> >> timed out inside Gmail’s systems
>> >>
>> >>
>> >>
>> >> IS anyone else experiencing this?
>> >
>> >
>> >
>> >  Yes, seeing this as well.
>> >
>> > --Jaren
>> > ___
>> > 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

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

Re: [mailop] Gmail Internal mail delay Issues

[John Stephenson]

Yes.  I at least one other ESP has acknowledge to me that they are
seeing this.  I've also seen this change apparent in some gmail
headers which show the time to delivery.  It appears that Gmail
started to make this change in February.  We became aware of it in
April and things only seem to be getting worse in May.

It looks like they have  slowed the acceptance messages they will
receive in a connection and they will refuse new connections from
being opened.  As this is pre-SMTP and we are using Momentum, we do
not see a temporary failed attempt--we just see delays in sending out.
This does not target any specific IP or IP group--this appears like a
universal speed limit.  This can result in significant delays--I'm not
sure if these effects are known or considered at Gmail.

- J
On Thu, May 31, 2018 at 7:38 PM Jaren Angerbauer
 wrote:
>
> On Wed, May 30, 2018 at 10:53 AM, Paul Witting  
> wrote:
>>
>> All,
>>
>>
>>
>> We’ve been getting complaints of slowness receiving mail and undelivered 
>> mail since last Saturday; all involve Gmail. Just checked on another one, 
>> submitted to Gmail at 5/29 11:28 PDT, but the next hop server didn’t get it 
>> until 5/30 02:10 PDT; our serer got it 3 seconds later. We’ve had another 
>> client’s delayed oer 24 hours, and we are pretty sure another timed out 
>> inside Gmail’s systems
>>
>>
>>
>> IS anyone else experiencing this?
>
>
>
>  Yes, seeing this as well.
>
> --Jaren
> ___
> 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] SpamCannibal RBL

[John Stephenson]

I just checked spamcannibal.com and for me, I see the 'domain has expired'
message.  I didn't go to the website at first as I received a very scary
page from FortiGuard that the web page was blocked.  That still leaves us
unsure if the original owner wants to maintain this list, even if he has
the opportunity.
On Wed, May 30, 2018 at 7:17 AM Mark Foster  wrote:

> Doesn't ICANN policy require the domain to be put into a pending state and
> disabled in the DNS for a period of time before it's allowed to be resold?

> Here it is, grace period:

> https://www.icann.org/resources/pages/expired-2013-05-03-en

> Failure to work in the DNS is often the trigger for the owner 'hey, maybe
> i've forgotton to do something' response.

> If that'd happened I'd have expected the domain to stop working well
> before it could change ownership.  But have caught out registrars in the
> .com zone failing to get this right before, so nothing would surprise me.

> Mark.


> > The record was recently updated 15 years and 4 days after this domain
was
> > originally
> > created. My assumption is that this domain may have expired and the
> > current
> > owner purchased and re purposed this domain opportunistically. Other
> > blacklists have died this way.
> >
> >
> > Domain Name: SPAMCANNIBAL.ORG
> > Registry Domain ID: D98199203-LROR
> > Registrar WHOIS Server: whois.tucows.com
> > Registrar URL: http://tucowsdomains.com
> > Updated Date: 2018-05-30T03:16:26
> > Creation Date: 2003-05-26T19:20:39
> > Registrar Registration Expiration Date: 2018-05-26T19:20:39
> > Registrar: TUCOWS, INC.
> > Registrar IANA ID: 69
> > Domain Status: ok https://icann.org/epp#ok
> > Registry Registrant ID:
> > Registrant Name: Contact Privacy Inc. Customer 016557784
> > Registrant Organization: Contact Privacy Inc. Customer 016557784
> > Registrant Street: 96 Mowat Ave
> > Registrant City: Toronto
> > Registrant State/Province: ON
> > Registrant Postal Code: M6K 3M1
> > Registrant Country: CA
> > Registrant Phone: +1.4165385457
> > Registrant Phone Ext:
> > Registrant Fax:
> > Registrant Fax Ext:
> > Registrant Email: spamcannibal@contactprivacy.com
> > Registry Admin ID:
> > Admin Name: Contact Privacy Inc. Customer 016557784
> > Admin Organization: Contact Privacy Inc. Customer 016557784
> > Admin Street: 96 Mowat Ave
> > Admin City: Toronto
> > Admin State/Province: ON
> > Admin Postal Code: M6K 3M1
> > Admin Country: CA
> > Admin Phone: +1.4165385457
> > Admin Phone Ext:
> > Admin Fax:
> > Admin Fax Ext:
> > Admin Email: spamcannibal@contactprivacy.com
> > Registry Tech ID:
> > Tech Name: Contact Privacy Inc. Customer 016557784
> > Tech Organization: Contact Privacy Inc. Customer 016557784
> > Tech Street: 96 Mowat Ave
> > Tech City: Toronto
> > Tech State/Province: ON
> > Tech Postal Code: M6K 3M1
> > Tech Country: CA
> > Tech Phone: +1.4165385457
> > Tech Phone Ext:
> > Tech Fax:
> > Tech Fax Ext:
> > Tech Email: spamcannibal@contactprivacy.com
> > Name Server: ns1.renewyourname.net
> > Name Server: ns2.renewyourname.net
> > On Wed, May 30, 2018 at 6:47 AM Marc Bradshaw via mailop
> > 
> > wrote:
> >
> >> We received a bunch of noise from rbl checks against the
> >> spamcannibal.org
> > blacklist, the domain was briefly redirecting to an expired domain page,
> > and now redirects to some rather less reputable websites.
> >
> >> Does anyone have a contact, or know the status of this blacklist?
> >
> >> --> Marc Bradshaw - Deliverability/Abuse at FastMail
> >>  m...@fastmailteam.com | @marcbradshaw
> >
> >
> >> ___
> >> 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
> >

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

Re: [mailop] SpamCannibal RBL

[John Stephenson]

The record was recently updated 15 years and 4 days after this domain was
originally
created. My assumption is that this domain may have expired and the current
owner purchased and re purposed this domain opportunistically. Other
blacklists have died this way.


Domain Name: SPAMCANNIBAL.ORG
Registry Domain ID: D98199203-LROR
Registrar WHOIS Server: whois.tucows.com
Registrar URL: http://tucowsdomains.com
Updated Date: 2018-05-30T03:16:26
Creation Date: 2003-05-26T19:20:39
Registrar Registration Expiration Date: 2018-05-26T19:20:39
Registrar: TUCOWS, INC.
Registrar IANA ID: 69
Domain Status: ok https://icann.org/epp#ok
Registry Registrant ID:
Registrant Name: Contact Privacy Inc. Customer 016557784
Registrant Organization: Contact Privacy Inc. Customer 016557784
Registrant Street: 96 Mowat Ave
Registrant City: Toronto
Registrant State/Province: ON
Registrant Postal Code: M6K 3M1
Registrant Country: CA
Registrant Phone: +1.4165385457
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: spamcannibal@contactprivacy.com
Registry Admin ID:
Admin Name: Contact Privacy Inc. Customer 016557784
Admin Organization: Contact Privacy Inc. Customer 016557784
Admin Street: 96 Mowat Ave
Admin City: Toronto
Admin State/Province: ON
Admin Postal Code: M6K 3M1
Admin Country: CA
Admin Phone: +1.4165385457
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: spamcannibal@contactprivacy.com
Registry Tech ID:
Tech Name: Contact Privacy Inc. Customer 016557784
Tech Organization: Contact Privacy Inc. Customer 016557784
Tech Street: 96 Mowat Ave
Tech City: Toronto
Tech State/Province: ON
Tech Postal Code: M6K 3M1
Tech Country: CA
Tech Phone: +1.4165385457
Tech Phone Ext:
Tech Fax:
Tech Fax Ext:
Tech Email: spamcannibal@contactprivacy.com
Name Server: ns1.renewyourname.net
Name Server: ns2.renewyourname.net
On Wed, May 30, 2018 at 6:47 AM Marc Bradshaw via mailop 
wrote:

> We received a bunch of noise from rbl checks against the spamcannibal.org
blacklist, the domain was briefly redirecting to an expired domain page,
and now redirects to some rather less reputable websites.

> Does anyone have a contact, or know the status of this blacklist?

> --> Marc Bradshaw - Deliverability/Abuse at FastMail
>  m...@fastmailteam.com | @marcbradshaw


> ___
> 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] Hotmail SNDS page down?

[John Stephenson]

I'm seeing the exact same thing on Safari on a Mac and on Chrome on a PC
running Windows 10.  I am able to use the same credentials to login to
Hotmail.com, but if I switch to the SNDS page, it keeps doing a number of
redirects, then I get the verbiage Al posted.

Best,

John


On Wed, Apr 25, 2018 at 6:16 PM, Al Iverson  wrote:

> Hi Krishna,
>
> Still not able to access from here.
>
> Using Safari on Mac (which I have used to access SNDS just fine before
> this issue), I now get stuck in loop pinging between URLs and then it spits
> out this error:
> Sign in
> Something went wrong and we can't sign you in right now. Please try again
> later.
> The Microsoft account login server has detected too many repeated
> authentication attempts. Please wait a moment and try again.
>
> Perhaps it's a browser issue but I figured I would pass this along since
> it was what was happening to me earlier today as well.
>
> Cheers,
> Al Iverson
>
> On Wed, Apr 25, 2018 at 7:42 PM, Krishna Garewal via mailop <
> mailop@mailop.org> wrote:
>
>> Should all be working again, please let us know if you see any issues.
>>
>>
>>
>> *From:* mailop  *On Behalf Of *Michael Wise
>> via mailop
>> *Sent:* Wednesday, April 25, 2018 12:37 PM
>> *To:* John Possidente ; Mohammed Ahmed <
>> mohamm...@aweber.com>
>> *Cc:* mailop 
>>
>> *Subject:* Re: [mailop] Hotmail SNDS page down?
>>
>>
>>
>>
>>
>> People are being poked, the issue is being worked. ☹
>>
>>
>>
>> Aloha,
>>
>> Michael.
>>
>> --
>>
>> *Michael J Wise*
>> Microsoft Corporation| Spam Analysis
>>
>> "Your Spam Specimen Has Been Processed."
>>
>> Got the Junk Mail Reporting Tool
>> 
>> ?
>>
>>
>>
>> *From:* John Possidente 
>> *Sent:* Wednesday, April 25, 2018 7:28 AM
>> *To:* Mohammed Ahmed 
>> *Cc:* mailop ; Michael Wise <
>> michael.w...@microsoft.com>
>> *Subject:* Re: [mailop] Hotmail SNDS page down?
>>
>>
>>
>> The CAPTCHA on the support page seems to be broken as well.
>>
>>
>>
>> On Wed, Apr 25, 2018 at 9:54 AM, Mohammed Ahmed 
>> wrote:
>>
>> Hello Michael,
>>
>>
>>
>> Looks like we are getting 503 error when trying to access SNDS data.
>> Just wanted to give you heads up.
>>
>>
>>
>>
>>
>> Thanks,
>>
>>
>>
>> --
>>
>>
>> Mohammed Ahmed
>>
>> Director, Deliverability
>>
>>
>>
>>
>> ___
>> 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
>>
>>
>
>
> --
> al iverson // wombatmail // miami
> http://www.aliverson.com
> http://www.spamresource.com
>
> ___
> 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] btinternet.com blacklist

[John Stephenson]

I hope nobody gets hurt in this massive and sudden effort to dog pile on
top of Dom for assuming that being a good sender was enough to avoid being
blocked.  It was naive given the realities of the internet, but let's not
pretend we're all above being trapped in our own perspectives.

On Tue, Jul 11, 2017 at 3:39 PM, Larry M. Smith 
wrote:

> Dom Latter wrote:
> (snip)
> > But it shouldn't matter.  We are not spammers.  [...]
>
> .. And btinternet.com is supposed to automatically know this?  How?
>
> --
> SgtChains
>
> ___
> 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] Invaluement ivmURI contact/hints

[John Stephenson]

>
> Turned out the customer you identified offlist is one of the few customers
> sending B2B email outside of italy and this is the field where we have more
> difficulties in doing antispam because we don't have feedbacks (no FBL
> because there are no hotmail/yahoo/gmail) and most time we don't even
> receive manual complaints. So we only have some
> openrate/clickrate/bouncerate/unsubrate to look at and they sometimes are
> not so bad (sometimes spammers are good at choosing their recipients).
> That's why I always try to get some indicators on who is the sender of the
> email when I found this kind of blocks.
>

I've had some success in looking at just click actions to evaluate sender
quality.  This helps level the playing field (somewhat) when comparing
senders against each other.  I look the sum of complaints and unsubscribes
divided by the sum of complaints, unsubscribes and clicks through on
content--this gives you a ratio of people that are specifically
disinterested in the content.  Looking just at clicks avoids a number of
skews as this just measures people taking direct action on the message.  An
open is sometimes a passive aciton and is skewed when mail is delivered to
spam folder.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft spam folder issue (Forefront?) for a specific IP

[John Stephenson]

I've only recieved templated, non-responsive responses from Microsoft's
ticketing system over the past two months.  Replying with additional detail
and requesting escalation does not appear to be effective.

On Wed, Apr 26, 2017 at 12:27 PM, Stefano Bagnara  wrote:

> Hi all,
>
> I have an issue with email *delivered* but to the *spam folder* to
> Microsoft (both Hotmail/Outlook.com and Office365/Exchange online
> platforms).
>
> I already used the form (Microsoft ticket is SRX1383552039ID) but I keep
> receiving human but "standard" responses asking me the SMTP error (even if
> I start telling them the email is delivered to their spam folder and I also
> attach full message headers) or telling me to use SNDS and JMRP (that I
> already use).
>
> I send the very same email from 2 completely different IPs, one IP deliver
> it correctly, the other, instead, ends up in the spam folder.
>
> Microsoft replied that the IP is not listed/blocked in any way from them
> but they didn't provide any hint why one IP is able to deliver it in inbox
> while the other is not able to do that (they both delivered to inbox in
> past).
>
> The IPs are transactional, have less than 500 messages per day (to
> microsoft) and are "Green" and with no complaint and no spam traps in the
> last 90 days in the SNDS report. SNDS in "IP Status" says "All of the
> specified IPs have normal status."
>
> I see the one delivered to inbox have the following headers added by
> microsoft:
>
>> SpamDiagnosticOutput: 1*:5*
>> SpamDiagnosticMetadata: Default*:2*
>> X-Microsoft-Antispam-Mailbox-Delivery:
>>   abwl:0;wl:0;pcwl:0;kl:0;iwl:0;ijl:0;dwl:0;dkl:0;rwl:0;ex:0;auth:1;
>> *dest:I*;WIMS-SenderIP:213.XXX.189.13;WIMS-SPF:app%2ered
>> acted%2eit;WIMS-DKIM:gmail%2ecom;WIMS-822:redacted2%
>> 40gmail%2ecom;WIMS-PRA:sender%2bredacted2%2eredacted%2eit%40app%2e
>> redacted%2eit;WIMS-AUTH:PASS;ENG:(5061607094)(102400140);
>
>
> While the one being classified as spam has this header:
>
>> SpamDiagnosticOutput: 1:*22*
>> SpamDiagnosticMetadata: *Default*
>> X-Microsoft-Antispam-Mailbox-Delivery:
>>   abwl:0;wl:0;pcwl:0;kl:0;iwl:0;ijl:0;dwl:0;dkl:0;rwl:0;ex:0;auth:1;
>> *dest:J*;WIMS-SenderIP:*188.XXX.188.64*;WIMS-SPF:app%2eredacted
>> %2eit;WIMS-DKIM:gmail%2ecom;WIMS-822:redacted2%
>> 40gmail%2ecom;WIMS-PRA:sender%2bredacted2%2eredacted%2eit%40app%2e
>> redacted%2eit;WIMS-AUTH:PASS;ENG:(5061607094)(102400140)
>> *(102420017);RF:JunkEmail;OFR:SpamFilterAuthJ;*
>
>
> On office365 I see
>
> X-Forefront-Antispam-Report: IP:213.XXX.189.13;IPV:NLI;CTRY:IT;EFV:NLI;
>> *SFV:NSPM*;SFS:(8196002)(3158022)(300031)(106034)(
>> 438002)(596005)(286005)(189002)(199003)(47976999)(429011)(54356999)(
>> 43066003)(7636002)(50986999)(2501003)(400107014)(
>> 356003)(110446001)(85226003)(146002)(19627405001)(966004)(
>> 19618635001)(106466001)(1096003)(7846003)(74482002)(
>> 84326002)(125075)(606005)(7906003)(53416004)(6486002)(
>> 118246002)(7596002)(6392003)(733005)(42882006)(6916009)(
>> 7066003)(6506006)(34003)(564073)(1981051)(
>> 33646002)(9686003)(345071)(53346004)(173073)(
>> 25786009)(8676002)(6306002)(236005)(500011)(110136004)
>> (6512007)(2351001)(54896002)(956001)(50919006);DIR:INB;SFP:;*SCL:1*
>> ;SRVR:DB6P193MB0232;H:ms13.redacted.it;FPR:;SPF:Pass;
>> MLV:nov;MX:1;A:1;PTR:ms13.redacted.it;LANG:it;
>
>
> vs
>
> X-Forefront-Antispam-Report: CIP:188.XXX.188.64;IPV:NLI;CTRY:IT;EFV:NLI;
>> *SFV:SPM*;SFS:(8046002)(3158022)(106034)(300031)(
>> 438002)(286005)(596005)(189002)(199003)(125075)(
>> 429011)(7066003)(43066003)(53346004)(606005)(42882006)(
>> 1981051)(6916009)(956001)(500011)(110136004)(
>> 6506006)(236005)(6306002)(146002)(733005)(564073)(
>> 6512007)(54896002)(9686003)(356003)(966004)(8676002)(
>> 7596002)(32003)(7906003)(1096003)(173073)(6392003)(
>> 50986999)(7846003)(54356999)(400107014)(7636002)(
>> 6486002)(110446001)(74482002)(2501003)(345071)(25786009)
>> (84326002)(33646002)(47976999)(53416004)(85226003)(2351001)(
>> 106466001)(19627405001)(118246002)(50919006)(69026009);DIR:INB;SFP:;
>> *SCL:5*;SRVR:AM5P193MB0225;H:mx64.redacted.it;FPR:;SPF:Pass;MLV:nov;MX:1;
>> A:1;PTR:mx64.redacted.it;*CAT:SPM*;LANG:it;
>>
>
> Both IP are used since more than an year, with almost constant volume and
> the first IP was working "fine" until a couple of days ago.
>
> From the 2 couple of headers I guess the problem is the IP itself but
> Microsoft support simply told me something like they "don't see anything
> 'offhand' that would prefent email from my IP from reaching their
> customers" or "per their research, my IP is currently not under any active
> block lists from their end".
>
> Both IP are listed in RFC-Clueless because the reverse domain has its own
> email hosted on GSuite  and RFC clueless list all of them (but they are
> both listed).
>
> The only public blocklist where the first IP is listed while the second is
> not listed is webiron and specifically