[mailop] Terminally BAD in Google Postmaster Tools - A Tale of Woe and Cry for Help

[Brian Sullivan via mailop]

Hi mailop community,

I work in deliverability for a prominent ESP and am struggling with terminally 
bad Gmail IP & domain reputation, along with almost 100% spam placement for a 
particular sender going back many months.

My most recent submission to Gmail's bulk sender support portal:

=

Detailed description of your issue *

This sender has been sending only recent engagers (opened or clicked in the 
past 15 days) for a long period in an effort to regain inbox placement at 
Gmail. After several months no improvement has been seen. The sender will now 
expand audience targeting to 0-60 day engagers in an attempt to reduce 
complaint rates that might be causing IP and domain reputation to remain 'Bad' 
in Postmaster Tools. Please consider mitigating spam filtering for this sender 
so that their reputation can reset.



For context, this sender ceased high volume promotional batch mailing in 
mid-2020. At that time, engagement at Gmail increased ~3x and remained at that 
level during a ~3-month period. High volume batch mailings then resumed causing 
volume to increase exponentially and engagement rates to fall back to 
previously lower levels. All mail routed to the inbox before this transitional 
period, and all has routed to Gmail's spam folder since high volume batch 
mailings resumed despite super-tight audience engagement filtering.
=

I'm appealing to the list here in hopes of getting actionable input towards a 
resolution. Heartfelt commiserations are welcome, but practical, actionable 
advice is preferred.

'Brian
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] trust.prod.hygiene.egress.cloud connections

[J Doe via mailop]

On 2021-09-09 8:25 p.m., Jarland Donnell via mailop wrote:

I'm not seeing any from 51.11.6.150 or any mention of egress.cloud in my
recent logs. I do seem to recall that at least at some point, right 
after they purchased it from the original dev, the Outlook mobile app 
did make the connections to the mail servers from their own IP space. 
But I'd expect to have those ranges all throughout my logs.


On 2021-09-09 18:30, J Doe via mailop wrote:

Hi,

Has anyone encountered the following host connecting to their
submission service:

Sep  1 17:19:52 server postfix/smtpd[1158]: Anonymous TLS connection
established from trust.prod.hygiene.egress.cloud[51.11.6.150]:14208:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

A quick WHOIS shows it goes back to a Microsoft IP.  I can't say for
certain, and it might be coincidental, but I seem to remember it
connecting roughly around the same time I setup up Outlook on Android
for a user.

Thanks,

- J


Hi Jarland,

Thanks for your feedback.  Ok, at least at this point it appears to be 
non-malicious, so I won't worry too much about it.  Some IP reputation 
sites had indicated a possibility of maliciousness, but I haven't seen 
it attempt anything (not to mention that some reputation sites are 
better than others).


- J
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] trust.prod.hygiene.egress.cloud connections

[J Doe via mailop]

On 2021-09-09 8:10 p.m., Graeme Slogrove via mailop wrote:


Yes, we see it regularly.

Would not surprise me that it pings/test the users domain endpoint when setting 
up outlook on mobile client and confirming the details.

-Original Message-
From: mailop  On Behalf Of J Doe via mailop
Sent: Friday, 10 September 2021 11:30 AM
To: mailop@mailop.org
Subject: [mailop] trust.prod.hygiene.egress.cloud connections

Hi,

Has anyone encountered the following host connecting to their submission
service:

Sep  1 17:19:52 server postfix/smtpd[1158]: Anonymous TLS connection 
established from trust.prod.hygiene.egress.cloud[51.11.6.150]:14208:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

A quick WHOIS shows it goes back to a Microsoft IP.  I can't say for certain, 
and it might be coincidental, but I seem to remember it connecting roughly 
around the same time I setup up Outlook on Android for a user.

Thanks,

- J


Hi,

Interesting.  What's somewhat strange is that it's been doing this for a 
number of months, now.  The user in question has purchased an iPhone and 
no longer uses the Android device that Outlook was set up on.


Are people seeing that it is "pinging" for long periods of time (ie: 
months after setup/configuration) ?


Thanks,

- J
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] trust.prod.hygiene.egress.cloud connections

[Jarland Donnell via mailop]

I'm not seeing any from 51.11.6.150 or any mention of egress.cloud in my 
recent logs. I do seem to recall that at least at some point, right 
after they purchased it from the original dev, the Outlook mobile app 
did make the connections to the mail servers from their own IP space. 
But I'd expect to have those ranges all throughout my logs.


On 2021-09-09 18:30, J Doe via mailop wrote:

Hi,

Has anyone encountered the following host connecting to their
submission service:

Sep  1 17:19:52 server postfix/smtpd[1158]: Anonymous TLS connection
established from trust.prod.hygiene.egress.cloud[51.11.6.150]:14208:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

A quick WHOIS shows it goes back to a Microsoft IP.  I can't say for
certain, and it might be coincidental, but I seem to remember it
connecting roughly around the same time I setup up Outlook on Android
for a user.

Thanks,

- J
___
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] trust.prod.hygiene.egress.cloud connections

[Graeme Slogrove via mailop]

Yes, we see it regularly.

Would not surprise me that it pings/test the users domain endpoint when setting 
up outlook on mobile client and confirming the details.

-Original Message-
From: mailop  On Behalf Of J Doe via mailop
Sent: Friday, 10 September 2021 11:30 AM
To: mailop@mailop.org
Subject: [mailop] trust.prod.hygiene.egress.cloud connections


-
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
-

Hi,

Has anyone encountered the following host connecting to their submission
service:

Sep  1 17:19:52 server postfix/smtpd[1158]: Anonymous TLS connection 
established from trust.prod.hygiene.egress.cloud[51.11.6.150]:14208:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

A quick WHOIS shows it goes back to a Microsoft IP.  I can't say for certain, 
and it might be coincidental, but I seem to remember it connecting roughly 
around the same time I setup up Outlook on Android for a user.

Thanks,

- J
Email secured by Trustwave advanced threat protection. Learn more at 
https://trus.tw/mailmarshal
This transmission may contain information that is privileged, confidential, 
and/or exempt from disclosure under applicable law. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or use of the information contained herein (including any reliance thereon) is 
STRICTLY PROHIBITED. If you received this transmission in error, please 
immediately contact the sender and destroy the material in its entirety, 
whether in electronic or hard copy format.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] trust.prod.hygiene.egress.cloud connections

[J Doe via mailop]

Hi,

Has anyone encountered the following host connecting to their submission 
service:


Sep  1 17:19:52 server postfix/smtpd[1158]: Anonymous TLS connection 
established from trust.prod.hygiene.egress.cloud[51.11.6.150]:14208: 
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)


A quick WHOIS shows it goes back to a Microsoft IP.  I can't say for 
certain, and it might be coincidental, but I seem to remember it 
connecting roughly around the same time I setup up Outlook on Android 
for a user.


Thanks,

- J
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google and IPv6, was Recommendation for inbox provider?

[Brandon Long via mailop]

On Thu, Sep 9, 2021 at 2:18 AM Slavko via mailop  wrote:

> Hi,
>
> Dňa 8. 9. o 22:44 Brandon Long via mailop napísal(a):
> > Hmm, blocking connections is highly unusual for us, as it doesn't provide
> > any feedback, usually we respond with a 5xx banner or to HELO.  I would
> > check to see if you can reach www.google.com on IPv6 from the same box,
> and
> > if you can, then go ahead and send me your IPv6 address and I can
> escalate
> > that.
>
> I can ping it from that box:
>
> ping -ac2 2a00:1450:400c:c07::1b
> PING 2a00:1450:400c:c07::1b(2a00:1450:400c:c07::1b) 56 data bytes
> 64 bytes from 2a00:1450:400c:c07::1b: icmp_seq=1 ttl=107 time=32.9 ms
> 64 bytes from 2a00:1450:400c:c07::1b: icmp_seq=2 ttl=107 time=31.7 ms
>
> --- 2a00:1450:400c:c07::1b ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 31.702/32.297/32.892/0.595 ms
>
> It is a LXC container with limited software, but here is nmap output
> from its physical host:
>
> nmap -6p 25 2a00:1450:400c:c07::1b
> Starting Nmap 7.70 ( https://nmap.org ) at 2021-09-09 10:44 CEST
> Nmap scan report for wo-in-f27.1e100.net (2a00:1450:400c:c07::1b)
> Host is up (0.029s latency).
>
> PORT   STATESERVICE
> 25/tcp filtered smtp
>
> Nmap done: 1 IP address (1 host up) scanned in 2.57 seconds
>
> > Unusual means it's almost always a manual step taken in response to a
> spam
> > or other bad acting campaign of extremely large magnitude... but
> sometimes
> > those types of blocks can linger.
>
> Here is wery low traffic out from my MTA, and only small amount of this
> outbound mails are going to gmail (<10/week), thus it cannot be massive
> in any mean ;-)
>
> I use HE IPv6 tunnel, with /48 net, from which i use only one /64 block
> yet, thus even all neighbors are under my control. I have even working
> PTR for IPv6. I didn't noticed any unusual outbound traffic from my net.
> Delivery via IPv4 works without any problems, thus for now i enabled
> ipv4_prefer in my MTA.
>

These types of blocks would likely be a larger subnet than that.

I can't do any investigation without knowing your IP address or net.

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

Re: [mailop] No one is "too big" anymore

[Jarland Donnell via mailop]

Please feel free! I love being able to share my work.

On 2021-09-09 09:51, Brielle via mailop wrote:

On 9/9/21 1:30 AM, Jarland Donnell via mailop wrote:


Domains taken from the envelope senders of a recent round:
https://github.com/mxroute/rspamd_rules/commit/3b136e8812c74f35a32e61c8ad21f1f176c5b32d#diff-17eafba14786093de653e1da1991e0677cd7798c2ac277f196ab0eb09f24fc49


Ohhh, nice.  rspamd maps!  I hope you don't mind, integrated this into 
my setup.


I do have my own rspamd maps available here in case anyone might find
them useful.  Ever since retiring the AHBL dnsbl/rhsbl lists, I've
been working on some more interesting replacement data sets, and the
rspamd maps happen to be one of them.

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

Re: [mailop] mailop Digest, Vol 14, Issue 19

[Len Shneyder via mailop]

Hi Jarland,

I work at Twilio and come from the SendGrid side. I understand the
frustration and we feel it too because we don't host any pages, newsletter
subscriptions or other similar mechanisms for our customers. On the
contrary we try and get our customers to implement Captcha on their forms
and pages to avoid exactly what you describe. If you want to message me off
list and let me know what you're seeing, share a header, our team will
absolutely investigate what's happening here.

Thanks!
-L


Len Shneyder
VP Industry Relations
[image: Twilio] 
EMAIL l...@twilio.com
TWITTER @LenShneyder 



>
>
> --
>
> Message: 2
> Date: Thu, 9 Sep 2021 10:38:44 +0200
> From: Simon Bressier 
> To: jarl...@mxroute.com
> Cc: mailop 
> Subject: Re: [mailop] No one is "too big" anymore
> Message-ID:
> <
> cadsxy6jq0g5odsvjeitd2o6fbmoxengmwmnef-e8mmcp_zn...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Jarland,
>
> I'm working at Sendinblue, I'm interested actually in knowing more
> about the behavior you are reporting here.
>
> If I understand properly, you are talking about one address for
> example, that is being added to multiple lists on many of our
> customers by posting automatically that email address on unprotected
> newsletter registration forms on our customer's websites ?
>
> Not an easy one to detect here, if you confirm the behavior, we'll see
> if/how we could detect that.
>
> Thanks !
>
>
> Le jeu. 9 sept. 2021 à 09:39, Jarland Donnell via mailop
>  a écrit :
> >
> > Recently a provider, well...criminal, who goes by the name ByteFend has
> > been performing a massive attack against my customers. They've asked for
> > my help, and I've offered it. In the process, I've found that I can no
> > longer consider companies to be "too big to block" after allowing
> > themselves to be used in these attacks. I thought you all might like to
> > share some of the data I've come across along the way.
> >
> > Domains taken from the envelope senders of a recent round:
> >
> https://urldefense.com/v3/__https://github.com/mxroute/rspamd_rules/commit/3b136e8812c74f35a32e61c8ad21f1f176c5b32d*diff-17eafba14786093de653e1da1991e0677cd7798c2ac277f196ab0eb09f24fc49__;Iw!!NCc8flgU!KtUNCCCZL_orHVQRJgbQS9oIpOiO3jW-vpqbqvqxcxMvgIP6IJFeM-kKkes$
> >
> > Most recent round of IPs:
> >
> https://urldefense.com/v3/__https://clbin.com/wL7e3__;!!NCc8flgU!KtUNCCCZL_orHVQRJgbQS9oIpOiO3jW-vpqbqvqxcxMvgIP6IJFeGqqbbM0$
> >
> > The attacker focuses on non double opt in newsletters that allow anyone
> > to sign up without a captcha, and allow themselves to be flooded with
> > requests. This of course fills their inbox with junk, and acts as the
> > wonderful old DDOS attack for email.
> >
> > Among these are Sendgrid, Mailgun, Sendinblue, Yahoo, Yandex, iCloud,
> > Orange, Google, Microsoft, the list goes on. It's time to start holding
> > accountable these companies by devaluing their products until their
> > customers begin holding them accountable. I'll fire the first shot.
> > ___
> > mailop mailing list
> > mailop@mailop.org
> >
> https://urldefense.com/v3/__https://list.mailop.org/listinfo/mailop__;!!NCc8flgU!KtUNCCCZL_orHVQRJgbQS9oIpOiO3jW-vpqbqvqxcxMvgIP6IJFe4Z11qcw$
>
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] No one is "too big" anymore

[Michael Peddemors via mailop]

Shameless plug..

Need a replacement data set?


https://www.intra2net.com/en/support/antispam/index.php_sort=accuracy_order=desc.html

SpamRats!

On 2021-09-09 7:51 a.m., Brielle via mailop wrote:

On 9/9/21 1:30 AM, Jarland Donnell via mailop wrote:


Domains taken from the envelope senders of a recent round:
https://github.com/mxroute/rspamd_rules/commit/3b136e8812c74f35a32e61c8ad21f1f176c5b32d#diff-17eafba14786093de653e1da1991e0677cd7798c2ac277f196ab0eb09f24fc49 



Ohhh, nice.  rspamd maps!  I hope you don't mind, integrated this into 
my setup.


I do have my own rspamd maps available here in case anyone might find 
them useful.  Ever since retiring the AHBL dnsbl/rhsbl lists, I've been 
working on some more interesting replacement data sets, and the rspamd 
maps happen to be one of them.






--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Any one else seeing SenderScore going crazy?

[Michael Peddemors via mailop]

Seems to be trying to send some kind of backlog.. (flood of reports)

Not only are the messages NOT SPAM, but we don't even host the domains 
in question any more ;)  But again, something is wrong with the way they 
do business.. Dec 2019? Really?


This is a OpenSRS Abuse Report for an email message received from domain 
, IP 104.128.152.139, on Fri, 06 Dec 2019 00:39:35 +.



Subscription-Link: https://fbl.returnpath.net/manage/subscriptions/498775
User-Agent: ReturnPathFBL/2.0
Original-Rcpt-To: 
Source-Ip: 104.128.152.139
Abuse-Type: complaint
Reported-Domain: 


--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] No one is "too big" anymore

[Simon Bressier via mailop]

Hi Jarland,

I'm working at Sendinblue, I'm interested actually in knowing more
about the behavior you are reporting here.

If I understand properly, you are talking about one address for
example, that is being added to multiple lists on many of our
customers by posting automatically that email address on unprotected
newsletter registration forms on our customer's websites ?

Not an easy one to detect here, if you confirm the behavior, we'll see
if/how we could detect that.

Thanks !


Le jeu. 9 sept. 2021 à 09:39, Jarland Donnell via mailop
 a écrit :
>
> Recently a provider, well...criminal, who goes by the name ByteFend has
> been performing a massive attack against my customers. They've asked for
> my help, and I've offered it. In the process, I've found that I can no
> longer consider companies to be "too big to block" after allowing
> themselves to be used in these attacks. I thought you all might like to
> share some of the data I've come across along the way.
>
> Domains taken from the envelope senders of a recent round:
> https://github.com/mxroute/rspamd_rules/commit/3b136e8812c74f35a32e61c8ad21f1f176c5b32d#diff-17eafba14786093de653e1da1991e0677cd7798c2ac277f196ab0eb09f24fc49
>
> Most recent round of IPs:
> https://clbin.com/wL7e3
>
> The attacker focuses on non double opt in newsletters that allow anyone
> to sign up without a captcha, and allow themselves to be flooded with
> requests. This of course fills their inbox with junk, and acts as the
> wonderful old DDOS attack for email.
>
> Among these are Sendgrid, Mailgun, Sendinblue, Yahoo, Yandex, iCloud,
> Orange, Google, Microsoft, the list goes on. It's time to start holding
> accountable these companies by devaluing their products until their
> customers begin holding them accountable. I'll fire the first shot.
> ___
> 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] No one is "too big" anymore

[Brielle via mailop]

On 9/9/21 1:30 AM, Jarland Donnell via mailop wrote:


Domains taken from the envelope senders of a recent round:
https://github.com/mxroute/rspamd_rules/commit/3b136e8812c74f35a32e61c8ad21f1f176c5b32d#diff-17eafba14786093de653e1da1991e0677cd7798c2ac277f196ab0eb09f24fc49


Ohhh, nice.  rspamd maps!  I hope you don't mind, integrated this into 
my setup.


I do have my own rspamd maps available here in case anyone might find 
them useful.  Ever since retiring the AHBL dnsbl/rhsbl lists, I've been 
working on some more interesting replacement data sets, and the rspamd 
maps happen to be one of them.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Not receiving Yahoo Complaint Feedback Loop

[Lili Crowley via mailop]

Please contact me off list.
thanks

Lili Crowley

she/her
Postmaster





On Thu, Sep 9, 2021 at 10:04 AM Serizy via mailop  wrote:

> Hello, I would like to post a problem we are having regarding Yahoo CFL.
>
> We started several email programs on July and to be ready we did setup
> sending domains under Yahoo Complaint Feedback Loop here:
>
> Yahoo! Help - Submit a Form
> 
>
> We received confirmation code, and after that, a thank you page showed
> process was completed:
>
> *"Thank you! *
> *We've received your email.Your request will be processed within 48 hours.
> If there are no issues with the data provided, you will start receiving CFL
> reports at the reporting address provided. If you do not receive the
> reports or need to make changes in the future, contact Customer Care."*
>
> We did this for several different domains and sub-domains, but nothing was
> received after three weeks of sending...nothingwe tried then to update
> information again, but no complaints have ever been received. We are
> increasing volume and I assume now we should receive at least some feedback
> regarding complaints...but nothing. And no way of checking CFL setup.
>
> We tried to contact Yahoo postmaster support, but no answer yet.
>
> Anybody here has any clue of what might be happening? Is CFL having a
> downtime or something similar? Any hint? Maybe someone at Yahoo postmaster
> team reads this and can throw some light on the problem.
>
>
> Thanks in advance.
> Best regards.
>
>
> David
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__list.mailop.org_listinfo_mailop&d=DwIGaQ&c=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY&r=VCg-Q9ZdQlK27bNQMmErgRlkvpS8hDriASSkCoU3s2s&m=VHNyyknlHI8KnfPLeb-gjAkGigdxSfJ4nO-7TG8IQ40&s=FaI6waE8YaSSeLio2fK0_gtOwx22uHGNKoQ9mxH--30&e=
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Not receiving Yahoo Complaint Feedback Loop

[Serizy via mailop]

Hello, I would like to post a problem we are having regarding Yahoo CFL.

We started several email programs on July and to be ready we did setup sending 
domains under Yahoo Complaint Feedback Loop here:

Yahoo! Help - Submit a 
Form

We received confirmation code, and after that, a thank you page showed process 
was completed:

"Thank you!
We've received your email.Your request will be processed within 48 hours. If 
there are no issues with the data provided, you will start receiving CFL 
reports at the reporting address provided. If you do not receive the reports or 
need to make changes in the future, contact Customer Care."

We did this for several different domains and sub-domains, but nothing was 
received after three weeks of sending...nothingwe tried then to update 
information again, but no complaints have ever been received. We are increasing 
volume and I assume now we should receive at least some feedback regarding 
complaints...but nothing. And no way of checking CFL setup.

We tried to contact Yahoo postmaster support, but no answer yet.

Anybody here has any clue of what might be happening? Is CFL having a downtime 
or something similar? Any hint? Maybe someone at Yahoo postmaster team reads 
this and can throw some light on the problem.


Thanks in advance.
Best regards.


David



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

Re: [mailop] No one is "too big" anymore

[Damon via mailop]

I have found that Clickbank is unwittingly(?) causing an issue with
their abandon cart process.

One just needs to fill in the email address or just click a link that
has the address auto-filled- That's it. Don't have to hit submit or
anything. That address is added to the abandoned cart funnel.
As far as I can tell, there are zero anti-abuse functions in this process.

-Damon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] 421 error when sending to Yahoo accounts

[Laura Atkins via mailop]

There’s a contact pathway on the postmaster site you linked to: 
https://postmaster.verizonmedia.com/sender-request 
. Filling that out may get 
a response. 

With that being said, it is very likely that your mail is being blocked due to 
user complaints. Has there been a change in volume of mail recently? Sometimes 
these blocks are against content in the mail as well. Domains and URLs inside 
the message develop their own reputation and Yahoo will block mail if it 
mentions domains that are generating complaints. 

Given you’re a hosting company, I’d suggest ensuring the customer using that 
box isn’t spamming. I’d also do a security sweep on that box to make sure it’s 
not infected. Finally, I’d really look at improving my rDNS for outbound 
mailservers. The rDNS on that IP screams “I’m part of a snowshoe network” to 
me. 

laura 


> On 8 Sep 2021, at 23:18, Andre M via mailop  wrote:
> 
> Hello,
> 
> We've been seeing an issue with Yahoo blocking mail coming from one of our 
> domains 'bridgecatalog.com' since yesterday:
> 
> Remote Server returned: '421 4.7.0 [TSS04] Messages from 74.114.207.182
> temporarily deferred due to unexpected volume or user complaints - 4.16.55.1;
> see https://postmaster.verizonmedia.com/error-codes' 
> 
> This is a pretty large group that is RFC and CAN-SPAM compliant as far as we 
> know. I've also ran through and verified that DMARC, SPF and DKIM records are 
> all in place and functioning properly as far as MXToolbox is concerned. Is 
> this something we should just wait out as they recommend, or is there anymore 
> we can do to help   expedite this process?
> 
> Thanks,
> Andre
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

Re: [mailop] No one is "too big" anymore

[Simon Bressier via mailop]

Thank you Joshua, you got a spike today from more than 100 of our
clients with 1 to 5
mails each, always emails sent through SMTP relay, I'll check if we
can do something to prevent flood to a single address from forms. Not
an easy task and that can lead to a lot of false positives.

That's actually where it would be so helpful
https://www.m3aawg.org/rel-WebFormHeader , but as far I've seen, there
is no adoption on CMS side or framework side, that would help a lot to
identify such bad activities on forms bombing.


Le jeu. 9 sept. 2021 à 11:02,  a écrit :
>
> Hey friend,
>
> Happy to be a fountain of data on this in every possible way. You are
> understanding it correctly. In the process of mitigating this for my
> clients, I provoked the attacker to target myself with an attack that
> mirrored what he did to my customers. This allowed me to gain data that
> I don't have to censor or ask for consent to share.
>
> Here's an example of one of the ones that came from sendinblue:
>
> 2021-09-09 06:00:05 1mOD6R-0003fn-Oi <=
> bounces-54559210-abuse=mxroute@email.louis-herboristerie.com
> H=email.louis-herboristerie.com [185.41.31.12] P=esmtps
> X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no S=28077
> DKIM=email.louis-herboristerie.com
> id=9bf190c9-616d-48fc-8b30-0c29fe795...@smtp-relay.sendinblue.com
> T="Votre panier vous attend !" from
>  for
> ab...@mxroute.com
>
> Full source:
> https://paste.mxrouteapps.com/?1bce6365a355348a#9aSswYd4J91ysb9yiCiLyhbgZUXtCYcrMF81ctbWoAyk
>
> On 2021-09-09 03:38, Simon Bressier wrote:
> > Hi Jarland,
> >
> > I'm working at Sendinblue, I'm interested actually in knowing more
> > about the behavior you are reporting here.
> >
> > If I understand properly, you are talking about one address for
> > example, that is being added to multiple lists on many of our
> > customers by posting automatically that email address on unprotected
> > newsletter registration forms on our customer's websites ?
> >
> > Not an easy one to detect here, if you confirm the behavior, we'll see
> > if/how we could detect that.
> >
> > Thanks !
> >
> >
> > Le jeu. 9 sept. 2021 à 09:39, Jarland Donnell via mailop
> >  a écrit :
> >>
> >> Recently a provider, well...criminal, who goes by the name ByteFend
> >> has
> >> been performing a massive attack against my customers. They've asked
> >> for
> >> my help, and I've offered it. In the process, I've found that I can no
> >> longer consider companies to be "too big to block" after allowing
> >> themselves to be used in these attacks. I thought you all might like
> >> to
> >> share some of the data I've come across along the way.
> >>
> >> Domains taken from the envelope senders of a recent round:
> >> https://github.com/mxroute/rspamd_rules/commit/3b136e8812c74f35a32e61c8ad21f1f176c5b32d#diff-17eafba14786093de653e1da1991e0677cd7798c2ac277f196ab0eb09f24fc49
> >>
> >> Most recent round of IPs:
> >> https://clbin.com/wL7e3
> >>
> >> The attacker focuses on non double opt in newsletters that allow
> >> anyone
> >> to sign up without a captcha, and allow themselves to be flooded with
> >> requests. This of course fills their inbox with junk, and acts as the
> >> wonderful old DDOS attack for email.
> >>
> >> Among these are Sendgrid, Mailgun, Sendinblue, Yahoo, Yandex, iCloud,
> >> Orange, Google, Microsoft, the list goes on. It's time to start
> >> holding
> >> accountable these companies by devaluing their products until their
> >> customers begin holding them accountable. I'll fire the first shot.
> >> ___
> >> 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] Google and IPv6, was Recommendation for inbox provider?

[Slavko via mailop]

Hi,

Dňa 8. 9. o 22:44 Brandon Long via mailop napísal(a):
> Hmm, blocking connections is highly unusual for us, as it doesn't provide
> any feedback, usually we respond with a 5xx banner or to HELO.  I would
> check to see if you can reach www.google.com on IPv6 from the same box, and
> if you can, then go ahead and send me your IPv6 address and I can escalate
> that.

I can ping it from that box:

ping -ac2 2a00:1450:400c:c07::1b
PING 2a00:1450:400c:c07::1b(2a00:1450:400c:c07::1b) 56 data bytes
64 bytes from 2a00:1450:400c:c07::1b: icmp_seq=1 ttl=107 time=32.9 ms
64 bytes from 2a00:1450:400c:c07::1b: icmp_seq=2 ttl=107 time=31.7 ms

--- 2a00:1450:400c:c07::1b ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 31.702/32.297/32.892/0.595 ms

It is a LXC container with limited software, but here is nmap output
from its physical host:

nmap -6p 25 2a00:1450:400c:c07::1b
Starting Nmap 7.70 ( https://nmap.org ) at 2021-09-09 10:44 CEST
Nmap scan report for wo-in-f27.1e100.net (2a00:1450:400c:c07::1b)
Host is up (0.029s latency).

PORT   STATESERVICE
25/tcp filtered smtp

Nmap done: 1 IP address (1 host up) scanned in 2.57 seconds

> Unusual means it's almost always a manual step taken in response to a spam
> or other bad acting campaign of extremely large magnitude... but sometimes
> those types of blocks can linger.

Here is wery low traffic out from my MTA, and only small amount of this
outbound mails are going to gmail (<10/week), thus it cannot be massive
in any mean ;-)

I use HE IPv6 tunnel, with /48 net, from which i use only one /64 block
yet, thus even all neighbors are under my control. I have even working
PTR for IPv6. I didn't noticed any unusual outbound traffic from my net.
Delivery via IPv4 works without any problems, thus for now i enabled
ipv4_prefer in my MTA.

If you need more info, be free to contact me off list.

regards
Slavko
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] No one is "too big" anymore

[Jarland Donnell via mailop]

Hey friend,

Happy to be a fountain of data on this in every possible way. You are 
understanding it correctly. In the process of mitigating this for my 
clients, I provoked the attacker to target myself with an attack that 
mirrored what he did to my customers. This allowed me to gain data that 
I don't have to censor or ask for consent to share.


Here's an example of one of the ones that came from sendinblue:

2021-09-09 06:00:05 1mOD6R-0003fn-Oi <= 
bounces-54559210-abuse=mxroute@email.louis-herboristerie.com 
H=email.louis-herboristerie.com [185.41.31.12] P=esmtps 
X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no S=28077 
DKIM=email.louis-herboristerie.com 
id=9bf190c9-616d-48fc-8b30-0c29fe795...@smtp-relay.sendinblue.com 
T="Votre panier vous attend !" from 
 for 
ab...@mxroute.com


Full source: 
https://paste.mxrouteapps.com/?1bce6365a355348a#9aSswYd4J91ysb9yiCiLyhbgZUXtCYcrMF81ctbWoAyk


On 2021-09-09 03:38, Simon Bressier wrote:

Hi Jarland,

I'm working at Sendinblue, I'm interested actually in knowing more
about the behavior you are reporting here.

If I understand properly, you are talking about one address for
example, that is being added to multiple lists on many of our
customers by posting automatically that email address on unprotected
newsletter registration forms on our customer's websites ?

Not an easy one to detect here, if you confirm the behavior, we'll see
if/how we could detect that.

Thanks !


Le jeu. 9 sept. 2021 à 09:39, Jarland Donnell via mailop
 a écrit :


Recently a provider, well...criminal, who goes by the name ByteFend 
has
been performing a massive attack against my customers. They've asked 
for

my help, and I've offered it. In the process, I've found that I can no
longer consider companies to be "too big to block" after allowing
themselves to be used in these attacks. I thought you all might like 
to

share some of the data I've come across along the way.

Domains taken from the envelope senders of a recent round:
https://github.com/mxroute/rspamd_rules/commit/3b136e8812c74f35a32e61c8ad21f1f176c5b32d#diff-17eafba14786093de653e1da1991e0677cd7798c2ac277f196ab0eb09f24fc49

Most recent round of IPs:
https://clbin.com/wL7e3

The attacker focuses on non double opt in newsletters that allow 
anyone

to sign up without a captcha, and allow themselves to be flooded with
requests. This of course fills their inbox with junk, and acts as the
wonderful old DDOS attack for email.

Among these are Sendgrid, Mailgun, Sendinblue, Yahoo, Yandex, iCloud,
Orange, Google, Microsoft, the list goes on. It's time to start 
holding

accountable these companies by devaluing their products until their
customers begin holding them accountable. I'll fire the first shot.
___
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] No one is "too big" anymore

[Jarland Donnell via mailop]

Recently a provider, well...criminal, who goes by the name ByteFend has 
been performing a massive attack against my customers. They've asked for 
my help, and I've offered it. In the process, I've found that I can no 
longer consider companies to be "too big to block" after allowing 
themselves to be used in these attacks. I thought you all might like to 
share some of the data I've come across along the way.


Domains taken from the envelope senders of a recent round:
https://github.com/mxroute/rspamd_rules/commit/3b136e8812c74f35a32e61c8ad21f1f176c5b32d#diff-17eafba14786093de653e1da1991e0677cd7798c2ac277f196ab0eb09f24fc49

Most recent round of IPs:
https://clbin.com/wL7e3

The attacker focuses on non double opt in newsletters that allow anyone 
to sign up without a captcha, and allow themselves to be flooded with 
requests. This of course fills their inbox with junk, and acts as the 
wonderful old DDOS attack for email.


Among these are Sendgrid, Mailgun, Sendinblue, Yahoo, Yandex, iCloud, 
Orange, Google, Microsoft, the list goes on. It's time to start holding 
accountable these companies by devaluing their products until their 
customers begin holding them accountable. I'll fire the first shot.

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