Re: [mailop] MagicMail / MIPSpace Listing
A server manage is also listed on All and Poor lists. I did a search around that IP space, including stuff that never sends emails, like VPN concentrators, routers, and unused IP and they're listed too inside the same /24. I wouldn't be surprised if they block /24s. Removal URL that I found is https://www.mipspace.com/removal.php Joe On 1/29/2022 at 4:45 PM, "John Gateley via mailop" wrote: > >I just checked my server (very small) and it has the same result >as yours. >Both of them are on the MIPSpace-All and MIPSpace-Poor list. >I can't find any way to delist. > >These are not pure spam, they are focused on (possibly solicited) >commercial email. > >Since my server is just my wife and I, and we send no bulk mail at >all, >it is a puzzle why I am on their list. > >John > >On 1/29/22 3:41 PM, Scott Mutter via mailop wrote: >> Anybody from MagicMail or MIPSpace able to give any insight as >to >> why 205.251.153.98 is listed? >> >> 550-Your message was rejected by this user and was not delivered. >> 550-Reason: This system uses BMS to check your IP address >reputation, >> and was rejected by the user. IP=[205.251.153.98]. >> 550-Protection provided by: MagicMail version 5.0 >> 550-For more information, please visit the URL: >> 550-http://www.linuxmagic.com/power_of_ip_reputation.html >> 550-or contact your ISP or mail server operator. >> 550 4572d27e-814b-11ec-be05-005056a29aa8 >> >> Would love to have more information about this listing. This is >not a >> client facing mail server. It's used for our company's mail >systems >> only. So I can pretty much vouch that it's not sending out any >spam. >> >> ___ >> 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] Microsoft/O365 SPF failures
That is intentional/by design. The source is inside 40.95.0.0/16 which is their "relay pool". It is documented here - https://docs.microsoft.com/microsoft-365/security/office-365-security/high-risk-delivery-pool-for-outbound-messages. Scroll down to the relay pool subheader and read up more about it. Hope this helps. On 1/20/2022 at 11:32 AM, "Klaus Ethgen via mailop" wrote: > >Hi, > >since several weeks I see more and more SPF-Errors for mails >coming from >O365. It seems that when mails gets relayed, they use outbound mail >servers that are not valid for sending from the (relaying, not >origin) >mail address. > >My O365 account where I have relaying active is an academic >account. > >The last failure comes from IP 40.95.92.45 and is trying to deliver >mails from klaus_eth...@stud.phzh.ch (my academic account). > > > spfquery -ip 40.95.92.45 -sender klaus_eth...@stud.phzh.ch > fail > Please see >http://www.openspf.org/Why?id=klaus_ethgen%40stud.phzh.ch=40.95. >92.45=spfquery : Reason: mechanism > spfquery: domain of stud.phzh.ch does not designate 40.95.92.45 >as permitted sender > Received-SPF: fail (spfquery: domain of stud.phzh.ch does not >designate 40.95.92.45 as permitted sender) client-ip=40.95.92.45; >envelope-from=klaus_eth...@stud.phzh.ch; > >It is pretty impudent from microsoft to write in the deliver >failure: > It's likely that only the recipient's email admin can fix the > problem. Unfortunately, it's unlikely Office 365 Support will >be able > to help with these kinds of externally reported errors. > >No, it IS solely the fault of Microsoft not be able to manage SMTP >correctly. > >Any ways to get them to correct their SMTP setup? > >Regards > Klaus > >Ps. Could it be, that http://www.openspf.org/Why is broken? I get >connection refused. >-- >Klaus Ethgen >http://www.ethgen.ch/ >pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen > >Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Malware waves from hotmail.com
Hello Scott, Azure's IP space, updated once a week with one week lead before they go live - https://www.microsoft.com/en-us/download/details.aspx?id=56519 From the looks of the json filename, it is changed after each release, so I wouldn't recommend re-downloading the below json file for new updates - https://download.microsoft.com/download/7/1/D/71D86715-5596-4529-9B13-DA13A5DE5B63/ServiceTags_Public_20210531.json AWS - https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html - If the download URL doesn't change (doesn't seem to me that it does), you can go straight to https://ip-ranges.amazonaws.com/ip-ranges.json. If you have an AWS account, you can sign up for notifications when new subnets are added. (It requires using their SNS service.) GCP - https://cloud.google.com/compute/docs/faq#find_ip_range - If the download URL doesn't change (doesn't seem to me that it does), you can go straight to https://www.gstatic.com/ipranges/cloud.json -joe On 6/5/2021 at 7:22 AM, "Michael Peddemors via mailop" wrote: > >Sorry, bit laid up and typing with one hand, but luckily all the >top >three publicly list their IP(s), unfortunately they do it via web >URLs' >that you need to parse instead of via say a rwhois entry. > >(some are listed at various services you can query in RBL format >such as >RATS-AZURE) > >Some you can check via PTR naming conventions, and others you can >do an >ASN lookup. > >don't have the URL's handy, but welcome to reach out off list. > > > >On 2021-06-04 4:08 p.m., Scott Mutter via mailop wrote: >> On Fri, Jun 4, 2021 at 1:24 PM Michael Peddemors via mailop >> mailto:mailop@mailop.org>> wrote: >> >> With apache, you can use modsecurity quite easily, and you >can block >> all >> azure (and other cloud providers ranges) from certain >services like >> wordpress, or contact forms etc.. (you can even do dns based >checks or >> rbldnsd) .. >> >> >> Are there any links for this? AFAIK mod_security is just a >module - to >> actually do anything it requires a ruleset. Further from that, >how does >> it determine what is Azure and what is not? Is it just blocking >IP >> addresses? Seems you'd need a list of all of the Azure IP >address >> space. And from what I have seen the offending IPs are all over >the place: >> >> 157.55.39.138 >> 207.46.13.5 >> 20.83.33.136 >> 20.94.247.9 >> 40.124.141.27 >> 40.124.141.27 >> 40.124.193.244 >> 40.76.220.206 >> >> Are just a few. >> >> But if there's a way to block Azure and other cloud based >services, I'd >> be interested in that. But I'd suspect you'd need a list of all >of >> their IP address spaces - is that information available some >where? >> >> >> ___ >> 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" 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] SuspiciousRemoteServerError
I don't think it's a global change by Microsoft. If you're correct that the error is a certificate issue, it is within the realm of possibilities that a particular O365 customer (provided *.eurprd08.prod.outlook.com is O365) has created a send connector for a domain that you host (or not, if they really screwed it up), requiring a trusted certificate, as opposed to a self-signed cert. They can additionally require a specific domain or wildcard (*.example.com) be listed in the subject name/subject alt name field of the trusted certificate presented. However, it has been my experience that Microsoft does not allow you to set Connectors that don't succeed during the config process. Eg: If the test email fails to transmit, O365 does not allow the customer to save the connector config. Now, I have no clue how that is enforced through PowerShell... but since the GUI is basically PS wrapped with nice buttons and input fields, I'd hope the experience is uniform. -joe On 5/19/2021 at 3:33 AM, "Wolfgang Rosenauer via mailop" wrote: > >Hi, > >I see increasing reports that sending from MS365 (and similar) >fails >with messages like these: > >Server at *.eurprd08.prod.outlook.com returned '550 5.4.318 >Message expired, connection reset >(SuspiciousRemoteServerError)(450 >4.4.318 Connection was >closed abruptly (SuspiciousRemoteServerError))' >Server at XYZ returned '450 4.4.318 >Connection was closed abruptly (SuspiciousRemoteServerError)' > >There are some pointer that it might be related with TLS and >certificates. >Actually there really is for that target a configuration in use >that the >MX record name does not match the certificate dn but this was >never a >problem so far and I'm not sure if that is causing the issues. > >Did MS introduce some feature/setting to do strict checking on TLS >certificate names and MX DNS names? > > >Thanks, > Wolfgang >___ >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] paypal.com issues
Maybe it was a temporary issue? Right now I only see one entry - dig paypal.com txt | findstr "spf" paypal.com. 3444IN TXT "v=spf1 include:pp._spf.paypal.com include:3ph1._spf.paypal.com include:3ph2._spf.paypal.com include:3ph3._spf.paypal.com include:3ph4._spf.paypal.com include:3ph5._spf.paypal.com ~all" -joe On 5/20/2021 at 6:10 AM, "Javier Angulo via mailop" wrote: > >Hi, > >I wonder if somebody is having problems with paypal.com on the >receiving >side (or maybe someone from paypal can help). > >We are rejecting what seems to be legit messages from paypal >employees >because: >- They have a p=reject DMARC record >- DKIM check fails (body has been altered) >- paypal.com has 2 SPF records: > >$ dig txt paypal.com +short >... >"v=spf1 include:pp._spf.paypal.com include:3ph1._spf.paypal.com >include:3ph2._spf.paypal.com include:3ph3._spf.paypal.com >include:3ph4._spf.paypal.com include:3ph5._spf.paypal.com ~all" >"v=spf1 include:aspmx.pardot.com ~all" > >So at least IMHO a single SPF record should be used. > >Cheers, >Javier >___ >mailop mailing list >mailop@mailop.org >https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
