> Currently there are issues sending mail to outlook, gmail, hotmail, and yahoo (they use outdated nospam-block lists and do not help us in finding a solution. Please find a more serious mail provider.
... very curious to know what this sysop considers a "serious mail provider."
A serious mail provider would not block legitimate incoming email with massive amounts of collateral false positives.
A serious mail provider would care about ensuring that this does not happen and handle enquiries sent to the RFC-mandated address postmaster@ and respond promptly to such enquiries.
I send mail from Digital Ocean. I can tell you that neither Apple nor Microsoft give two hoots about any of those if you are on their ASN blocklist.
I send lots of email that is verified with SPF and DKIM to them via relays. But any messages sent directly from "untrustworthy" IP ranges are just blocked with a generic message.
This is in contrast to GMail which rightfully treated my first messages as suspicious. But once a handful of users pressed "not spam" they don't care about what IP it comes from anymore as the ___domain reputation has taken precedence.
Not only that. I used to run an email server and despite the fact that I had all of that one day outlook decided to consider my IP address (on AWS EC2) as spam and thus reject emails.
To this day is too much effort running your email service. I moved to an account to Infomaniak that works good and I don't dove all my data to Microsoft or Google.
Given that this sysop thinks that these email providers still use IP-based block lists, it gives me the impression that this person has been out of the email game for a long, long time.
As others have mentioned, the ___domain also does not use SPF, DMARC or PTR address. So it'll also be unlikely that they sign their outbound email with DKIM.
Microsoft absolutely does use strict ASN-based blocking.
> permanent error (550): 5.7.1 Unfortunately, messages from [{REDACTED IP}] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3140). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
The other providers don't seem to be as picky. (At least I haven't seen major issues sending from Digital Ocean which is an ASN with a bad reputation.) It seems that once they had experience with my ___domain (with SPF + DKIM) they judge messages primarily using ___domain reputation not IP reputation.
Those are temporary/ephemeral IP restrictions. They typically last for a few minutes. That's not the same as the static 'outdated' IP block lists that the OP is referring to.
Simply said: if block lists were permanent, we'd be blocking the entire IPv4 space by now. And also, spammers would have almost free reign when using IPv6, since you can get blocks of millions of addresses for free. Large email providers know this, they have been battling spam for decades now.
When enabling DMARC the IP address more or less becomes irrelevant. If the email is not DMARC aligned the email won't be accepted anyway (I'm assuming a 'reject' DMARC policy here) and if the email is DMARC aligned, the ___domain reputation, rather than IP reputation will be used.
When working with DMARC aligned domains, most email service providers will rely solely on content based spam detection, and how often people flag the email as spam to determine the ___domain's reputation.
Of course I am generalizing here. What I wrote here is true for most large email service providers, but each have their own implementation. And of course there will always be self-hosted/on-premise solutions that keep using static block lists (for example: Spamhaus).
These aren't temporary. Every message I have sent for years has got the same block message. Sure, they aren't necessarily outdated but they aren't lasting for a few minutes.
> When working with DMARC aligned domains, most email service providers will rely solely on content based spam detection
This seems to be true for most major providers. But my experience shows that Microsoft and Apple don't do this. They still apply strict broad IP-based blocking. Sending messages from the same ___domain via a relay such as AWS SES is perfectly fine. But if the sender IP is in Digital Ocean ASN it is dropped right away. The ___domain is p=reject
I worked with a guy who would take every piece of spam we got, dig into the mail headers, and then add the source IP to a custom blacklist on our mail server. It took a few hours to figure out why we weren't getting email from a customer and that's how I found the list.
He had manually added over 20,000 IP addresses to the list.
Let's talk about Microsoft as serious mail provider:
I self-host my mail server for <10 years. My server is in 0 blocklists. DKIM / DMARC / SPF implemented since ages. The company I work for, hosts their emails on 0365, I have been sending emails from one account to the other with no problem.
Recently I got an email from an outlook.com account. I am in the contacts list of the sender. I tried to respond, my email was rejected. The email auto-response from MS contained links with "things you should do in order to make mails from your server acceptable by MS". I have everything done already since ages. Nothing missing.
I googled on how to "appeal". I find a hell lot of people complaining in MS forums about it, no obvious solution.
Eventually I find a portal from MS to do exactly that: Appeal. I tried to use the portal but I got an error "event service error" - or something similar. Portal not working.
I say "what the heck - I ll try later". I do try later, same outcome. Several times. For days. I google the error, I find several threads on redit since years complaining that the portal doesn't work giving this exact error. Since years.
I keep trying nevertheless to respond to the email and go through the portal again for days. Nothing.
I try the following: I signup for azure, it asks me for an email address, I say I have none and guides me to sign up to outlook. Outlook asks me for a backup email address, I provide my email address from the blocked server.
I then try to respond again to the original email that outlook has been rejecting - WORKS.
Summary again: MS blocks email my mail server for not fulfilling requirements that it actually fulfills. MS portal to object, doesn't work since years. I create an outlook email and set self-hosted mail address as "backup" - my server gets unblocked.
Fun fact: I received "on-boarding" emails from MS Azure to my new MS Outlook account. MS Outlook classified them as "Junk".
Actually, that's precisely expected from Microsoft. The impossibility of communicating with any humans who've ever been in the same room as a clue about how to fix these things assures this.
I’ve seen my fair share of email delivery issues, but all being this globally shit-canned says to me is “we’re operating in some very-abused IP space and operators aren’t lining up to let us in”.
This is all assuming that the mail is otherwise ticking all the boxes. One too many times I’ve seen someone get on their HN soapbox because their $5 DigitalOcean mail server keeps getting shit-canned, only to find after some polite prodding that they just flat-out weren’t aware of the modern-day complexities of sending email.
Not to say that this is what’s happening here, of course.
I got the impression this refers to the services geared toward the general public. I wonder if the providers have more stringent requirements for consumer email than for business email. I imagine the latter would be more likely to fuss about false positives, particularly when dealing with vendors or customers.
Probably one that's not free and ad-supported. Circa 2000, Hotmail and Yahoo were looked down on. Gmail avoided this by providing more storage than most ISPs offered and being invite-only.
Is IBM i the thing formerly known as AS/400? IBM's new shiny next-millennium single letter branding is more confusing than their old-school letters-virgule-numbers branding.
One of the most interesting things about IBM i/AS/400 is its use of hardware memory tagging. There is a secret set of extensions to the PowerPC ISA which allows you to associate a tag bit with every 16 bytes of memory. This is used to implement a capability-based model where valid pointers can't be forged.
It's amazing that (if I understand it correctly) the entire security of the system rests on the user not being able to execute arbitrary code. One wrong-code bug in the (privileged) compiler backend and it all falls down.
In practice, it doesn't matter so much, because IBM i is an (ever-increasingly fringe) server platform for business applications, so the odds of malicious code ever making their way on to the system is much less than for an OS used for more general purpose computing
But you are right, and in that it has something in common with sandboxing of Java applets, for example – which didn't work out as well as its inventors had hoped.
That said, although classic applications all run in a single shared address space, newer versions have added support for isolated per-process address spaces (teraspaces), which have in turn used been to add an AIX compatiblity layer (PASE). If you write your apps against AIX compatibility layer, you get process-based security just like you do on AIX. And in that layer you aren't just limited to calling (a subset of) AIX APIs, you can also call into IBM i native APIs which don't exist on AIX – albeit at some performance cost, since the call has to be marshalled into the single shared address space.
IBM's original JVM ran in the classic single shared address space, and was deeply integrated into the OS. Then they replaced it with J9, their JVM for AIX/Linux/Windows/etc, and J9 runs under the AIX compatibility layer. Given they encourage Java for developing new apps – a lot of apps now contain a mixture of legacy RPG/COBOL/etc code along with Java code to implement web UIs and SOAP/REST APIs – more and more stuff is running outside of the shared address space.
Yes, but it also reflects the fact that it is no longer a separate hardware line.
In the beginning (1978) was the IBM System/38, which had a custom CISC CPU architecture with 48-bit addressing (called IMPI), vaguely resembling the 360/370 mainframe instruction set, but incompatible with it, and having some rather high-level abilities like task switching in microcode (similar to hardware task switching on the 386). The System/38 had some very advanced features: single level storage, capabilities and programs compiled to byte code (which the OS then converted to the IMPI physical instruction set). However, IBM also had its System/36 "midrange" line (basically minicomputers but IBM preferred to call their business-oriented minicomputers "midrange"), which was incompatible and more of a traditional system architecture. So in 1988 IBM "unified" them by releasing the AS/400, which was basically a version 2.0 of the System/38, keeping the same basic architecture but adding a System/36 emulation subsystem so it could run most System/36 applications.
Separately, IBM had its RISC Unix RS/6000 line, which spawned POWER and PowerPC. And then in 1991, IBM came out with a new version of the AS/400 based on PowerPC instead of proprietary IMPI CISC. The fact that applications compiled to bytecode meant most applications could be ported to RISC seamlessly, since the new OS version translated the bytecode to PowerPC instructions instead of IMPI instructions. At the same time, much of the core of the OS was rewritten in C++ (having previously been in a proprietary PL/I dialect.)
But still, although RS/6000 and AS/400 now used the same CPU architecture, they were still physically different hardware. Originally, the AS/400 used its own PowerPC chips with additional instructions the RS/6000 ones lacked. Even after they unified the two lines on the same CPU models, they still had different firmware.
In 2000, there was a marketing-driven decision ("eServer") to rebrand RS/6000 to pSeries and AS/400 to iSeries. This was part of an attempt to present IBM's four distinct server platforms (mainframe, AS/400, RS/6000 and PC) as some kind of cohesive strategy (mainframe became zSeries and PC servers became xSeries).
Then, in 2006, the iSeries (formerly AS/400) and pSeries (formerly RS/6000) hardware lines were merged completely, to become IBM Power Systems. Now there was no physical difference between the hardware, it is just which OS you install on it. The IBM i (originally OS/400 and later i5/OS) operating system uses certain firmware features which AIX doesn't use – but all IBM Power Systems have that code in their firmware, it is just AIX and Linux don't call those functions. (There are now low-end Linux only machines which refuse to run AIX or IBM i, although possibly that's just a flag in the firmware license as opposed to distinct code.)
IBM I and Z (each with a dizzying array of branding zigs and zags going back decades) are both pretty interesting technologically.
I has a fancy memory architecture, very smart disk controllers (essentially distributed intelligence, like an octopus), a virtual instruction set (that has been used multiple times to almost seamlessly jump huge under-the-hood processor changes), and historically a reliability record second to none (the old box in the wiring closet running for years upon years, completely untended). Z has even more toys, including some of the strongest clustering, partitioning, security found anywhere. Sysplex, LPARs, and RACF are all impressive, especially given how many decades ago they started. We won't even talk about the DBMS and transaction monitors, which are their own brand of crazy strong.
Those immersed in the higher-volume, standard microprocessor, Unix/Linux or Windows, cloud mainstream don't give "proprietary systems" much thought or respect. But we probably should. Those who knew the IBM I or Z, or the DEC VAX/VMS, HP MPE, Tandem NonStop, etc.—they were too expensive, too few in number, too quirky—but what they did well, they did outstandingly well in their purpose-focused, allopatrically speciated ways. Better in many cases that we can do today with the latest 2024 gear.
I think this is the biggest problem, plus the fact these systems tend to be tied to proprietary - and also very expensive - hardware platforms. If I want to learn about GNU/Linux or BSD, all I need is a computer (PC in most cases, but other options exist) and an Internet connection. These days, most people (at least in Europe and North America) have these anyway, so it's really easy to get started in the comfort of one's own home.
Having a free account on a public machine is cool, but it's not the same as having your own system, especially if you want to learn about system administration.
The killer, of course. As they say: anyone can build a bridge that stands, but it takes an engineer to build a bridge that barely stands. In this game, a solution that's too expensive is often not a solution at all.
I'm not sure this is proper usage. Virgule is French for Comma, not Slash. And to my knowledge, there is no French equivalent for Slash and if there is, it's not commonly used.
> I wasn't speaking French, I was speaking English, in which virgule means slash.
It seems like you and GP both have valid points.
Borrow-words usually (AFAIK) generally have the same meaning in the donor and recipient languages. So referring to the donor-language definition is a good way to figure out intended usage.
IIUC, virgule has different meanings in Latin, French, and English. I'm guessing that's what's throwing us off.
Most AS/400's are tucked in the back corner of a warehouse workshop closet, absolutely slathered in dust. There's coax cables for 5250 terminals. A musty smell.
In the workshop, blue collar workers can bang out commands and instructions faster than a grey beard computer scientist at MIT running their entire life in EMACS.
Only one or two people know where that AS/400 lives. It's power supply was hot swapped 21 years ago.
Agreed. They are workhorses that keep on running. If/when a piece of hardware fails like a disk or RAM it gets hotplugged via the Hardware Management Console [1] and since it has single level storage [2] all pages in RAM are protected for 48 hours in the event of a catastrophic power failure.
> Most AS/400's are tucked in the back corner of a warehouse workshop closet, absolutely slathered in dust
In the 1990s, my dad worked in a pharmaceutical factory. The whole factory was run by a single AS/400. Being the pharmaceutical industry, it was all very clean, no dust anywhere to be seen. Their server room, complete with raised floor, seemed rather barren – all it contained was the AS/400, a tape drive, and a couple of Netware servers. The operator sat in an adjoining room, able to observe the servers through a large glass window. In high school my dad got me an unpaid internship for two weeks in their IT department, but sadly they refused to give me a login to the AS/400. Closest I got, was they had a contractor writing RPG code in the cubicle next to mine, and he let me look over his shoulder.
normally, yes/kinda(though not REWRITE actually just RECOMPILE - no code changes unless you need to use the new field) . that happens. though you can abstract file access and use a modular approach to do that and only recompile that abstraction layer (think Hibernate but for the old days)
keep in mind the system used this as a safety feature. to make sure that you dont blow off your foot with incorrect access to the file.
Liberachat IRC, ##ibmi
Feel free to drop by.