from:"Michael via mailop"

Re: [mailop] Echospoofing

2024-08-01 Thread Michael via mailop

45.137.126.85, known spam source.. But yeah, Cloudmark is no longer the 
same quality as it used to be..


On 8/1/24 14:36, Mark Alley via mailop wrote:

On 8/1/2024 4:18 PM, Scott Q. via mailop wrote:

CloudFilter is Proofpoint, right ?

We still gets tons of Spam from them. Not sure if this is related to 
this echospoofing but we just got a pretty big wave


Received: from omta040.useast.a.cloudfilter.net 
(omta040.useast.a.cloudfilter.net [44.202.169.39])
by mx.emailarray.com (Haraka/2.8.21) with ESMTPS id 
6075B447-619F-4FE2-94FB-B6B586F92374.3
envelope-from
(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL);
Thu, 01 Aug 2024 16:19:30 -0400
Received: from eig-obgw-6009a.ext.cloudfilter.net ([10.0.30.184])
by cmsmtp with ESMTPS
id ZYIHspqDRnNFGZcGnsTR6p; Thu, 01 Aug 2024 20:19:29 +
Received: from cp-in-14.webhostbox.net ([103.50.162.147])
by cmsmtp with ESMTPS
id ZcGksNXf0oaMiZcGlsDN9r; Thu, 01 Aug 2024 20:19:28 +
X-Authority-Analysis: v=2.4 cv=deKG32Xe c=1 sm=1 tr=0 ts=66abedd0
  a=+OZ35jC+7F35rNibgVyYDA==:117 a=jZ5zol7y3lBdV6rxEGevAg==:17
  a=MKtGQD3n3ToA:10 a=yoJbH4e0A30A:10 a=5KLPUuaC_9wA:10 a=M51BFTxLslgA:10
  a=A4EqBspgoKYA:10 a=n9Fe_nV6:8 a=x8JhEuIrCajjPMggPtkA:9
  a=PEF53iIozS7NwpkX:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10
  a=xOl7BDxbbtdmDN2MprIA:9 a=HXjIzolwW10A:10 a=T6a71-JsGAwA:10
  a=wlHTxKAh8-WCeF7hZiUK:22 a=WVAGjVSKdBBTa5aWMILr:22 a=WIq2oDtJ_6PiUi2x2ys3:22
Received: from [45.137.126.85] (port=62285 helo=[185.198.243.176])
by cp-in-14.webhostbox.net with esmtpsa  (TLS1.2) tls 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96.2)
(envelope-from)
id 1sZcGi-002goN-2w



Technically yes, that's Cloudmark (owned by Proofpoint) - but no, 
"Echospoofing" has nothing to do with Cloudmark at all.


To my knowledge, .pphosted.com (hosted Proofpoint enterprise mail 
clusters) were the primary affected targets.


- Mark Alley


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


--
"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" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best practices for VPS providers?

2024-07-15 Thread Michael via mailop


They best way is to address that in the egress router.
Most routers nowadays can have alerts and triggers based on traffic, so 
simply create a router policy that sends an alert when too many tcp syn 
packets out from an IP attempt to connect to remote IPs on port 25.


You can do this for many different ports of course, including port 
465/587 etc.. to detect auth attacks from your VPS servers.


On 7/12/24 12:36, Mark E. Jeftovic via mailop wrote:


On 2024-07-12 2:21 PM, Marco Moock wrote:

Am 12.07.2024 um 10:57:15 Uhr schrieb Mark E Jeftovic via mailop:

Implement a policy that if big amounts of spam are going out you can
immediately block outgoing port 25.
Is there anything commonly used for monitoring the level of outbound 
SMTP? Or are vendors forcing all outbound through an egress server to 
scan everything, or homerolling wireshark, tcpdump, web flo scripts.


You'd need to be able to break down which unit is generating the spam.

- mark

-
Mark E. Jeftovic 
Co-founder & CEO easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225

/"Never expect a thing you do not want,
and never desire a thing you do not expect."
-- Bob Proctor /

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


--
"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" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Another 'Verified Email' service on AWS EC2

2024-06-26 Thread Michael via mailop




On 6/26/24 04:24, Jeff Peng via mailop wrote:

On 2024-06-26 15:11, Gellner, Oliver via mailop wrote:

On 26.06.2024 at 00:24  Jeff Pang via mailop wrote:

since aws ses was blocked, other esp such as mailchannel, mailgun, 
sendgrid can be blocked also?



That's a good idea, except when you have to deal with companies like
Everbridge Inc or Tencent QQ, which apparently think it's a good 
idea to

  rent VMs at various cloud providers and run them with their default
config.


Amazon SES does not use email servers with PTR records that end with 
compute-1.amazonaws.com, so it is not affected. 
ec2-.compute-1.amazonaws.com is the default name of AWS instances 
and only used where the owner did not specify his own domain. This is 
akin to people sending emails from @...onmicrosoft.com or 
@...azurewebsites.net or @...vps.ovh.




My mail server for domain simplemail.co.in has a ptr with the azure 
domain as value:


$ dig mx.simplemail.co.in +short
20.120.225.36

$ dig -x 20.120.225.36 +short
tls-mail.westus2.cloudapp.azure.com.

do you think if I should change the ptr value to something other like my 
own domain?


Yes, the domain in the PTR record should reflect the responsible party..
There are M3AAWG Best Practices articles that can go into more details..

But, for example.. this is your responsibility, not Azure's when you 
have a spam leakage.  If you want ordinary people to notify you, they 
will go to your  website as reflected in the domain in the PTR, to look 
for contact information.


This is even more important than FCrDNS



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


--
"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" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Delivery issues with libero.it / virgilio.it (IOL)

2024-04-03 Thread Michael via mailop


You do realize you forgot to provide your IP Address ;)

On 4/3/24 15:56, Claudio Faoro via mailop wrote:

Hi everyone,

a couple of weeks ago I configured a new Postfix server, it's used 
exclusively by a newsletter service with 2 subscribers.
The newsletter service has been active for more than 10 years on a very 
old server running qmail.
Unfortunately, I had to decommission the old qmail server in a few days, 
replacing it with the new one. It was not possible to keep the same IP 
address.
I've correctly configured the SPF, DKIM, DMARC and PTR records 
(mail-tester.com gives me 10/10).
The first few days, I had problems delivering mail to several providers 
due to the amount of messages. I guess it's partly due to the new IP.

For example:

Mar 30 15:37:00 mx1 postfix/smtp[2021]: 6940F7FF09: to=, 
relay=mx-eu.mail.am0.yahoodns.net[188.125.72.74]:25, delay=3473, 
delays=0.47/3472/0.71/0.04, dsn=4.7.0, status=deferred (host 
mx-eu.mail.am0.yahoodns.net[188.125.72.74] said: 421 4.7.0 [TSS04] 
Messages from REDACTED temporarily deferred due to unexpected volume or 
user complaints - 4.16.55.1; see 
https://postmaster.yahooinc.com/error-codes (in reply to MAIL FROM command))


After a few mailings, the situation seems to have stabilized, Yahoo no 
longer gave me problems.
Unfortunately, a good percentage of our subscribers use an email address 
from Italiaonline/IOL (libero.it, virgilio.it, iol.it, inwind.it, etc...).

Most of the emails to IOL get bounced:

Mar 30 00:15:40 mx1 postfix/smtp[51700]: 509762617D: to=, 
relay=smtp-in.libero.it[213.209.1.129]:25, delay=116950, 
delays=116848/101/0.09/1.1, dsn=4.0.0, status=deferred (host 
smtp-in.libero.it[213.209.1.129] said: 451 too many messages, slow down. 
[smtp-22.iol.local; LIB_650] (in reply to end of DATA command))


The limit is triggered very quickly and it's removed after several hours.
I tried to throttle the sending to IOL addresses on Postfix 
(destination_concurrency_limit = 2 and destination_rate_delay = 300s), 
but I keep getting capped after a while.
I don't have much information regarding the old qmail server, but it 
seems that there were not all these problems (there wasn't even DKIM and 
DMARC configured!).


I don't understand how to resolve these problems with the libero.it 
mailboxes (and more generally, with all Italiaonline mailboxes). Do you 
have a contact in Italiaonline who can help me?

Any info would help me, thanks in advance.

Regards,
Claudio

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


--
"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" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Meta outgoing servers in black list (SORBS, 0SPAM...)

2024-02-01 Thread Michael via mailop

It would be helpful if Meta used a better PTR naming convention for 
these servers.. ;)


host 66.220.155.136
136.155.220.66.in-addr.arpa domain name pointer 
66-220-155-136.mail-mail.facebook.com.


Not sure who dreamed up that one..

On 2/1/24 02:18, Philip Paeps via mailop wrote:

On 2024-02-01 17:32:14 (+0800), Eduardo Díaz Comellas via mailop wrote:
I've got a customer complaining that they doan't receive emails from 
Meta for password reset. We have tracked down this to see that a lot 
of this servers are blacklisted in popular blacklists.


[...]

I usually don't care when the sender is blacklisted, as our policy is 
that the sender has to deal with their own problems, but this 
particular customer has a point.


I think "don't care: it's the sender's problem" is a sound policy.

I temper and denylists I use with allowlists.  DNSWL is a popular one. 
Abusix has a good one too.  There are others.


Check https://multirbl.valli.org


Btw, how do you deal with this big players' blacklist problems?


The same way I deal with other players.

Philip



--
"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" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamcop from a forwarding standpoint

2024-01-25 Thread Michael via mailop

Interesting note in passing, some customers who also had spamcop in 
their RBL listing has noted that even some Microsoft outgoing IPs are 
appearing on that RBL.. (cannot confirm)


Not that they don't deserve it, but rejecting based on that RBL might 
cause some grief, better to use it as a scoring flag..


Still, love what SpamCop does.. our cluster has even had the odd report 
over the last couple years, and though maybe not timely, it was usually 
an accurate report of a compromised user we had already actioned 
automatically.


On 1/25/24 01:30, Andy Smith via mailop wrote:

Hi,

On Thu, Jan 25, 2024 at 09:58:17AM +0100, Cyril - ImprovMX via mailop wrote:

Unfortunately for us, Spamcop believe we are the one sending spam when they
trace back the Received headers, because we are the last hop before landing
to that user's inbox.

Is there a way to tell in the headers that we are merely forwarding emails
(we do have spam protection in place, but some of them always manage to get
through) ?


There's no way for you to do this, because SpamCop has no way to
know that you are "part of" the recipient's infrastructure.

SpamCop instructs its users not to ever report forwarded email if
you like I should think you could continue marking every report as
resolved or not applicable due to the fact that it's forwarded and
SpamCop would side with you (I've no special knowledge on this).

Something that a SpamCop user CAN do is register (with them) the
forwarding path, and then SpamCop will know about that. Here's the
help for that:

 
https://forum.spamcop.net/forum/7-mailhost-configuration-of-your-reporting-account/

That's something only the SpamCop user can do though, and if they're
not understanding the issue and blindly hitting "report" then that
won't help you.

The exact same problem happens when people report spam that they
received through a mailing list. The SpamCop user needs to be a bit
careful.

Thanks,
Andy



--
"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" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP dictionary attacks from 20.42.100.251 (one of Microsoft's IP addresses)

2024-01-02 Thread Michael via mailop

For the record,it's all of the Azure, Google, AWS Cloud, Tencent and 
many other cloud providers that are now abused for BEC Email Compromise, 
and dictionary attacks.


Since very few 'servers' are used for email authentication/clients it is 
quite effective to block email auth from those providers by default.


MagicMail servers allow blocking AUTH from those ranges by default, 
except for allowed exemptions, for the last couple years as it has got 
that bad.


There is a difference between an email client, and other devices, so 
various fingerprinting and identification tricks in the SMTP and IMAP 
servers can help.


But there are edge cases to consider, eg desktop in the cloud, and IMAP 
monitoring SaaS tools, but in general.. blocking AUTH from cloud 
providers that don't quickly respond to abuse complaints, is the way to 
go ;0


Happy New Year All..



On 1/1/24 02:05, Marco Moock via mailop wrote:

Am 01.01.2024 um 01:46:44 Uhr schrieb Randolf Richardson, Postmaster
via mailop:


Is anyone seeing large numbers of dictionary attacks from
20.42.100.251 (which is owned by Microsoft)?  I'm curious if they're
engaging in large-scale targeting.


Doesn't have a PTR, so no regular mail server.
I assume it is one of their Azure customers servers that has been
hacked or is rented by an abuser.


P.S.:  I don't bother reporting abuse directly to Microsoft anymore
because in the past they just bounced every message sent to their
postmaster@ and abuse@ accounts.


For what reason did the bounce those messages?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--
"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" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Bounces

2023-11-16 Thread Michael via mailop

Always terrible when big ESP's simply say 'Remove Us' and think it will
happen because they are big, instead of 'asking' why you are being
flagged, and what can you do to improve your reputation..

Especially as a 'Financial Services' related business, the onus is on
you to ensure that you are at the top of your game, and have clear
transparency..

And on this list, you better be willing to share exactly what
email/domain/ip is having the problem, if you want the community to help
you out..

On 11/16/23 03:46, Polath, Kiran via mailop wrote:

Hello Team,

We at Broadridge Financial Solutions sends millions of email as
financial customer communication on behalf of our clients .We see our
emails are frequently getting blocked by charter.net
& rr.com, this is impacting our reputation . Can you take it as high priority and remediate this as it is very important to our customers to have this resolved. please find the below reasons