Re: [mailop] DigitalOcean IP ranges gone
Dňa 25. novembra 2022 21:21:18 UTC používateľ Jarland Donnell via mailop napísal: >DO uses third-party services to send emails. If you want to block only their >cloud ranges, blocking all of their announcements is appropriate. Anyway, i do not block them directly. I use that ranges to penalize (include in score) clouds in my SMTP connection/RCPT reject score, to be more restrictive to them. But in last three months log i see rejected only 24 (all clouds) of them, thus not as big problem as often mentioned in this ML and I can live without that. I am only disappointed, that this particular cloud is not available now. Hope it will be back again/soon. Thanks to all ;-) regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Partial issues forwarding mails to gmail.com
On 2022-11-24 at 17:20 +0100, Martin Flygenring via mailop wrote: > Is anyone else seeing similar issues when forwarding mails from > gmail.com, back to other addresses at gmail.com? Yes, it seems nitpicky again. I recently received a report of one of those failing. Which are a pain to figure out if it's actually an error in the forwarding server, that might be unexpectedly breaking the DKIM signature... or not at all. Gmail seems to have periods which are fine, and then some months when they reject a lot more. I can't but think that Black Friday is probably related. PErhaps they are receiving more spam that usual, which makes their filters to be more aggressive; or perhaps we are even receiving more spam that gets forwarded to them. Regards ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Partial issues forwarding mails to gmail.com
On 2022-11-24 at 15:28 -0800, Michael Peddemors wrote: > Every modern email client can check multiple email accounts. > The day when remote forwarding was a necessity has now passed, and > now with things like SPF and other email tests, forwarding simply > breaks.. When trying to get some user in the past to do that, I have been told that the mail client they want to use is... Gmail. One which doesn't support fetching mail from an IMAP account. (Also, with no clear explanation on why only that "client" serves their workflow [1], so it's not as if we could replace it by adding an extra feature, even if we had the means to d that) 1- https://xkcd.com/1172/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Partial issues forwarding mails to gmail.com
On 2022-11-25 at 00:10 -0500, Dave Anderson wrote: > And even when it's possible it's not always desirable. An > organization > I'm involved with has many @ email aliases > which forward to the person(s) responsible for those functions. This > is convenient for people who need to communicate with us since they > don't have to hunt for the responsible person(s) and their email > address(es), and is convenient for us since we can easily change the > forwarding when who is responsible for a function changes. > > Dave Forwarding is not the problem. The problem is that the forwardee's server is not aware of the forwarded, and treats it as first-party email. I'd say that forwarding such as the one you describe is done internally every day at lots of organisations. And it doesn't cause any problem, since the original and final server are "the same" (in the same organizational domain) and there is a trust relationship. However, if they are handled by distinct organisations, say j...@freebsd.org to j...@example.net, jdoe should get example.net configured so that freebsd,org MTA is treated as a trusted hop [whenreceiving email for j...@example.net]. When people configure forwarding only at the sending side, the setup is incomplete, and the result may or may not work (or, as it oten happens, work only sometimes), since from example.net point of view, the freebsd MTA is "spoofing everything". Now, one reason it's not done is that the end users don't know they should do anything at that side, but another is that most of them use provders which don't offer such option at all (and generally even freemails for which they don't have any support), So it's a semi-broken setup. (Yes, ARC is presented as a solution, and it could avoid it if the sealer was trusted, but you would still need to have a way to trust it, which is largely similar to getting it configured based on source IP, or a forwarding DKIM selector) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DigitalOcean IP ranges gone
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] DigitalOcean IP ranges gone
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 -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DigitalOcean IP ranges gone
Hello, if we are talking about a list of DO IP prefixes, why not rely on routing information with bgpq4 [1] instead? $ bgpq4 AS-14061 -A4R32 -F '%n/%l\n' | wc -l 85 $ bgpq4 AS-14061 -A6R128 -F '%n/%l\n' | wc -l 3 $ Should be more reliable than a manually updated txt file. [1] https://github.com/bgp/bgpq4 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DigitalOcean IP ranges gone
Dňa 25. novembra 2022 18:09:21 UTC používateľ Jim Popovitch via mailop napísal: >It hasn't been there since at least 2022-Feb according to this: I am sure, that it was accessible after that date, my last update is from 28. october of this year... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DigitalOcean IP ranges gone
On 2022-11-25 10:05, Slavko via mailop wrote: Hi, i was using https://digitalocean.com/geo/google.csv to fill my internal rbldnsd, but recently i start getting 404 for it. I do not update these IP ranges too often, thus i am not sure when it starts to happen, but the problem persists about one week. I checked DO docs, but the URL doesn't changed in it. Please, know someone if it is some temporary problem, list is gone, or that URL changed? regards We just started seeing errors last week on that list. But I don't expect it to change much ;) -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DigitalOcean IP ranges gone
On Fri, 2022-11-25 at 18:05 +, Slavko via mailop wrote: > Hi, > > i was using https://digitalocean.com/geo/google.csv to fill my > internal rbldnsd, but recently i start getting 404 for it. I do not > update these IP ranges too often, thus i am not sure when it > starts to happen, but the problem persists about one week. > > I checked DO docs, but the URL doesn't changed in it. > > Please, know someone if it is some temporary problem, list > is gone, or that URL changed? > It hasn't been there since at least 2022-Feb according to this: https://www.digitalocean.com/community/questions/what-happened-to-the-digitalocean-ip-address-list ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] DigitalOcean IP ranges gone
Hi, i was using https://digitalocean.com/geo/google.csv to fill my internal rbldnsd, but recently i start getting 404 for it. I do not update these IP ranges too often, thus i am not sure when it starts to happen, but the problem persists about one week. I checked DO docs, but the URL doesn't changed in it. Please, know someone if it is some temporary problem, list is gone, or that URL changed? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Another interesting batch of suspicious activity on an IPXO network..
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.531 webstore.od.co.il # 84.32.92.561 mail.gest
Re: [mailop] Another interesting batch of suspicious activity on an IPXO network..
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.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 > > .. mi
