Re: [mailop] Email connection timeouts from Proofpoint (67.231.157.0/24) to my Aussie Broadband static IP (mx1.imrryr.org[144.6.86.210])

2024-06-22 Thread Mark Delany via mailop
On 06Jun24

> I too raised a ticket with ABB as I accidentally discovered that 
> 67.231.157.0/24 was not
> able to reach my mail servers on the ABB network.

FYI. ABB have worked with the other network ops and recently fixed this routing 
issue.

Not strictly a mailops issue per se, but 67.231.157.0/24 is almost entirely 
SMTP outbound
for Proofpoint, so effectively a mail issue.


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


Re: [mailop] too many bad IP blocked

2024-06-22 Thread Ralph Seichter via mailop
* Alessandro Vesely via mailop:

> Researchshows that thousands of rules are fine, but hundreds of
> thousands bring it on its knees.  I attach a picture.

Nobody spoke of hundreds of thousands of rules. That includes the
OP. Unless this magnitude is ever even remotely reached, I see little
incentive to worry about such a completely hypothetical situation,
beyond satisying an understandable curiosity.

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


Re: [mailop] too many bad IP blocked

2024-06-22 Thread Alessandro Vesely via mailop

On Fri 21/Jun/2024 18:12:13 +0200 Ralph Seichter via mailop wrote:

* Jeff Pang via mailop:


given currently I have 3000+ block IPs, every normal client requests
to submission, the ip will be checked through those 3000+ list, which
slow down the normal client's connection certainly.


I consider this is a case "measure, don't guess". I am right now logged
into at a none-too-fancy server moving terabytes of data per day, with
thousands of iptables entries -- without breaking a sweat. Some RAM and
CPU cycles are of course required, but unless you have concrete evidence
of your server struggling, you may be jumping at shadows.



That's still more of a moral judgment than a measure.  Setting up the system 
takes time, and when you feel satisfied of how it works under the current load, 
you certainly don't want to change it.

Research[*] shows that thousands of rules are fine, but hundreds of thousands 
bring it on its knees.  I attach a picture.


Best
Ale
--

[*] 
https://kinvolk.io/blog/2020/09/performance-benchmark-analysis-of-egress-filtering-on-linux

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


Re: [mailop] reverse proxy for smtp client

2024-06-22 Thread Jeff Pang via mailop


Hello

that's b/c the attachment can be sent as 100MB between users.
some users said they are hard sending large mail, so I am asking the 
question.


Thanks.


Although, I am interested in how much the latency affects the
submission and how much that impacts your users.


--
Jeff Pang
jeffp...@aol.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] reverse proxy for smtp client

2024-06-22 Thread Marco Moock via mailop
Am 22.06.2024 um 15:45:36 Uhr schrieb Jeff Pang:

> that's b/c the attachment can be sent as 100MB between users.
> some users said they are hard sending large mail, so I am asking the 
> question.

Is that a latency or bandwidth issue?
TCP is affected by high latency and will slow down.

To make your solution work, place the MTA at a place where it is good
reachable (low latency, high bandwidth) to your clients.
Then the MTA will handle the slow connection.

-- 
Gruß
Marco
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop