joshdata

Thanks for your work! (If our paths crossed you would have known me as the persistent guy at GovTrack asking for bill status XML over and over. :) )

This is not really a fair picture of history. The folks at the Government Publishing Office who decided to use RSS have really no connection to Swartz's prosecutors and probably were using RSS before the prosecution. (This is also not a government "embracing" RSS. It's one website. And it's been there for a long time.)

If someone put you in charge, you probably would not know how to do the thing you're imagining. (For example, "classified" doesn't really apply to Congress. That's an executive branch thing. So you're already on the wrong track.) Don't fool yourself that it's just a matter of having a bright idea that's the difference between the world as it is and the world as you want it.

The civil servants who are responsible for creating govinfo.gov deserve some praise for publishing a truly massive amount of information in an accurate, reliable, and developer-friendly way. (I know them. They are hard-working people!) Also worth noting that these things don't just happen on their own. Dozens of advocates outside of the government (myself included) have advocated for these sorts of things to come about for decades, and they're always in danger of disappearing if advocates and other users of the data don't continually demonstrate to decision-makers the importance of it.

Great!

The bills proposed by legislators are published in open data (thanks to years of advocacy by myself and others, but that's another story). If you want to read it and know who proposed it, this information has been readily available on the Internet since 1995. If you want to do some data mining, the data has been readily available to download in XML for about 5-10 years from Congress itself and for the decade before that from govtrack.us. If you're not doing the data mining already, that is about you and not about the availability of the data.

Ahha! Glad to hear.

Thanks!

I think around 1998 or 1999. I don't think we disagree on the facts: I totally agree that there is a lot more to understand and that deliverability is a nightmare. No question. What I see is that today people can achieve a reasonable mail server while being an expert at less.

> I ran mailinabox for a year or two ... the documentation seemed actively hostile

Maintainer of Mail-in-a-Box here. I'm sorry you had that experience. Definitely was not the intention of the project to be hostile (but I can see how it might come off that way).

> Things that have happened in the last 20 years include SPF, DKIM, DMARC

Right, of course. The protocols are more complex. (Add TLS, MTA-STS...) But whereas 20 years ago you _had_ to start from scratch and understand the whole stack, today that's just not necessary. There are numerous projects that make running a mail server readily possible without knowing e.g. the sendmail configuration macro language. And there are many many more good resources to learn it all if you want to know than there were 20 years ago. It is both a more complex technology and also undeniably easier for people to actually do it.

The comments all seem to be from people who think making an artisanal choice is a bad thing. There should be more art, experimentation, and expression in computing. If we've outgrown running our own mail servers as a practical choice, because there are now more good options, and we can enjoy running a mail server as a more humanly choice, that's a good thing.

Not much has actually changed about the complexity of running a mail server in the last 20 years --- if anything it's gotten easier. What's changed is there are other, polished, turn-key options now. Great. (Those options tend to have spam policies that aren't friendly to the independent servers, but that's life.)

Choose to be artisanal.

(I'm the primary maintainer of https://mailinabox.email/.)

I operate a website that likely meets one of the requirements to be subject to CCPA that received the emails from the research study. We have basically no revenue or staff. I didn't appreciate being lied to (about who was sending the message), being threatened (with legal enforcement), wasting my time (the study was scrapped), and being used for research without consent (the fact that this happens all the time doesn't excuse it). If they wanted to know our CCPA/GDPR policies, they could have simply asked. I also received emails from the study at two other domains I own and one that mentioned a domain I don't even own, but which probably don't matter for CCPA - all of which made me think that this was a scam and legal trap to take seriously.

It wasn't retribution. This was in the works for many years and this was just an opportunistic time to put it up / it became something people were suddenly interested in. -- the guy behind the linked site

> A better strategy would be to determine which ISP serves Congress, and pay them for the data of IPs originating from Congress.

This isn't an either-or scenario. If you want to do that, do that. Go raise a lot of money. In the meanwhile, there's this, and it didn't cost anything.

We'd consider helping with that, but someone else would need to take the lead on the effort. -- the guy behind GovTrack

The US Congress is not subject to federal FOIA law, so that would be impossible at the federal level. -- guy behind the linked site

> Why would you choose the 538 map to pick on

It was a convenient example. And I hadn't noticed the interactivity before writing the article. That said, I don't think the zoom function makes it much better.

If you think it's OK to routinely portray America as being only rural white America, and if you're not interested in knowing in a quantified way how different a map is from reality, then we live in different worlds. As I said at the top of the article, the point wasn't that there is a bias (because that's no surprise to anyone) but to find out how large that bias is.

Hey. I'm the author of the article.

If folks want to toss links to good examples of cartograms in replies here, I'll add them to the article!

> Does mail-in-a-box then provide the scripts to perform regular software updates and any configuration migrations between versions?

Yes it does.

Only half of the US Code is authoritative (so called 'positive law titles'). For the rest, the original statutes are authoritative.

For the authoritative part- Congress isn't the only stakeholder who wants to see the law published correctly, fortunately. Businesses, lawyers, federal agencies, and others are looking over the US Code as it is published. In many ways it's like the open source model: many eyes and many copies (e.g. in libraries) keep it safe. The law is 200+ years old, though, so we're still stuck with old-timey ways of doing it for now.

Congress is very quickly modernizing now. They recently converted the US Code into very good XML: http://uscode.house.gov/download/download.shtml. Anyone could copy it into github or run it through diff to see changes.

I'm trying to build a system that is simple and auditable. Mail-in-a-Box is also really a system configuration project and not a project to build a better UI. So the goals are very different.

For instance on auditing, from looking at Kolab's source code I have no idea what kind of security settings are used. In Mail-in-a-Box I try to make these sorts of things clear and highly commented in the setup script.

Hi, metadata.

It sounds scary to set up glue records, but so is setting up all of the DNS records manually that you'd need for really good mail: MX, SPF, DKIM, and DMARC, and if you want secure DNS and/or mandatory encryption on the wire you'll want DANE records and zone signing.

Mail-in-a-Box wants to take over your DNS because it wants to take care of all of this for you. If you run your own DNS, it's still secure. An alternative is to use a new domain name.

Thanks for the feedback.

[I'm the guy behind the project.]

Yup, didn't mean to imply that I had solved the whole problem. :)

Yes, it uses STARTTLS, HSTS, modern cipher settings, DNSSEC and many more security best practices! [I'm the guy behind the project.]

As corv mentioned in another comment, the goal of Mail-in-a-Box is a little different from iRedMail. I'm trying to build something closer to a one-click email appliance that eventually anyone might be able to use, rather than a setup for sysadmins. [I'm the guy behind the project.]

Hey. Please start an issue on github sooner rather than later so you don't do lots of work and then I end up rejecting the PR. :) Communication! [I'm the guy behind the project.]

Deliverability is more of a problem than if you use something like Gmail (it's easy for them when they control both ends of the email!), but I've been running my email off of Mail-in-a-Box for more than a year and those sorts of issues haven't been more than a rare inconvenience. [I'm the guy behind the project.]

There's a Vagrantfile in the project. I haven't used it in production this way, but it should work. [I'm the guy behind the project.]

Mail-in-a-Box includes a check like this in its setup script, actually. [I'm the guy behind the project.]