[mailop] SURBL contact?

[Jarland Donnell via mailop]

Does anyone on the list know anyone at SURBL, or is anyone at SURBL on 
this list? A customer of ours at MXroute has his domain blacklisted on 
there. They don't give a reason, won't remove it, and I can't open a 
ticket with them because one was already opened. I've never run into 
issues with SURBL before so I'd really like to not pull any influence 
they have from our systems, I figured reaching out on here would be my 
last resort before doing so.


Much appreciated and sorry to bother!
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] salesforce phishing emails

[Jarland Donnell via mailop]

My experience is similar. My observation has been that Salesforce does 
not care about abuse, that almost all of the mail coming from their 
platform is unsolicited marketing email, and that they're a trash spam 
company worth blocking.


On 2024-06-13 12:09, Michael Peddemors via mailop wrote:

On 2024-06-13 08:28, Anne P. Mitchell, Esq. via mailop wrote:



On Jun 12, 2024, at 11:40 PM, Hans-Martin Mosner via mailop 
 wrote:


Am 12.06.24 um 18:04 schrieb Anne P. Mitchell, Esq. via mailop:


  I've also always found abuse@ to be responsive there, and it's 
peopled by a real person, who gives real responses (at least that 
was the case as recently as 12/21/23.


That's interesting, I've been sending lots of abuse reports to that 
address before and never received a response (or noticed a change in 
the pattern). But then I'm not a lawyer ;-þ


That's interesting - it _could_ be in part that I'm a lawyer (and 
perhaps more relevantly a known anti-spam lawyer), however I also 
wonder if it has to do with volume - I report to SF quite sparingly 
(simply because the amount of spam we get here, while copious, is 
rarely from SF).  If you are sending a lot of complaints, I wonder if 
that's a factor (granted it *shouldn't* be a factor, but I wonder 
if...).


Anne

---
Anne P. Mitchell, Esq.


It's you ;) Everyone answers YOUR emails ... hehehe

But seriously, yes we are seeing too many cases of emails of obviously 
'harvested' email databases from SalesForce..


And no, we aren't going to report every case that we see.  Thing is, 
anyone using harvested databases should be triggering all kinds of 
alarm bells at the ESP, eg hi bounce rates etc..


If their teams aren't reacting to those internal checks and balances, 
it is unlikely that an abuse report will carry much weight (Unless it 
is from Anne)


Unfortunately, history has taught us the only real way to get attention 
is when they end up on rejection lists.. All the way back to the SPEWS 
days..


And in some cases *cough* (SendGrid) even that is not enough to make 
change happen.


Speaking of what Business Drivers are required to enact change.. 
Curious.. what business drivers would be needed to have Cox and Verizon 
and Comcast to action compromised CPE equipment on their networks?


Not that hard to detect, (heck, I am sure others like us might even 
share that data) and I am sure that aside from the fact that it 
stealing customer data, and slowing their connections to a crawl, there 
must be a business driver for ISP's to let customers know about threats 
on their networks, or actually remove/replace those devices.


Comments?

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

Re: [mailop] IPv6 only MX

[Jarland Donnell via mailop]

Cloudflare typically doesn't proxy SMTP traffic. Unless something 
changed from the last I knew, I believe an enterprise plan may be 
required for them to do it. You might need to proxy the SMTP yourself 
through another dual stack system.


If I'm wrong feel free to embarrass me. I've grown more comfortable with 
being wrong these days!


On 2024-06-07 21:24, Jeff P via mailop wrote:

Hello

I have a VPS which has IPv6 only.
If I setup a mailserver on it, and use cloudflare email routing as the 
front.

Can cloudflare (or others) deliver messages correctly to this IPv6 MX?

Thanks.
___
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] [STATE OF THE UNION] Tales from the Trenches..

[Jarland Donnell via mailop]

Possibly valuable attachments:

- We saw an increase in compromised email accounts sending Comcast 
phishing emails which actually contained HTML that pulled valid Comcast 
assets into the emails. To the point that we have halted all outgoing 
mail containing those assets. This might correlate to the increase in 
compromised accounts you noticed.


- SendGrid is actually responding to and taking action on abuse 
complaints. This is worthy of celebration. It doesn't fix everything, 
and you know as well as I do that by the time you hit one spammer a new 
one pops up, but this indicates an actual intention to protect their 
investments. I'm all for it.


On 2024-05-30 12:24, Michael Peddemors via mailop wrote:
Both life and Business have been very active, so it's been a bit since 
I posted one of these.. It's about time again..


* SendGrid continues to allow the same common threats from escaping
* Increase in threat actors from Thailand/Vietnam region, but probably 
proxies for Chinese actors
* Digital Ocean IP space of course very bad, and most people already 
block/flag that IP space for spammers, but threat actors increasingly 
using the space for email compromise attacks.  Suggest that you block 
all authentication from that IP space by default, for both IMAP and 
SMTP, unless the IP is operated from a known good actor, similar to the 
GCloud, Amazon, Azure problems.
* ColoCrossing still a major pain, hopefully the new acquisition will 
improve the situation.
* NameCheap continues to allow the same abuse of their webmails for the 
same actors, with no improvement. (It's NOT that hard)
* Botnet spam attacks continue their decline, however email compromise 
attacks, and other attacks are on the rise, fortunately with old 
fingerprints that make them easy to stop.

* OVH is just opening the door to spammers..
* RackNerd IP space is to the point it's almost auto-block now.

Something is going on with Comcast IP space, a large increase in email 
compromise attacks, quite widespread, wonder if this is a case of CPE 
equipment compromise?


Netease/ntesmail has a lot more abuse coming from it the last couple of 
weeks.


Zimbra email compromises always surprise, given the amount of 
governments still using it.  They do know there is RBL's that list 
known abusive BEC Attackers?


LogicWeb still is giving IP space to too many obvious bad actors. 
(Doesn't anyone do a DNS walk on their IP space any more?)


Gmail and o365 leakage still showing these operators don't care about 
outbound, the phishing templates are old, and obvious.. Enough with the 
'1st page on Google' spam please?  And the Nigerian Prince scams?


MailChimp and MailGun are quickly catching up to SendGrid, as far as 
letting obvious known phishing templates from leaving their systems.


We thought 'backscatter' was a thing of the past, but seeing increases 
from all kinds of sources.  People, please do your spam filtering 
earlier in the process.. (Just saw some this week from ionos.com 
exchange servers?)


Portugese Invoice phishing seems to be on the decline, but this may be 
more due to the networks responsible for hosting these actors are being 
blocked more regularly.


But in general, fake invoice and RFQ emails are still the go-to for bad 
actors, mostly through compromised email accounts.  And would you 
believe that DHL phishing is still a thing?


At least GoogleGroups spammers are on the decline as well.

One surprise, is the fear about AI and ChatGPT created malware 
campaigns has not really seen the light of day.  It's still about how 
to get it delivered, rather than the content.  And as someone once 
pointed out, spammers often still use obvious bad language and obvious 
fake content, they are looking to catch the less intelligent or tech 
savvy targets.


Anyways, it's still a real scary place out there. Thanks to those out 
there that are also in the fight to make the world a better place, just 
wish that network operators were more responsible for what leaves their 
networks..


And of course, let's all remember to block/drop those really bad 
networks at the perimeter.. whether you use SpamHaus, SpamRats DROP 
lists ARE your friend, and help make the internet a better place


Now, time to get the new toy out this weekend, and try to put the bad 
things out of the mind.. have a safe and pain free weekend all.


-- Michael --

Todays' ASN to watch from the spam auditors?

Orelsoft AS200918

45.145.220.0/22
185.126.196.0/22
185.186.36.0/24
185.186.37.0/24
185.186.38.0/24
185.186.39.0/24
185.30.160.0/23
185.32.182.0/23
185.91.116.0/22

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

[mailop] Does Google not accept bounce emails anymore?

[Jarland Donnell via mailop]

421-4.7.26 Your email has been rate limited because it is 
unauthenticated. Gmail requires all senders to authenticate with either 
SPF or DKIM. Authentication results: DKIM = did not pass SPF [] with ip: 
[136.175.108.34] = did not pass For instructions on setting up 
authentication, go to 
https://support.google.com/mail/answer/81126#authentication 
5614622812f47-3d1b370fc69si2809030b6e.141 - gsmtp


Bounces coming from blank envelope senders are being held to SPF/DKIM 
authentication, which of course fails. Been seeing this a lot lately. 
Should we just not send bounce emails to Google anymore?

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

[mailop] "The email didn't arrive" to Office 365

[Jarland Donnell via mailop]

Hey friends,

Quick question for you experts. What do you find to be the most common 
root cause for reports of emails not being received by Office 365 
domains, when you can confirm conclusively that Microsoft accepted the 
email? Obviously spam folder delivery should rank high, but what else? 
Are there admin settings for Office 365 organizations that result in 
emails being accepted by their servers but not delivered to the 
recipients? Maybe quarantined somewhere?


We hear it often but we've never had a failed test to 
Outlook/Hotmail/O365, and yet still people open support tickets making 
claims that we failed to deliver the emails. We rarely hear back from 
them after asking them to tell their recipient to contact their IT 
department about it. So I feel a bit in the dark as to what other things 
to suggest beyond:


1. Check spam folder
2. Contact IT dept

I sure would like to have more clear and direct suggestions in my 
arsenal.


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

[mailop] Microsoft outages?

[Jarland Donnell via mailop]

Hoping it’s not just me, looking for a sanity check. Our queues today 
are packed with these responses from Microsoft’s mail servers:


451 4.7.500 Server busy. Please try again later

Hoping, surely, it’s not that they’re deferring email from us and just 
experiencing normal issues.

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

Re: [mailop] Apple mail admins?

[Jarland Donnell via mailop]

I once had this problem with another company and I'm going to share it 
here just in case it resonates with anyone:


Despite my NS records pointing to newer servers for years, one day this 
company (of noteworthy size and fame) queried ns1.mydomain.tld and 
insisted on using the values returned by it until I went back and forth 
with them for what I believe was a few weeks. So when I migrated a 
server to new IP, everyone using OpenD... I mean this company, failed to 
resolve the server.


On 2024-05-02 16:13, Jason R Cowart via mailop wrote:

Is anyone from the Apple email team here by chance?  If so, please
contact me off list.

It appears that Apple is sending to our users via a legacy mail server
that is no longer in our MX record.

Thanks,

Jason Cowart

Stanford University
___
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] is warming IPs still necessary?

[Jarland Donnell via mailop]

While I agree with your points Laura (and generally anything you have to 
say), I felt this right here warranted a secondary point worth making 
public to the mailing list:



It’s more necessary - you need to warm up both your IP and your
domain AND the combination of IP and domain addresses.


It's very difficult for people to know what warming up really looks 
like. If it were a numbered list of absolute and universal rules, they 
would have to change a week later. This makes "email warmup" services 
extremely attractive to people. But please, DO NOT fall for this trap. 
This is purely my opinion, but email warmup services are about to reach 
crisis levels. Legitimate domains sharing subject/content trends with 
spammers to a degree typically only reached when a sender on the 
legitimate domain is compromised, combined with the systematic/automated 
effort to manipulate spam filters at email providers, will very likely 
have fallout for the people using these services.


They're becoming so trendy that the mere use of the word "warmup" is 
starting to sound like an endorsement of these services.


On 2024-03-26 04:21, Laura Atkins via mailop wrote:

On 25 Mar 2024, at 22:58, Gerald Oskoboiny via mailop
 wrote:

We are planning to move the system that hosts our email discussion
lists from its old home where it has been for decades to an EC2
instance on AWS. It does about 15k deliveries per day, most of which
go to gmail or google-hosted email systems.


Don’t use EC2 for mail. Use SES.


Is it still necessary to warm up new IP addresses gradually instead
of going directly to this volume of deliveries? My impression is
that it's less and less necessary in the age of DMARC, SPF and DKIM.


It’s more necessary - you need to warm up both your IP and your
domain AND the combination of IP and domain addresses.


Nothing else would be changing from the recipient's point of view
aside from the IP address (and network): the domain, return-paths,
dkim keys and selectors involved would all be the same as they have
been.

The new IP address doesn't seem to be on many public RBLs, and I
have contacted Microsoft to have it removed from their block list.


Doesn’t matter. It’s a new IP - therefore it starts with a mildly
negative reputation.


Do many current sites require an IP's reputation to be established
gradually? (particularly Google) Would it just greylist deliveries
for a few hours, or fail worse than that?

The new host will be doing deliveries directly, not using SES.


That is, IMO, a very poor choice.

laura
 --
The Delivery Expert

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Delivery hints and commentary: http://wordtothewise.com/blog
___
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] [spamhaus] de-listing requests successful, but only for a couple of days.

[Jarland Donnell via mailop]

I'm gonna be "that guy" though for a minute.

If there are any IPv6 only mail servers, they are hobbyists trying to 
prove a point. There are a ton of IPv4 only mail servers. In short, 
there is no benefit to sending mail over IPv6 beyond the ideological 
preference some people have for feeling like they're ushering in the 
future. A future they've been predicting would arrive any day now for 
well over a decade.


On 2024-03-16 11:44, Bill Cole via mailop wrote:

On 2024-03-14 at 20:26:00 UTC-0400 (Thu, 14 Mar 2024 17:26:00 -0700)
Jay Hennigan via mailop 
is rumored to have said:


On 3/14/24 15:18, Michael Grimm via mailop wrote:

OVH is sharing a /64 subnet among multiple customers since they 
started their public cloud project. You are only provided with a 
single IPv6 address for your instance. In the years before that, I 
had had access to an exclusive /64 subnet.


This is very bad practice on OVH's part. Why are they doing this? Are 
they afraid of running out of IPv6 addresses?


Unlikely.

They are afraid of running out of the scarcity that allows them to make 
money by hoarding addresses and selling the clean ones at a premium.


Proper IPv6 deployment by mass-market hosters and ISPs is an attack on 
their business models. It is, in a sense, anti-capitalist in that it 
eliminates any meaningful address scarcity and so eliminates the 
profitable market for usable addresses.

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

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

[Jarland Donnell via mailop]

Is it plausible that Google had a temporary issue reaching your DNS 
servers?


On 2024-02-27 16:30, Rob Nagler via mailop wrote:

gmail.com [1] started failing messages from domains which are
correctly setup for SPF (and have been for some years):

550-5.7.26 Gmail requires all senders to authenticate with
either SPF or DKIM. 550-5.7.26  550-5.7.26  Authentication
results:
550-5.7.26  DKIM = did not pass 550-5.7.26  SPF [nagler.me [2]]
with ip:
[139.177.203.52] = did not pass 550-5.7.26  550-5.7.26

$ dig +short txt nagler.me [2]

"v=spf1 a mx ip4:139.177.203.52 include:_spf.google.com [3] -all"

Sending to (paid) Google Workspace domains works fine. Nothing has
changed on our end, and failures only started this morning.

Any ideas?

Thanks,
Rob



Links:
--
[1] http://gmail.com
[2] http://nagler.me
[3] http://spf.google.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] Microsoft 365 IP addresses listed on Spamcop

[Jarland Donnell via mailop]

Microsoft has a very well known spam problem right now. If you have a 
support contact for Office 365, please make sure to use that as well to 
complain. They desperately need to hear from their customers that 
sharing IPs with spammers, who appear (at least from our perspective) to 
operate with impunity, is unacceptable for a paid service. Right now 
they're #4 on here: https://www.spamhaus.org/statistics/networks/ 
(though that may include their cloud IPs as well). We actually receive 
more spam from Hotmail/O365 IPs than ham these days, which is not at all 
historically normal for them.


On 2024-02-15 01:32, Christopher Hawker via mailop wrote:

Hello all,

 I am attempting to send mail from a M365 tenancy, however, we are
seeing issues with it being filtered due to the address appearing on
bl.spamcop.net.


_"Decision Engine classified the mail item was rejected because of
IP Block (from outbound normal IP pools) -> 550 mail from
40.107.107.97 refused, see http://www.spamcop.net - Your mail
provider is blocked because is sending SPAM."_


If there is anyone on-list from Microsoft, could you please take a
look? It's causing issues 🙁

Thanks,
Christopher Hawker
___
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] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?

[Jarland Donnell via mailop]

I think it's very situational. But Spamhaus seems to imply that it's 
currently relevant, not just a one time mistake. It could be more than 
just poor list hygiene. Well intentioned people creating systems that 
are abused by spammers is something I come across daily. I'll give an 
example:


Just today I had a conversation with a customer about how their 
Wordpress registration form was being used to send spam. They are not 
spammers, their website is not spammy. But when you register, you input 
a name and email. Wordpress then sends an email to the address you 
entered on their website, and the first sentence in the body of the 
email is "Hi {name}" where "{name}" is the name entered into the form. 
So, as you probably already guessed, "Hi you can purchase cheap viagra 
from bit.ly/spammyurl" (paraphrased example) was the first sentence in 
the body of the emails they were sending out.


Just like that Wordpress user had no idea that their systems were 
perfectly set up for abuse, the library may have a problem of their own.


On 2024-02-14 17:20, Robert L Mathews via mailop wrote:

I find myself having a difference of opinion with Spamhaus about a
certain type of RBL listing, and I'm wondering what others think.

The situation is that the Reply-To email address of a public library's
"your book is due in five days" reminder system is listed in the
Spamhaus HBL [1], which Spamhaus says is because messages involving
that address are hitting spamtraps.

(That sounds plausible: Maybe some library users don't update their
email addresses, then the library unwisely doesn't remove bouncing
messages to discontinued domain names, and the addresses eventually
get repurposed as spamtraps. Or maybe the library isn't properly
verifying the user-supplied addresses to start with. If people want to
check their own logs, the listed Reply-To email address is
mcpldpubserv at gmail dot com, with an envelope sender of sierranot at
marmot dot org.)

Anyway: One of my customers complained that this listing is causing
SpamAssassin to block their library reminder messages. I "whitelisted"
the address on our end, but in an attempt to be helpful, I also
reported it to Spamhaus as a false positive, because it's affecting
messages that are requested by recipients and transactional.

Spamhaus says they don't remove such listings, though, because by
their definition, it's not a false positive if some of the messages
are reaching spamtraps -- in other words, that addresses sending to
spamtraps are correctly listed as "This email address is used for
malicious activities" in the HBL description solely because of the
spamtraps.

I'm a little surprised by that. The sender is of course engaging in
poor list hygiene, and it's reasonable for an automated RBL process to
initially list an address that is sending to spamtraps. But I've
always thought that trusted RBLs should have a policy of "if it turns
out that a listing is also affecting user-requested, non-malicious,
transactional messages, that's not okay".

Am I off base with that expectation?

(I've also contacted the library, who I have no connection to, but
this has been happening for months, so... )

--
Robert L Mathews



Links:
--
[1] 
https://docs.spamhaus.com/datasets/docs/source/10-data-type-documentation/datasets/030-datasets.html#hbl

___
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] Is forwarding to Gmail basically dead?

[Jarland Donnell via mailop]

Aside from the question in the subject, because I see this brought up a 
lot on the mailing list in relation to email forwarding, would passing 
ARC signatures even matter when the problem is that Google is 
increasingly rejecting forwarded emails due to the DMARC policy of the 
original sender domain?


We've had great results for a long time just using SRS. I know how some 
of you feel about it, but using the tools in front of me, SRS has done 
the job. But now that Google is pushing DMARC harder, more and more 
domains are setting their DMARC policy to reject, and Google appears to 
at least be enforcing this more than before. From the look of it, we can 
no longer forward emails from Yahoo to Gmail:


550-5.7.26 Unauthenticated email from yahoo.com is not accepted due to 
domain's DMARC policy. Please contact the administrator of yahoo.com 
domain if this was a legitimate mail. To learn about the DMARC 
initiative, go to https://support.google.com/mail/?p=DmarcRejection 
ev25-20020a056808291900b003be1cb5a890si971207oib.250 - gsmtp


Is it time to throw in the towel on email forwarding? Nearly 100% of 
users who forward email do so because they want it in Gmail. POP3 fetch 
has it's own concerns (local to local mail imported over POP3 fails SPF 
on import and gets filtered to spam). I'm quite skeptical that ARC fixes 
anything but theory and how people wish it was (or hope for it to be) 
trusted.

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

Re: [mailop] iCloud outage?

[Jarland Donnell via mailop]

Thanks for helping me confirm this friends. To close the loop, I sent an 
email to icloudad...@apple.com and the problems appear to have halted 
very early this morning (US/Central).


On 2024-01-17 03:13, Dan Malm via mailop wrote:

On 2024-01-17 08:47, Jarland Donnell via mailop wrote:
Just a quick sanity check, are others seeing intermittent failure to 
reach iCloud servers? My logs are filled with:


450 Error connecting to 17.57.156.30. Unexpected socket close

I've been having trouble delivering mail to them for at least 12 
hours. I hope it's not just me, but it would help to know if it is.

Seeing the same from multiple icloud IPs:
17.42.251.62
17.57.156.30
17.57.154.33
17.57.152.5
17.57.155.34

Connection gets cut randomly. I see it happening on 
banner/ehlo/mail/rcpt


But some other ips work, so mails do get delivered eventually.

Looking at my logs this seems to be a long-running issue with icloud, 
but at a much smaller scale than now. I've got 30 days worth of logs 
and I can see these errors happening throughout the whole timespan, 
though at a much smaller scale; just a handful of errors per day. The 
current larger issues seem to have started around 2024-01-16 20:00 UTC

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

[mailop] iCloud outage?

[Jarland Donnell via mailop]

Just a quick sanity check, are others seeing intermittent failure to 
reach iCloud servers? My logs are filled with:


450 Error connecting to 17.57.156.30. Unexpected socket close

I've been having trouble delivering mail to them for at least 12 hours. 
I hope it's not just me, but it would help to know if it is.


<3
Jarland
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?

[Jarland Donnell via mailop]

Don't forget about Elon's New Heater!

We're seeing a bit of a reduction of complaints now from this. Are any 
others seeing it start to slow down as well? I'm hoping MS is getting 
better at fighting it, but it may just be that I have. I haven't quite 
gone as far as blocking them but I have added high spam scores, and even 
increased spam scores from all MS IPs.


On 2024-01-16 16:24, Russell Clemings via mailop wrote:

Since exim_mainlog rolled over Saturday night, I see 332 successful
incoming emails from onmicrosoft.com [2] and 52 spam rejects. Based on
the subject lines, all of the successes were spam. So I've added
"blacklist from *.onmicrosoft.com [2]" to spamassassin. I just hope
people won't be too disappointed about missing out on their Dewalt
Power Stations and their YETI 30-Oz. travel mugs.

On Mon, Jan 15, 2024 at 10:30 AM Randolf Richardson, Postmaster via
mailop  wrote:


FWIW, after a log file review we are contemplating blocking

"azurewebsites.net [1]" as well as "@onmicrosoft.com [2]".

Our logs are showing small quantities of SMTP traffic from
"azurewebsites.net [1]" that are usually being blocked due to SPF
failures, and usually sending to weird, nonsencial non-existent
eMail
addresses where the local-part is a series of randomly-selected
letters and digits, sometimes intermixed with names of birds,
furniture, food, vehicles, colours, etc., all of which are recipient

addresses that don't exist and have never existed.

I'm assuming it's a source of eMail debris from broken
systems.  I'm
almost tempted to set up a honeypot to see whatever trash it's
trying
to spew out, but I'd rather do something more productive (like
flossing my teeth).


Curious if others are coming to the same conclusion?


I'm currently leaning in a block-on-sight direction since
I'm seeing
zero legitimate eMail coming from hosts self-identifying as hosts in

the "azurewebsites.net [1]" domain name in the HELO and EHLO
commands.


Regards,
Mark
_
L. Mark Stone, Founder
North America's Leading Zimbra VAR/BSP/Training Partner
For Companies With Mission-Critical Email Needs

- Original Message -
From: "Mark Alley via mailop" 
To: "Andrew C Aitchison" 
Cc: "mailop" 
Sent: Sunday, January 14, 2024 6:30:22 PM
Subject: Re: [mailop] Anyone else noticing an increase in spam

from Office365 distribution lists?




Ah, yep, thanks for catching that typo.
On 1/14/2024 4:56 PM, Andrew C Aitchison wrote:


On Sun, 14 Jan 2024, Mark Alley via mailop wrote:


BQ_BEGIN
This is anecdotal, but I think it illustrates even at a smaller

scale the persistent problem Microsoft currently has with their
tenancy.


I did some quick perusal of the last month's data from our email

logs, and out of a total of 22,473 external emails that contain a
.onmicrosoft.com [2] subdomain in the RFC5322.FROM field -- 22,086
were blocked because of various reasons:


* 21,228 spam
* 1 malware
* 759 phishing
* 5 impostor
* 93 "hard" failed SPF without a DMARC record since

onmicrosoft.com [2]

doesn't have one. (probably forwarded)

387 "clean" emails were delivered successfully initially, and 151

of those initial delivers were then later retroactively classified
as being spam or phishing.


So even at this scale, we're left with a minutia of ~0.01%



236/22473 ~= 1%


BQ_BEGIN
"legitimate" emails, most of which are from misconfigured Exchange

Online mailboxes or Office365 groups from various businesses.


So, YMMV widely, but for most organizations, as John said,

definitely not going to be missing /too /much. Most of what I see
that's legitimate in our traffic would be 3 or 4 specific subdomain
additions to a safelist from the hypothetical block rule, and that
would be it.


- Mark Alley

BQ_END


BQ_END

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

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


--
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/

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


--

===
Russell Clemings

===

Links:
--
[1] http://azurewebsites.net
[2] http://onmicrosoft.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

[mailop] Office 365 spam is getting ridiculous

[Jarland Donnell via mailop]

I think we've finally reached the point where more spam comes from 
Office 365 customers than legitimate and desirable email. Here's just 
ONE spam campaign from Office 365 we pulled logs for today: 
https://mxbin.io/piaQqm


Notice the different subdomains they send from:

*@csw11.besmartforgoodlife.com
*@csw12.besmartforgoodlife.com
*@csw13.besmartforgoodlife.com
*@csw14.besmartforgoodlife.com
*@csw15.besmartforgoodlife.com
*@csw16.besmartforgoodlife.com
*@csw17.besmartforgoodlife.com
*@csw18.besmartforgoodlife.com
*@csw19.besmartforgoodlife.com
*@csw20.besmartforgoodlife.com
*@csw21.besmartforgoodlife.com
*@csw22.besmartforgoodlife.com
*@csw23.besmartforgoodlife.com
*@csw24.besmartforgoodlife.com
*@csw25.besmartforgoodlife.com
*@csw26.besmartforgoodlife.com
*@csw27.besmartforgoodlife.com
*@csw28.besmartforgoodlife.com
*@csw29.besmartforgoodlife.com
*@csw30.besmartforgoodlife.com
*@csw31.besmartforgoodlife.com
*@csw36.besmartforgoodlife.com
*@csw37.besmartforgoodlife.com

And that's just one campaign, for just one day. At this point, we've 
blacklisted Microsoft IP ranges and we now consider email from them to 
more likely be spam than ham. Our blacklist isn't an outright block, but 
if Microsoft can't get their act together maybe a block is what we all 
need to do collectively. This is worse than the last few years of Gmail 
SEO spam.

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

Re: [mailop] Merry Christmas from Google?

[Jarland Donnell via mailop]

Indeed. We use SRS though and Google seems to like it fine enough, I 
just mean to say that I’ll never filter 1:1 what Google considers to be 
spam from email forwarding. It’s not all even spam really, but like any 
of us they have their own challenges.


I also noticed our list friend Al made a blog post about the new 
messages they return:  
https://www.spamresource.com/2023/11/gmail-new-spam-related-rejections-and.html?m=1


I “think” these new messages represent a clarification on the reasons 
more than a change of the internal reasons. I’ve long suspected their IP 
rate limit message of only sometimes being an actual IP based rate 
limit. I just never sat down long enough to prove it.


On 2023-12-17 02:00, Marco Moock via mailop wrote:

Am 16.12.2023 um 16:07:19 Uhr schrieb Jarland Donnell via mailop:


Obligatory: We don't intend to send any email their way that could be
perceived as unsolicited, but our users do use forwarders and we'll
never completely match their filters.


If they use forwarders, SPF will fail in the case the envelope sender
isn't rewritten. Check your logs for that.
___
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] Merry Christmas from Google?

[Jarland Donnell via mailop]

Hey friends,

I just noticed that on November 22nd, Google started returning new 
errors:


421-4.7.28 Gmail has detected an unusual rate of unsolicited mail 
originating from your SPF domain [userdomain.tld 15]. To protect our 
users from spam, mail sent from your domain has been temporarily rate 
limited. For more information, go to 
https://support.google.com/mail/?p=UnsolicitedRateLimitError to review 
our Bulk Email Senders Guidelines. 
o13-20020a056870200d00b002033c710f0asi2122725oab.109 - gsmtp


And a little of this:

421-4.7.28 Gmail has detected an unusual rate of unsolicited mail 
originating from your DKIM domain [ 15]. To protect our users from spam, 
mail sent from your domain has been temporarily rate limited. Please 
visit https://support.google.com/mail/?p=UnsolicitedRateLimitError to 
review our Bulk Email Senders Guidelines. 
y5-20020a056808130500b003b3eaa2eb4esi890433oiv.53 - gsmtp


And of course, the more generic:

421-4.7.28 Gmail has detected an unusual rate of unsolicited mail. To 
protect our users from spam, mail has been temporarily rate limited. 
Please visit 
https://support.google.com/mail/?p=UnsolicitedRateLimitError to review 
our Bulk Email Senders Guidelines. 
i1-20020a9d68c100b006d47c518673si38890oto.150 - gsmtp


It seems like Google is no longer just rate limiting IP addresses for 
this, but getting down into finer detail when rate limiting. Perhaps it 
was always there and the messaging has just been clarified. Either way, 
a welcome change, and good news for anyone who didn't know about it.


Obligatory: We don't intend to send any email their way that could be 
perceived as unsolicited, but our users do use forwarders and we'll 
never completely match their filters.

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

Re: [mailop] Outlook.com losing eMail messages and SNDS reporting failures

[Jarland Donnell via mailop]

I never found anyone of consequence who would agree with me or admit 
that it happens, but I will continue to swear that this is a feature of 
Hotmail/Outlook. The first time I identified it I think was in 2013. A 
customer reported the same behavior from their HostGator VPS (when I 
worked there). I had a test Hotmail account so I logged into their VPS 
and sent myself an email. Microsoft accepted it, but it was nowhere to 
be found. Not the spam folder, inbox, nothing. I moved another domain to 
their VPS temporarily and sent mail from that domain, and it was 
received. To me that drew the conclusion that this was related to the 
reputation of the sending domain in Microsoft's systems.


We're not alone:

https://answers.microsoft.com/en-us/outlook_com/forum/all/mail-not-received-outlookcom-response-to-sending/fd4211a6-c8e6-41fb-a94e-8254706f2ec1

https://answers.microsoft.com/en-us/outlook_com/forum/all/messages-reported-as-250-queued-for-delivery-but/f451cda5-ba7d-45ff-b643-501efe2413dc

https://answers.microsoft.com/en-us/outlook_com/forum/all/sendgrid-says-emails-delivered-but-customers-with/62de80ab-c006-4507-86d1-708d255c996d

https://answers.microsoft.com/en-us/outlook_com/forum/all/email-accepted-by-hotmail-but-not-delivered/83621726-60f8-46ce-9416-daf2385acca3

I for one would love to see this topic validated, but all I find across 
the internet seems to be gaslighting like "Is your SPF correct?"


On 2023-12-01 22:36, Randolf Richardson, Postmaster via mailop wrote:

Some of my users have been reporting that eMail messages are getting
lost intermittently when they're sent to users at any internet domain
name that relies on OUTLOOK.COM for its MX.

Our mail server logs confirm that all outbound messages were
accepted to those MX's (except for mistyped addresses or when a
user's quota is exhausted, in which case the usual SMTP rejections
occur).  No bounces were received.

Users have also reported the same intermittent problems when sending
from other providers (including GMail, YahooMail, etc.).  No bounces
were received (as far as I know).

We signed up for Microsoft's SNDS over a year ago, and added the
IPv4 addresses of our mail servers (unfortunately IPv6 is still not
supported, so more than 50% of our outbound SMTP connections won't be
included in whatever statistics are supposed to be provided by SNDS).

After logging in, the "View Data" section indicates the following:

No data for specified IPs on this date

In the past we were able to download a few CSV reports using the
links in the "Automated Data Access" section, but now they're only
presenting empty files (0 bytes).

Does anyone know if this just a temporary problem with SNDS that
occurs from time-to-time, or is there something more that we need to
do to get meaningful results from SNDS?  (The ChatGPT AI support bots
have not been helpful.)

Thanks.

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

Re: [mailop] Convincing clients of the importance of eMail recipient consent for mailing list subscriptions

[Jarland Donnell via mailop]

After the years of harassment I’ve endured by being subscribed to 
hundreds of thousands of mailing lists that are not double opt in, I’d 
say just casually toss my email into their mailing list and watch me 
convince them by way of harassment. I’m so far beyond asking nicely, my 
sanity wasn’t in short supply but it’s long gone.



On 2023-11-27 12:42, Randolf Richardson, Postmaster via mailop wrote:

What have you found to be some of the best approaches to convince
clients that the confirmed opt-in process is necessary for operating
eMail lists?  (The ethical aspects are pretty straight-forward.)

Many marketing people seem to be terrified of the idea of users
having to confirm their consent when subscribing to a mailing list
(e.g., by following a unique link in an eMail message to complete the
process).  The marketers almost always say "it will be too
complicated for the average user," and want to eliminate the
confirmation step altogether (which is not an ethical approach from
my perspective).

Presenting legal aspects is quite convenient here in Canada (because
of our anti-spam laws), and preventing inclusion in blacklists is
another helpful motivator, but I'd prefer to find a ways that get
mailing list operators to want to ensure that "every eMail recipient
consented" without the begrudging "we do this because we have to"
perspective.

Thank you for your thoughts and ideas.

Postmaster - postmas...@inter-corporate.com
Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.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

[mailop] Comcast issues?

[Jarland Donnell via mailop]

Anyone else seeing issues connecting to comcast.net MX servers today? 
We've got emails piling up in queue and connection failures all over.

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

Re: [mailop] Google rate-limiting more aggressively than usual?

[Jarland Donnell via mailop]

I "feel" like there's been an increase but I'm not sure if the numbers 
support my gut feeling. Here's some stats I just pulled if you want to 
look at them: 
https://docs.google.com/spreadsheets/d/14RfO9_RBnQBu4i2lzP4zYMGaQfTDGtNLmcC_E0xQeP4/edit?usp=sharing


On 2023-11-17 08:37, Philip Paeps via mailop wrote:
For the past couple of days, mx2.FreeBSD.org is queuing more mail to 
Google than usual.


This is the 421:

421-4.7.28 Gmail has detected an unusual rate of unsolicited mail. To 
protect 421-4.7.28 our users from spam, mail has been temporarily rate 
limited. Please 421-4.7.28 visit 421-4.7.28  
https://support.google.com/mail/?p=UnsolicitedRateLimitError to 421 
4.7.28 review our Bulk Email Senders Guidelines. 
m17-20020a67f71100b0045d8a438106si295017vso.199 - gsmtp (in reply 
to end of DATA command)


We're not sending out more unsolicited mail than usual.  Postmaster 
Tools suggests authentication, spam rates, etc etc etc all unchanged.  
We do all the things in the Bulk Sender Guidelines (except DMARC 
because we don't want to frustrate our users ability to use third-party 
mailing lists that don't mitigate it).  We add ARC headers to all our 
outbound mail.


Since about September, we're hitting the rate limiter ~70% of the time 
every couple of days.  Since ~15 November we're hitting the rate 
limiter for almost all mail we send.


Anyone else noticing this?

(We run hundreds of mailing lists (all of them confirmed opt-in, of 
course) and have dozens of plain forwarding aliases.  Our spam 
filtering is pretty effective but there will always be some spam.)


Brandon: any insights?  Happy to supply more logs.

Best wishes.
Philip

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

Re: [mailop] How to report abuse to cloudflare? Only via Web-Form?!? Phishing sites not against cloudflare policy!?!

[Jarland Donnell via mailop]

Another perspective might be “Why care?”

It’s their site that’s compromised, it’s up to them to care about it. If a host 
is sending abusive traffic your way, block the host, devalue their IPs by 
reducing the networks they can communicate with. Surely their website’s abuse 
isn’t making it back to you through the CF network, what is the IP connecting 
to your server?

> On Nov 16, 2023, at 4:28 AM, Benoit Panizzon via mailop  
> wrote:
> 
> Hi Laura
> 
>> Cloudflare does not concern itself with abuse. It does not host any 
>> websites, it only proxies back to the web host. They are not responsible for 
>> the content and they are unable to disconnect customers.
> 
> I am aware they do not host the content.
> 
> But they hide the IP address of their 'customer' and if that customer
> does not have any contact details on their site, there is no way to
> contact them. Especially of this is a malicious customer.
> 
> And yes, of course they are able to discontinue forwarding traffic to
> their customer and thus prevent more phishing to happen.
> 
>> I can’t imagine anyone who has been paying attention to expect cloudflare to 
>> take action against any abusive content. It’s not in their nature, and never 
>> has been. They protect a whole lot worse than phishing sites and have doxxed 
>> people who complain about abuse.
> 
> At least, they just discontinued proxying traffic to the phishing site
> and changed the DNS entries to reveal the IP of the 'real' hoster. So I
> have send a new complaint to the hoster and hope he will either urge
> his customer, wo is aware of the issue but ignoring it, to fix the
> hacked site, or block them until they do so.
> 
> Mit freundlichen Grüssen
> 
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
> 
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> ___
> 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] [External] Re: Microsoft CERT Report Response Marked As Spam

[Jarland Donnell via mailop]

Well, I don't think I have much room to argue with the guy who single 
handedly blocks the most spam on all of my servers. Thanks for that by 
the way.


On 2023-11-09 12:58, Kevin A. McGrail via mailop wrote:
I wouldn't agree with that.  Microsoft sending emails with invalid 
dates alone would put this under the threshold. -KAM


On 11/9/2023 1:41 PM, Jarland Donnell via mailop wrote:
A score of 5.8 on SpamAssassin rules is fairly low. It would be more 
advisable for you to consider adjusting your settings. SpamAssassin is 
designed in such a way that it will always trigger a variety of rules 
for every email, legit or otherwise. It shouldn't be too strange to 
see a legit email in the range of 3-5, and I'd say 5.8 isn't too far 
out from there.

___
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] Microsoft CERT Report Response Marked As Spam

[Jarland Donnell via mailop]

A score of 5.8 on SpamAssassin rules is fairly low. It would be more 
advisable for you to consider adjusting your settings. SpamAssassin is 
designed in such a way that it will always trigger a variety of rules 
for every email, legit or otherwise. It shouldn't be too strange to see 
a legit email in the range of 3-5, and I'd say 5.8 isn't too far out 
from there.


On 2023-11-08 06:43, L. Mark Stone via mailop wrote:

We filed an abuse report with Microsoft for some bad emails.

Normally we don't bother, but these emails were concerning enough that 
we thought we should bring them to Microsoft's attention.  While it 
would be nice if Microsoft did a better job at filtering outbound 
emails, that's not the point of this post here.


We got back a "Microsoft CERT Report  Received" email, 
which email went straight to Junk, with the following SpamAssassin 
tests firing:


X-Spam-Status: Yes, score=5.824 required=3.8 
tests=[DATE_IN_PAST_03_06=1.076,
 DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 
DKIM_VALID_AU=-0.1,

 DKIM_VALID_EF=-0.1, FORGED_SPF_HELO=1, HTML_FONT_LOW_CONTRAST=0.001,
 HTML_MESSAGE=0.001, MISSING_HEADERS=2, RCVD_IN_DNSWL_HI=0.001,
 RCVD_IN_MSPIKE_H2=-0.001, REPLYTO_WITHOUT_TO_CC=1.946, 
SPF_HELO_PASS=-0.001,
 SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, 
T_SCC_BODY_TEXT_LINE=-0.01,

 URI_TRUNCATED=0.001] autolearn=disabled

In case anyone else is waiting for responses from Microsoft, recommend 
you check your Junk/Spam folder.


Hope that helps,
Mark
_
L. Mark Stone, Founder
North America's Leading Zimbra VAR/BSP/Training Partner
For Companies With Mission-Critical Email Needs
___
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] script to collect SPF addresses by domain?

[Jarland Donnell via mailop]

This is what I use: https://github.com/equk/spf_list/

I get as otherwise mentioned that SPF macros defeat this in theory, but 
in practice I've not (to date) found myself attempting to extract the 
IPs from an SPF record of a domain that uses macros. In practice, this 
has saved me a lot of time for the purposes I use it.


On 2023-10-30 14:01, Michael W. Lucas via mailop wrote:


Hi,

Trying to not reinvent the wheel here.

I want to create an allow list of the big providers that retry from
multiple IP addresses. (Spam from them won't be caught by
protocol-level checks like postscreen, it needs rspamd or somesuch).

It seems that someone surely would have created a "grab the SPF
records and create a list" script, recursing the included
records. Search engines are not useful to find it, though.

Any pointers?

==ml___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Jarland Donnell via mailop]

Thanks for the heads up on this. I've just set our mail servers to watch 
out for this and treat it as a 5xx. I hadn't noticed, but if I'd ever 
noticed a 4xx on "Relay access denied" I likely would have added this 
logic immediately without even taking time to second guess it, as I 
can't think of a time that I considered that to be a temporary error 
from anyone.


On 2023-10-07 15:41, Kirill Miazine via mailop wrote:


Hi, mailops

Recently I experienced a very "interesting" case which gave my personal 
email server "poor" "sender score" due to high rate of emails sent from 
my server to non-existent users.


It _couldn't_ be right, as the server is used only by myself and some 
very few family members, and there is no activity which should have 
triggered that score.


I think I figured out what it was. A user sent an email to another 
family member, but using contact's old email domain which used to be 
hosted by Fastmail, but where no such user would exist anymore (I don't 
know if domain still exists as a domain at Fastmail, but clearly MX 
point to them).


I'd guess a 5xx response would be appropriate -- at least on port 25, 
but Fastmail sent 451, and made my Exim try -- and keep re-trying -- 
all IP addresses of all their MX. I have very conservative retry rules, 
so emails would be kept in the queue for a month...


I _guess_ that Fastmail is using sender score, because sender score 
graphs started at the date of that one particular email was sent. So 
every try must have been giving me "bad" score.


And I wouldn't even have discovered that if not OpenSMTPD misc@ lits 
rejected my email, and today would accept it, but add a sender-score 
header, which made me start digging...


Senders to Fastmail beware, and maybe consider treating their 4xx 
errors as permanent.


Logs below:

Oct  7 08:45:03 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.220]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:06 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.218]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:08 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.216]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:10 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.219]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:13 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.217]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:16 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in2-smtp.messagingengine.com [64.147.123.52]: SMTP error from remote 
mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access denied

___
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] [Attn: Mailbox Providers] Mandated Email Notice Announcement

[Jarland Donnell via mailop]

Thank you for this. I've taken steps to ensure that you will not meet 
any problem sending these emails to customers of our platform.


On 2023-10-04 23:37, Justin Frechette via mailop wrote:


Attention Mailbox Providers:

As outlined in the "Sending Mandated Emails to Large Audiences" best 
practice published by M3AAWG, this message is to inform you of a high 
volume of email that will be sent by IDX (https://www.idx.us) via 
iContact to recipients that have a higher likelihood of bouncing, 
reporting as spam, or marking as phish.


Due to data privacy concerns and advice from Counsel, I am unable to 
share the specific organization that IDX (via iContact) will be sending 
these notices on behalf of in this forum. I'm hopeful the details I can 
share are enough for you to assist with any mitigation efforts possible 
for these required notices.


From Address: i...@mail.idx.support
From Name: : Notifications
Subject: Incident Notice for  Rewards Members

Dates: Starting Friday, October 6, 2023
Total Volume: 20 million
Duration: 15 days
Daily Volume: 1.5 million (excluding weekends)

Sending IPs:
74.202.227.59
74.202.227.60
74.202.227.61
74.202.227.62

Return-Path Domain: mail.idx.support
DKIM Domain: mail.idx.support
Gmail & Yahoo recipients will have a second DKIM domain for FBLs: 
icontactmail10.com [1]


DMARC: mail.idx.support has a published p=reject record

Sending will commence Friday, October 6, 2023 to an initial audience of 
around 1.5 million contacts with future messaging to be delivered each 
business day to around the same list size. We are anticipating the 
campaign to last around 15 days.


These IPs and domains will not be used for any other sender during this 
time as well as no other content than these mandated notices.


iContact has done our due diligence to remove/replace as many shared 
data points from these notices as possible. Our core sending is opt-in 
email marketing for SMBs and I would greatly appreciate any filtering 
you could do to prevent these notices from negatively impacting our 
other mail streams.


My contact information is below and please reach out should you have 
any questions or concerns. Thank you again for your assistance.


Justin Frechette
Manager, Deliverability & Compliance, iContact
Senders Co-Chair, M3AAWG
jfreche...@icontact.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop




Links:
--
[1] http://icontactmail10.com___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Jarland Donnell via mailop]

SRS is usually fairly trivial these days, but DMARC changes things. 
While SRS is doing fine for our users when forwarding email to Gmail, 
when auth fails and DMARC = reject Google will tell you pretty plainly 
that they're probably not going to accept it: 
https://support.google.com/mail/answer/2451690


"For example, eBay and PayPal publish a policy requiring all of their 
mail to be authenticated in order to appear in someone's inbox. In 
accordance with their policy, Google rejects all messages from eBay or 
PayPal that aren't authenticated."


It's my finding that at scale, there's no silver bullet to ensure that 
100% of emails you forward are going to be accepted by Google, or anyone 
really. That's why anyone who considers their inbox mission critical 
needs to rely on their inbox provider, and not a third party accepting 
email from their inbox provider. Most users won't have a complaint about 
this, they won't even notice what wasn't accepted when forwarding (and 
often didn't really want whatever it was anyway). But that's because 
most users don't consider their personal inbox to be mission critical, 
and most users with a mission critical inbox use their work email system 
rather than forward everything from c...@fortune500company.tld to 
babybearbobca...@gmail.com.


On 2023-09-13 01:44, Jason R Cowart via mailop wrote:


Hi Brandon,

Thank you for the responses.  I'll send you some examples off list of 
successes and failures from the exact same sender and final recipient, 
both Gmail users.  I'd very much like to understand why we are seeing 
what appears to be an increase in DKIM validation failures in order to 
determine what can be done to improve the situation.  We are aware of 
DKIM signatures using the strict canonicalization option failing 
validation after forwarding, but in these examples the relaxed 
canonicalization was used.


We do not rewrite the envelope sender as we forward. I'm not convinced 
the non-trivial effort needed to shift to rewriting the sender would 
yield a durable solution to this problem, as it would not help with a 
DMARC check since the resulting SPF pass will be out of alignment with 
the sender in the From: header.  It would seem we're dependent on the 
initial DKIM signature passing validation.  I'd welcome any other 
perspectives on the topic.


Best,

Jason

From: Brandon Long 
Date: Tuesday, September 12, 2023 at 8:29 PM
To: Jason R Cowart 
Cc: mailop@mailop.org 
Subject: Re: [mailop] Authentication Bounces by Gmail

Looking at the messages from that IP getting that rejection message, 
I'm seeing a lot of DKIM body hash did not verify, I'd also verify that 
your system isn't modifying the messages that it is forwarding.


Brandon

On Tue, Sep 12, 2023 at 8:20 PM Brandon Long  wrote:

That message did not have a DKIM header ... or was so garbled that we 
didn't extract it.


Due to DKIM replay, we may spam reject forwarded messages that DKIM 
verify but not SPF, but those would not have that rejection message.


And yes, we are continuing to ramp no auth, no entry.

I'm sure I've had a long explanation on here in the past year, but the 
short answer is if the message is not DKIM valid and you're forwarding, 
you should rewrite


the MAIL FROM to a domain you own that will SPF authn the message... 
and try not to forward spam.


Brandon

On Tue, Sep 12, 2023 at 6:00 PM Jason R Cowart via mailop 
 wrote:


We are seeing an increasing number of bounces by Gmail related to 
failed authentication checks.  The bounces include language like:


<<< 550-5.7.26 This mail is unauthenticated, which poses a security 
risk to

the
<<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender 
must

<<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this
message,
<<< 550-5.7.26 DKIM checks did not pass and SPF check for [mcn.org [1]] 
did not

pass
<<< 550-5.7.26 with ip: [67.231.157.125]. The sender should visit
<<< 550-5.7.26 
https://support.google.com/mail/answer/81126#authentication [2]

for
<<< 550 5.7.26 instructions on setting up authentication.
z6-20020a05622a028600b00403a8e58423si1377805qtw.448 - gsmtp
554 5.0.0 Service unavailable

This is occurring in situations where our users forward their mail to a 
personal Gmail account.  SPF checks will of course fail in the 
scenario, but DKIM checks should pass.  In fact, they most often do 
pass--users impacted by this are only seeing a small subset of their 
mail from a given sender bounced (which often times will be a Gmail 
sender).  In cases where the user retains a copy locally we've been 
able to verify that the DKIM signature was present and was successfully 
validated by our system.


Is anyone else experiencing this?

Is anyone from Google could reach out to me off-list to discuss that 
would be much appreciated.


Best,

Jason Cowart

Stanford University IT

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

Re: [mailop] Authentication Bounces by Gmail

[Jarland Donnell via mailop]

https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme

On 2023-09-13 01:19, Atro Tossavainen via mailop wrote:


I'm sure I've had a long explanation on here in the past year, but the
short answer is if the message is not DKIM valid and you're 
forwarding, you

should rewrite
the MAIL FROM to a domain you own that will SPF authn the message... 
and

try not to forward spam.


That's not how forwarding works, Brandon.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Jarland Donnell via mailop]

It's not at all unusual for FBL to be used to block recipients. 
Transactional email providers quite often use feedback loop reports to 
add recipients to their customer's suppression list. The reason you 
specifically find it frustrating is because of this:


Most of the providers on the feedback loops report an email back to the 
feedback loop when the user clicks "Report spam" or something similar. 
While I'm not sure if/when you stopped, for the longest time Fastmail 
was the only one on the feedback loop who reported every single email to 
the feedback loop that they themselves filtered to user's spam folders, 
and this feature was on by default. So if your spam filter moved a 
transactional email into a user's spam folder without them having 
specifically configured or clicked anything, your user was then added to 
a suppression list at the transactional email provider, likely prompting 
an excess of support tickets on your end. This then forced your users to 
then reach out to the end customers of the transactional provider and 
beg them to find someone at their company who knew how to remove them 
from the suppression list, which frankly tends to be very few people at 
those companies (regardless of their size).


The reason I know this is because I worked for a hosting company that 
would frequently stop receiving abuse complaints from Cloudflare because 
their abuse complaints got filtered into the spam folder at Fastmail, 
which instantly set off a FBL complaint, and caused us to land on the 
suppression list at the transactional email provider that Cloudflare 
used for their abuse department at the time.


I've been ignoring feedback loop complaints from Fastmail for a long 
time because of this. Should I take this as word that I can finally stop 
doing that?


On 2023-09-11 07:05, Neil Jenkins via mailop wrote:


On Mon, 11 Sep 2023, at 21:24, Support 3Hound via mailop wrote:

During years the FBL became a kind of "safe feature" for users that 
prefer to click "junk" or "spam" and be sure they will not receive 
anymore.

[...]
FBL generates also a good data flow for the mailbox provider that may 
filter the "next e-mail" from a sender that don't honor the FBL (or 
can't act realtime the unsubcribe) generating a better service for the 
end user and a way to identify good player and bad ones.


That's a ... different perspective on this behaviour. Treating an FBL 
report as "unsubscribe" (or rather _proscribe_ at the ESP level) is 
terrible for user experience and not at all what the feedback loop 
should be used for IMO. Users click Report Spam by mistake one time 
(this happens _a lot)_ and suddenly they don't get emails they want. 
Even worse, as the proscription is often at the ESP-level, the original 
sender ban be unaware of the block and thinks they are still sending 
correctly. These are a nightmare for our customer support team to deal 
with -- the sender's support are saying they are sending the message, 
our support are telling the customer there's no logs of it ever 
reaching our servers. The customer is stuck in the middle


This has already caused us to drastically reduce the times we send FBL 
reports at Fastmail -- not every Report Spam will do so, only if the 
user repeatedly does so for a specific sender -- and I am still 🤏 this 
close to stopping sending anything.


Feedback loops should be used by ESPs to identify bad _senders_, by 
looking at aggregate reports. Never for unsubscribing specific 
recipients.


Neil.
___
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] RNC v. Google Dispositioin

[Jarland Donnell via mailop]

That's been a lot of my finding as well. While I fully empathize with 
efforts to tackle bias, spam from affiliates of the RNC is worse than 
their counterparts. Mainstream bias is worse in the opposite direction, 
spam is worse in this direction. It's quite fair to notice the flaws 
from every angle and that they're different (regardless of whether or 
not anyone feels they're equal, just different).


Given that I'm more likely to be biased in the opposite direction, it's 
noteworthy that I see more spam from affiliates of the complainant in 
this case. They're more numerous, they're more clickbaity, and they're 
more often targeted at people who didn't consent via any double opt-in 
procedure.


So, a solid win for all of us.

On 2023-08-26 14:54, Rob McEwen via mailop wrote:

BigTech is overflowing with extreme-leftist bias - especially with 
their social media fact-checkers - and (to a lesser extent) this bias 
overflows into their spam filtering and search results - HOWEVER - the 
RNC and so many right-wing politicians are among the WORST to try such 
a lawsuit because the RNC, and many of their affiliates, spam like 
crazy and are OFTEN using shady-as-hell practices, such as using crappy 
third party senders who sent to 100% purchased lists, in addition to 
sending from newly-bought domains with zero reputation. It's a 
cesspool. And they make some of the most unethical low-rent ESPs 
wealthy in the process. The owners of some of those of those ESPs are 
spoiled rotten rich brats who think that rules don't apply to them. 
Likewise, every time I'm dealing with their spam, and I think about the 
CEOs of these shady ESPs they're using - I get this image in my mind of 
one or another of the shady drug dealers in the movie, Boogie Nights. 
THAT is who they really are! (I have inside info about them - this is a 
good summary of what these people are like!)


I do know of a few ethical ESPs that cater to conservative politicians 
and who do send ethically/correctly - but they are few and far between. 
Ironically, that the RNC tried this complaint - will only make the 
leftist bias from BigTech - worse!


Likewise, the Republican bill to unravel 47US230 - is a total disaster 
- and all co-sponsoring that are either idiots are didn't even hardly 
read it. 47US230 probably needs improvement because it's somewhat 
abused - but their proposed fix utterly fails to understand how much 
47US230 protects antispam and antimalware "good guys" from being run 
out of business bu frivolous slapp lawsuits. Everyone will suffer 
greatly if 47US230 is altered or replaced in an unwise way.


Rob McEwen, invaluement

-- Original Message --
From "Anne Mitchell via mailop" 
To "Gellner, Oliver via mailop" 
Date 8/26/2023 2:29:46 PM
Subject [mailop] RNC v. Google Dispositioin

I'm surprised that nobody has mentioned this here, because it was a 
big win for Gmail plus has language which is applicable to any ISP.


In the order (in which the RNC complaint was dismissed) the court 
basically not only smacked down the RNC, but made clear that the 
Communications Decency Act (i.e. Federal Law) was developed in part 
to:


"encourage the development of technologies which maximize user control 
over what information is received by individuals, families, and 
schools who use the Internet and other interactive computer services"


..and the court goes on to say that "Permitting suits to go forward 
against a service provider based on the over-filtering of mass 
marketing emails would discourage providers from offering spam filters 
or significantly decrease the number of emails segregated. It would 
also place courts in the business of micromanaging content providers 
filtering systems in contravention of Congresss directive that it be 
the provider or user that determines what is objectionable".


There's a lot more, it's a great opinion (full text of the court order 
is included in our article):


https://www.isipp.com/blog/rnc-v-google-republican-national-committee-gets-smacked-down-by-court-full-text-of-order-here/

Anne

---
Anne P. Mitchell
Attorney at Law
Email Law & Policy Attorney
CEO Institute for Social Internet Public Policy (ISIPP)
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email 
marketing law)

Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus, eMail Abuse Prevention System (MAPS)

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

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

Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe

[Jarland Donnell via mailop]

I usually reply and ask them to cancel the order/reservation. Maybe next 
time the person won't be so careless writing down their email.


On 2023-08-24 07:12, Chris Adams via mailop wrote:


What do you do when legitimate mail (lately, DoorDash order info and
Delta Airlines tickets) is sent to the wrong address?  These types of
messages rarely have an unsubscribe method.  I get a ton of crap to a
Gmail address that I really only use for Google-related stuff (not as a
general email box), so I know instantly that this is not to me.

Why do vendors think they don't need an unsubscribe in this type of
mail?  Just because their customers are dumb and don't know their own
email address doesn't mean they should continue sending personal
information about them to other people.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Jarland Donnell via mailop]

SPF contains information about which IP addresses are authorized or 
unauthorized to send messages for a given domain. It does not contain a 
policy on what to do with this information.


"Sender Policy Framework"

See G.1-G.4, which are strangely worded for a system that doesn't 
contain any policies: https://datatracker.ietf.org/doc/html/rfc7208


On 2023-08-21 15:17, Gellner, Oliver via mailop wrote:


On 19.08.2023 at 19:01 Jarland Donnell via mailop wrote:

Is "-all" not indeed a policy in SPF, directed by the domain owner? I 
would argue that it is. Especially given that there are options there, 
each one defining how the domain owner wishes SPF failure to be 
treated. I would find it odd to say that should ignore domain owners 
when they say "-all" since that's a direct and clear request by them.


SPF contains information about which IP addresses are authorized or 
unauthorized to send messages for a given domain. It does not contain a 
policy on what to do with this information.
If someone decides to reject messages from sources listed as 
unauthorized, this is a policy set up by the *receiver*. Fair enough. 
I'm just saying that if the domain owner actually *did* create a policy 
(within the DMARC record, as DMARC allows you to include a policy) and 
this policy says „my messages are authorized as long as they are coming 
from those IP addresses and/or carry a valid cryptographic signature of 
my domain" then I recommend against simply ignoring this policy and 
rejecting messages exclusively based on SPF across the board. This 
might lead to false positives. And one cannot claim that those false 
positives happened on request of the domain owner, when the domain 
owner set up a policy that instructed something different - but the 
receiver ignored it to save some CPU cycles on his box.


--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de<mailto:dmt...@dm.de> * www.dmTECH.de 
[1]<http://www.dmtech.de>

GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen 
oder sich bei uns bewerben, verarbeiten wir personenbezogene Daten. 
Informationen unter anderem zu den konkreten Datenverarbeitungen, 
Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer 
Datenschutzbeauftragten finden Sie 
hier<https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832>.

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




Links:
--
[1] http://www.dmTECH.de___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Jarland Donnell via mailop]

ARC is where it's at


I haven't spent much time on ARC but if I understand correctly, isn't 
that a 100% trust based system? Meaning I have to trust that when you 
say you authenticated it, that you're trustworthy when saying it?


On 2023-08-21 04:30, Taavi Eomäe via mailop wrote:


On 21/08/2023 12:08, Laurent S. via mailop wrote:

I guess they don't care about breaking DKIM either. Avoiding to break 
SPF isn't rocket science.


Many methods to avoid breaking SPF will break DKIM (if it exists, thus 
DMARC). It's not rocket science, but it's not trivial.


ARC is where it's at, not (only) SPF and SRS-like methods.

___
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] hotmail.com SPF forgot IPv6

[Jarland Donnell via mailop]

Is "-all" not indeed a policy in SPF, directed by the domain owner? I 
would argue that it is. Especially given that there are options there, 
each one defining how the domain owner wishes SPF failure to be treated. 
I would find it odd to say that should ignore domain owners when they 
say "-all" since that's a direct and clear request by them.


On 2023-08-19 06:31, Gellner, Oliver via mailop wrote:


On 19.08.2023 at 12:30 Benny Pedersen via mailop wrote:

prove it, it just loose dmarc aligment, if it was hardfails, lets not 
ignore domain owners, ever


spf softfails can still pass dkim, hopefully you know this


You don't have to ignore domain owners as they do not put any kind of 
policy into SPF records. SPF does not allow one to to this.
What domain owners can do is set up a policy in the DMARC record. Of 
course on the receiver side you can make up any number of additional or 
even contradictory policies like the one you described, as in „your 
server, your rules". But I believe the guidance from M3AAWG which 
actually takes existing policies from the sender side into account is 
more friendly and provides less false positives. In a nutshell this 
means: Do not reject emails based solely on SPF failures as soon as the 
sending domain has a valid DMARC record.


--
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de 
[1]

GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen 
oder sich bei uns bewerben, verarbeiten wir personenbezogene Daten. 
Informationen unter anderem zu den konkreten Datenverarbeitungen, 
Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer 
Datenschutzbeauftragten finden Sie 
hier.

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




Links:
--
[1] http://www.dmTECH.de___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Hotmail's Blocklist and S3150

[Jarland Donnell via mailop]

Reply and ask them to provide temporary mitigation to the IP range. If 
they say they can't, just reply and ask for it again. Repeat as 
necessary. I promise it's okay, this is an intended workflow.


On 2023-08-17 16:41, Dan Mahoney (Gushi) via mailop wrote:


Hey there all.

Dayjob (ISC -- BIND, F-root, DHCP, those guys) just spun up a new ip 
block to put a few F&F/Employee VMs on.  We are the ISP -- this is our 
netblock space.  We've owned this block for a while, just haven't used 
it recently, and we've never really used it for *any* spam sending 
purpose.


One thing I'll note is that it looks *LIKE* an RFC1918 ip, but it's 
not. (192.158 versus 192.168).


One of them tried to send mail and got this block message (note, all 
domains are intaxct, but I have changed a letter in the uer-portion to 
stop it from getting picked up by harvesters).


Aug 16 14:41:20 mail postfix/smtp[7844]: D47CA7A4672:
to=, orig_to=, 
relay=hotmail-com.olc.protection.outlook.com[104.47.56.161]:25,
delay=1.9, delays=0.08/0.02/1.7/0.15, dsn=5.7.1, status=bounced (host 
hotmail-com.olc.protection.outlook.com[104.47.56.161] said: 550 5.7.1
Unfortunately, messages from [192.158.252.15] weren't sent. Please 
contact your Internet service provider since part of their network is 
on
our block list (S3150). You can also refer your provider to 
http://mail.live.com/mail/troubleshooting.aspx#errors.

[CO1NAM11FT106.eop-nam11.prod.protection.outlook.com
2023-08-16T21:41:20.664Z 08DB9E137B1F64A7] (in reply to MAIL FROM
command))

Aug 16 14:41:20 mail postfix/smtp[7844]: D47CA7A4672:
to=, orig_to=, 
relay=hotmail-com.olc.protection.outlook.com[104.47.56.161]:25,
delay=1.9, delays=0.08/0.02/1.7/0.15, dsn=5.7.1, status=bounced (host 
hotmail-com.olc.protection.outlook.com[104.47.56.161] said: 550 5.7.1
Unfortunately, messages from [192.158.252.15] weren't sent. Please 
contact your Internet service provider since part of their network is 
on
our block list (S3150). You can also refer your provider to 
http://mail.live.com/mail/troubleshooting.aspx#errors.

[CO1NAM11FT106.eop-nam11.prod.protection.outlook.com
2023-08-16T21:41:20.664Z 08DB9E137B1F64A7] (in reply to MAIL FROM
command))

We reached out to MS, requested a delist, To which MS responded:

===

Hello,

Thank you for contacting Microsoft Online Services Technical Support.
This email is about ticket number [number], which was opened regarding 
your delisting request for [192.158.252.15].


It appears that the IP you submitted is not currently listed on any of 
our block lists.  This may be due to an earlier delisting request that

has already been processed.

If you continue to receive Non-Delivery Receipts (NDRs), or "bounce 
messages," that indicate that the IP address is still blocked by our 
spam
filtering system, please forward one of the messages to us and we will 
investigate further.


Thank you again for contacting Microsoft Online Services technical 
support and giving us the opportunity to serve you.




We are continuing to receive these.  Is there some magic incantation I 
need to know.  Shiboleet! (Help, plz).


-Dan___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Delivery Reports, requested by Microsoft 'Outlook' customer, reported as Spam by same Microsoft 'Outlook' customer?

[Jarland Donnell via mailop]

Suppression lists. All the big transactional email providers have them. 
We do it with feedback loops, if someone reports a legitimate and 
desired email as spam then we block them from our entire platform. The 
person who wants to send mail to them can try to reason with them and 
get the block removed, but very rarely does anyone care to (because 
they're not happy about their recipient reporting them as spam either).


Of course, you have to consider the source as well. For example, if we 
get a feedback loop message from Fastmail we don't add it to the 
suppression list. Because their default behavior is that they forward 
everything they filter to their user's spam folder back to the feedback 
loop. So a user doesn't have to do anything for this to happen other 
than not change default settings. Comcast users frequently claim they're 
just deleting the email when it comes in over the feedback loop (often 
months later) but I don't buy it, I still put those on the suppression 
list.


On 2023-08-10 11:07, Al Iverson via mailop wrote:


Doesn't seem like a new problem, really. Any user can report spam on
anything they want, and I'm not aware of any mechanism to suppress
stupid reports from the sending side.

On Thu, Aug 10, 2023 at 10:35 AM Benoit Panizzon via mailop
 wrote:


Hi Team

I would be very happy, if anymone at microsoft could get
in touch with me, we probably get more than 90% false positives from
the microsoft spam report robot.

Newest crazy addition!

exam...@outlook.com is sending an email indicating request for a
delivery report.

Our server AFTER delivering the email, obliges:

From:(Mail Delivery System)
To: exam...@outlook.com
Successful Mail Delivery Report

This is the mail system at host idefix.imp.ch.

Your message was successfully delivered to the destination(s)
listed below. If the message was delivered to mailbox you will
receive no further notifications. Otherwise you may still receive
notifications of mail delivery errors from other systems.

The mail system
=== snip ===

exam...@outlook.com is reporting this as spam. We get a complaint from
microsoft asking for us to suspend 'mailer daemon' for sending
unsolicited emails. Doh!

Microsoft, could you please just block customers like this one who
repeatedly abuse your spam complaint machinery?

Or build some simple rules to redirect 'dubious' spam reports to be
reviewed by a human before clogging abuse desks of fellow ISP with 
such

reports?

Dubious could be:

* from a 'mailer daemon'.
* containing other signs that it is some sort of bounce.
* Quoted text matching an email recently sent by your customer.

etc

I also wonder if you told your customers, confirming to GDPR, that you
are disclosing their mail content to the abuse desk of any ISP around
the world. We repeatedly get all sort of emails reported as spam, 
which

I would consider to contain very sensitive information like salary
information etc.

Mit freundlichen Grüssen

-Benoît Panizzon-
--
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
___
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] Big Outbreak at Mailgun Yesterday?

[Jarland Donnell via mailop]

Mailgun has at least been pretty responsive to abuse complaints lately, 
major props to them for that. That alone sets them several grades above 
their marketed counterparts.


Now Shopify is becoming a problem over here. You can register people for 
newsletters at Shopify stores and if the unsubscribe links ever actually 
result in a removed subscription, it would be news to me. Plus they 
completely ignore abuse complaints at every level. So they're almost 
equal to a criminal enterprise at this stage.


On 2023-07-20 09:15, Michael Peddemors via mailop wrote:

All guardpost IPs, but again it would be nice if big ESP's used the 
actual sender in the MAIL FROM's so that only the bad guys get blocked, 
and not all their customers..


IMHO..

Sorry everyone, haven't had much time for our regularly scheduled 
'state of the union', working on getting other team members on the 
list, to start posting.


But next week, will make sure we get a full take on the trends over the 
last couple of weeks.


-- Michael --

--
"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 mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Jarland Donnell via mailop]

Perhaps it's going off topic and apologies if so, but this makes me 
wonder a second thing. Who is, and why are they, adding subdomains to 
the PSL when subdomains above that in hierarchy are in the same zone 
file?


On 2023-07-13 13:06, Robert L Mathews via mailop wrote:


On 7/13/23 10:44 AM, Jaroslaw Rafa via mailop wrote:

If .tld is on PSL, then example.tld will be the organizational domain. 
And
it definitely should have its own zone file, so it should have SOA. I 
can't

imagine a scenario in which it doesn't.


An example is something like "apc.homeoffice.gov.uk": its parent 
"homeoffice.gov.uk" is on the PSL, but both appear to be part of the 
same zone:


$ dig apc.homeoffice.gov.uk SOA

... QUERY: 1, ANSWER: 0, AUTHORITY: 1 ...

;; AUTHORITY SECTION:
homeoffice.gov.uk.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] No MX but A: broken MTA(s)

[Jarland Donnell via mailop]

Does anyone actually receive mail by their A record in 2023? I'd just 
assume break the RFC and save the resources for retrying and eventually 
bouncing every email that ends up attempting delivery to an A record.


On 2023-07-11 14:45, Michael Orlitzky via mailop wrote:


On Tue, 2023-07-11 at 13:36 -0500, Grant Taylor via mailop wrote:


However, I don't see any mention of a-record fallback in RFC 5321.  --
I didn't chase any updates.  --  I do see four occurances of "fall" in
the document, three of which are fall( )back and all three have to do
with something other than MX records vs a-records.

As such, I'd question the veracity of current SMTP needing to support
a-record fallback.


5.1.  Locating the Target Host

Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in Sections 2.3.5 and 3.6),
a DNS lookup MUST be performed to resolve the domain name... The lookup
first attempts to locate an MX record associated with the name... If an
empty list of MXs is returned, the address is treated as if it was
associated with an implicit MX RR, with a preference of 0, pointing to
that host.

___
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] SendGrid is deleting your mail

[Jarland Donnell via mailop]

I thought I was a wild one with testing in production with SpamAssassin 
rules set to 0 score. That way I could determine the impact without 
making the impact at all, or without adding resource overhead to other 
parties just because I was playing around.


I think it's a good point here that we all wish everyone would do the 
same thing, but you can't just get upset at people reacting to others 
who aren't doing things the way we wish they were, and not also get 
upset at the people who they're reacting to. In a perfect world we'd all 
do the same things all of the time, in reality there's nuance and not 
making adjustments for it is to be willfully ignorant of it. We all do 
what we have to do at the end of the day.


I'm no fan of SpamGrid, I'm actually genuinely surprised to see that 
anyone works on the project at all anymore. I thought Twilio was just 
going to milk it until it's revenue dropped below overhead and then 
repurpose the IPs / sell off the brand. Since, you know, it seems like 
so little there has changed from an external perspective since this: 
Sendgrid Under Siege from Hacked Accounts - Krebs on Security [1]


But credit where it's due, someone digging into response codes and 
reacting to the strange ways that everyone else handles their own mail 
servers, I respect the work.


On 2023-06-23 16:28, Michael Orlitzky via mailop wrote:


I don't necessarily disagree with this, but here's another perspective.
Blacklists are hard to test in production because they rely on a third
party. When testing a new config, it's common (at least in postfix
land) to switch your reject code from 5xx to 4xx while you see how
things play out. Basically, you're giving yourself time to look at the
logs and decide if you're losing mail that you don't want to lose. When
you're satisfied, you switch the reject code back to 5xx. There are
several config parameters designed for this.



Links:
--
[1] 
https://krebsonsecurity.com/2020/08/sendgrid-under-siege-from-hacked-accounts/___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] UCEPROTECT L2 fact

[Jarland Donnell via mailop]

I'm afraid what I have around it is anecdotal. However, if the topic is 
of interest I would highly recommend setting it up in SpamAssassin or 
something like that, with a 0 score. Use that to gather data on it. I 
don't think you'd find any false positives from doing so. I initially 
imported the L1 list to kickstart our RBL (mxrbl.com) and the only 
requests for removal of those initial IP sets were from people who were 
compromised and then fixed it, or from new IP owners reasonably denying 
connection to the previous owner (OVH cloud mostly).


Of the third parties I've brought in to augment my spam fighting, UCE L1 
probably generated the least complaints. Even spamrats generates more 
user complaints, despite being fairly sane.


On 2023-05-22 14:29, Bill Cole via mailop wrote:


On 2023-05-22 at 12:01:52 UTC-0400 (Mon, 22 May 2023 11:01:52 -0500)
Jarland Donnell via mailop 
is rumored to have said:

I have not personally run into anyone using L3 or L2 in my experiences 
thus far. Their L1 list is what most, if anyone, would be subscribing 
to I would think. Their L1 list is actually really, really good.


Do you have any hard numbers on this? E.g. on marginal improvement it 
provides?


My checking of it is very limited, as I only check what makes it to my 
eyeballs,  which is not influenced by UCEPROTECT. So when I check an 
IP, it's because multiple more trustworthy DNSBLs, SpamAssassin, and my 
own bespoke tactics have failed to identify spam. I see almost no 
matches.


On 2023-05-14 05:47, Slavko via mailop wrote:

Hi,

i read multiple times, from multiple sources about UCEPROTECT
BL, how it is suspicious, etc...

Recently i got notification from ShadowServer, that i am on
blacklist, in particular on UCEPROTECT-L2 BL, which AFAIK
blocks whole networks as anounced by ASN. Thus i was curious,
what happens around me.

Today UCEPROTECT reports 32 incidents for /22 net. We can
discuss if 32 is enough for blocking whole network block or
not, but OK -- 32 incidents is over their policy... But all these
32 incidents was generated by 1 (one) IP! In other words,
one IP is enough for UCEPROTECT to block whole /22 network.

Now i really can know how wrong is this BL (and no, i never
used it, i even removed it from my check script)...

I am not very interested in that list, nor in how bad that RBL
is, but i am curious: is someone (bigger than personal) using
it? Or do you know someone who is using it? What is/can be
the reason to use it?

thanks



___
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] UCEPROTECT L2 fact

[Jarland Donnell via mailop]

Definitely. They'll even tell you up front that this isn't your average 
list and will block legitimate email: 
https://www.uceprotect.net/en/index.php?m=3&s=5


On 2023-05-22 15:02, John Devine wrote:

Hmmm I started using dnsbl-3.uceprotect.net a few months ago, should I 
desist?


JD

On 22 May 2023, at 17:01, Jarland Donnell via mailop 
 wrote:


I have not personally run into anyone using L3 or L2 in my experiences 
thus far. Their L1 list is what most, if anyone, would be subscribing 
to I would think. Their L1 list is actually really, really good.


On 2023-05-14 05:47, Slavko via mailop wrote:
Hi,

i read multiple times, from multiple sources about UCEPROTECT
BL, how it is suspicious, etc...

Recently i got notification from ShadowServer, that i am on
blacklist, in particular on UCEPROTECT-L2 BL, which AFAIK
blocks whole networks as anounced by ASN. Thus i was curious,
what happens around me.

Today UCEPROTECT reports 32 incidents for /22 net. We can
discuss if 32 is enough for blocking whole network block or
not, but OK -- 32 incidents is over their policy... But all these
32 incidents was generated by 1 (one) IP! In other words,
one IP is enough for UCEPROTECT to block whole /22 network.

Now i really can know how wrong is this BL (and no, i never
used it, i even removed it from my check script)...

I am not very interested in that list, nor in how bad that RBL
is, but i am curious: is someone (bigger than personal) using
it? Or do you know someone who is using it? What is/can be
the reason to use it?

thanks

___
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] UCEPROTECT L2 fact

[Jarland Donnell via mailop]

and charges for delists...


This is a very commonly cited misconception. Delisting from their BL is 
automated. If you are impatient and demand immediate intervention, you 
can pay them to circumvent their automation and delist you early. This 
is only beneficial if you have actually fixed the reason you were 
listed, and are on your way to being delisted by their automation 
anyway. Else, you'll simply be relisted and you'll have made a nice 
donation to them for nothing.


On 2023-05-22 09:48, Steve Freegard via mailop wrote:


Don't get me started on this one.

I'm not aware of anyone other than zealots that use it.  I can't 
imagine that it's useful for anything other than scoring a very small 
amount in something like SA/rspamd or for use in some meta/composite 
rules, but IMHO it's a waste of DNS lookups.


It's so strict and badly run that it gives the rest of us a bad name 
(and charges for delists...).  Of all the DNSBLs that I wish would just 
disappear, this would be at number one on my list.


Kind regards,
Steve.

On Mon, 22 May 2023 at 09:31, Slavko via mailop  
wrote:



Hi,

i read multiple times, from multiple sources about UCEPROTECT
BL, how it is suspicious, etc...

Recently i got notification from ShadowServer, that i am on
blacklist, in particular on UCEPROTECT-L2 BL, which AFAIK
blocks whole networks as anounced by ASN. Thus i was curious,
what happens around me.

Today UCEPROTECT reports 32 incidents for /22 net. We can
discuss if 32 is enough for blocking whole network block or
not, but OK -- 32 incidents is over their policy... But all these
32 incidents was generated by 1 (one) IP! In other words,
one IP is enough for UCEPROTECT to block whole /22 network.

Now i really can know how wrong is this BL (and no, i never
used it, i even removed it from my check script)...

I am not very interested in that list, nor in how bad that RBL
is, but i am curious: is someone (bigger than personal) using
it? Or do you know someone who is using it? What is/can be
the reason to use it?

thanks

--
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--

Steve Freegard

|

Senior Product Owner

T.

+44 7740 364348

abusix.com [1]

Book a meeting [2]

[3]

[4]

[5]

[6]

CONFIDENTIALITY This email and any attachments are confidential and may 
also be privileged or otherwise protected from disclosure. If you are 
not the named recipient, please notify the sender immediately and do 
not disclose the contents to another person, use it for any purpose, or 
store or copy the information in any medium.


You'll find further information about privacy here [7].

[8]

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




Links:
--
[1] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzZTf64_AIC7pyl-xmo2L5eYJtYu1PnTYrDUUBmQW-VxiqyfDuPS_3WZnIEFz1xocGdBhnxAEyhHhg3_G29KPX5gu0-0JxXoL3Lw4zV1rZI4zA5EgDWnGc90iUX1HRTDIs=
[2] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzdypi6WPqhVkFKkuLiMX0pY_5fawxs7P25-lwfZUyr7w==
[3] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyIo6EwBskR6pg3M12nuwEx_9G03qmurLHy8H_IjsK3cg==
[4] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDweOZAf2SFcCyyLHlLyd4j2GB_p_YWWJ_3WJxEqTQND2A==
[5] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDz5UNyOTEm_EvRFXdshn5-xBpkDGWEZYln2qrkxaFuQc-FVdHa5XQ8gkUA8UK9te-A=
[6] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyEop3qI2i2HFrm2U65Sd5oxcB4tERwhAI5MzR-NKIKtw==
[7] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDwp6TTQAR8uw54LR3mph76uODAm2MU0ep-sVltZqsar_A==
[8] 
https://cloud.letsignit.com/collect/b/64527ce39279adc5fb539cbb?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzNwzD38Zsn2jhinwiDHXxKe3fLl79VhrrHHWopNbulGK8U-TmlvnN27_c7uQRHayw=___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] UCEPROTECT L2 fact

[Jarland Donnell via mailop]

I have not personally run into anyone using L3 or L2 in my experiences 
thus far. Their L1 list is what most, if anyone, would be subscribing to 
I would think. Their L1 list is actually really, really good.


On 2023-05-14 05:47, Slavko via mailop wrote:


Hi,

i read multiple times, from multiple sources about UCEPROTECT
BL, how it is suspicious, etc...

Recently i got notification from ShadowServer, that i am on
blacklist, in particular on UCEPROTECT-L2 BL, which AFAIK
blocks whole networks as anounced by ASN. Thus i was curious,
what happens around me.

Today UCEPROTECT reports 32 incidents for /22 net. We can
discuss if 32 is enough for blocking whole network block or
not, but OK -- 32 incidents is over their policy... But all these
32 incidents was generated by 1 (one) IP! In other words,
one IP is enough for UCEPROTECT to block whole /22 network.

Now i really can know how wrong is this BL (and no, i never
used it, i even removed it from my check script)...

I am not very interested in that list, nor in how bad that RBL
is, but i am curious: is someone (bigger than personal) using
it? Or do you know someone who is using it? What is/can be
the reason to use it?

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

[mailop] Massive botnet going off today?

[Jarland Donnell via mailop]

Curious if anyone else is seeing an event similar to this. Here's the 
logs of 1 hour on one of our servers, for what I propose to be a botnet: 
https://clbin.com/4khRA


I'm leaving the recipient domains in it because they're not actually 
customer domains. Either they used to be, or they've had their MX 
pointed to us maliciously. I can't accurately say at the moment. 
Whatever is happening in these logs, it looks fairly consistent, and 
quite distributed. What I can't figure out yet, and I'm hoping responses 
or lack thereof from others will shed light on, is whether or not this 
is a targeted attack against our infrastructure or simply a large scale 
event that we're all seeing.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Amazon please stop your outgoing spam

[Jarland Donnell via mailop]

To be fair it sounds like they're providing fine customer service, their 
customer is just trash.


On 2023-05-12 12:39, Mary via mailop wrote:


No they haven't, but I don't expect them to do so.

Don't they have the same zero-customer-support policy like every other 
major tech company?


On Fri, 12 May 2023 17:40:18 +0100 John Devine via mailop 
 wrote:



Have Amazon commented at all?

JD

___
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] Missing PTR errors from Google?

[Jarland Donnell via mailop]

Curious if anyone else is seeing an increase in errors like this from 
Google:


550-5.7.25 [136.175.108.212] The IP address sending this message does 
not have a PTR record setup, or the corresponding forward DNS entry does 
not point to the sending IP. As a policy, Gmail does not accept messages 
from IPs with missing PTR records. Please visit 
https://support.google.com/mail/answer/81126#ip-practices for more 
information. l82-20020acabb5500b00364a7d5bb44si4487299oif.64 - gsmtp


A few of my servers screwed up SRS config for forwarding and began 
forwarding email with the original envelope sender, and it seems to have 
a 100% correlation to these messages in our logs. It would seem that 
Google is returning the wrong error for the event, but I'm curious if 
it's somehow isolated to me. I suppose you might need to be forwarding 
email poorly to have seen it, but never hurts to ask.


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

Re: [mailop] New to mass mailings

[Jarland Donnell via mailop]

On the chance that John's message here is read as "well that's just one 
opinion" let me reiterate: If I find someone emailing my customers from 
a list of scraped or purchased "leads" I will immediately and 
permanently block them from my infrastructure, and refund every customer 
that thinks I was too harsh to do so. We all have our own interpretation 
of what is a reasonable reaction but one think you'll see us all shout 
in perfect concert: This is the definition of spam.


On 2023-05-08 21:14, John Levine via mailop wrote:

It appears that H via mailop  said: How are you 
acquiring your leads, are you purchasing them from somewhere? Building 
lists of leads ourselves but also purchased leads. Just the former 
would be way too slow of course. By the way, we are communicating
with corporate customers, not with individuals using their personal 
email addresses.


Oh, that's your problem. If you buy addresses and send mail to them,
the recipients will complain that you're sending them spam. And they
will be right. Don't do that. Scraping addresses off web sites is no
better. Don't do that either.

R's,
John

PS: We know the people who sold them claimed they're 100% opt-in.
___
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] Dormant IP range coming online for large event

[Jarland Donnell via mailop]

Hey friends,

I just wanted to offer a heads up for anyone doing research, watching 
statistics, or that would be so kind as to add any 
whitelistings/mitigations for it. We're about to spin up 
136.175.109.0/24 for an event that starts on May 15th. A customer of 
ours, who is very legitimate, will be running a potentially high volume 
event. It'll be heavily monitored for abuse, the emails will be for 
registrations for a giveaway, and the list will be deleted after the 
event. All very above board.


But in this case where our emails have been coming exclusively from 
136.175.108.0/24, you'll see emails from our systems being spread across 
both /24s for about a week. Afterward, we'll spin 136.175.109.0/24 back 
down and reduce our load to the one /24 again.


I'll be at the helm for the event. If you see abusive behavior it'll 
probably be at the same time that I do (which should have very quick 
correlation with a halt in the behavior). But ab...@mxroute.com is alive 
and well, and all read/processed by a human (me).


Thanks friends!

Jarland Donnell
MXroute Administrator
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Charter/Spectrum Tampa SMTP relay question

[Jarland Donnell via mailop]

Relaying your domain email through your local ISP, is that a common 
approach? It seems weird from my perspective. I’d route it through 
mail.baby instead and call it a day. Interserver is doing great work 
over there with a mailchannels fallback for pennies.


On 2023-04-28 10:11, Jay R. Ashworth via mailop wrote:
A couple days ago, a client started getting 550 errors on their 
outbound mail
from a local install of KerioConnect, saying that the From had to match 
the
email address in the SMTP Auth -- which of course it wouldn't, domain 
relaying

doesn't work like that.

This sounds like a deliverability policy change, and I hope it's 
obvious why
I don't even *expect* the tech support line to know what I'm talking 
about. :-)


Can anyone in Spectrum confirm or deny, and maybe tell me what the 
expected

way to do this has become now?

Cheers,
-- jra

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

Re: [mailop] ab...@microsoft.com => Mailbox full

[Jarland Donnell via mailop]

The age old problem: Hire a bunch of people to read it that aren't 
skilled enough to do anything about it, or hire people who are skilled 
to handle it but don't have the time or manpower to read it all.


I'm surprised they even have an abuse inbox. I just block spammy senders 
from MS/O365 domains and let them deal with the reduced number of people 
they can do business with, as the result of their choice to send spam.


On 2023-04-20 11:51, Michael Rathbun via mailop wrote:

On Thu, 20 Apr 2023 15:32:18 +0200, Benoit Panizzon via mailop
 wrote:

...


Delivery has failed to these recipients or groups:

ab...@microsoft.com
The recipient's mailbox is full and can't accept messages now. Please 
try resending your message later, or contact the recipient directly.


Back when I worked in the O365 spam analysis process, I launched a 
crusade to
discover who, if anybody, actually reads abuse@microsoft.  The eventual 
result

was that there was a person who supposedly looked at it now and again.

[snip]


Yes please, how can I contact the microsoft abuse desk more directly?


There wasn't one when I worked there.  Not from lack of trying to get 
one

launched.

mdr

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

Re: [mailop] [E] Yahoo "Message not allowed" error

[Jarland Donnell via mailop]

That is actually the entirety of the SMTP response from 
mx-eu.mail.am0.yahoodns.net at that time:


"554 Message not allowed - [299]"

Other error messages linked to 
https://postmaster.yahooinc.com/error-codes but not that one. Nothing 
seems to help much on that page for this case unless I just assume the 
message is "Those people can't email Yahoo anymore." I'm fairly 
confused.


On 2023-04-18 16:25, Marcel Becker via mailop wrote:

On Tue, Apr 18, 2023 at 12:16 PM Jarland Donnell via mailop
 wrote:


id=<481770.862217189-sendEmail@srv4414> (554 Message not allowed -
[299])


This is most likely not the full SMTP response we provide. The full
one will tell you the reason -- including a link to a page explaining
what to do and who to contact.

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

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

[mailop] Yahoo "Message not allowed" error

[Jarland Donnell via mailop]

A customer of ours has been seeing this lately for their emails:

Apr 17 21:19:12 zmta1 node[116029]: info Sender/default/116029[11] 
1879115f156000becb.001 REJECTED[other] from={censored} 
to={censored}@yahoo.dk src=136.175.108.211 
mx=mx-eu.mail.am0.yahoodns.net[188.125.72.74] 
id=<481770.862217189-sendEmail@srv4414> (554 Message not allowed - 
[299])


They seem to be fine on SPF, DKIM, etc. I'm curious if anyone here has 
any insight, or if anyone from Yahoo might be willing to reply off list 
and share any insights. Anything is appreciated!

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

Re: [mailop] SPF behavior on email forwarding

[Jarland Donnell via mailop]

On 2023-04-14 07:45, Taavi Eomäe via mailop wrote:

On 14/04/2023 15:22, Laura Atkins via mailop wrote:
Unless they’re rewriting the envelope, yes. This is part and parcel of 
how SPF works. I’m somewhat surprised that those services are not 
rewriting the envelope, though. Unfortunately, I don’t have the Google 
access / infrastructure to test this and see what they’re doing.


Google supports ARC, SRS is a hack of the past compared to it.


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


Correct me if I'm wrong but isn't the trust level of ARC basically 
"trust me bro?" At least SRS and SPF require ownership of the domain.

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

Re: [mailop] Sent my first spam in 26 years

[Jarland Donnell via mailop]

Did you get any samples of the spam campaign? Most of the ones I've seen 
in the last few weeks appear to be more computer viruses (stealing 
credentials from the user's systems), and I've had all of zero 
blacklistings for the ones that got past me even for several hours.


On 2023-04-13 18:16, Peter E. Fry via mailop wrote:
Got a couple user accounts compromised.  One was used to send a spam, 
killed after it hit the quota (100).  I happened to be sitting on the 
server logs, trying to pin down the very odd joe-job done using 
information from one account when the other blew up in my face, so I 
was able to kill them immediately.


I don't appear to be in any RBLs... yet...
I've done the basic work on my equipment, of course -- hopefully I 
don't have any more holes.  Y'all got any recommendations for public 
space cleanup work, so to speak?



Side note: One compromised account has a likely vector; the other is a 
mystery, which is disturbing.


Other side note: Had my open relay exploited in 1997.


Peter E. Fry


___
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] Google PTR lookup issues or just me?

[Jarland Donnell via mailop]

I've seen a slight increase of messages like this from Google recently:

550-5.7.25 [136.175.108.254] The IP address sending this message does 
not have a PTR record setup, or the corresponding forward DNS entry does 
not point to the sending IP. As a policy, Gmail does not accept messages 
from IPs with missing PTR records. Please visit 
https://support.google.com/mail/answer/81126#ip-practices for more 
information


Is anyone else seeing similar behavior? I count 26 instances today, and 
3 complaints thus far spread out over let's say 1-3 weeks (working from 
memory). I'm curious if it's just me.

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

Re: [mailop] linodeusercontent.com/googleusercontent.com, I'm so done with you

[Jarland Donnell via mailop]

On 2023-04-08 01:20, Hans-Martin Mosner via mailop wrote:
And that's why I'm still in favor of blocking spammer-hosting providers 
swiftly and broadly. It needs to affect the non-spamming customers, 
too, to be a strong economic incentive for keeping spammers out. Of 
course I also punch holes when contacted by affected e-mail users, but 
at least I have a chance to tell them that they're with a bad provider 
and are supporting criminal activities by letting themselves being used 
as human shields.




And see if I did something like that too many times, my customers would 
all leave me to go to a competitor that didn't. I would be empowering 
that competitor to exist by giving a clear opening for a market position 
that I chose to exit. Which means that then my net impact on the 
situation, after making too many of those blocks, would be exactly 
equivalent to me never having made the blocks at all. Which means all I 
effectively did was transfer my income stream to another party, the 
internet never changed. Nothing got better, I'm simply then an unknown 
martyr that no one wants to interview.


That's where the real problem lies, when you realize that there are only 
a handful of companies that can actually make an impact on what each 
other does. All you really end up doing is torturing your users, unless 
you run one of those few companies.

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

Re: [mailop] linodeusercontent.com/googleusercontent.com, I'm so done with you

[Jarland Donnell via mailop]

I mean if the goal is to try not to appear hostile to customers, rate 
limiting a port is as bad or worse than blocking it. At least with 
blocking you know right away, but rate limiting it could create much 
more time in troubleshooting for an admin that missed the 
announcement/notification/policy about it. And there are obviously 
plenty of perfectly fine reasons to burst a port that doesn't even 
bother anyone but yourself.


On 2023-04-07 23:29, Suresh Ramasubramanian via mailop wrote:

Why would you need to blanket block port 25 outbound when you could
rate limit and/or dynamically block it?

Yes - abusers would then go and get a few hundred thousand accounts
and send maybe 10 emails per vps or droplet or whatever the abused
provider calls it.

And this is just smtp based abuse - doesn’t count for example :

Farmed account signup bots

Bots that will spam through other webmail, social media etc providers
from your IP space

Assorted other nastiness

Controlling bad signups becomes essential - and deciding if you want
to keep and retain the sort of customers that trigger blocks.

The last several types might end up with a nullroute being applied in
extreme cases, as you can appreciate

--srs
-

From: mailop  on behalf of Jarland Donnell
via mailop 
Sent: Saturday, April 8, 2023 9:47:23 AM
To: mailop@mailop.org 
Subject: Re: [mailop] linodeusercontent.com/googleusercontent.com, I'm
so done with you

To be clear they have an amazing abuse team, easily the first people I

would hit up if I were hiring in that area. Just top notch admins.

Blocking SMTP by default makes sense, but settling on the best way to
handle opening it (automated? manual review?) is a discussion that is
very easy to get stuck in. I don't know where they're at on that
discussion by now, but when I left it was something I would have
referred to as "on the table." That to say most of the stakeholders
would entertain the discussion.

There's likely an attached fear that appearing even remotely hostile
to
customers could quickly drive them to a competitor in a pretty
competitive market. You have to think that as much as people like you
and I would appreciate them doing it, their customers would likely
only
be speaking up about it to say the opposite. You might decrease abuse
complaints but you might also decrease NPS scores, and the people
sending abuse complaints are usually not your customers (so pleasing
them doesn't = $). You might think that reducing IP blacklisting could

reduce customer complaints and bad NPS scores. I don't think reality
actually plays out that way because Gmail doesn't use external
blacklists (that I'm aware of), and Microsoft will unblock individual
IPs upon request (sometimes after some back and forth), and that
accounts for almost all of what people want anyway. And even that
would
only matter to customers that run mail servers anyway.

On 2023-04-07 22:02, Neil Anuskiewicz via mailop wrote:

On Apr 4, 2023, at 12:42 PM, Jarland Donnell via mailop
 wrote:

I feel like I've told this story before on the list, but I can't



recall. It always feels worth telling.

When I worked at DigitalOcean I took what felt like a year (may

have

been less) and I focused more energy than any one person probably

ever

has at any cloud provider on tackling spammers based on abuse
complaints and recognition of patterns recognized from

investigating

abuse complaints. I had Python scripts running through the customer



database at one point looking for key indicators and would mass

shut

down accounts either before they started to spam, or not very long
after. No false positives. I would shut down a ton of accounts

every

day to zero complaints, because they were all exactly what I knew

they

were and they knew what they were doing. I had video meetings with
several frequent complainers who would come at us from social media



angles to inform them of how their complaints were informing my

work,

and what I was doing to try to reduce their complaints.

Despite all of that, I don't think I ever succeeded in even

reducing

the complaints. The only way to tackle this successfully at a cloud



provider, in my opinion, is to block SMTP traffic and only unblock

it

under certain conditions. There will never be enough humans as
dedicated and capable as I was, without raising prices to the point



that it drives customers and spammers to the clouds that aren't
spending that kind of money on abuse handling, to make a

difference.


Just my 2c.


Jarland, I see your point. And with that much abuse it doesn’t

seem

unreasonable to block SMTP traffic by default. Perhaps there’d be

a

process of getting it turned on but with some vetting. Anyway, now I



kind of understand why so much is coming out of DO. They are trying

to

bail out a class 5 rapids with a bucket. I wonder why they don’t

look

at SMTP? This massive, e

Re: [mailop] linodeusercontent.com/googleusercontent.com, I'm so done with you

[Jarland Donnell via mailop]

To be clear they have an amazing abuse team, easily the first people I 
would hit up if I were hiring in that area. Just top notch admins.


Blocking SMTP by default makes sense, but settling on the best way to 
handle opening it (automated? manual review?) is a discussion that is 
very easy to get stuck in. I don't know where they're at on that 
discussion by now, but when I left it was something I would have 
referred to as "on the table." That to say most of the stakeholders 
would entertain the discussion.


There's likely an attached fear that appearing even remotely hostile to 
customers could quickly drive them to a competitor in a pretty 
competitive market. You have to think that as much as people like you 
and I would appreciate them doing it, their customers would likely only 
be speaking up about it to say the opposite. You might decrease abuse 
complaints but you might also decrease NPS scores, and the people 
sending abuse complaints are usually not your customers (so pleasing 
them doesn't = $). You might think that reducing IP blacklisting could 
reduce customer complaints and bad NPS scores. I don't think reality 
actually plays out that way because Gmail doesn't use external 
blacklists (that I'm aware of), and Microsoft will unblock individual 
IPs upon request (sometimes after some back and forth), and that 
accounts for almost all of what people want anyway. And even that would 
only matter to customers that run mail servers anyway.



On 2023-04-07 22:02, Neil Anuskiewicz via mailop wrote:
On Apr 4, 2023, at 12:42 PM, Jarland Donnell via mailop 
 wrote:


I feel like I've told this story before on the list, but I can't 
recall. It always feels worth telling.


When I worked at DigitalOcean I took what felt like a year (may have 
been less) and I focused more energy than any one person probably ever 
has at any cloud provider on tackling spammers based on abuse 
complaints and recognition of patterns recognized from investigating 
abuse complaints. I had Python scripts running through the customer 
database at one point looking for key indicators and would mass shut 
down accounts either before they started to spam, or not very long 
after. No false positives. I would shut down a ton of accounts every 
day to zero complaints, because they were all exactly what I knew they 
were and they knew what they were doing. I had video meetings with 
several frequent complainers who would come at us from social media 
angles to inform them of how their complaints were informing my work, 
and what I was doing to try to reduce their complaints.


Despite all of that, I don't think I ever succeeded in even reducing 
the complaints. The only way to tackle this successfully at a cloud 
provider, in my opinion, is to block SMTP traffic and only unblock it 
under certain conditions. There will never be enough humans as 
dedicated and capable as I was, without raising prices to the point 
that it drives customers and spammers to the clouds that aren't 
spending that kind of money on abuse handling, to make a difference.


Just my 2c.


Jarland, I see your point. And with that much abuse it doesn’t seem 
unreasonable to block SMTP traffic by default. Perhaps there’d be a 
process of getting it turned on but with some vetting. Anyway, now I 
kind of understand why so much is coming out of DO. They are trying to 
bail out a class 5 rapids with a bucket. I wonder why they don’t look 
at SMTP? This massive, expensive yet inadequate system doesn’t seem 
likely to be in DO’s interest. Where’s the benefit to DO to do things 
this way? Just curious.


Neil
___
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] linodeusercontent.com/googleusercontent.com, I'm so done with you

[Jarland Donnell via mailop]

I feel like I've told this story before on the list, but I can't recall. 
It always feels worth telling.


When I worked at DigitalOcean I took what felt like a year (may have 
been less) and I focused more energy than any one person probably ever 
has at any cloud provider on tackling spammers based on abuse complaints 
and recognition of patterns recognized from investigating abuse 
complaints. I had Python scripts running through the customer database 
at one point looking for key indicators and would mass shut down 
accounts either before they started to spam, or not very long after. No 
false positives. I would shut down a ton of accounts every day to zero 
complaints, because they were all exactly what I knew they were and they 
knew what they were doing. I had video meetings with several frequent 
complainers who would come at us from social media angles to inform them 
of how their complaints were informing my work, and what I was doing to 
try to reduce their complaints.


Despite all of that, I don't think I ever succeeded in even reducing the 
complaints. The only way to tackle this successfully at a cloud 
provider, in my opinion, is to block SMTP traffic and only unblock it 
under certain conditions. There will never be enough humans as dedicated 
and capable as I was, without raising prices to the point that it drives 
customers and spammers to the clouds that aren't spending that kind of 
money on abuse handling, to make a difference.


Just my 2c.

On 2023-04-04 11:14, Hans-Martin Mosner via mailop wrote:
Those two cloud providers are currently providing 99% of the incoming 
spam at one site.


googleusercontent.com sends a never-ending flood of DHL phishing mails.

linodeusercontent.com sends unsolicited ad crap using a domain 
"klwinkel.app".


Time for large scale IP range blocking, I really can't stand this 
anymore.


Is there anybody there who reads abuse reports, tracks down culprits 
and *fooking shuts them down*?


Aggravated,
Hans-Martin

___
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] Absurd Outlook-originating spam from i...@usa.org

[Jarland Donnell via mailop]

I'm curious if anyone else is seeing this trend today. I've gathered and 
mildly censored some logs around this campaign I'm seeing today:


https://clbin.com/DkSDr

Getting a bit of it across the fleet but none more than that one server 
I pulled those logs from. Just some counts from the fleet of 
"i...@usa.org" strings in the current exim log:


tuesday.mxrouting.net: 11
longhorn.mxrouting.net: 0
safari.mxrouting.net: 12
blizzard.mxrouting.net: 16
pixel.mxrouting.net: 32
lucy.mxrouting.net: 0
redbull.mxrouting.net: 2
echo.mxrouting.net: 16
witcher.mxrouting.net: 0
wednesday.mxrouting.net: 0
moose.mxrouting.net: 2
eagle.mxlogin.com: 28
london.mxroute.com: 76
shadow.mxrouting.net: 22
taylor.mxrouting.net: 0
monday.mxrouting.net: 6
sunfire.mxrouting.net: 1159
arrow.mxrouting.net: 18

Lucky for me, it mainly targeted domains that seem to have left our 
service but left their MX records pointing to our servers (or 
potentially domains that pointed MX to our servers just to poorly DDOS 
it with this campaign). But it is an odd campaign indeed, and I haven't 
seen one quite this bad while simultaneously consistent from Microsoft 
servers in recent memory. Are others seeing a similar campaign? Mostly 
just asking to determine if it's targeted.

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

Re: [mailop] Hotmail will start rejecting messages that fail DMARC

[Jarland Donnell via mailop]

I'd like to add a +1 to this for clarification, but in my case I'm 
focused solely on SRS. Will Hotmail reject DMARC failures based on From 
headers or envelope senders? I mean, Gmail already rejects a lot of 
DMARC failures based on From headers (I assume, since rewriting envelope 
sender doesn't seem to consistently change the result), so there's 
plenty of precedent for it and most people aren't really going to blame 
anyone for doing what Gmail does. But it sure is nice if our users can 
see the same behavior when forwarding as they have until now.


On 2023-03-22 16:52, Sebastian Nielsen via mailop wrote:

I think forwarders and mailing lists should start rewriting From:
instead to a adress for which they are authorative, or encapsulate the
list message in a new rfc822 container, where the inner container is
the email unmodified, and the outer container is From: replaced with
the list or forwarding adress, To: replaced with forwarding final
destination, and Subject: replaced with "Fwd: [Original subject]".

That should make it DMARC safe, even with strict alignment enabled.

 Originalmeddelande 
Från: John Levine via mailop 
Datum: 2023-03-22 20:28 (GMT+01:00)
Till: mailop@mailop.org
Kopia: jdellap...@microsoft.com
Ämne: Re: [mailop] Hotmail will start rejecting messages that fail
DMARC

It appears that Jeff Dellapina via mailop 
said:

-=-=-=-=-=-
-=-=-=-=-=-

Hey Mailop,

Microsoft is proud to announce our Consumer email service

(Outlook/Hotmail/MSN/Live) will now honor the DMARC record of
"p=reject" by

rejecting the message if the domain fails DMARC. Previously, messages

that failed DMARC were sent to the junk folder (Quarantine). Over the

next 30 days these DMARC-failing messages will be rejected.


Any chance you'll be using ARC headers to mitigate the damage to
mailing lists and other forwarders?

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

Re: [mailop] New iteration of SMTP callback snakeoil

[Jarland Donnell via mailop]

On the off chance that more data helps, here are my findings (with only 
recipient domains censored) based on a log audit of those "senders."


Logs: https://clbin.com/RKWkN

Considering that everything before the @ looks to be generated by an 
algorithm, it should be sufficiently redacted but still might offer 
further insight into the algorithm itself.


On 2023-03-11 05:57, Peter N. M. Hansteen via mailop wrote:

Hi,

Since some time yesterday I've seen a largish number of delivery 
attempts to
obviously generated, invalid addesses in some of our domains, with the 
following

apparent senders:

informat...@ckuser.com
informat...@mbxchk.com
informat...@reqck.com
informat...@send-now.net
informat...@usereml.com
informat...@uservfy.com
informat...@validmbx.com

I assume this is yet another round of somebody selling a SMTP callback
setup much like the morons described in this piece -

https://bsdly.blogspot.com/2017/08/twenty-plus-years-on-smtp-callbacks-are.html

but before I publish any further rants I would kind of like to hear 
what

the think they're doing.

So does anybody here have useful conact information for one or more of 
the
domains listed? I assume trying the RFC2142 addresses will be a waste 
of time.


All the best,
Peter

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

Re: [mailop] h-email.net

[Jarland Donnell via mailop]

At second glance, it seems more that I’m seeing spammers stating their 
HELO as “mail.h-email.net” while sending from IPs unrelated to that of 
the actual mail.h-email.net. So probably what I’m seeing is actually 
unrelated to anything run by whoever owns that domain.


On 2023-03-03 18:49, Richard W via mailop wrote:
My guess is these are spam support services, not spam sending services. 
They might be drop boxes or service signup boxes.  I've checked the /24 
and /22 around these IPs and natch, nadda in SpamCop for them


Richard

On 2023-03-03 6:16 p.m., Jan Schaumann via mailop wrote:

Jarland Donnell via mailop  wrote:
A quick parse of my logs suggests that it's a spam-only operation, so 
likely
won't correlate to any particular front-end mail service. I mean just 
100%
correlation with spam in my logs, and not a small amount of logs 
either.


Interesting that e.g., Spamhaus doesn't have it in its
RBL, nor do many others.  Weird.

*shrug*

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

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

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

Re: [mailop] h-email.net

[Jarland Donnell via mailop]

A quick parse of my logs suggests that it's a spam-only operation, so 
likely won't correlate to any particular front-end mail service. I mean 
just 100% correlation with spam in my logs, and not a small amount of 
logs either.


On 2023-03-03 17:12, Jan Schaumann via mailop wrote:

Hey,

Does anybody here know who h-email.net is?  I see
mail.h-email.net listed as the MX for a large number
of domains, but can't identify the organization behind
it.  (Registered through Amazon, but whois privacy...)

There are some indicators on the web that this might
be used for disposable mails, but it's not clear to me
if that is the sole use.

The other curious thing is that mail.h-email.net has
only IPv4 addresses (in Digital Ocean and Hetzner),
but h-email.net has an SPF policy that only allows
IPv6 connections:

$ host mail.h-email.net
mail.h-email.net has address 178.62.199.248
mail.h-email.net has address 165.227.156.49
mail.h-email.net has address 165.227.159.144
mail.h-email.net has address 5.75.171.74
mail.h-email.net has address 5.161.98.212
mail.h-email.net has address 167.235.143.33
$ host -t txt h-email.net
h-email.net descriptive text "v=spf1 ip6:fd96:1c8a:43ad::/48 -all"

Any thoughts?

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

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

Re: [mailop] Gmail blocking of good customer

[Jarland Donnell via mailop]

In defense of Google on that, Christine works for Shopify. Shopify is a 
huge spam outlet. If you want to flood someone's inbox with junk, find 
thousands of shopify sites and sign them up for their newsletters. Zero 
double opt in procedures, and if you happen to get a response to abuse 
complaints their response is roughly equivalent to "Deal with it."


Shopify doesn't deserve deliverability.

On 2023-02-24 18:19, Bill Cole via mailop wrote:

On 2023-02-24 at 16:09:26 UTC-0500 (Fri, 24 Feb 2023 21:09:26 +)
Simon Greenwood via mailop 
is rumored to have said:

[...]
This (which I didn't know) adds a whole different aspect to the issue 
- much has been said about how email is now centralised and is almost 
impractical to run as a small operator level, but if a company like 
Shopify and indeed Sendgrid can't assure mail delivery because the 
largest mail operators will reject mail sporadically based on 
non-specific criteria, and more that someone in Christine's position 
doesn't have someone they can call at Google or Microsoft or wherever, 
then there's a bigger problem.


Sendgrid can't deliver mail because they are grossly incompetent at 
avoiding spammers as customers.


But yes, it is a HUGE problem that the largest mailbox providers have 
essentially no support for senders except for various inaccurate 
"knowledge bases" and systems like SNDS and JMRP that don't work as 
advertised. (At least Google doesn't pretend that they want to help...) 
The fact that Christine Borgia has to put out a public SOS here to get 
random bits of advice on deliverability to Google is an indictment of 
what has become of email. It is clearly no longer possible to know how 
to do email well.

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

Re: [mailop] Gmail blocking of good customer

[Jarland Donnell via mailop]

On 2023-02-24 12:38, Andrew C Aitchison via mailop wrote:

On Fri, 24 Feb 2023, Alessandro Vesely via mailop wrote:


On Fri 24/Feb/2023 18:41:34 +0100 Christine Borgia via mailop wrote:


I also should have mentioned we use shared IPs so there is no issue 
with volume from our servers, however volume from the domain is 
definitely spikey. They only send every 2-3 months when they promote 
a new event.



I think you should try and send at least ~100 mails every day to keep 
an IP warm.  Otherwise you're a ghost...


So now you have to send spam to avoid being thought to be a spammer ?


Microsoft is the same way. It's too common now that you need a continual 
and reasonable volume of email from an IP to keep a high reputation. 
It's difficult to publicly point to the result in the places that matter 
because they're all closed and internal, but it's very noticeable and MS 
will tell you it's true if you talk to the right people. This is why I 
cut our sending pool down to a /24 from a /22 a while back, spreading 
out the volume too thin caused increased spam folder delivery 
(determined by testing and volume of user complaints).

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

Re: [mailop] Compromised email account trends

[Jarland Donnell via mailop]

Forgot to add on to this:

If your SMTP hostnames, as your customers would configure in Outlook, is 
a strange and very unlikely thing for them to send in the subject of an 
email, you can also catch these even earlier. This is a censored example 
of an email subject sent by this virus today:


T="longhorn.mxrouting.net 587 u...@domain.tld password"

It seems to pull hostname, port, user, and pass to combine and make an 
email subject. As best I can tell, from Outlook config files.


On 2023-02-21 17:04, jarl...@mxroute.com wrote:

Great post! Got another one for you all today:

coteru...@gmail.com

This one hit one of our customers pretty hard (password reuse, virus, 
bad variables).


On 2023-02-21 12:10, Steve Freegard wrote:

I recently wrote an entire blog post on this topic that might be of
interest:

https://abusix.com/resources/blocklists/compromised-account-detection-with-abusix-mail-intelligence-and-postfix/

It's based on Postfix, but adapting this for Exim shouldn't be
difficult.

Kind regards,
Steve.

On Wed, 8 Feb 2023 at 13:48, Jarland Donnell via mailop
 wrote:


Hey everyone. I've been thinking about how I could add some more
value
to this list and there's one thing I've been working on for a while
that
I think will be really helpful to share.

Email accounts get compromised. It happens. Especially when using
base
standards (IMAP/POP/SMTP) that inherently lack two-factor
authentication
mechanisms. As I discover ways to identify when accounts have been
compromised, I'd like to share them with you all.

Today I discovered a new trend based on an abuse complaint, which
allowed me to further identify several compromised user email
accounts
across our platform. I'd like to share with you the headers and
body,
censored of any customer information, that was sent to me in an
abuse
complaint (I also removed the recipient that actually reported it):


https://paste.mxrouteapps.com/?862a67d53b18e8df#2k9DaEP1V9pPe6Th5CmeMS4JbyD38ZkTdDoLpYuWEvcT


I expect that this bad actor will change their behavior, and I'll of

course adjust. However, if you turn your attention to these two
variables in your logs today you will find anyone who has been
compromised very recently by this actor:

1. Email subject appears blank in logs (ex. T="" in exim log)
2. The first recipient they send to is jackgrelesh...@gmail.com

If you find someone sending email to jackgrelesh...@gmail.com on
your
platform today, most especially with a blank subject, I will gladly
take
the beating for you if you suspend the user and find it to be a
false
positive. The idea that following these trends could produce a false

positive has, in my case at least, proven to be more of a rough
theory
than a reality.

Some bonus indications of similar but different compromises:

- Any email sent to ollegas2...@gmail.com, glob22aa.fun, or
mx373.com [1]
consistently links to what I believe is a virus that sends out a
user's
email credentials to the bad actor.

Keep up the good fight friends.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--

Steve Freegard

|

Senior Product Owner

T.

+44 7740 364348

abusix.com [2]

Book a meeting [3]

 [4]

 [5]

 [6]

 [7]

CONFIDENTIALITY This email and any attachments are confidential and
may also be privileged or otherwise protected from disclosure. If you
are not the named recipient, please notify the sender immediately and
do not disclose the contents to another person, use it for any
purpose, or store or copy the information in any medium.

You’ll find further information about privacy here [8].



Links:
--
[1] http://mx373.com
[2] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzZTf64_AIC7pyl-xmo2L5eYJtYu1PnTYrDUUBmQW-VxiqyfDuPS_3WZnIEFz1xocGdBhnxAEyhHhg3_G29KPX5gu0-0JxXoL3Lw4zV1rZI4zA5EgDWnGc90iUX1HRTDIs=
[3] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzdypi6WPqhVkFKkuLiMX0pY_5fawxs7P25-lwfZUyr7w==
[4] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyIo6EwBskR6pg3M12nuwEx_9G03qmurLHy8H_IjsK3cg==
[5] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDweOZAf2SFcCyyLHlLyd4j2GB_p_YWWJ_3WJxEqTQND2A==
[6] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDz5UNyOTEm_EvRFXdshn5-xBpkDGWEZYln2qrkxaFuQc-FVdHa5XQ8gkUA8UK9te-A=
[7] 

Re: [mailop] Compromised email account trends

[Jarland Donnell via mailop]

Great post! Got another one for you all today:

coteru...@gmail.com

This one hit one of our customers pretty hard (password reuse, virus, 
bad variables).


On 2023-02-21 12:10, Steve Freegard wrote:

I recently wrote an entire blog post on this topic that might be of
interest:

https://abusix.com/resources/blocklists/compromised-account-detection-with-abusix-mail-intelligence-and-postfix/

It's based on Postfix, but adapting this for Exim shouldn't be
difficult.

Kind regards,
Steve.

On Wed, 8 Feb 2023 at 13:48, Jarland Donnell via mailop
 wrote:


Hey everyone. I've been thinking about how I could add some more
value
to this list and there's one thing I've been working on for a while
that
I think will be really helpful to share.

Email accounts get compromised. It happens. Especially when using
base
standards (IMAP/POP/SMTP) that inherently lack two-factor
authentication
mechanisms. As I discover ways to identify when accounts have been
compromised, I'd like to share them with you all.

Today I discovered a new trend based on an abuse complaint, which
allowed me to further identify several compromised user email
accounts
across our platform. I'd like to share with you the headers and
body,
censored of any customer information, that was sent to me in an
abuse
complaint (I also removed the recipient that actually reported it):


https://paste.mxrouteapps.com/?862a67d53b18e8df#2k9DaEP1V9pPe6Th5CmeMS4JbyD38ZkTdDoLpYuWEvcT


I expect that this bad actor will change their behavior, and I'll of

course adjust. However, if you turn your attention to these two
variables in your logs today you will find anyone who has been
compromised very recently by this actor:

1. Email subject appears blank in logs (ex. T="" in exim log)
2. The first recipient they send to is jackgrelesh...@gmail.com

If you find someone sending email to jackgrelesh...@gmail.com on
your
platform today, most especially with a blank subject, I will gladly
take
the beating for you if you suspend the user and find it to be a
false
positive. The idea that following these trends could produce a false

positive has, in my case at least, proven to be more of a rough
theory
than a reality.

Some bonus indications of similar but different compromises:

- Any email sent to ollegas2...@gmail.com, glob22aa.fun, or
mx373.com [1]
consistently links to what I believe is a virus that sends out a
user's
email credentials to the bad actor.

Keep up the good fight friends.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--

Steve Freegard

|

Senior Product Owner

T.

+44 7740 364348

abusix.com [2]

Book a meeting [3]

 [4]

 [5]

 [6]

 [7]

CONFIDENTIALITY This email and any attachments are confidential and
may also be privileged or otherwise protected from disclosure. If you
are not the named recipient, please notify the sender immediately and
do not disclose the contents to another person, use it for any
purpose, or store or copy the information in any medium.

You’ll find further information about privacy here [8].



Links:
--
[1] http://mx373.com
[2] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzZTf64_AIC7pyl-xmo2L5eYJtYu1PnTYrDUUBmQW-VxiqyfDuPS_3WZnIEFz1xocGdBhnxAEyhHhg3_G29KPX5gu0-0JxXoL3Lw4zV1rZI4zA5EgDWnGc90iUX1HRTDIs=
[3] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzdypi6WPqhVkFKkuLiMX0pY_5fawxs7P25-lwfZUyr7w==
[4] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyIo6EwBskR6pg3M12nuwEx_9G03qmurLHy8H_IjsK3cg==
[5] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDweOZAf2SFcCyyLHlLyd4j2GB_p_YWWJ_3WJxEqTQND2A==
[6] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDz5UNyOTEm_EvRFXdshn5-xBpkDGWEZYln2qrkxaFuQc-FVdHa5XQ8gkUA8UK9te-A=
[7] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyEop3qI2i2HFrm2U65Sd5oxcB4tERwhAI5MzR-NKIKtw==
[8] 
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDwp6TTQAR8uw54LR3mph76uODAm2MU0ep-sVltZqsar_A==

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

Re: [mailop] How to get Google to set a null MX for gmail.co ?

[Jarland Donnell via mailop]

Same. In fact, if anyone wants it, I regularly update a list which is 
mostly intended to help out my customers that receive a lot of fake 
email signups on blogs, forums, etc. Feel free to take from it: 
https://github.com/mxroute/da_server_updates/blob/master/exim/spam_recipients


On 2023-02-16 15:02, Hans-Martin Mosner via mailop wrote:

Am 16.02.23 um 17:57 schrieb Tom Perrine via mailop:


The subject says it all.

We’ve got users (who doesn’t?) who fat-finger gmail.com to
gmail.co – apparently A LOT.

The domain gmail.co seems to be an anti-squat domain, and on HTTP it
throws a 404 – as expected. (Although they could have redirected
to gmail.com – whatever).

But, there’s no MX, so SMTP falls back to the A, and mail sits in
our outbound queues until it expires, etc.

Any idea who/how to suggest to Google that a null MX would be
appreciated?


I prefer to do these things on my own, then I can be sure they get
done in a reasonable timeframe.

Our /etc/postfix/transport map has about 700 error entries for
fat-finger domains. For many of them, it would be difficult and
time-consuming to find the actual domain owners, convince them to add
an MX record, etc. On the other hand, adding a new entry is a matter
of 10-15 seconds. Guess which option I prefer.

Cheers,
Hans-Martin
___
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] Compromised email account trends

[Jarland Donnell via mailop]

Hey everyone. I've been thinking about how I could add some more value 
to this list and there's one thing I've been working on for a while that 
I think will be really helpful to share.


Email accounts get compromised. It happens. Especially when using base 
standards (IMAP/POP/SMTP) that inherently lack two-factor authentication 
mechanisms. As I discover ways to identify when accounts have been 
compromised, I'd like to share them with you all.


Today I discovered a new trend based on an abuse complaint, which 
allowed me to further identify several compromised user email accounts 
across our platform. I'd like to share with you the headers and body, 
censored of any customer information, that was sent to me in an abuse 
complaint (I also removed the recipient that actually reported it): 
https://paste.mxrouteapps.com/?862a67d53b18e8df#2k9DaEP1V9pPe6Th5CmeMS4JbyD38ZkTdDoLpYuWEvcT


I expect that this bad actor will change their behavior, and I'll of 
course adjust. However, if you turn your attention to these two 
variables in your logs today you will find anyone who has been 
compromised very recently by this actor:


1. Email subject appears blank in logs (ex. T="" in exim log)
2. The first recipient they send to is jackgrelesh...@gmail.com

If you find someone sending email to jackgrelesh...@gmail.com on your 
platform today, most especially with a blank subject, I will gladly take 
the beating for you if you suspend the user and find it to be a false 
positive. The idea that following these trends could produce a false 
positive has, in my case at least, proven to be more of a rough theory 
than a reality.


Some bonus indications of similar but different compromises:

- Any email sent to ollegas2...@gmail.com, glob22aa.fun, or mx373.com 
consistently links to what I believe is a virus that sends out a user's 
email credentials to the bad actor.


Keep up the good fight friends.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Hetzner

[Jarland Donnell via mailop]

Ever been on the receiving end of a retaliatory abuse complaint? As a 
Hetzner customer I expect some trust in the company I pay money to, that 
they'll give me a chance to face my accuser and fix the problem if there 
is one, or give a response as to why I shouldn't have to if there isn't 
a problem.


There are two sides to every story, surprisingly companies aren't keen 
to just kick all of their customers out by third party demand, on 
demand.


On 2023-02-07 07:15, Atro Tossavainen via mailop wrote:

Neither do I. The response simply describes what is happening. When a
third party X complains that Hetzner customer Y is a spammer, I 
consider

it only appropriate that Hetzner passes the complaint along and asks Y
for a statement, and does not simply impose restrictions on Y based on
X's say-so. Informing X of what the internal process entails does not
look offensive, let alone insulting, to me.


Have you ever been on the receiving end of retaliation from a spammer, 
Ralph?

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

Re: [mailop] Question of SPF record

[Jarland Donnell via mailop]

Take this:

v=spf1 a mx ip4:74.208.4.194 ~all

Change it to this:

v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de ~all

Done :)

On 2023-02-05 18:13, H via mailop wrote:
I have a domain with multiple email addresses hosted by Ionos. I have 
found that outgoing emails can come from a range of Ionos email IPs.


I have created a TXT record for my domain containing one IP4 address 
but outgoing emails seem to be sent from different IP4 addresses. As an 
example I now have:


v=spf1 a mx ip4:74.208.4.194 ~all

I know I can add at least one more ip4 address using the same format 
but I am not sure exactly what the Ionos email ip range might be so:


- Is there a way of saying eg. ip4:72.20.8.*

- Or should I delete the ip4 component and instead add:

include:mydomain.tld (corrected of course)

Suggestions appreciated!

Thanks.

___
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] Using cloud hosts for MX (not SMTP)

[Jarland Donnell via mailop]

Though it's possible that you may see this more with governments and 
such, I've not noticed that anyone significant blocks their own traffic 
outbound to OVH, except for a couple of military contractors (which 
isn't my definition of significant to any average person). If they block 
anything it's usually blocking their own inbound email which came from 
an OVH IP, rather than their own outbound email headed toward an OVH IP.


On 2023-01-17 20:34, Alberto Abrao via mailop wrote:

Hello,

first message to this list. I have been lurking for a while, and I 
learned a lot here. Thank you.


I operate a personal e-mail server, and, as soon as I started 
self-hosting, I requested a static IP from my ISP, moving records as I 
changed to a different provider.


During the move, I was relying on the "retry" period of the SMTP 
protocol, which worked just fine.


Still, it generates an error message to the sender. I was looking to 
"split" my server, having the MX (inbound) at a cloud provider (OVH), 
and keeping outbound SMTP on the IP provided by my ISP.


I see many posts saying that e-mails from cloud providers such as OVH 
are blocked outright by many. That had me wondering if it's a good idea 
to proceed with this plan, as I may not be able to receive messages 
from senders under these operators.


That'd assume the block is inbound and outbound, instead of 
inbound-only. Is that the case?


One more thing, would a set up like this interfere with my "score", so 
to speak?



Once again, thank you.

Kind regards,
Alberto Abrao

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

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

Re: [mailop] gmail putting most messages into Spam

[Jarland Donnell via mailop]

One very obvious one I hit right away. You seem to be sending from 
@ccs.covici.com, and it has no SPF record: 
https://www.whatsmydns.net/#TXT/ccs.covici.com


A good, solid SPF record is a bare minimum these days. Google is 
requiring it more than ever, and while the message they're giving you 
isn't the one I'm used to seeing for that, every negative point about 
the email you send is a mark against you which means every aspect you 
can improve on is relevant.


On 2023-01-17 18:03, John Covici via mailop wrote:

OK, well, now I can't send even to a single gmail address.  What is
mail-tester.com  --I have never used it?  Is it a website?


On Tue, 17 Jan 2023 18:20:09 -0500,
Jarland Donnell via mailop wrote:


On 2023-01-17 17:06, John Covici via mailop wrote:
> Still broke for me.

I believe your issue was different from the one in this thread
and best summarized by your message in that separate thread:

On 2023-01-17 10:31, John Covici via mailop wrote:
> Hi.   For some reason this morning, I am having problems sending to
> gmail addresses.  I get the following error for each:
>
> <<< 550-5.7.1 [166.84.7.93  12] Our system has detected that this
> message is
> <<< 550-5.7.1 likely unsolicited mail. To reduce the amount of spam
> sent to Gmail,
> <<< 550-5.7.1 this message has been blocked. Please visit
> <<< 550-5.7.1
> https://support.google.com/mail/?p=UnsolicitedMessageError
>  Now I have had no problems sending to gmail, but this message was
>  send to maybe 40 users or so -- is this my problem, or am I doing
>  something else wrong?
>
> Thanks in advance for any suggestions.

It's arguable which is worse, but this is definitely different
than spam folder delivery. I would argue your situation is better
because I'd rather know it wasn't delivered than tell someone to
check their spam folder, because people just don't and you have
little clear insight into the fact that they absolutely need to
look there. That said, I just performed a log audit and I do not
see a recent increase in these error messages from our side. I'm
not Google, obviously, but we process enough email that I feel
like polling my logs can easily indicate a trend of lack thereof.

My first instinct in your position would be to use something like
mail-tester.com to get a basic check over your headers, DNS,
etc. I know it's not wildly popular on this list but in a world
where the average user still runs to mxtoolbox, mail-tester.com
is exponentially better in it's assessments.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


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

Re: [mailop] gmail putting most messages into Spam

[Jarland Donnell via mailop]

You visit mail-tester.com, copy the email address, send an email to it, 
and then wait about 15-30 seconds and click the button. It'll give you 
an overview. It's not perfect, but if your email has some very 
significant, avoidable problems it's an easy way to identify a few 
common ones.


On 2023-01-17 18:03, John Covici via mailop wrote:

OK, well, now I can't send even to a single gmail address.  What is
mail-tester.com  --I have never used it?  Is it a website?


On Tue, 17 Jan 2023 18:20:09 -0500,
Jarland Donnell via mailop wrote:


On 2023-01-17 17:06, John Covici via mailop wrote:
> Still broke for me.

I believe your issue was different from the one in this thread
and best summarized by your message in that separate thread:

On 2023-01-17 10:31, John Covici via mailop wrote:
> Hi.   For some reason this morning, I am having problems sending to
> gmail addresses.  I get the following error for each:
>
> <<< 550-5.7.1 [166.84.7.93  12] Our system has detected that this
> message is
> <<< 550-5.7.1 likely unsolicited mail. To reduce the amount of spam
> sent to Gmail,
> <<< 550-5.7.1 this message has been blocked. Please visit
> <<< 550-5.7.1
> https://support.google.com/mail/?p=UnsolicitedMessageError
>  Now I have had no problems sending to gmail, but this message was
>  send to maybe 40 users or so -- is this my problem, or am I doing
>  something else wrong?
>
> Thanks in advance for any suggestions.

It's arguable which is worse, but this is definitely different
than spam folder delivery. I would argue your situation is better
because I'd rather know it wasn't delivered than tell someone to
check their spam folder, because people just don't and you have
little clear insight into the fact that they absolutely need to
look there. That said, I just performed a log audit and I do not
see a recent increase in these error messages from our side. I'm
not Google, obviously, but we process enough email that I feel
like polling my logs can easily indicate a trend of lack thereof.

My first instinct in your position would be to use something like
mail-tester.com to get a basic check over your headers, DNS,
etc. I know it's not wildly popular on this list but in a world
where the average user still runs to mxtoolbox, mail-tester.com
is exponentially better in it's assessments.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


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

Re: [mailop] gmail putting most messages into Spam

[Jarland Donnell via mailop]

On 2023-01-17 17:06, John Covici via mailop wrote:

Still broke for me.


I believe your issue was different from the one in this thread and best 
summarized by your message in that separate thread:


On 2023-01-17 10:31, John Covici via mailop wrote:

Hi.   For some reason this morning, I am having problems sending to
gmail addresses.  I get the following error for each:

<<< 550-5.7.1 [166.84.7.93  12] Our system has detected that this
message is
<<< 550-5.7.1 likely unsolicited mail. To reduce the amount of spam
sent to Gmail,
<<< 550-5.7.1 this message has been blocked. Please visit
<<< 550-5.7.1
https://support.google.com/mail/?p=UnsolicitedMessageError
 Now I have had no problems sending to gmail, but this message was
 send to maybe 40 users or so -- is this my problem, or am I doing
 something else wrong?

Thanks in advance for any suggestions.


It's arguable which is worse, but this is definitely different than spam 
folder delivery. I would argue your situation is better because I'd 
rather know it wasn't delivered than tell someone to check their spam 
folder, because people just don't and you have little clear insight into 
the fact that they absolutely need to look there. That said, I just 
performed a log audit and I do not see a recent increase in these error 
messages from our side. I'm not Google, obviously, but we process enough 
email that I feel like polling my logs can easily indicate a trend of 
lack thereof.


My first instinct in your position would be to use something like 
mail-tester.com to get a basic check over your headers, DNS, etc. I know 
it's not wildly popular on this list but in a world where the average 
user still runs to mxtoolbox, mail-tester.com is exponentially better in 
it's assessments.

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

Re: [mailop] gmail putting most messages into Spam

[Jarland Donnell via mailop]

Just a +1 report for the sake of data. The only legitimate emails I have 
in my spam folder at Gmail are from Inno Supps and healthcare.gov. Inno 
Supps I get because of their products and, therefore, their language is 
quite similar to standard spam campaigns. Healthcare.gov I get because, 
legitimate as they may be, they sure are spammy little shits.


I have not seen an increase in customer complaints about emails landing 
in Gmail folders. If anything, compared to the growth over the last 
holiday season, the complaints are fewer and farther between relative to 
the number of customers we have.


I can absolutely say without question though that I have repeatedly 
witnessed since 2011 (when my work in the field began) users who found 
benefit in purchasing new domains to increase their chances of landing 
in inboxes. EIther because of a past history of intentional abuse (being 
sorry doesn't fix filters), their domains using TLDs that were 
inherently more highly associated with abuse (Why does .monster even 
exist if not for spam?), or their domains used keywords that were very 
common in spam like "health" or "healthcare" (huge increase in the years 
following ACA passage in the US).


On 2023-01-17 07:16, Paul Gregg via mailop wrote:

Heads up in case anyone else is experiencing this.

We are aware of a recent change in behaviour of gmail.com where
most email is placed directly into Spam folder.

So far we have dozens of customers reporting this.
Tested myself with full SPF, DKIM and DMARC with p=reject - which gmail
itself marks as passing all tests. The mail was also delivered over 
TLS.

Mails go to Spam.

We're trying to reach out to google, but so far have no response.

We don't think it is just 'us', as reddit r/msp has others reporting
same from O365 direct to gmail.

PG
___
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] Valid SPF/DKIM/DMARC *SPAM* coming from my domain ?!

[Jarland Donnell via mailop]

Is there some kind of forwarding address or something that would end up 
going through your mailgun account? The reason I ask is this header 
right here:


Received: from reflectiv.net (os3-384-25366.vs.sakura.ne.jp 
[133.167.109.120]) by db739d28cce8 with SMTP id ; Wed, 11 Jan 
2023 00:26:59 GMT


Not something I'd expect to see if it were submitted over an API or 
something, though I'm not familiar enough with mailgun to say for sure. 
That said, this IP 133.167.109.120 is all over my logs today spoofing my 
customer's emails to send them emails. It's nothing I'm not used to 
seeing, pretty standard behavior on my side at least for these bitcoin 
scammers. They're not usually very personalized beyond what they can 
quickly script, they're very low effort and very much a "spray and pray" 
technique.


On 2023-01-11 15:00, Cyril - ImprovMX via mailop wrote:

Hi everyone!

Today, I received a spam ("I got full access to your computer and
installed a trojan" kind of email). In general, I completely ignore
these, but today was different:

The sender and recipient were my own email! What's odd is that I did
configure SPF (granted, with a "~") but also a DMARC reject policy.

Looking at the email headers and also the output from GMail, both SPF
and DKIM were successful ("pass"), which means the sender, somehow,
was able to send an email using my account.

I would love your input on the issue, but here are my thoughts so far:

1. My account was compromised, and the password was leaked, allowing
that user to send an email with my account. This would make sense, but
the sending account was only used to be configured within GMail. As
soon as the password was generated, I pasted it on GMail and never
saved it elsewhere.
2. Theoretically, if I were to create an account on Mailgun, I would
be able to send an email from my account and have a valid SPF for any
other services that use Mailgun too (since their SPF would include
Mailgun's IPs), but it wouldn't explain the valid DKIM though. For
this, Mailgun should only allow my account to be able to send using my
domain.
3. Did Mailgun have any database leak that I wasn't aware of?

Of course, as soon as I saw this email, I generated a new password for
my account, but I still wonder how this could have happened. I would
appreciate if you had any insights I've missed that would make sense.

Here are the headers from the email with my end email redacted:
https://pastebin.com/knqbTa8K

Thank you!
___
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] verizon email-to-text gateway mail deferred evening and night

[Jarland Donnell via mailop]

Considering how easy it is to get IPs blocked from every Verizon-owned 
brand, because one single person sent the wrong email to SMS and tripped 
a filter, and that you have to escalate to the CEO's team to get 
unblocked, I don't know why anyone even rolls these dice anymore. I tell 
everyone to use Twilio or Pushover if they want to get messages to 
phones.


On 2023-01-06 09:15, chris via mailop wrote:

Yep this is intentional to coerce into pay to play

On Fri, Jan 6, 2023, 10:07 AM Osborne, Richard via mailop
 wrote:


We have been seeing this also for about the last week.  Our Verizon
reps are telling us we need to pay for their EMAG (Enterprise
Messaging) service to not get blocked.

Richard Osborne

Information Systems

West Tennessee Healthcare

NOTICE:  (1) The foregoing is not intended to be a legally binding
or legally effective electronic signature. (2) This message may
contain legally privileged or confidential information.  If you are
not the intended recipient of this message, please so notify me,
disregard the foregoing message, and delete the message immediately.
I apologize for any inconvenience this may have caused.

From: mailop  On Behalf Of Dima Gomonyk
via mailop
Sent: Friday, January 6, 2023 6:28 AM
To: z...@stat.colostate.edu; mailop@mailop.org
Subject: Re: [mailop] verizon email-to-text gateway mail deferred
evening and night

Attention: This email originated from outside of West Tennessee
Healthcare. Always validate the sender's email address before
clicking on links or attachments as they may not be safe. Never
provide your username or password to a site you do not trust. Please
forward suspicious e-mails to phish...@wth.org.

I've been looking into this exact thing yesterday: Verizon's
mail-to-sms gateways. Might have been going on a long time and I’m
just noticing.

No emails are accepted between 0:00 to 11:59 UTC time every day (the
deferrals during that time frame are a somewhat misleading AUP#CNCT
from Cloudflare)
Emails are accepted only between 12:00 to 23:59 UTC time every day.

12 UTC is 7 EST

So in my opinion this looks like an enforced “do not disturb” by
Verizon to ensure SMS delivery only between 7am to 7pm EST time -
during the "social hours" or whatnot. At least one other ESP I have
contact with has confirmed they're seeing exactly the same time
frames.

I'm not a fan of the somewhat unclear bounce/deferral string they're
returning but I don't think Coudflare is doing it on their own, it's
too clean of a cutoff time - probably a Verizon rule.

On 01/06/2023 02:22, Zube via mailop wrote:


This is new as the past few days and rather odd.

Mail sent through the Verizon email-to-text gateway is fine during

the day when the relay is:

relay=vrz-mms.mx.a.cloudfilter.net [1]. [52.37.233.84]

or

relay=vrz-mms.mx.a.cloudfilter.net [1]. [35.169.108.175]

but starting somewhere around 5pm MST, mail sent to vtext.com [2],

vzwpix.com [3] or mypixmessages.com [4] is deferred:

relay=smtpin02-mms.vzw.a.cloudfilter.net [5]. [52.33.196.155],

dsn=4.0.0, reply=421 vrz-ibgw-6003a.ext.cloudfilter.net [6]

Mail sent from gmail makes it through.

Sometime around 5am the following day, a resend of the mail makes

it through again, but then it's hitting one of the two other
servers

listed above.

I'm not the only one seeing this:





https://community.verizon.com/t5/Verizon-Messages/Vtext-messages-Severe-Delay/td-p/1240767/page/7

[7]

Going the other way, text-to-email seems to work fine and it
arrives from

(in one test) twbgohaavzwvcmta-c-nk-x-00-sms-02.vtext.com [8]
[63.55.64.200]

after first going through m04.vzwpix.com [9] (unknown
[63.59.66.15])

If anyone from Verizon or cloudfilter.net [10] is listening,
please

advise.

Cheers,

Zube

___

mailop mailing list

mailop@mailop.org

https://list.mailop.org/listinfo/mailop [11]


--

--

Dima Gomonyk
_Email Deliverability&Abuse Specialist, SMTP_

Campaigner | iContact | SMTP

p:

877.705.9362

a:

2 Gurdwara Rd, Suite 300, Ottawa, Canada

w:

smtp.com [12] e: dmitry.gomo...@smtp.com

-

-

This email, its contents and attachments contain information from
Ziff Davis, Inc. and/or its affiliates which may be privileged,
confidential or otherwise protected from disclosure. The information
is intended to be for the addressee(s) only. If you are not an
addressee, any disclosure, copy, distribution or use of the contents
of this message is prohibited. If you have received this email in
error, please notify the sender by reply email and delete the
original message and any copies.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



Links:
--
[1] http://vrz-mms.mx.a.cloudfilter.net
[2] http://vtext.com
[3] http://vzwpix.com
[4] http://mypixmessages.com
[5] http://smtpin02-mms.vzw.a.cloudfilter.net
[6] http://vrz-ibgw-6003a.ext.cloudfilter.net
[7] 
https://linklock

Re: [mailop] Contact at mxrouting.net / mxroute.com /porkbun.com ?

[Jarland Donnell via mailop]

Right here friend.

On 2023-01-03 14:07, Peter N. M. Hansteen via mailop wrote:
Does anyone have useful contact info for one or more of those (which I 
am beginning to believe is in fact the same outfit)?


Some odd delivery problems with messages that are some of the least 
useful I have seen.


So bad, in fact, that I have already threatened to blog about them.

Contact off-list is fine.

All the best,
Peter

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

Re: [mailop] I received a scam letter from Paypal

[Jarland Donnell via mailop]

For someone already using billing automation it works that way, but 
think more in terms of a web designer with 5 clients, billing a client 
for a quick job. PayPal has a lot of functions for a lot of different 
use cases that could range from helping freelancers to large businesses.


I'm not sure how much needs to be done after registration to gain the 
feature but I imagine if you have a working login, you have the feature.


On 2022-12-28 12:55, Jaroslaw Rafa via mailop wrote:

Dnia 28.12.2022 o godz. 12:33:05 Jarland Donnell via mailop pisze:

It's a perfectly legitimate feature of PayPal that you can create an
invoice and send it to someone. Pretty much every invoice service
that exists allows similar. They just have a problem with malicious
users creating invoices for people that don't owe them any money.


I understand they need to already be Paypal customers and be somehow
verified and "allowed" by Paypal to create invoices for other users?

Is this some additional feature of Paypal? Paypal's basic operation, 
ie.
being a payment processor, does not require such feature at all. In 
normal
payment processing flow in an Internet shop you don't get any invoice 
until
you have paid for the goods you are ordering, and this invoice is sent 
to

you directly by the shop, and not via the payment processing service.

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

Re: [mailop] I received a scam letter from Paypal

[Jarland Donnell via mailop]

It's a perfectly legitimate feature of PayPal that you can create an 
invoice and send it to someone. Pretty much every invoice service that 
exists allows similar. They just have a problem with malicious users 
creating invoices for people that don't owe them any money.


On 2022-12-28 12:14, Cyril - ImprovMX via mailop wrote:

Hi everyone!

If I recall correctly, there was already a discussion here on
something similar, but I'd like to share my story here.

Yesterday, I received an email from Paypal with the subject "Reminder
- You have paid an invoice".

The content of the email is the following:

There are a few things to note that are surprising :

* The email is really coming from Paypal (serv...@paypal.com)
* The SPF/DKIM AND DMARC are valid
* All the links inside the email point to Paypal.com, even though I
haven't clicked on the "View ad Pay Invoice"
* The sending IP (66.211.170.90) is from Paypal: mx4.phx.paypal.com
[1] (https://check.mx/ptr/66.211.170.90)

And a few inconsistencies :

* The subject says, "You have paid an invoice", but the body says,
"Please pay your invoice"
* The bottom indicates that Paypal "will always contain your full
name", but the top indicates "Hello, PayPal Customer"
* I haven't tried the phone number but pretty sure that's where the
scammers are sitting.

Here's the validation from GMail:

What I'm saying here, is what the hell? How a scam can come from
Paypal like this?
This is a serious issue, and they need to fix this because I'm not
sure my parents would catch the scam here, all seems legit!

Stay safe, and happy holidays!

Best,
Cyril

Links:
--
[1] http://mx4.phx.paypal.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] Contact info for antispamcloud.com ?

[Jarland Donnell via mailop]

Fairly certain that belongs to SpamExperts. I don't think they send 
email from that domain, it could be spoofed in an effort to abuse 
someone's poorly executed whitelist, since anyone using their service 
has to ignore SPF for emails coming from their servers, whitelisting is 
usually involved.


On 2022-12-25 14:42, Peter Nicolai Mathias Hansteen via mailop wrote:

Hi,

Does anyone here have usable contact info for the domain
antispamcloud.com [1]?

Something there is apparently trying to contact postmaster@ in one of
our domains, but since they have no valid MX record and their actual
outbound SMTP senders do not match their SPF, so even the coddling
described in
https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html
is no use.

- Peter

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673
seconds.



Links:
--
[1] http://antispamcloud.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] Google Abuse?

[Jarland Donnell via mailop]

It's a simple matter of cost vs benefit. People sitting and responding 
personally to abuse complaints all day do not, directly, generate 
revenue. Given their size and adoption in the marketplace, personal 
responses to abuse complaints are not going to increase their market 
share.


On 2022-12-16 15:51, Eric Tykwinski via mailop wrote:

This is just more of a question on why they wouldn’t acknowledge a
receipt of the abuse report posted to their web form?

Here’s the response I got back:

Thank you for submitting a report. We take our users' privacy and
security very seriously, so we appreciate your concern. We will use
the information you provide to conduct an investigation. We will
contact you if we need more details; however, you will not receive a
response or email acknowledgment of your submission.

Details, in case you’re interested: It was a domain squatter using a
customer’s domain to try and gain access to their bank account.  I
do believe the attempt was unsuccessful, but wanted to report anyways
just in case they can find a pattern.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300
___
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] Report sharing

[Jarland Donnell via mailop]

Thanks for sharing this. I'm asking publicly as I'm curious if this 
message spawns any conversation, but have you seen or heard a lot of 
intentional abuse around using bsdly.net email addresses specifically to 
attack website owners? I find that emails to these bsdly.net addresses 
seem to trigger immediate blacklistings at sorbs, which is still 
relatively highly utilized. Effectively, this means that if I sign up 
for a blog or mailing list, even if those websites do everything 
correctly, and fill out an @bsdly.net address as if it were mine, the 
confirmation email will cause IP blacklisting. A noteworthy blacklisting 
at that, not just some insignificant RBL.


I, of course, mitigate against this now. The moment anyone on my 
platform tries to email @bsdly.net, they're halted and flagged for human 
review. But I don't consider that the most favorable position to take 
because spam traps become useless concerning emails they don't receive. 
I wouldn't mind the occasional blacklisting when it's deserved, even 
though I catch them before anyone can even parse their logs, if the data 
proved helpful at a larger scale. When a spammer breaks through, 
consequences are inevitable after all.


So I suppose my question is, do you notice any significant amount of 
behavior that could match my description? I would assume almost every 
confirmation email you receive at those addresses (double opt-in to a 
mailing list or website registration) would represent a case where 
someone didn't purchase or scrape lousy mailing lists but instead was 
targeted by a third party who wanted to cause them harm. Automated 
social engineering at it's finest.


On 2022-12-14 05:15, Peter N. M. Hansteen via mailop wrote:
On Wed, Dec 14, 2022 at 11:58:17AM +0100, Camille - Clean Mailbox via 
mailop wrote:


As I see some of you are sharing reports about sources of unwanted 
emails,


For your collections and hopefully with potential for some practical 
use -
This article 
https://bsdly.blogspot.com/2018/08/badness-enumerated-by-robots.html 
has useful
summaries of the lists generated at bsdly.net with links to the data 
and further info.


All the best,
Peter

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

Re: [mailop] DigitalOcean IP ranges gone

[Jarland Donnell via mailop]

DO uses third-party services to send emails. If you want to block only 
their cloud ranges, blocking all of their announcements is appropriate.


On 2022-11-25 14:16, Slavko via mailop wrote:
Dňa 25. novembra 2022 19:15:07 UTC používateľ Lukas Tribus via mailop 
 napísal:

Hello,

if we are talking about a list of DO IP prefixes, why not rely on
routing information with bgpq4 [1] instead?


I live in hope, that these published IPs are including cloud infra 
only,

not other IPs, as eg. their official MTAs (outbound) etc, while that AS
ranges includes it.

I tried bgpq4 some time ago, while i do not remember which cloud
provider it was, and there was huge difference between published
IP range and whole ASN ranges.

regards

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

Re: [mailop] Another interesting batch of suspicious activity on an IPXO network..

[Jarland Donnell via mailop]

That is great to hear, and I hadn't thought about when the IPs might be 
announced elsewhere. Under that context, the amount of spam from the 
IPXO network is actually probably fairly small relative to what it could 
be. Look forward to seeing how the operation continues to grow, sounds 
like you understand the problems you've inherited.


On 2022-11-25 08:33, Gustavas Davidavičius via mailop wrote:

Hello,

There seems to be some misunderstanding in what IPXO is and how it 
operates.


When I first tested the IPXO network they required me to pay them a 
custom fee to exclude my services from their internal mail scanner. 
They would otherwise downgrade connections from SSL and intercept the 
SMTP traffic, then scan the contents of emails for spam. I can't 
imagine that still functions <..>


I believe you are referring to Heficed. I'm not sure when this 
happened, but it must have been way before IPXO was born, because it's 
been almost 2 years now, that Heficed no longer allows switching the 
mailing filter off under any circumstances. I'm not sure if there was 
some fee before I joined the company, but when I had joined there was 
just a handful of exceptions made, which later turned into no 
exceptions.
That system still works, if a certain spam threshold is reached, 
Heficed completely blocks all SMTP traffic.


IPXO is what used to be the Heficed IP Marketplace, as a separate 
entity. It's purely an IP lease platform - without any hardware to run 
those IPs on. A person renting IP space will have to either have their 
own infrastructure or use some hosting services to use the IPs.



Anyone from IPXO on the list that might explain what the network 
operators are doing to combat spam these days?


Since the leased IP space is not used anywhere within our owned 
infrastructure, we do not get to see or control what goes out into the 
internet. Due to this reason, we are primarily reactionary in our 
approach - all the IP space has our Abuse-c, so we could observe all 
the abuse reports generated and act upon them. We of course forward all 
of them to the lessees, who are all primarily resellers and take 
actions if the reported abuse does not get acted upon.


Of course, this approach is very limited so we are currently developing 
multiple solutions that will allow as to be more proactive in our 
approach - e.g. we are working on an automated alerting system for rDNS 
changes, to be able to notice such cases as reported below, before it 
gets to be used for nefarious purposes. Until we get that finished and 
running, reports as that one does help us out, please never hesitate to 
report at abuse-t...@ipxo.com.


I hope this brings at least a tiny bit of clarity,
Gustavas D
IPXO Abuse Prevention Team

-Original Message-
From: mailop  On Behalf Of Jarland Donnell 
via mailop

Sent: Thursday, November 24, 2022 6:07 PM
To: mailop@mailop.org
Subject: Re: [mailop] Another interesting batch of suspicious activity 
on an IPXO network..


When I first tested the IPXO network they required me to pay them a 
custom fee to exclude my services from their internal mail scanner. 
They would otherwise downgrade connections from SSL and intercept the 
SMTP traffic, then scan the contents of emails for spam. I can't 
imagine that still functions given the amount of spam sent from their 
networks, and most companies that deploy systems like that purchase 
very expensive appliances rather than build their own, which would be 
quite a waste of money to just give up on so quickly.


Anyone from IPXO on the list that might explain what the network 
operators are doing to combat spam these days?


On 2022-11-24 09:40, Michael Peddemors via mailop wrote:

I don't think all these companies are operating on this network..

Eg..

host -t TXT hostedexchange.co.il
hostedexchange.co.il descriptive text "v=spf1 ip4:212.143.142.84
ip4:194.90.28.61 -all"

Obvious attempts to hide activity using legitimate companies?

#   84.32.92.41   
mail01.info.messe-muenchen.de

#   84.32.92.6 1   mail.suminet.com
#   84.32.92.131   out3.mail.studentaid.gov
#   84.32.92.141   out4.mail.studentaid.gov
#   84.32.92.161   out9.mail.studentaid.gov
#   84.32.92.181   out2.mail.studentaid.gov
#   84.32.92.221   stl-mta-dmz-02-pub.dol.gov
#   84.32.92.301   mail.bpd.ci.buffalo.ny.us
#   84.32.92.362   lmta224.e.sharkninja.com
#   84.32.92.401   mail.beind.com
#   84.32.92.421   mail2.cncloud.co.il
#   84.32.92.451   kinneret4.kinneret.co.il
#   84.32.92.461   relay2.mpv.co.il
#   84.32.92.481   mail.hishtil.com
#   84.32.92.501   owa.s-wear.co.il
#   84.32.92.53 

Re: [mailop] Partial issues forwarding mails to gmail.com

[Jarland Donnell via mailop]

I have noticed that one of the most consistently rejected emails when 
forwarded to Gmail, is an email from Google. I just rotate outbound IPs 
on that message using ZoneMTA and it'll get through. Waiting for an IP 
to clear a rate limit with Gmail just seems like bad business at this 
point.


On 2022-11-24 10:20, Martin Flygenring via mailop wrote:

Hello all

For the past few weeks, we've noticed increasing queues on our 
MX-servers when forwarding some emails to our users alternate 
addresses, if that forwarding address is a gmail.com address. Most of 
the mails go through without issues, but some end up getting deferred 
with the error message:
    421 4.7.28 [185.164.14.118 15] Our system has detected an unusual 
rate of unsolicited mail originating from your IP address. To protect 
our users from spam, mail sent from your IP address has been 
temporarily rate limited. Please visit 
https://support.google.com/mail/?p=UnsolicitedRateLimitError to review 
our Bulk Email Senders Guidelines. 
bj3-20020a170902850300b001895e356f00si917651plb.152 - gsmtp (in reply 
to EOD command)


Now, the interesting part is that for almost 98% of the mails currently 
in queue, Google is the original sender of the email.


Total mails deferred/in queue due to the above message, at the time of 
writing: 2696

Top 3 original sender:
   2582 gmail.com
 38 google.com
 22 calendar-server.bounces.google.com

For reference, we currently have 2.8m registered domains, meaning we 
send millions of mails towards gmail on a monthly basis.
So while it is a very small amount of mails that end up in this state, 
we are still puzzled about why. Especially when so many of the original 
senders are gmail-addresses or other Google addresses.


I have been looking through our queues, and most often it looks like 
very legit mails that gmail just doesn't want to accept. For example:

- Friends talking about a christmas lunch/dinner
- Someone who's heating at home isn't working
- Some friends talking about a LEGO build they're doing together
- Building management meetings
- Someone that's sad they can't join a presentation because they're on 
vacation

.. and so on. Very innocent stuff.

We use SRS when forwarding, and every forward that users set up 
requires verification by the forward recipient, by them clicking a link 
to confirm they want to accept these forwards.


Looking at our graphs, between Oct 25th and Nov 7th we had 16 mails get 
deferred/bounce because of the above error message. Since Nov 8th, 
we're looking at somewhere between 250 and 1000 mails pr. day. 
Sometimes the mail eventually goes through with delay, but there are 
some that never make it through.


Is anyone else seeing similar issues when forwarding mails from 
gmail.com, back to other addresses at gmail.com?

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

Re: [mailop] Another interesting batch of suspicious activity on an IPXO network..

[Jarland Donnell via mailop]

When I first tested the IPXO network they required me to pay them a 
custom fee to exclude my services from their internal mail scanner. They 
would otherwise downgrade connections from SSL and intercept the SMTP 
traffic, then scan the contents of emails for spam. I can't imagine that 
still functions given the amount of spam sent from their networks, and 
most companies that deploy systems like that purchase very expensive 
appliances rather than build their own, which would be quite a waste of 
money to just give up on so quickly.


Anyone from IPXO on the list that might explain what the network 
operators are doing to combat spam these days?


On 2022-11-24 09:40, Michael Peddemors via mailop wrote:

I don't think all these companies are operating on this network..

Eg..

host -t TXT hostedexchange.co.il
hostedexchange.co.il descriptive text "v=spf1 ip4:212.143.142.84 
ip4:194.90.28.61 -all"


Obvious attempts to hide activity using legitimate companies?

#   84.32.92.41   mail01.info.messe-muenchen.de
#   84.32.92.6 1   mail.suminet.com
#   84.32.92.131   out3.mail.studentaid.gov
#   84.32.92.141   out4.mail.studentaid.gov
#   84.32.92.161   out9.mail.studentaid.gov
#   84.32.92.181   out2.mail.studentaid.gov
#   84.32.92.221   stl-mta-dmz-02-pub.dol.gov
#   84.32.92.301   mail.bpd.ci.buffalo.ny.us
#   84.32.92.362   lmta224.e.sharkninja.com
#   84.32.92.401   mail.beind.com
#   84.32.92.421   mail2.cncloud.co.il
#   84.32.92.451   kinneret4.kinneret.co.il
#   84.32.92.461   relay2.mpv.co.il
#   84.32.92.481   mail.hishtil.com
#   84.32.92.501   owa.s-wear.co.il
#   84.32.92.531   webstore.od.co.il
#   84.32.92.561   mail.gestec.co.il
#   84.32.92.621   smtp.hostedexchange.co.il
#   84.32.92.651   mail.almog-ltd.com
#   84.32.92.771   mail69.publicators.com
#   84.32.92.801   fbsnd01104-jc.im.kddi.ne.jp
#   84.32.92.831   fbsnd01101-jc.im.kddi.ne.jp

.. might as well include the rest, in case someone on the list operates 
one of these domains..


84.32.92.851   snd00102-jc.im.kddi.ne.jp
   84.32.92.881   echtclxmr12ac10.ech.jpx.co.jp
   84.32.92.891   echtclxmr11ac10.ech.jpx.co.jp
   84.32.92.981   jmg2-aq.joshin.co.jp
   84.32.92.991   jmg2-ap.joshin.co.jp
   84.32.92.101   1   jmg2-an.joshin.co.jp
   84.32.92.103   1   jmg2-al.joshin.co.jp
   84.32.92.106   1   jmg-ao.joshin.co.jp
   84.32.92.107   1   jmg-an.joshin.co.jp
   84.32.92.113   1   john2.cantamen.de
   84.32.92.116   1   mout01.cdn.csl-computer.net
   84.32.92.117   1 
dwn-thor.deutsche-wirtschafts-nachrichten.de

   84.32.92.122   1   dev.otec.org
   84.32.92.126   1   mailer.acog.org
   84.32.92.137   1   e-bind.us
   84.32.92.142   1   ozmtabm02.ms.com
   84.32.92.146   1   ozmtaint01.ms.com
   84.32.92.154   1   mail01.www-101.aig.com
   84.32.92.159   2   mail1611.isramail.co.il
   84.32.92.162   1   mail03.marketing.nuance.com
   84.32.92.165   1   mail03.info.messe-muenchen.de
   84.32.92.167   1   gg9.uniki.de
   84.32.92.168   1   mail.balkanautomotive.rs
   84.32.92.173   1   dedi138.your-server.de
   84.32.92.182   1   gateway.rocketmarketing.it
   84.32.92.184   1   nl-he-1.abelssoft.de
   84.32.92.189   1   auris.cityhost.com.ua
   84.32.92.191   1   mailgw2.solucionait.com
   84.32.92.192   1   mx.dominos.ua
   84.32.92.199   1   a-06.wlk-msg.de
   84.32.92.201   1   gateway.sxm.it
   84.32.92.210   1   mta27-87.sears.com
   84.32.92.211   1   mta26-87.sears.com
   84.32.92.220   1   mta16-87.toms.com
   84.32.92.221   1   vmta15.87.lstrk.net
   84.32.92.223   1   vmta13.87.lstrk.net
   84.32.92.224   1   vmta12.87.lstrk.net
   84.32.92.227   1   vmta255.86.lstrk.net
   84.32.92.230   1   vmta249.86.lstrk.net
   84.32.92.233   1   vmta245.86.lstrk.net
   84.32.92.235   1   vmta243.86.lstrk.net
   84.32.92.239   1   vmta238.86.lstrk.net
   84.32.92.243   1   vmta234.86.lstrk.net
   84.32.92.246

Re: [mailop] Contact at Outlook?

[Jarland Donnell via mailop]

Assuming that doesn't pan out, can you file an abuse complaint with 
their DNS provider? Sure can't hurt anything.


On 2022-11-23 13:12, Cyril - ImprovMX via mailop wrote:

Hi everyone ,

I'm hoping that someone will be able to put me in contact with someone
working at Outlook.

We are still having a really bad issues regarding our previous
discussion on having a lot of bounces and I'm hoping to have some help
from someone ar Outlook.

Thank you !

Best,
Cyril
___
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] Massive bounce report campaign

[Jarland Donnell via mailop]

I would block the recipient domains at the MTA level and cut out the IP 
rate limiting for a while. An MTA should be able to handle the rejection 
for the domain fine. I do the same with exim when a user tries to give 
me the job of mass forwarding bounces, I just won't do it. In my mind a 
flood of bounces means bad behavior and I justiy the block by refusal to 
participate in whatever it is they're doing.


I don't think you're crazy here at all, if half of your job suddenly 
becomes forwarding bounce emails that's just not a good look.


On 2022-11-22 04:54, Cyril - ImprovMX via mailop wrote:

Hi!

I would appreciate your help on a bad issue we are having.

We are facing a very large amount of connections from Outlook, in the
order of 50k connections per minute (whereas the second "most active"
server is at 100).

Upon investigation, we discovered that one of our users is a
mass-sending email service (such as Mailgun; it seems legit in
itself), and they created one domain per client to handle bounce
reports, such as sp-bounce.{client's domain}.

Since the MX of these domains points to our server, any bounce report
sent is sent to our server. (Our service is a forwarding email, so
once we get the email, we forward it to the above user). (I'll add a
comment on this right after)

The problem is that I don't see how we can stop Outlook from sending
all these bounce reports to us. I thought about updating the SPF to
block that sender from including us, but we don't manage their DNS.

Right now, what we've done is to stop accepting connections from a
sender (in this case, Outlook) after an abnormal amount of connections
per a given period, but this doesn't avoid the fact that Outlook still
tries to connect to us massively, and also impact our regular users
that receive emails from Outlook sender legitimately.

What I'm hoping by reaching out to you is to hope someone has already
faced something similar and has some suggestions on how to mitigate -
or ideally block - this.

This could be a pretty well DDoS attack done by mail servers.

On the comment above regarding the bounce report being sent: That is
my suspicion, by looking at the domain names (sp-bounce), the email it
receives, and the sender activity. But maybe there is another logical
explanation I'm missing!
I mean, to have 50k connections per minute to deliver bounce reports
means that the running campaign must be in the order of millions of
emails just for Outlook!

All help is deeply appreciated!!!

Thank you all in advance.

Best regards,
Cyril
___
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] [EXTERNAL] Really good paypal phishing email this morning

[Jarland Donnell via mailop]

Basically, you go here:
https://www.paypal.com/invoice/s/manage

Click the gear symbol, Business Information, fill out what you want and 
add a logo. Then click Save, create an invoice for someone, and PayPal 
will send it to them. There's not much of anything that any of us can do 
to filter it without risking false positives, because we'll never have 
any consistent idea of what's real and fake when it all comes from such 
a high reputation sender using a feature that we don't necessarily want 
to block recipients from being able to use.


On 2022-11-18 15:30, Michael Wise via mailop wrote:

This .. is what I wanted to see.

Did it really go to you, or did it stop off somewhere else first?

  To: zachery Rose 

It does appear that it went direct, so my initial theory is off I
guess.

Aloha,

Michael.

--

Michael J Wise
Microsoft Corporation| Spam Analysis

"Your Spam Specimen Has Been Processed."

Open a ticket for Hotmail [3] ?

From: mailop  On Behalf Of Zach Rose via
mailop
Sent: Friday, November 18, 2022 11:38 AM
Cc: mailop@mailop.org
Subject: Re: [mailop] [EXTERNAL] Really good paypal phishing email
this morning

Yeah, that's my theory at the moment, very likely that the call is
coming from inside the house, but they didn't find the person who made
the call before it was made.

Delivered-To: REDACTED
Received: by 2002:a05:640c:1b81:b0:190:7afb:ee7a with SMTP id
r1csp516216eiw;
Fri, 18 Nov 2022 06:23:32 -0800 (PST)
X-Google-Smtp-Source:
AA0mqf6dcoQaNhG4JYaaq7jvwEAJxfF8XCQ2Zy1qPt4mGssaSyPzrvU0HsohJxkBvLOIjhuKLb6N
X-Received: by 2002:a65:67d1:0:b0:476:87ad:9d78 with SMTP id
b17-20020a6567d100b0047687ad9d78mr6785903pgs.169.1668781412334;
Fri, 18 Nov 2022 06:23:32 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1668781412; cv=none;
d=google.com [4]; s=arc-20160816;

b=U4pbrfCYSxjulk8kCNLer1j7TfaCaowzf2yDYMqeQMVmG4g/JvAXzf0m4serzWoqTi

OBEY9TrwfM2j3yQssfS8OMOnWmBP+pO7KYBmg67sBb57BdZlx/+txIylik9rNKuyXsEh

O5+LN63Y1RqiSPLK44tgV3uHSeYS5n+qE0gJHgS1lojzvH/tEkxESiQHix+K7sWYnBUt

EXjoD4UKa4x1WGOsOPsb64AYM/AMs2TImhoZCqg+tT2Otsn1/Hz34iMozy9tR0yBB15q

+Eq4bNx9gjV8EpetyAjAQF7XHwWknzhig/MtiVy76GwNuCpUxd8yW+Bw3/fwTtBL6zl6
 QFYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com [4]; s=arc-20160816;
h=amq-delivery-message-id:mime-version:from:to:subject
 :pp-correlation-id:message-id:date:content-transfer-encoding
 :dkim-signature;
bh=+ooJ/KHJ7NcHSktaVA2Efxv2wUuyyzgRC9OcH8lTKPI=;

b=PbkHny3v4CR7wqQUcdh8f9PRFBMO+7dUlCVLzG9d8uDG0Uc+4jNqlkRB5chwPq1AUw

QG3rN1n+lpU1t/MEz0fnZ2k1Rwzrr0j/2L0fHhhX0eJ8UheOHbcVNDSF1hjDfwPayN43

ggWon6WA5mEYJ6jTPt5ODvSC0shj5SrQBq2C57tCG4WOjWGK63UhilfiZS/GgpoyzgvG

UItaCRQKijOkG9k8bNub0rZ77LEdRoCK6RaEe6mhKmTv0doesmgdyhlb8+1e8V8Uvy7T

tqhqfvqUyzVOgL5HmUZIjNl/XkNXA966EGTLfDqf1DWDsf0LRjpZpJiJViixPJ63UMKA
 /azQ==
ARC-Authentication-Results: i=1; mx.google.com [5];
   dkim=pass header.i=@paypal.com [6] header.s=pp-dkim1
header.b=i5V5Jd8P;
   spf=pass (google.com [4]: domain of serv...@paypal.com
designates 66.211.170.89 as permitted sender)
smtp.mailfrom=serv...@paypal.com;
   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com
[6]
Return-Path: 
Received: from mx1.phx.paypal.com [7] (mx3.phx.paypal.com [8].
[66.211.170.89])
by mx.google.com [5] with ESMTPS id
c5-20020a655a8500b0044fb332e9c2si4180181pgt.560.2022.11.18.06.23.32
for 
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256
bits=128/128);
Fri, 18 Nov 2022 06:23:32 -0800 (PST)
Received-SPF: pass (google.com [4]: domain of serv...@paypal.com
designates 66.211.170.89 as permitted sender) client-ip=66.211.170.89;
Authentication-Results: mx.google.com [9];
   dkim=pass header.i=@paypal.com [10] header.s=pp-dkim1
header.b=i5V5Jd8P;
   spf=pass (google.com [11]: domain of serv...@paypal.com
designates 66.211.170.89 as permitted sender)
smtp.mailfrom=serv...@paypal.com;
   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com
[10]
DKIM-Signature: v=1; a=rsa-sha256; d=paypal.com [10]; s=pp-dkim1;
c=relaxed/relaxed;
q=dns/txt; i=@paypal.com [10]; t=1668781410;
h=From:From:Subject:Date:To:MIME-Version:Content-Type;
bh=+ooJ/KHJ7NcHSktaVA2Efxv2wUuyyzgRC9OcH8lTKPI=;
b=i5V5Jd8PU85hThj/qbYYNVtrAe9utMx13ls4RqO/wxfIUwhUDUQ0jzygOkTfY88K
BE74YiE8NsQGHdn4tMuGpInCw+7bnGFPBmOrlk22QztSUjqPH80z6lDtI7NrPpF6
RYaiNevk4cJU4eEXXyr6fIT1fdcDwFdL4WErZ0w0KLpgYwd7dnwgqDrgvDWNJQWd
wzgmA+qZ+9UUrDCsv/h3JCmWBoJaFs3Eaph019ifvg2hLCvZ6Zo3iEqE8aLFQx3b
PDgFKnpTxxI+E1HaIpZJGQwpSI2q7TYrSKvwEBwko9OFXkWe9zlngcE/Km17TlpB
0ujZJGDU7e4EtiOBfTM96g==;
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"
Date: Fri, 18 Nov 2022 06:23:30 -0800
Message-ID: <65.AC.09725.26597736@ccg01mail05>
X-PP-REQUESTED-TIME: 1668781403501
X-PP-Email-transmission-Id: 917850f8-674c-11ed-96b4-3cecef6afc2b
PP-Correlation-Id: f349957836b68
Subject: Invoice from Walmart (0067)
X-MaxCode-Template: RT0

Re: [mailop] Google Gives Gmail Mass Email Services the Boot

[Jarland Donnell via mailop]

This is excellent news. I'm quite ready for some of these services to 
move my way and try to pull off similar activities. I'd love to ruin 
their day just a bit more.


On 2022-11-18 11:56, Anne Mitchell via mailop wrote:
It's about time, and to the extent that you were involved (if at all), 
Brandon, *thank you*!


"Users of mass email services such as Gmass, Woodpecker, Lemlist and 
others that have been using Gmail’s API to send bulk email that tricked 
recipients into thinking that they were receiving personal one-to-one 
emails have been put on notice today by Google: “Applications that use 
multiple accounts to abuse Google policies, bypass Gmail account 
limitation, circumvent filters and spam, or otherwise subvert 
restrictions are prohibited from accessing Gmail API scopes.”"


https://www.isipp.com/blog/google-gives-gmail-mass-email-services-the-boot/

Anne

---
We provide the Good Senders email sender reputation certification list 
to inbox providers

around the world. Learn more at gettotheinbox.com

Anne P. Mitchell,  Esq.
CEO Get to the Inbox by SuretyMail
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email 
marketing law)

Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus, eMail Abuse Prevention System (MAPS)
___
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] Really good paypal phishing email this morning

[Jarland Donnell via mailop]

Someone probably named themselves "Walmart" on PayPal and issued an 
invoice in their UI for your email, triggering PayPal to send you an 
invoice for it.


On 2022-11-18 09:09, Zach Rose via mailop wrote:

https://www.screencast.com/t/dNPpByTSjrq

I rarely use paypal, if ever, and haven't shopped with Walmart in over
a decade, but I can see how this would fool a lot of people. Passed
DKIM/SPF/DMARC, and the code of the email itself referenced their own
static file CDN, so this feels like a scam account internally rather
than a spoofed email.
___
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] Can't deliver to Microsoft from a subnet

[Jarland Donnell via mailop]

Just to be sure because I didn't see you mention it, make sure you've 
contacted them via the form I often see linked so many different ways 
but I'll link as this: 
https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ccsid=636165504238569370


Make sure to request that the IPs be put into temporary mitigation as 
you're warming up a new IP range. When they tell you that can't be done, 
reply and ask for it again, as many times as is necessary. It's just the 
way the dance is done, I've always been told.


Certainly, it would be faster for one of our friends here on this list 
to help you if they can, but it's been a few hours since you sent this 
and I at least have information that is more helpful than silence. So I 
hope it helps some.


On 2022-11-14 03:13, Rodolfo Saccani via mailop wrote:

If anybody from Microsoft con help on this, my gratitude will be huge.


Some companies (like Southeastern railways, for example) are currently
unable to deliver their legit email traffic to Microsoft customers.

We are an email security vendor operating worldwide, we develop and
sell email security virtual appliances and we also operate thousands
of those in our cloud for the customers that choose so.

In London we had to rush to move customers out of UKCLOUD because the
company went into liquidation (
https://ukcloud.com/hub/news/liquidation/ ). UKCLOUD used to host
assets of government bodies, it has been branded as “the UK
sovereign cloud” and for this reason many of our UK customers wanted
to be hosted there.

Because of the liquidation, service continuity is not guaranteed
anymore. We have quickly moved all of the customers to another DC in
London and for such customers we used a new IPv4 /24 that we had
recently acquired (194.39.109.0/24).

We usually don’t have problems in ramping up the reputation of a new
subnet, all of our outbound email traffic is scanned and clean, every
customer has it’s own IP address(es) and we do not accept marketing
customers.

This time it’s been different. The spike in email traffic from about
100 IP addresses belonging to this new subnet is probably seen as
suspicious. These IP addresses are currently heavily rate-limited
despite us having followed the usual procedure through escalations
with Microsoft support.

Some of these customers (public service operators and major colleges,
for example) have a significant outbound email flow being scanned and
delivered from these IP addresses, well above the current limits
allowed by Microsoft and we are forced to route some of the traffic
through relays with a good reputation. This is an emergency procedure
for us because it mixes outbound traffic of different customers
through shared IP addresses, which is something that we don’t do
except in critical situations like this.

Rate-limiting is usually temporary and the limits increase in a
reasonable time but this time it looks like it’s not happening. I am
worried that we might have ended up in a corner, for this reason I
decided to write here, something I’ve never done in many years.

Thanks to whoever will be able to help or provide suggestions.

Rodolfo

--

Rodolfo Saccani | CTO

Email: rodolfo.sacc...@libraesva.com | Phone: +3903411880307 [1]



Links:
--
[1] tel:+3903411880307
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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