Slashdot Mirror

• VOVIDA
• RFC 3261 -- Session Initiation Protocol
• RFC 3263 -- Location of SIP Services
• The SIP Working Group Charter
• Additional SIP WG Info

• The SIPPING Working Group
• Additional SIPPING information

Before misleadingly filling your comment with "IETF", maybe you should read a few IETF documents and join their working groups yourself.

I will gladly admit that mDNS doesn't have to be crap in itself, and may be cool, but Apple's proposed implementation is NOT going through the IETF standards process.

And Apple IS hijacking the .local tld, and not only did the IETF never recommended that it be reserved for Apple's Rendezvous, but in fact, had "concerns about multicast storms resulting from site-wide mDNS usage, as well as concerns about cache pollution" (among others).

What they eventually adopted in the standards track is LLMNR.

LLMNR also doesn't require suddenly taking over a widely used tld.

Also: "Rendezvous is an individual submission that is not a work item of any IETF working group, and is currently not an IETF standard. While it is possible for an individual submission to become an IETF standard, this is unlikely in this case because an existing WG (DNSEXT) is already working on a competing protocol (LLMNR), which has just completed DNSEXT WG last call."

See the LLMNR FAQ.

Here's a possible solution for you: RFC 2397. The basic idea is that you can embed your graphic data right in the page. There's no separate URL to the images, so there's no way they can link to you from offsite.

Obvious problems: your pages become huge, people who don't want images have to suck them down anyway, and it only works in a couple of web browsers. I guess it depends on just what you're trying to do and how bad the problem is.

I'd paste the example in here, but it would probably trigger a filter. If you're running Mozilla, load that RFC page, highlight the whole mess starting with "data:image...", then load it just like it's a URL. You should see a face.

I'm on the side of Jabber/XMPP, but it's worth pointing out that SIP is already a standard and there is already a group which are doing the same for SIMPLE.

I'm on the side of Jabber/XMPP, but it's worth pointing out that SIP is already a standard and there is already a group which are doing the same for SIMPLE.

XMPP-Charter
SIP-Charter

sig(h)

XMPP-Charter
SIP-Charter

sig(h)

Screw fiber! lets use avian carriers. (RFC1149)

The evil that it does bring is in the form of anti-Free networking, where Linux boxes are used to form cheap routers and gateways, without a Cisco(R)-Symantec(R) licensed monitoring system

Don't worry, I'm sure there will eventually be a patch for Linux's iptables, so it can detect the evil bit.
Your linux firewill could have something like this:
/sbin/iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,EVIL SYN,EVIL -j DROP

RFC3514

Can RFC 1149 (or the more advanced 2549) be related somehow?

Can RFC 1149 (or the more advanced 2549) be related somehow?

There are quite a number of such proposals. For instance...

• Designated Senders Protocol: A Way to Identify Hosts Authorized to Send SMTP Traffic
• A DNS RR for simple SMTP sender authentication
• Repudiating MAIL FROM

...among others. The Internet Research Task Force Anti-Spam Research Group (IRTF ASRG) currently has a sub-group specifically dedicated to the unification of these proposals. This is a relatively recent initiative (only about a month old). You can find archives of the discussion at gmane.org.

What happened to that proposal to add records (as comments, so the DNS protocol wasn't broken) to the DNS saying that a domain was authoratative for the envelope 'From ' header?

It is still an internet-draft. I think the URL for the current version is here.

That sounded like a good idea, so long as the MTA's took it up...

Yes, unless a really high proportion of the people who send you mail made these records available, you couldn't block mail that didn't have it. It might work as a "probably not spam" indicator in things like SpamAssassin at some lower level, though.

Using the MAC address is only one way to assign addresses, and MAC addresses can be changed. RFC 3041: "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" gives another, based on frequently changing random addresses.

Even with static addresses, ISP logs would still be necessary to see who owns them. You might be able to find out some other way, like if you have logs of them logging into a web site with a username or email address - but this works for dynamic addresses too.

There is no way that Microsoft can take over the email system because they simply don't have the near-monopoly on servers that they have on the desktop.

Patrick

• Never implemented
• Only implemented by the vendor who wrote the protocol (as proprietary software)
• Only implemented by GPL software

Who the hell is the ECMA?

Look at thier site.

Aparently people cannot be members, only companies and universities (non-profit companies)

Why not an IETF standard?

They've served very well so far.

Sun has repeatedly balked at standardizing Java due to the inherent loss of control.

I was pretty sure that Sun had published a Java standard. How is a standards org comprised of Micriosoft and it's vassals any better? I was under the impression that the only company that had problems with the Java standard was the one company that had attemped to hijack the standard by implementing undocumented extensions and breaking Suns published standard in order to make users dependant on thier own crappy browser. (Before any of you attempt to defend IE, please try using at least one other modern browser.)

Have things changed so much that we can trust Microsoft and its "standards body" largely consisting of companies dependent on Microsoft to keep all extensions to this "standard" in the open and available to all players? Can we trust them to not later replace the "standard" with propietary replacements requiring either licensing or a switch of platform to a Microsoft product?

Microsoft has attempted to hijack widely accepted standards in the past, is there any indication that this copmpany even knows what the word means?

No.

The number 5 was used a while back for an experimental protocol (see section 8.7), so this is 6. The even/odd rule is nothing to do with this.

Will it really be enough? This parody takes a look.

Whatever happened to IPv5? What was special about it?

I'm not sure if IPv5 really existed using that name, and if it did, it only existed at an experimental level. After some quick "googling", it seems "IPv5" was the real-time streaming protocol using version number 5 and running alongside IP, having some parts in common. Some people might have called it "IPv5", and "IPv6" was probably chosen to avoid confusion with this one. Here's more info about the protocol:

- Experimental Internet Stream Protocol, Version 2 (ST-II)
- Internet Stream Protocol Version 2 (ST2)

Whatever happened to IPv5? What was special about it?

I'm not sure if IPv5 really existed using that name, and if it did, it only existed at an experimental level. After some quick "googling", it seems "IPv5" was the real-time streaming protocol using version number 5 and running alongside IP, having some parts in common. Some people might have called it "IPv5", and "IPv6" was probably chosen to avoid confusion with this one. Here's more info about the protocol:

- Experimental Internet Stream Protocol, Version 2 (ST-II)
- Internet Stream Protocol Version 2 (ST2)

There are several initiatives underway to use DNS to authenticate SMTP transactions: this seems like a good way to avoid the nastiness described by the parent poster...

• http://spf.pobox.com/draft-mengwong-spf-01.txt

• http://www.pan-am.ca/draft-ietf-asrg-dsprotocol-00 .txt

• http://www.ietf.org/internet-drafts/draft-danisch- dns-rr-smtp-03.txt

Pixie

Rendezvous is an Apple trade name for ZeroConf, or Zero Configuration, a new IETF standard that Apple had a leading role in.

The whole point is, you do _not_ have to have a network setup - it figures out what's out there, and makes the necessary adjustments.

You don't even have to be running DHCP (although it recognizes it and works with it).

FCC sources have also revealed a last-minute amendment to the proposed ruling which would require all HDTV broadcasts to comply with RFC3514.

VoIP using P2P technology is a great idea, byt Skype looks like a proprietary solution (correct me if I'm wrong).

Would someone care to enlighten me on VoIP/P2P solutions using open standards?

• The SIP home page at Columbia Univ.
• An excellent SIP FAQ, also hosted at columbia.
• and, naturally, the SIP RFC for those of you who get off on reading those things...

Already some posts have been talking about the severity of the punishment for each forged "From" header. But from the indictment:

hijacking or "spoofing" the return addresses of e-mail accounts of reporters at the Philadelphia Inquirer

Clearly, forging a mail header is "hijacking", which we all know too well is an act of terrorism.

Moreover, I'm surprised the DMCA was not used to levy additional jail time-- after all, the "alleged" terrorist cracked the authentication scheme as described in RFC 821, somehow confusing the SMTP protocol into accepting a non-valid "reverse-path" value.

Our friends at the NSA are still trying to determine how this was accomplished.

I completely agree... of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

I completely agree... of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

I completely agree... of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

I completely agree... of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

I completely agree... of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

Of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

Of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

Of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

Of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

Of course, that would be "Submit a DRAFT" and IFF (if and only if) you are "measured and not found lacking" will it become an RFC (with MUCH review and oversight). In fact, there is just simply NO WAY that this "service" would have made it past the IETF review process. None. Nadda, zilch.

draft-danisch- dns-rr-smtp-02

And this TXT record for the *.smtp-client. subdomain is the ugliest DNS hack I have ever seen.

The above draft makes sense and introduces a reverse MX DNS record type....

This type of approach doesn't sound totally rubbish - but I'd be happier if ISP's would ALL impliment anti-spoofing filters on their routers as in RFC2827.

This type of approach doesn't sound totally rubbish - but I'd be happier if ISP's would ALL impliment anti-spoofing filters on their routers as in RFC2827.

If not, what are the key differences?

I suspect you are pulling my leg about not knowing what IRC is ,but i will respond anyway.
IRC = Internet Relay Chat.
RFC here
And an explantion here

The central idea behind reverse-DNS/MX proposals is to answer the following 2 questions:

1. Does a particular domain have a list of authorized IP addresses that are allowed to send out e-mail on behalf of the domain?

2. Is the IP address of the mail server that is attempting to talk to me on that authorized list?

The devil is, of course, in the details/implementation. (Can we do it without breaking older versions of BIND? What attacks is it suspectible to?)

Here's the (4) proposals that I know about (since I just went looking yesterday):

RMX proposal - No news on Mike Rubel's page since June 2003. Not much on the official home page either. The last published draft is June 2003.

DMP - Last IETF draft published Aug 2003 and expires at the end of Sep 2003. However, version 5 of the document has not yet been posted and the author(s) does not have seem to have a central site to check for news.

DRIP - Last draft was published July 2003, expires Dec 2003. I don't see anywhere a central home page to check for news.

SMTP+SPF - Last update was mid-July 2003. I'm not sure if there is an IETF draft being floated or not.

The central idea behind reverse-DNS/MX proposals is to answer the following 2 questions:

1. Does a particular domain have a list of authorized IP addresses that are allowed to send out e-mail on behalf of the domain?

2. Is the IP address of the mail server that is attempting to talk to me on that authorized list?

The devil is, of course, in the details/implementation. (Can we do it without breaking older versions of BIND? What attacks is it suspectible to?)

Here's the (4) proposals that I know about (since I just went looking yesterday):

RMX proposal - No news on Mike Rubel's page since June 2003. Not much on the official home page either. The last published draft is June 2003.

DMP - Last IETF draft published Aug 2003 and expires at the end of Sep 2003. However, version 5 of the document has not yet been posted and the author(s) does not have seem to have a central site to check for news.

DRIP - Last draft was published July 2003, expires Dec 2003. I don't see anywhere a central home page to check for news.

SMTP+SPF - Last update was mid-July 2003. I'm not sure if there is an IETF draft being floated or not.

Sites with MTAs (mail servers that transmit messages) would add special "reverse MX" DNS records that give a list of all the valid IP numbers for their server. This is slightly different than a normal MX record, but I'm not going into the fine details (which I don't entirely understand anyway).

Upon receiving a message, the receiving server would do a lookup on that special RMX record for the domain in the From: header. If there is a response, the IP number of the connecting MTA must match one of the valid IP numbers which that domain says are its mail servers.

Like any change, it requires many sites to adopt it. But it's fully reverse compatible with existing smpt infrastructure. You'd think such a simple, backwards compatible proposal would be a "no brainer". (this is different from the existing practice of doing a normal mx lookup... see below for a link to the full RMX proposal).

For the sad story of resistance to any changes, no matter how compatible they may be with existing SMPT, start reading at section 12.4 of the Internet Draft RMX Proposal. This proposal is pretty well written and quite accessible to most people who know a little about SMTP.

For anyone who buys into the "we gotta implement strong crypto/authentication" arguement of the parent post (such as 3-4 moderators who mod'd it up), please take some time to skim through that internet draft... such as section 3 after having read the part at the end about the incredible resistance there has been to even such a very simple and compatible change.

When I first read the subject line I thought it was going to be related to RFC 1149 "A Standard for the Transmission of IP Datagrams on Avian Carriers", which can be used to send your email using an archaic form of postal service (although not really snail mail I guess).

Quick, without peeking at the answer, what's the difference between a URI, a URL, and a URN? OK, now that we are all on the same page :-), what is "info:"? you'd expect it to be a URN. It isn't (from the RFC):

7.2 Why Not Use a URN Namespace ID for Identifiers from Public Namespaces?

RFC 2396 [RFC2396] states that a "URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier". An "info" URI on the other hand does not assert persistence of resource names or of the resource itself, but rather declares namespaces of identifiers managed according to the policies and business models of the Namespace Authorities. Some of these namespaces will not have persistence of identifiers as a primary purpose, while others will have locator semantics as well as name semantics. It would therefore be inappropriate to employ a URN Namespace ID for such namespaces.

Which I read to mean that an info: URI may, or may not, be a URL (i.e., useful for actually accessing the resource); may, or may not, be a URN (i.e., provides some semblence of a chance that it means the same thing today as it did yesterday). Oh, did I mention that it may, or may not, be case sensitive, and may or may not be subject to scheme-specific normalization rules?

It seems that someone (say "Perfection") got fed up holding the fort agains a hoard of requests for top-level URI schemes - or someone (say "Kludge") got fed up with the demand that these schemes actually have some well defined semantics. Or both. Either way, they had this brilliant notion... why don't we have a junk^H^H^H^Hinfo: URI scheme with as little control over semantics as we can get away with? If some top-level URI scheme sucks, we'll just put it there. We'll spin off a company to be the registrar so "Perfection" will be able to pretend not to see it, and "Kludge" will be able to register all the junk^H^H^H^Hinformation URIs he wants!

I guess it does make some sort of twisted sense... In the meanwhile, proposals like the taguri proposal languish. Here's a years-old proposal that attempts to define coherent semantics for time-persistant identifiers, without requiring a (new) registration agency. We can't have that, can we?

Sigh. Insert mandatory "I for one welcome the arrival of our new info:disposable:gjyr4784ghf89yf4h URI masters" post here...

The URI namespace is already quite broad and has many ways to define "public" namespaces, usually based upon the URN subset of the URI specification. Just a few open-ended namespaces so far include the OID-based URI namespace, such as "urn:oid:1.3.6.1.2.1.27", (RFC 3061). You also have RFC 3151 for public identifier URIs.

Really, there is nothing new technically here. The only useful thing it brings beyond the URN spec is the new registration authority. It can still prove useful, but it's not like it's actually solving any real technical limitation in our current set of URIs.

The URI namespace is already quite broad and has many ways to define "public" namespaces, usually based upon the URN subset of the URI specification. Just a few open-ended namespaces so far include the OID-based URI namespace, such as "urn:oid:1.3.6.1.2.1.27", (RFC 3061). You also have RFC 3151 for public identifier URIs.

Really, there is nothing new technically here. The only useful thing it brings beyond the URN spec is the new registration authority. It can still prove useful, but it's not like it's actually solving any real technical limitation in our current set of URIs.

The URI namespace is already quite broad and has many ways to define "public" namespaces, usually based upon the URN subset of the URI specification. Just a few open-ended namespaces so far include the OID-based URI namespace, such as "urn:oid:1.3.6.1.2.1.27", (RFC 3061). You also have RFC 3151 for public identifier URIs.

Really, there is nothing new technically here. The only useful thing it brings beyond the URN spec is the new registration authority. It can still prove useful, but it's not like it's actually solving any real technical limitation in our current set of URIs.