Re: [mailop] reverse proxy for smtp client

Am Sat, 22 Jun 2024 07:01:00 +0800 schrieb Jeff Pang via mailop : > do you know if there is a reverse proxy for submission? > for instance, my server is in the US, while some customers are in EU, > so I consider to deploy a reverse proxy in EU for speeding up their > access. Then you need a real

Re: [mailop] reverse proxy for smtp client

According to Viktor Dukhovni via mailop : >In any case, modern MUAs deliver mail in the background, and TCP handles >high delay networks just fine, so most users don't feel any impact from >high RTTs to the submission service. It is your IMAP store and >especially any webmail servers that you

Re: [mailop] reverse proxy for smtp client

On Sat, Jun 22, 2024 at 07:01:00AM +0800, Jeff Pang via mailop wrote: > do you know if there is a reverse proxy for submission? None should be necessary. > For instance, my server is in the US, while some customers are in EU, > so I consider to deploy a reverse proxy in EU for speeding up their

[mailop] reverse proxy for smtp client

Hello list, do you know if there is a reverse proxy for submission? for instance, my server is in the US, while some customers are in EU, so I consider to deploy a reverse proxy in EU for speeding up their access. Thanks. -- Jeff Pang jeffp...@aol.com

Re: [mailop] too many bad IP blocked

before it gets resolved I have to take time to do: 1. setup iptables + ipset for fail2ban, or 2. update the system to use nftables, or 3. use null route, and/or 4. use spamhaus XBL Thanks for all the help. regards But I feel like this discussion has been resolved already. -- Jeff Pang

Re: [mailop] too many bad IP blocked

On Fri, 2024-06-21 at 01:01 +, Ferris, Rhys (SCC) via mailop wrote: > > > > I guess my mentality is a large IPTables is still less of a load > than letting them establish a connection and attempt to > authenticate, but I'm certainly open to better ideas. Somewhat OT, but if you can switch

Re: [mailop] [E] Yahoo Delays

On Fri, 21 Jun 2024 13:46:27 -0400, Lili Crowley via mailop wrote: >Things should be improving but it will take time for the queues to calm down That was prophetic. When I first read this, there was nothing in my Y! mail. Eleven minutes later, 21 new pieces in the Spam folder... mdr --

Re: [mailop] [E] Yahoo Delays

Things should be improving but it will take time for the queues to calm down Thanks! *Lili Crowley* she/her Postmaster On Fri, Jun 21, 2024 at 11:01 AM Lili Crowley wrote: > Hey all > > We are hearing this is happening in volume. We’re looking into it now. > >

Re: [mailop] too many bad IP blocked

* 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

Re: [mailop] too many bad IP blocked

Matus UHLAR - fantomas via mailop skrev den 2024-06-21 17:27: But I feel like this discussion has been resolved already. unless :) i have solve to just know my custummers asn's, and only let there isp asn be allowed, this saves much more lines in shorewall then if i did shorewall

Re: [mailop] too many bad IP blocked

On 2024-06-21 04:53, Jeff Pang via mailop wrote: 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. On 21.06.24 10:57, Anthony Howe via mailop wrote: I

Re: [mailop] too many bad IP blocked

On 2024-06-21 04:53, Jeff Pang via mailop wrote: 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 think you are worrying about nothing. 3000+ IPv4

Re: [mailop] [E] Yahoo Delays

Hey all We are hearing this is happening in volume. We’re looking into it now. Thanks! *Lili Crowley* she/her Postmaster On Fri, Jun 21, 2024 at 11:00 AM Michael E. Weisel via mailop < mailop@mailop.org> wrote: > Happy Friday everyone. We have been seeing

[mailop] Yahoo Delays

Happy Friday everyone. We have been seeing some queue delays sending to Yahoo domains since around 8:45am Eastern this morning across the board of our clients IP’s. I’m not seeing bounces, just delays at this point where mail is just delivering out at about 5% of the normal speed.

Re: [mailop] too many bad IP blocked

On 2024-06-21 22:04, Bill Cole via mailop wrote: On 2024-06-20 at 20:10:32 UTC-0400 (Fri, 21 Jun 2024 08:10:32 +0800) Jeff Pang via mailop is rumored to have said: And in an hour it gets double IPs blocked. $ sudo iptables -L -n|grep DROP|wc -l 2805 any idea? About what? Unless you are

Re: [mailop] too many bad IP blocked

On 2024-06-21 at 02:56:44 UTC-0400 (Fri, 21 Jun 2024 08:56:44 +0200) Dominique Rousseau via mailop is rumored to have said: Also, if the same IPs are comming back often, you could look the "recidive" rules, for long term ban, and/or (semi)manually check wether IPs are from somme common

Re: [mailop] too many bad IP blocked

On 2024-06-20 at 20:10:32 UTC-0400 (Fri, 21 Jun 2024 08:10:32 +0800) Jeff Pang via mailop is rumored to have said: And in an hour it gets double IPs blocked. $ sudo iptables -L -n|grep DROP|wc -l 2805 any idea? About what? Unless you are seriously memory or cpu-constrained, 2805 simple

Re: [mailop] too many bad IP blocked

Dňa 21. júna 2024 13:43:15 UTC používateľ Alessandro Vesely via mailop napísal: >Login attempts don't seem to follow any kind of decent dictionary attack >strategy, as they try random userid/ password combinations, and repeat failed >ones. My devocot's auth daemon (mentioned early) can

Re: [mailop] too many bad IP blocked

On Fri 21/Jun/2024 14:55:16 +0200 Slavko via mailop wrote: Dňa 21. júna 2024 11:50:23 UTC používateľ Alessandro Vesely via mailop napísal: That db currently holds 2,014,973 records. Rather than ipset or single iptables rules, the IPs are stored on a Berkeley DB. They get blocked by a few

Re: [mailop] too many bad IP blocked

Dňa 21. júna 2024 11:50:23 UTC používateľ Alessandro Vesely via mailop napísal: >That db currently holds 2,014,973 records. Rather than ipset or single >iptables rules, the IPs are stored on a Berkeley DB. They get blocked by a >few iptables rules ending in -j NFQUEUE. That passes the

Re: [mailop] too many bad IP blocked

Am 21.06.2024 um 10:46:02 Uhr schrieb L. Mark Stone via mailop: > It's not uncommon for us to be blocking 30K-50K IP addresses, with no > performance issues. Reboots do take about a minute or two longer > however; Fail2Ban rewrites the route table on service start/stop to > populate/depopulate

Re: [mailop] too many bad IP blocked

On Fri, 21 Jun 2024, Jeff Pang via mailop wrote: today I clear up iptables rules, and run fail2ban again. in half of an hour, it blocked 1400+ IPs. $ sudo iptables -L -n|grep DROP|wc -l 1407 it seems the black ips are coming endlessly. most of the bad actions are like this one:

Re: [mailop] too many bad IP blocked

that's really nice info. I will read them. thanks. Consider switching to ipset-s or null routes, both have a lower overhead than plain rules. Ipset-s also have the benefit of supporting expiration (timeout). -- Jeff Pang jeffp...@aol.com ___

Re: [mailop] too many bad IP blocked

On Fri, Jun 21, 2024 at 10:46:02AM +, L. Mark Stone via mailop wrote: > We use "route" as the banaction in our Fail2Ban. If iptables or other filtering performance is a concern, I would definitely support the suggestion to use blackhole routes instead. Searching on obvious keywords dug out

Re: [mailop] too many bad IP blocked

On Fri 21/Jun/2024 10:55:53 +0200 Jeff Pang wrote: Here is the drop list by iptables, https://cloud.hostcache.com/drop.list can you help take a look? Of those 2805 addresses, 2726 are also on my block db, 79 are not. That db currently holds 2,014,973 records. Rather than ipset or single

Re: [mailop] too many bad IP blocked

thanks Mark. i will check the docs to see how route works. There is a Zimbra-specific blog post here:https://wiki.zimbra.com/wiki/Configure_Fail2Ban_for_Zimbra_Server_with_route_instead_of_iptables_to_block_IPs Our filter/jail for a Zimbra-specific nginx add-on is here (again,

Re: [mailop] too many bad IP blocked

Consider switching to ipset-s or null routes, both have a lower overhead than plain iptables rules. We've tested ipsets with hundreds of thousands of IPs, ipset-s also have the benefit of supporting entry expiration (timeout). smime.p7s Description: S/MIME Cryptographic Signature

Re: [mailop] too many bad IP blocked

We use "route" as the banaction in our Fail2Ban. It's not uncommon for us to be blocking 30K-50K IP addresses, with no performance issues. Reboots do take about a minute or two longer however; Fail2Ban rewrites the route table on service start/stop to populate/depopulate the route table. We

Re: [mailop] too many bad IP blocked

Am 21.06.2024 um 16:55:53 Uhr schrieb Jeff Pang via mailop: > Here is the drop list by iptables, > https://cloud.hostcache.com/drop.list > > can you help take a look? You can create a small script that parses the addresses to the application rblcheck in linux. IIRC ipset also offers a way to

Re: [mailop] too many bad IP blocked

Here is the drop list by iptables, https://cloud.hostcache.com/drop.list can you help take a look? regards. You can also use dnsbl (that may run locally) if that is faster. Is a valuable amount of those IPs listed in blocklist.de, spamhaus, uceprotect etc.? -- Jeff Pang jeffp...@aol.com

Re: [mailop] too many bad IP blocked

Dňa 21. 6. o 6:57 Viktor Dukhovni via mailop napísal(a): That said, it seemed reasonable to implement a recent suggestion from the Postfix list and block XBL-listed IPs from connecting to my submission services. This had a rather noticeable effect on the rate of failed SASL probes. The

Re: [mailop] too many bad IP blocked

Thanks Dominique. I will check ipset and learn it. iirc, current fail2ban can put the banned IPs in an ipset, which is very effcient for iptables filtering. -- Jeff Pang jeffp...@aol.com ___ mailop mailing list mailop@mailop.org

Re: [mailop] too many bad IP blocked

Dňa 21. 6. o 8:44 Matus UHLAR - fantomas via mailop napísal(a): Not sure about nftables. nowadays both, the iptables & ntables, share the same netfilter code/hooks. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list

Re: [mailop] too many bad IP blocked

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. regards. what is a theoretical performance hit worth to you, when compared to the possible cost of

Re: [mailop] too many bad IP blocked

never know ipsets. I will check it. thank you. regards. ipsets should be much more effective to work and maintain than iptables. -- Jeff Pang jeffp...@aol.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop

Re: [mailop] too many bad IP blocked

I will try to use spamhaus XBL for submission. thanks victor. the Postfix list and block XBL-listed IPs from connecting to my -- Jeff Pang jeffp...@aol.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop

Re: [mailop] too many bad IP blocked

Hi Jeff, Le Fri, Jun 21, 2024 at 07:20:17AM +0800, Jeff Pang via mailop [mailop@mailop.org] a écrit: > today I clear up iptables rules, and run fail2ban again. > in half of an hour, it blocked 1400+ IPs. > > $ sudo iptables -L -n|grep DROP|wc -l > 1407 > > > it seems the black ips are coming

Re: [mailop] too many bad IP blocked

On 21.06.24 07:20, Jeff Pang via mailop wrote: today I clear up iptables rules, and run fail2ban again. in half of an hour, it blocked 1400+ IPs. $ sudo iptables -L -n|grep DROP|wc -l 1407 I use ipset: REJECT tcp -- anywhere anywhere match-set block-mail src

Re: [mailop] Anyone from TIM Brazil on the list regarding fake NFe (Electronic Invoices Emails)?

Hi Jeff > Maybe give a try on this one? > admin.exter...@timbrasil.com.br > > But I doubt they will answer you. I'm not even able to send them emails, same as with their abuse desk. - The following addresses had permanent fatal errors - (reason: 550 5.4.1 Recipient address