Slashdot Mirror

I have wondered now and then, if not Bitcoin isn't actually a secret distributed Chinese Lottery.

With all these machines out there dedicated to brute-forcing SHA-256 collissions â" which is also the world's most used cryptographic hash algorithm, whenever NSA (or whichever agency created Bitcoin) wants a SHA-256 hash collision it just injects some requests to a bunch of bitcoin nodes, exploiting some vulnerability in the code and protocol.
And then the suckers will do the work for them.

It has been done before with Javascript in web pages, the same as "other" crypto-mining in Javascript on shadier sites more recently.
But this time the users would be none the wiser because the nodes are just doing whatever they were supposed to in the first place.

It's not just a holdover: it's also a compromise after different OS builders tried to simplify things the same way without coordinating and whose arbitrary choices happened to conflict. Once you have unixy LF and macish CR in the wild, reviving the old CRLF admixture made an equally unhappy compromised. That compromise was baked into telnet and subsequent protocols. By the time Microsoft brought MS-DOS to market, CRLF looked like the sensible, standards-compliant choice.

I am mostly summarizing the old EOLstory, which says it better.

I think you mean best practices. You can't just update the routing protocol and expect people to use it properly.
You can't fix incompetence by simply changing standards all the time.

Really, this attack was made possible by a whole lot of incompetence at many layers.

In the end, DNS will likely fix everything...
https://www.rfc-editor.org/rfc...

It's actually the complete opposite of what you describe: these docs from moz://a shouldn't even be necessary.

A standard should already be a concise, accurate, unambiguous description of a technology or methodology. A standard should also already include relevant examples, caveats, and other important information.

If the current W3C standards don't suffice as documentation, then these standards should be rewritten until they do.

There's no need for moz://a to be writing their own documentation, separate from the standards in question.

At most they should be providing a simple site like https://www.rfc-editor.org/ is for RFCs, that makes it easier to search for or otherwise find the standards documentation you're interested in.

There should be absolutely no reason for moz://a to be creating their own documentation describing things which should already be described fully by an existing standard.

It's generally done by some dead-end user that CC's instead of BCC's

You should be aware that BCC is not a guarantee that others will not see addresses. RFC5322 says: " The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains addresses of recipients of the message whose addresses are not to be revealed to other recipients of the message." This SOUNDS like it should be safe to use for sending messages to a lot of people without anyone knowing who else got it, but it isn't. RFC5322 talks about three common ways that mail systems deal with BCC, and says:

In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.)

The last sentence implies that some mail systems contain the full BCC line in copies sent to those BCC addresses. (Only "some" create individual BCC lines.) It does not use the mandates of "MUST" or "MUST NOT", so conforming implementations can actually show you, as a BCC recipient, the entire list of other BCC recipients. And I've seen that behaviour.

This is one of those areas where people assume the standards say one thing but actually don't. Like idiot web page designers who think they know the list of acceptable characters in an email address and yet they prohibit "+".

I remember IANA

Well, son... It's time to teach you a lesson. See, hosts were around before we had the DNS system. Allow me to show you when we started to move past them, in December of 1973...
http://www.rfc-editor.org/rfc/...

You're in your 30s, Alex. Being unemployed does not make you retired. It makes you unemployed. Collecting disability doesn't make you retired, it makes you unable to work.

As for your other posts, I see you failed to read mine and understand it. That's okay, APK. I'm kind of used to it. You failed to address any of my points. I do not *need* you to tell me about hosts. I'm well aware of what hosts do and the benefits of using them or not using them. I've never denied the technical merits of using a hosts file - ever. We've been over this before. Let me know when hosts can be refined as well as a whole host of other options. At this point in time, I have better choices for me. At this point in time, I have an effective system that's efficient with my time. It does everything I need it to do in the ways that I want to do them. I do things that the hosts file simply can not do. If the hosts file were a better tool for the job I want done, I'd do it. That's what you're continually not understanding. It's not even a difficult concept.

As for the rest of your many posts... Do you seriously think that crap-flooding and pretending to not be you is believed by anyone? If mildly amusing is your goal, you've managed.

Looks like a strong overlap with RFC 2801 - http://www.rfc-editor.org/info...

That would be "Internet Open Trading Protocol - IOTP Version 1.0, April 2000"

Let's be clear here - we are talking about one particular software package - albeit a very popular one - and not the underlying protocol (which itself is subject to errata, some of which are still under discussion).

If you're going to use highly technical terms, please follow the relevant RFCs: http://www.rfc-editor.org/rfc/...

S/MIME which used asymmetric encryption through the entire message and was thus cripplingly slow

This is untrue. S/MIME always used asymmetric encryption to wrap a symmetric key, and the symmetric key to encrypt the data. http://www.rfc-editor.org/rfc/...

Both the NSA and Hackers are using Keyboards to input data into computers.

Seriously, Jabber/XMPP are well known standards for implementing internet messaging.

This whole article smells like misinformation to work the media up into a frenzy. I don't see how these revelations can accomplish anything positive.

RFC 2119 is pretty basic stuff. You may wish to extend it with RFC 6919, which could include additional language which you must use for clarity (but we know you won't).

No doubt Mavericks improves upon at least a few things, but there are definite problems with it. I hit the ARP issue (http://www.macstadium.com/blog/osx-10-9-mavericks-bugs/), which made the application I was using (VMWare View) unusable.

So Apple's "bug" is to do what others have been doing for ages? Take this 8 year old bug report - and weep for the bug fix is actually what Apple supposedly does wrong now.

If a dynamic ARP entry expires at the Cisco router, the router will not broadcast its ARP request again, but, for efficiency purposes, it will unicast the ARP request to the Ethernet address mapped to the IP address in the expiring ARP entry. When this Ethernet address is of a secondary interface in the Load Balancing interface group of the Netware host, the Netware host will not respond to the ARP request. This behaviour of the NetWare ARP implementation is not consistent with the standard (see ftp://ftp.rfc-editor.org/in-notes/std/std37.txt), but, if it would reply, the Cisco router would always forward IP datagrams to the same interface, which defeats the purpose of inbound Load Balancing.

fix
CISCO IOS version 12.1.20 will delete the former dynamic ARP entry and broadcast the ARP request after it timed out on waiting for the reply to the unicasted ARP request.

This is an individual submission, not an IETF working group draft, and does not appear to either be proposed for an IETF wg draft or to be in the RFC Editor's queue. In short, it has nothing to do with the IETF.

The "evil bit" is from the mentioned RFC 3514.

Here we are again.

After VP8, protocol buffer, Google is a it again providing some free replacement of some existing standard (DTLS here http://www.rfc-editor.org/rfc/rfc4347.txt)

But of course, Google's people know better and have more money. And the list can go on. Dart as a replacement of javascript. Protocol buffer as replacement of ASN.1, SPDY to replace HTTP. With Jingle google tried to replace SIP protocol as well but at least the extended an existing standard but they dropped the support when stopping Google talk. For couse everyting is free, open source and Not Evil. So why bother?

Well as an aging network engineer, I am starting to be fed up with such "innovations". More consensus building would be refreshing.

Those plots are a bit misleading, as they intentionally leave out the Information Sciences Institute at USC. The ISI is responsible for drafting the lions share of early and fundamental RFCs including those defining IP, ICMP, UDP, TCP, SMTP and more. The internet did exist prior to 1988, unlike those plots would lead you to believe :) The core of the internet was developed almost entirely by government research agencies. Furthermore, the recent portions of the time plots are also misleading as they leave out "unknown" which largely consists of individuals who don't officially represent an organization.

Now the Internet is commercialized, a large number the RFCs do come from large companies whose business in the internet, but they didn't create it, and their various attempts to create something similar over the years all failed, because they insisted on proprietary closed systems. The internet is a textbook case of how the government does well at fundamental research, and the market does well with mass deployment and incremental R&D.

Those plots are a bit misleading, as they intentionally leave out the Information Sciences Institute at USC. The ISI is responsible for drafting the lions share of early and fundamental RFCs including those defining IP, ICMP, UDP, TCP, SMTP and more. The internet did exist prior to 1988, unlike those plots would lead you to believe :) The core of the internet was developed almost entirely by government research agencies. Furthermore, the recent portions of the time plots are also misleading as they leave out "unknown" which largely consists of individuals who don't officially represent an organization.

Now the Internet is commercialized, a large number the RFCs do come from large companies whose business in the internet, but they didn't create it, and their various attempts to create something similar over the years all failed, because they insisted on proprietary closed systems. The internet is a textbook case of how the government does well at fundamental research, and the market does well with mass deployment and incremental R&D.

Those plots are a bit misleading, as they intentionally leave out the Information Sciences Institute at USC. The ISI is responsible for drafting the lions share of early and fundamental RFCs including those defining IP, ICMP, UDP, TCP, SMTP and more. The internet did exist prior to 1988, unlike those plots would lead you to believe :) The core of the internet was developed almost entirely by government research agencies. Furthermore, the recent portions of the time plots are also misleading as they leave out "unknown" which largely consists of individuals who don't officially represent an organization.

Now the Internet is commercialized, a large number the RFCs do come from large companies whose business in the internet, but they didn't create it, and their various attempts to create something similar over the years all failed, because they insisted on proprietary closed systems. The internet is a textbook case of how the government does well at fundamental research, and the market does well with mass deployment and incremental R&D.

Those plots are a bit misleading, as they intentionally leave out the Information Sciences Institute at USC. The ISI is responsible for drafting the lions share of early and fundamental RFCs including those defining IP, ICMP, UDP, TCP, SMTP and more. The internet did exist prior to 1988, unlike those plots would lead you to believe :) The core of the internet was developed almost entirely by government research agencies. Furthermore, the recent portions of the time plots are also misleading as they leave out "unknown" which largely consists of individuals who don't officially represent an organization.

Now the Internet is commercialized, a large number the RFCs do come from large companies whose business in the internet, but they didn't create it, and their various attempts to create something similar over the years all failed, because they insisted on proprietary closed systems. The internet is a textbook case of how the government does well at fundamental research, and the market does well with mass deployment and incremental R&D.

Those plots are a bit misleading, as they intentionally leave out the Information Sciences Institute at USC. The ISI is responsible for drafting the lions share of early and fundamental RFCs including those defining IP, ICMP, UDP, TCP, SMTP and more. The internet did exist prior to 1988, unlike those plots would lead you to believe :) The core of the internet was developed almost entirely by government research agencies. Furthermore, the recent portions of the time plots are also misleading as they leave out "unknown" which largely consists of individuals who don't officially represent an organization.

Now the Internet is commercialized, a large number the RFCs do come from large companies whose business in the internet, but they didn't create it, and their various attempts to create something similar over the years all failed, because they insisted on proprietary closed systems. The internet is a textbook case of how the government does well at fundamental research, and the market does well with mass deployment and incremental R&D.

Please stop using the obsolete text/javascript MIME type. The correct MIME type for JavaScript programs is application/ecmascript or application/javascript - see RFC 4329. It's best to not use any type attribute because it is optional in HTML5 and was never needed in practice but if you insist on using optional attributes then please at least use the correct values.

Stil, I'm not sure it's a good idea to make all devices directly accessible over the internet, it's kind of like begging for a wormpocalypse.

You're expected to have a stateful firewall at the very same place where you have a NAT right now. This is described in RFC 4864.

And IPv6 can do better, without all the ugly side-effects of NAT: https://www.rfc-editor.org/rfc/rfc4941.txt

Sigh. As one of the Righthaven tools[1] found out the hard way ... the CM/ECF system used by all Federal District Courts has been tested to work with FF 3.5; from extensive personal experience it also works fine with FF 3.6. It does not work at all with FF 4.0+ (in that you can't use FF to upload PDFs, which is all you'd use the Electronic Case Filing system for (document retrieval is done through PACER, though they overlap).

For some stupid reason, ECF specifies an ACCEPT parameter of “image/*” for the PDF upload forms, which of course is incorrect (PDFs are MIME type “application/pdf” per IANA; see also, e.g., RFC 3778).

As of FF 4.0 (https://developer.mozilla.org/en/HTML/Element/input), that 'accept' parameter is honored and FF filters the file selector box to only permit image filetypes to be uploaded. End result? #massivefail

Yes, ECF is broken. But try getting not one, but 89, Federal bureaucracies to fix their tech in a timely fashion... (Each district court runs its own ECF system.)

Sigh.

[1] Declaration of Shawn A. Mangano, Esq., Righthaven LLC v. Democratic Underground, LLC, No. 10-cv-01356-RLH-GWF, docket entry 127-1 (Dist. Of Nevada, June 29, 2011)

Just one question: when was the last time when you wrote code using XLib? Or XCB for that matter.

A few months ago. Why? Personal interest. More recently, I've been working on tracking down a bug I've noticed when running luminance-hdr over X11 forwarding over SSH. I get X11 protocol errors which suggest data corruption. I think the bug is in either my sshd or my ssh client; I don't get the errors if I run over raw TCP.

It's very hard to do stuff with the old ways of X. It's very hard to get over the damned protocol to actually have some fast graphics.

I don't disagree. If you have an app which requires a high framerate with active changes in graphics, raw X11 isn't going to be close to ideal, and it doesn't seem that the existing commonly-available extensions to X make it much easier.

The X protocol is bad, and it's bad not because the design is bad (some ideas are very neat, really) but because the evolution of hardware and software made it obsolete.

Here I'd disagree with the wording, but you're substantially correct. The path of hardware and software evolution have made it inconvenient. It was driven by demand for fast, cheap 3D rendering on consumer PCs on Windows. (Which is probably part of why I keep hearing Wayland compared to Windows' graphical model)

This drove an assumption of very-low-latency connections between the graphical display and the application, and that assumption persists to this day.

But the 'old anonymous coward fart' wants to use his xfig, he's more than welcome. He can use it in a virtual machine, where he runs his old distribution, hopefully with better performances because Wayland helps instead of getting in the way.

I'm not the AC you're referring to, but I'm also one who loves X11. I've got two beefy machines on my network at home--mine and my fiancee's. When we have roleplaying company over, we both regularly use X11-over-SSH to run programs like PCGen or GURPS Character Assistant on laptops in a different room. When we're doing photo processing, we both regularly use X11 over the network to run our photo processing apps (she prefers ufraw, while I go for luminance-hdr).

I don't see how Wayland will help in that scenario.

And BTW: I wonder how many FTP servers implement that feature you're talking about.

Any that support both active and passive FTP modes, implemented naively (some FTP servers explicitly block active transfers to any but the user's IP as a security mechanism). This use case is specifically spelled out in RFC 959. See figure 2 in section 2.3. You, the user, open a control connection to both servers, you tell server1 to transfer the file passively (wait for a connection on a port), and you tell server2 to transfer the file actively, specifying server1:port as the destination.

RTFM

Nothing that RFC 1149 can't fix. And not just as a joke. Of course we're not talking about real-time streaming of Youtube here, but data will find a way to get in and out of Iran. You can prevent people from ever finding out about Internet (North Korea), but once they had it, it's impossible to take it away completely.

And I think it's rather difficult to get GPS coordinates based on just an IP address.

Can't we make RFC1876 mandatory? :-)

SMTP is unencrypted

You're doing it wrong.

And, since you ignored the RFC (5290) that comes up first when you Google for "best-effort rfc"

Google is not the RFC Index. RFC 5290 definitely doesn't define the terminology used by the differentiated services standards. When people speak of 'best effort' in regards to QoS, they are referring to the definition as it is defined in the differentiated services, and major router vendors use the same terminology, so this is what is accepted by the language using community.

Apparently you missed the heading of RFC 5290.

Status of This Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. IESG Note

The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work.
This RFC is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work.

As well as the part of RFC 2474 that states accordingly

A reasonable implementation of this PHB would be a queueing discipline that sends packets of this aggregate whenever the output link is not required to satisfy another PHB.

A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable.

- RFC 2026

There aren't that many actual IETF standards. The standards process isn't even a standard. HTTP is only a draft standard. RFC 1918 (which defines the 10.0.0.0/8 - 172.16.0.0/12 - 192.168.0.0/16 private IP addresses) is only a proposed standard, yet was published in 1996, and is in universal use.

It's always best to go to the original source.

Learn how to use Google man!

http://www.rfc-editor.org/rfc/rfc3390.txt [rfc-editor.org]
http://www.rfc-editor.org/rfc/rfc2581.txt [rfc-editor.org]

Learn how to use Google man!

http://www.rfc-editor.org/rfc/rfc3390.txt [rfc-editor.org]
http://www.rfc-editor.org/rfc/rfc2581.txt [rfc-editor.org]

Not sure why you got modded informative since the original poster and your "me-too" are both wrong . RFC 3390 is an extension to RFC2581. RFC 3390 says you MAY use an IW of up to 4 segments. If you don't use this option, you fall under RFC2581 which says the IW MUST be less than or equal to 2 segments.

http://www.rfc-editor.org/rfc/rfc3390.txt
http://www.rfc-editor.org/rfc/rfc2581.txt

Not sure why you got modded informative since the original poster and your "me-too" are both wrong . RFC 3390 is an extension to RFC2581. RFC 3390 says you MAY use an IW of up to 4 segments. If you don't use this option, you fall under RFC2581 which says the IW MUST be less than or equal to 2 segments.

http://www.rfc-editor.org/rfc/rfc3390.txt
http://www.rfc-editor.org/rfc/rfc2581.txt

I remember similar policies about ISP contracts only covering one machine, but I would guess they've since been abandoned. Now that you've reminded me, I think NAT was often implicitly marketed to home users as a way to fool ISPs; at some point, it became so common for home users to have multiple nodes that ISPs had to give up the limitation -- customer expectations had shifted too far. Perhaps we could call it "market disobedience," on the model of "civil disobedience."

I would also guess that individually assigning IPv6 addresses would be an administrative nightmare for ISPs, given the scale of the IPv6 namespace, given that everyone who knows what IPv6 is knows that there's practically no limit to the number of available IPv6 addresses, and given that there's reason to expect further growth in the number of Internet-connected devices in homes.

My understanding was that an RFC had recommended that ISPs assign network prefixes of at most /64, and suggested /48 -- if I'm reading it correctly, this is in RFC 4779, section 5.2.2.2.2, but I'm not certain I understand what I'm reading there.

"there isn't a benchmark for pigeon data speeds"

There is, but it used a 64-byte packet. Likely because the standard calls for the packet to be hand written on a piece of paper in Hex. While I'm usually in favour of sticking to standards, I think in this case I'll make an exception.

In rfc 1149 (A Standard for the Transmission of IP Datagrams on Avian Carriers) He should find all he needs to configure his pigeon network.

I'm sure that 90% of those preregistrations are by domain name squatters.

Of course they are, which is to be expected since this whole exercise is nothing more than registrars grabbing at cash.

The sad part is all the uninformed idiots posting here who support the idea -- if even a fair number of Slashdot posters still don't understand why this is such a horrible idea then it's no wonder ICANN caved. On the one hand, they look good to the morons who have been pushing for this stupid idea for years, and on the other they were probably bribed with a huge amount money. Win win!

For those wondering why .xxx is a terrible idea that is completely doomed to fail (at all the "official" goals at least, it will certainly succeed as the gravy train it's designed to be), read RFC 3675: .sex Considered Dangerous. It has all the same arguments being presented here, plus more.

Why all that hassle? I'm sure any spam message sent to a printer will have the evil bit set (see: RFC3514), so you can just tell the printer to ignore those messages... Simple!

No, it's on dogs. See, he posted from Fidonet! Dogs carry around TCPIP packets.

Damn kids and your blatant disregards for standards. Embrace, extend, extinguish, roll over, and you expect a treat EVERY TIME!

have been doing it for alot longer than us. Often around here outside it sounds like a DDoS.

http://www.rfc-editor.org/rfc/rfc1149.txt

http://www.faqs.org/rfcs/rfc2549.html

...but did you know it has actually been implemented?

http://news.bbc.co.uk/2/hi/africa/8248056.stm

Should I write "Updates" or "Obsoletes" RFC 3514?

Explain to me the business case for the internet.

The internet didn't just spring up out of nowhere. It started as a VERY small network and grew over a number of years. Check the date on that baby!

It was initially a way for the DOD to stay in touch with researchers and a mechanism for sharing information among universities. So the DOD funded it because there WAS a business case for it.

Then, it 1993 (damn near a quarter century after that first RFC), the Mosaic web browser was released. The rest, as they say is history. NASA has been around a lot longer than the internet and there's still not much of a business case. Don't get me wrong. We've learned a great deal and there have been great applications to come from what we've learned. But the fact is, we have more pressing issues on Terra Firma at the moment. Things like finding me a fucking job so I can feed my family.

I mean, seriously, when I was 8 years old (back in the 70s), I wrote to the White House asking to go to the moon. This led to me gaining a pen pal at NASA who I corresponded with for years afterwards and I credit him with helping to spur my interest in science. I don't think I would be the person I am today without someone like that inspiring me. Sending me photographs autographed by astronauts and all sorts of PR stuff. For me as a kid, it was very special. So understand, NASA holds a very special place in my heart. But at the same time, we have an economic reality that and there are a lot of families struggling to put food on the table. We need to keep our eye on the ball.

But, how did you post the above message?

TCP/SS, TCP/BDor TCP/AC

RFC 3229 discusses a design for delta encoding in HTTP. I once stumbled upon this when I thought of doing something like this, as well. This idea makes a lot of sense, but it's well known. The main problem I see is that you need both parties to support it. Since gzip compression in HTTP is fairly common, this is not at all impossible. I have not RTFA, so they may well be proposing something different.

Rule #1: you can't trust anything a spammer sends you, this includes their HELO/EHLO command.

Perhaps you should learn more about SMTP.

Although the parameter to HELO can be an outright lie, unless it's not following the RFC, you just accept it and ignore it. Anyone who uses a syntactically correct HELO to block e-mail is just asking for trouble.

What's important is the connecting IP address, envelope sender, and envelope recipient, only one of which can be faked in any meaningful way and still result in a chance to deliver e-mail. With just those three pieces of information, you can block almost all true spam without needing to close off vast swaths of the Internet at your firewall.

Using greylisting, strict SMTP RFC compliance checks, and SpamAssassin with scoring for blacklists, and with nearly 500 active e-mail accounts that end up in my inbox, and I generally see less than one piece of spam every day, although on really bad days I see two or three.