From olaf at ripe.net Wed Oct 1 17:46:07 2003 From: olaf at ripe.net (Olaf M. Kolkman) Date: Wed, 1 Oct 2003 17:46:07 +0200 Subject: [dns-wg] Reverse DNS Restructuring Project Message-ID: <20031001174607.315e0293.olaf@ripe.net> Dear Colleagues, I have just posted a proposal about the restructuring of the reverse DNS setup to the ncc-services-wg mailing list. I'd like to point out that this proposal has relevance to both the dns-wg and db-wg. You can find the proposal on http://www.ripe.net/reverse/proposal.html Please provide your feedback on the ncc-services-wg mailing list. With excuses for the cross-post, -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC From hadmut at danisch.de Tue Oct 14 00:02:40 2003 From: hadmut at danisch.de (Hadmut Danisch) Date: Tue, 14 Oct 2003 00:02:40 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization Message-ID: <20031013220240.GA8884@danisch.de> Hi, I don't know whether this was discussed on this mailing list before. I just subscribed and would like to hear your opinion about http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt which describes the RMX records, a method to store authorization records about who is authorized to send e-mails with sender addresses of the zone. It is intended to protect against spam, worms, and such rubbish. regards Hadmut From bortzmeyer at nic.fr Wed Oct 15 09:25:31 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 15 Oct 2003 09:25:31 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031013220240.GA8884@danisch.de> References: <20031013220240.GA8884@danisch.de> Message-ID: <20031015072531.GA12161@nic.fr> On Tue, Oct 14, 2003 at 12:02:40AM +0200, Hadmut Danisch wrote a message of 14 lines which said: > I don't know whether this was discussed on this mailing list before. > I just subscribed and would like to hear your opinion about > > http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt Bad idea, like every method that prevents me from using "From: bortzmeyer at nic.fr" (work address) when I'm at home and connected via my IAP Nerim. From Piet.Beertema at cwi.nl Wed Oct 15 09:37:19 2003 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 15 Oct 2003 09:37:19 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031015072531.GA12161@nic.fr> References: <20031013220240.GA8884@danisch.de> <20031013220240.GA8884@danisch.de> Message-ID: <5.1.0.14.2.20031015093635.029e3168@localhost> > > I don't know whether this was discussed on this mailing list before. > > I just subscribed and would like to hear your opinion about > > > > http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt > >Bad idea, like every method that prevents me from using "From: >bortzmeyer at nic.fr" (work address) when I'm at home and connected >via my IAP Nerim. Right. Exit roaming. And on the longer term: exit e-mail. Piet From brad.knowles at skynet.be Wed Oct 15 09:59:55 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 15 Oct 2003 09:59:55 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031015072531.GA12161@nic.fr> References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> Message-ID: At 9:25 AM +0200 2003/10/15, Stephane Bortzmeyer wrote: >> http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt > > Bad idea, like every method that prevents me from using "From: > bortzmeyer at nic.fr" (work address) when I'm at home and connected via > my IAP Nerim. I agree. The IETF/IRTF Anti-Spam Working Group is reviewing a number of similar proposals of this nature (including this one), and I am pretty strongly opposed to all of them, for similar reasons. Too many people support this concept to seriously hope that we can get this idea killed in committee before it ever gets into the documents that are generated by the ASRG. However, I can at least hope that enough caveats are added and the known problems it causes are highlighted strongly enough that people are either discouraged from using this sort of technique at all, or they only use it as part of a "whitelist" method. You may want to consider applying to join the ASRG if you feel strongly about this issue. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From daniel.karrenberg at ripe.net Wed Oct 15 10:03:06 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 15 Oct 2003 10:03:06 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031015072531.GA12161@nic.fr> References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> Message-ID: <20031015080306.GA6955@reifa-wave.karrenberg.net> On 15.10 09:25, Stephane Bortzmeyer wrote: > Bad idea, like every method that prevents me from using "From: > bortzmeyer at nic.fr" (work address) when I'm at home and connected via > my IAP Nerim. I have not read that draft. However I wish to point out that one's virtual location is quite independent from one's location in the Internet topology. I have been using tunnels of various description to "be" in many places when I work on my laptop for more than half a decade. This is quite independent of whether my laptop is at my home, like now, or at the office, or at a meeting half way across the globe or wherever else there is Internet. During the last years I have see this become more and more popular. Daniel From brad.knowles at skynet.be Wed Oct 15 10:11:56 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 15 Oct 2003 10:11:56 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031015080306.GA6955@reifa-wave.karrenberg.net> References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> <20031015080306.GA6955@reifa-wave.karrenberg.net> Message-ID: At 10:03 AM +0200 2003/10/15, Daniel Karrenberg wrote: > However I wish to point out that one's virtual location is quite > independent from one's location in the Internet topology. Indeed. Note that RMX-type proposals also break .forward, /etc/aliases-based mailing lists (probably >80% of all mailing lists in existence are actually just aliases and not done through a proper MLM), and have various other problems. > I have been > using tunnels of various description to "be" in many places when I work > on my laptop for more than half a decade. Indeed, but tunnels are not always possible or feasible, and in many cases should not be required. If all you want to do is send a public e-mail message, you should be able to use the local mail relay facilities available to you. In fact, many networks *require* you to use the local mail relay facilities. Of course, some of those are stupid enough to insist that you use a recognized local domain portion for your envelope sender address, which screws you even more. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From leo at bind.org Wed Oct 15 10:50:24 2003 From: leo at bind.org (leo vegoda) Date: Wed, 15 Oct 2003 09:50:24 +0100 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> <20031015080306.GA6955@reifa-wave.karrenberg.net> Message-ID: <20031015085024.GA51018@bind.org> On Wed, Oct 15, 2003 at 10:11:56AM +0200, Brad Knowles wrote: [...] > In fact, many networks *require* you to use the local mail relay > facilities. Of course, some of those are stupid enough to insist > that you use a recognized local domain portion for your envelope > sender address, which screws you even more. Isn't this where consumer power and competition law come into play? There are many ISPs and they have different market offerings. You pays your money and takes your choice. This works better in countries where there is a competitive market in ISP services, of course. Regards, -- leo vegoda "One size never fits all" RFC1925 - The Twelve Networking Truths From hadmut at danisch.de Wed Oct 15 13:41:22 2003 From: hadmut at danisch.de (hadmut at danisch.de) Date: Wed, 15 Oct 2003 13:41:22 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031015072531.GA12161@nic.fr> References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> Message-ID: <20031015114122.GA13997@danisch.de> On Wed, Oct 15, 2003 at 09:25:31AM +0200, Stephane Bortzmeyer wrote: > > > http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt > > Bad idea, like every method that prevents me from using "From: > bortzmeyer at nic.fr" (work address) when I'm at home and connected via > my IAP Nerim. > I see. Would you mind if I use "From: bortzmeyer at nic.fr" when I am at home? regards Hadmut From brad.knowles at skynet.be Wed Oct 15 14:44:22 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 15 Oct 2003 14:44:22 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031015085024.GA51018@bind.org> References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> <20031015080306.GA6955@reifa-wave.karrenberg.net> <20031015085024.GA51018@bind.org> Message-ID: At 9:50 AM +0100 2003/10/15, leo vegoda wrote: > Isn't this where consumer power and competition law come into play? > There are many ISPs and they have different market offerings. You > pays your money and takes your choice. Some people don't *have* a choice. It's certainly hard to have a choice when you are roaming on the iPass or GRiC networks, because you have no clue who your local provider really is. > This works better in countries where there is a competitive market > in ISP services, of course. Indeed. See above. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From brad.knowles at skynet.be Wed Oct 15 14:53:01 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 15 Oct 2003 14:53:01 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031015114122.GA13997@danisch.de> References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> <20031015114122.GA13997@danisch.de> Message-ID: At 1:41 PM +0200 2003/10/15, hadmut at danisch.de wrote: > I see. Would you mind if I use "From: bortzmeyer at nic.fr" when I am at > home? You can use whatever you want. There's nothing anyone can do to stop you. Moreover, the header "From:" is totally unrelated to the envelope sender address, and there's nothing in your proposal, or any similar proposal, that could successfully keep clever people from doing this sort of stuff anyway. Of course, keep in mind that recent viruses have used legitimate local e-mail addresses to send copies of themselves to people in that person's address book. You certainly shouldn't be able to prevent him from being able to use "From: bortzmeyer at nic.fr" when it's his own machine sending mail from his own MUA, assuming he were vulnerable to this sort of thing. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From hadmut at danisch.de Thu Oct 16 09:27:49 2003 From: hadmut at danisch.de (hadmut at danisch.de) Date: Thu, 16 Oct 2003 09:27:49 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> <20031015114122.GA13997@danisch.de> Message-ID: <20031016072749.GA3440@danisch.de> On Wed, Oct 15, 2003 at 02:53:01PM +0200, Brad Knowles wrote: > At 1:41 PM +0200 2003/10/15, hadmut at danisch.de wrote: > > > I see. Would you mind if I use "From: bortzmeyer at nic.fr" when I am at > > home? > > You can use whatever you want. There's nothing anyone can do to > stop you. Moreover, the header "From:" is totally unrelated to the > envelope sender address, and there's nothing in your proposal, or any > similar proposal, that could successfully keep clever people from > doing this sort of stuff anyway. Two replies: - So why is Stephane complaining that these proposals would break his ability to use "From: bortzmeyer at nic.fr" ? In fact, none of the proposals would stop him from doing so, but since he complained about this emotionally, I tried to pick up his argument the same way. People should read and understand a draft before attacking it. - The proposals are not intended to stop anyone from forging the From: line for several technical reasons, they are intended to stop forging the envelope sender address. There are very good reasons to do it this way, especially the different semantics of those addresses. The From: line specifies the author of the mail, the envelope address specifies the initiator of the transport. These addresses are not necessarily the same in reality. In many cases they can differ legaly, e.g. for list processors, forwarding, bouncing,... However, if such a mail turns out to be forged (i.e. it has not been written by the sender specified in the From: line) or is any kind of fraud, worm, virus,... then it needs to be tracked back to where it came from to identify the _sender_ . There is no technical way to verify the author, except for cryptographical signatures, which are undeployable in a world wide scale. But there is a way to do a light weight verification of the sender of the message by checking the authorization. That's what RMX and the RMX-like proposals do. You need to understand the technical, legal and semantical difference between sender and author. Otherwise you're lost. > Of course, keep in mind that recent viruses have used legitimate > local e-mail addresses to send copies of themselves to people in that > person's address book. You certainly shouldn't be able to prevent > him from being able to use "From: bortzmeyer at nic.fr" when it's his > own machine sending mail from his own MUA, assuming he were > vulnerable to this sort of thing. That's a very bad argument. - Even if he is the owner of his machine, this does not automatically mean that his is the owner of this particular domain or address. That's how emotions work, but security does not work this way. Being authorized to use a particular address does have nothing to do whether someone is the owner of a particular computer. I am right now using a computer to write this e-mail which I don't own. So what? To invent e-mail security, there must be a technical difference between those who are authorized to use an address and those who are not. This difference must be detectable by receivers. That's how security works. Would you prefer to ask every sender of an e-mail message whether he can show a purchase receipt for the computer to prove that he is the legitimate owner? Think about it. The being-the-owner-of-the- machine argument is nonsense. - If the virus needs to use a legitimate address, then any error messages of virus filter will be sent back to the person responsible for that machine, and the machine can be fixed or taken offline. This is not possible if the error messages are sent to the wrong address. - I and many other people are currently drowning in error messages from relays which received worm messages with my/their domain as a sender address. This is a much bigger problem than the worms themselves. RMX will stop this imediately. Hadmut From bortzmeyer at nic.fr Thu Oct 16 12:29:22 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 16 Oct 2003 12:29:22 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031015114122.GA13997@danisch.de> References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> <20031015114122.GA13997@danisch.de> Message-ID: <20031016102922.GA23247@nic.fr> On Wed, Oct 15, 2003 at 01:41:22PM +0200, hadmut at danisch.de wrote a message of 18 lines which said: > I see. Would you mind if I use "From: bortzmeyer at nic.fr" when I am at > home? I would mind a lot but there are no serious technical means to prevent it. (There are a lot of legal means but I don't always have the time to use them.) From brad.knowles at skynet.be Thu Oct 16 13:07:56 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu, 16 Oct 2003 13:07:56 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031016072749.GA3440@danisch.de> References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> <20031015114122.GA13997@danisch.de> <20031016072749.GA3440@danisch.de> Message-ID: At 9:27 AM +0200 2003/10/16, hadmut at danisch.de wrote: > - So why is Stephane complaining that these proposals would break his > ability to use "From: bortzmeyer at nic.fr" ? In fact, none of the > proposals would stop him from doing so, but since he complained > about this emotionally, I tried to pick up his argument the same > way. People should read and understand a draft before attacking it. I have read the various drafts, and I understand how they work. They all rely on someone designating a set of servers that are allowed to send e-mail from a particular domain or set of domains. Regardless of the implementation mechanism, that act alone breaks .forward, alias-based mailing lists, legitimate third-party relay when you are travelling, etc.... > However, if such a mail turns out to be forged (i.e. it has not > been written by the sender specified in the From: line) or is > any kind of fraud, worm, virus,... then it needs to be tracked back > to where it came from to identify the _sender_ . There is no > technical way to verify the author, except for cryptographical > signatures, which are undeployable in a world wide scale. Right, and nothing you do with an RMX-like proposal is going to make any difference here. The problem is that it doesn't help you until everyone (or most everyone) already does it, and until then it can only hurt. That is, unless it is only used as a whitelist mechanism, in which case what has it really bought you (and the entire rest of the Internet) to try to force everyone to do this? > But there is a way to do a light weight verification of the > sender of the message by checking the authorization. That's what > RMX and the RMX-like proposals do. No. That is not at all what they do. That is what they *claim* to do. With DNS cache poisoning, all that goes out the window. With over 50% of the ccTLD authoritative nameservers being open public caching/recursive nameservers, just how clueful do you honestly think people are going to be? And this is just one of many weaknesses. If you want to do authentication, you need those cryptographic methods. Nothing short of that is going to help. > You need to understand the technical, legal and semantical > difference between sender and author. Otherwise you're lost. That is precisely what I would say back to you. > - Even if he is the owner of his machine, this does not automatically > mean that his is the owner of this particular domain or address. He may not own that domain, but he almost certainly owns that address. And he's already got his MUA configured to use the appropriate outbound mail server, including all cryptographic authentication methods required to make the transmission of mail a smooth and invisible process. > To invent e-mail security, there must be a technical difference > between those who are authorized to use an address and those who are > not. This difference must be detectable by receivers. That's how > security works. You're not going to invent anything useful using fundamentally flawed ideas using systemically dain-bramaged DNS infrastructure around the world. If you think SMTP security is bad, you haven't begun to look at DNS security. > - If the virus needs to use a legitimate address, then any > error messages of virus filter will be sent back to the > person responsible for that machine, and the machine can > be fixed or taken offline. This is not possible if the error > messages are sent to the wrong address. That's assuming that the mailbox of the sender isn't already full of other bounces. That's assuming that the virus doesn't surreptitiously check the mailbox and delete all bounces, so as to cover it's tracks. That's assuming that the MTAs all along the chain are properly configured and actually issue bounces back to the envelope sender address, as opposed to paying attention to some easily forged header of some sort. That's assuming a whole hell of a lot of other things. > - I and many other people are currently drowning in error messages > from relays which received worm messages with my/their domain > as a sender address. This is a much bigger problem than the > worms themselves. RMX will stop this imediately. Something must be done. This is something. Therefore, this must be done. Riiiiiiiiiiiiiiiiiight. We've heard this before. As the former Sr. Internet Mail Administrator for AOL, I've probably been responsible for stopping more spam than you will ever see in your life. As one of the authors of some of the earliest anti-spam rulesets that were contributed back to the community, I am probably indirectly responsible for having stopped many, many orders of magnitude more spam than you can ever possibly see in your entire life. We're all suffering. What we shouldn't do is wave large quantities of weapons of mass destruction around in a crazied attempt to kill all the bugs -- doing so can only lead to our own destruction, and minor annoyance for the bugs. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From hadmut at danisch.de Thu Oct 16 15:07:37 2003 From: hadmut at danisch.de (hadmut at danisch.de) Date: Thu, 16 Oct 2003 15:07:37 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> <20031015114122.GA13997@danisch.de> <20031016072749.GA3440@danisch.de> Message-ID: <20031016130737.GA8226@danisch.de> On Thu, Oct 16, 2003 at 01:07:56PM +0200, Brad Knowles wrote: > At 9:27 AM +0200 2003/10/16, hadmut at danisch.de wrote: > > > - So why is Stephane complaining that these proposals would break his > > ability to use "From: bortzmeyer at nic.fr" ? In fact, none of the > > proposals would stop him from doing so, but since he complained > > about this emotionally, I tried to pick up his argument the same > > way. People should read and understand a draft before attacking it. > > I have read the various drafts, and I understand how they work. > They all rely on someone designating a set of servers that are > allowed to send e-mail from a particular domain or set of domains. Again, Stephane complained that the proposals would stop him from using "From: bortzmeyer at nic.fr" and you explicetely agreed, while at the same time you confirmed that all those proposals do not have anything to do with the header From: line. I still do not understand your opinion and your argument. If the proposals have nothing to do with the header From line (in fact, they don't), so why are you and Stephane complaining? > Regardless of the implementation mechanism, that act alone breaks > .forward, alias-based mailing lists, legitimate third-party relay > when you are travelling, etc.... No. If it doesn't touch the header From line, it doesn't break anything with that. Most mailing lists, all modern mailing list processors I've checked, most forwarding services correctly insert a new sender envelope address and will work with RMX just perfectly. > Right, and nothing you do with an RMX-like proposal is going to > make any difference here. The problem is that it doesn't help you > until everyone (or most everyone) already does it, and until then it > can only hurt. Wrong. If just Hotmail, AOL and Yahoo would provide RMX records and I'd query them, then I already would get rid of a significat amount of spam. And that's only a four party game. And even if I were the only person providing RMX records, it would already help getting rid of wrong delivery failure messages. > With DNS cache poisoning, all that goes out the window. With > over 50% of the ccTLD authoritative nameservers being open public > caching/recursive nameservers, just how clueful do you honestly think > people are going to be? And this is just one of many weaknesses. DNS cache poisoning is possible, but is found rarely. While I see tens of thousands of Spam per day, I didn't find any case of cache poisoning within the last two years. Do you really believe Spammers would be able to poision the DNS caches of a million receivers? That's not an acceptable argument. > If you want to do authentication, you need those cryptographic > methods. Nothing short of that is going to help. Wrong. Nonsense. There's organizational security, e.g. topological authentication, as done by e.g. firewalls. You should be better informed before propagating such claims. > He may not own that domain, but he almost certainly owns that > address. And how should anyone else check this? > And he's already got his MUA configured to use the > appropriate outbound mail server, including all cryptographic > authentication methods required to make the transmission of mail a > smooth and invisible process. So tell me how my receiving MTA can check this. What cryptographic authentication is he using that could be automatically checked by my machine? How do you want to deploy such a mechanism to countries where cryptography is not allowed? Do you believe that a billion of internet users will keep the secret keys on their windows machines secret? That's absurd. > You're not going to invent anything useful using fundamentally > flawed ideas using systemically dain-bramaged DNS infrastructure > around the world. Being insultive is not an argument. > If you think SMTP security is bad, you haven't > begun to look at DNS security. DNS security is still much better than SMTP security, because there is no SMTP security. Spammers using wrong sender addresses do not have to break any security mechanism by now. Breaking DNS is still not trivial, especially not for mass mailings. > That's assuming that the mailbox of the sender isn't already full > of other bounces. That's assuming that the virus doesn't > surreptitiously check the mailbox and delete all bounces, so as to > cover it's tracks. That's foolish. Not stopping spam and viruses because the mailbox could be filled with other rubbish is just ridiculous. And btw my relay has never been infected by a virus. Your argumentation is so farfetched and far from reality, that it doesn't convince in any way. > Something must be done. This is something. Therefore, this must be > done. > > Riiiiiiiiiiiiiiiiiight. We've heard this before. > That's the universal kiddy-argument against everything. Following you would mean to leave it just as it is. The current spam traffic might be suitable to your personal needs, but it isn't to others. > As the former Sr. Internet Mail Administrator for AOL, I've > probably been responsible for stopping more spam than you will ever > see in your life. Aha. AOL has also transported more spam than I will ever see in my life. So what? And what does this mean? That every anti-spam solution requires your personal approval? > As one of the authors of some of the earliest > anti-spam rulesets that were contributed back to the community, I am > probably indirectly responsible for having stopped many, many orders > of magnitude more spam than you can ever possibly see in your entire > life. Aha. And what does this mean? Do you want to tell me that you have the permission to spam-fight and I don't? > We're all suffering. What we shouldn't do is wave large > quantities of weapons of mass destruction around in a crazied attempt > to kill all the bugs -- doing so can only lead to our own > destruction, and minor annoyance for the bugs. So what are you proposing? Leave it as it is? If you have any better and feasible idea, don't hesitate to tell it. World will be happy to get it. I see that you don't like RMX. But I don't see what you want to have. A different mechanism? No spam protection at all? What do you want? Hadmut From brad.knowles at skynet.be Fri Oct 17 01:15:38 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri, 17 Oct 2003 01:15:38 +0200 Subject: [dns-wg] DNS RMX records - e-mail sender authorization In-Reply-To: <20031016130737.GA8226@danisch.de> References: <20031013220240.GA8884@danisch.de> <20031015072531.GA12161@nic.fr> <20031015114122.GA13997@danisch.de> <20031016072749.GA3440@danisch.de> <20031016130737.GA8226@danisch.de> Message-ID: At 3:07 PM +0200 2003/10/16, hadmut at danisch.de wrote: > I still do not understand your opinion and your argument. > If the proposals have nothing to do with the header From line > (in fact, they don't), so why are you and Stephane complaining? Because we want to use the proper envelope sender address, and have the bounces come back to our correct address. We don't want to be forced to use some garbage envelope sender address forced on us by the severely misguided which would cause our bounces to go to the wrong place, while the header would be unchanged. > No. If it doesn't touch the header From line, it doesn't break > anything with that. Most mailing lists, all modern mailing list > processors I've checked, most forwarding services correctly insert > a new sender envelope address and will work with RMX just perfectly. Did I say anything about breaking proper mailing lists? No. I said something about breaking .forward, which does not (and cannot) change the envelope sender address. I said something about breaking alias-based mailing lists (which also don't change the envelope sender address). I said something about breaking legitimate third-party relay when you are travelling. If you're going to argue on some subject, it might be a good idea to pay attention to what the other guy is talking about. > Wrong. If just Hotmail, AOL and Yahoo would provide RMX records and > I'd query them, then I already would get rid of a significat amount > of spam. And that's only a four party game. Wrong. Many people legitimately send e-mail from accounts like that, with return addresses legitimately within domains like this. > And even if I were the only person providing RMX records, it > would already help getting rid of wrong delivery failure messages. No, there would still be plenty of MTAs that would be misconfigured and pay attention to headers like "Errors-to:", and you'd be victim of header address spoofing, and the bounces resulting from them. > DNS cache poisoning is possible, but is found rarely. While I see > tens of thousands of Spam per day, I didn't find any case of cache > poisoning within the last two years. Do you really believe Spammers > would be able to poision the DNS caches of a million receivers? Sure. They can own networks of hundreds of thousands of PCs around the world, and use them to DDoS blacklist providers out of existence, and do so with impunity. It doesn't matter if you know precisely who they are, where they are, and exactly how they're doing it. You can have video of the act. It doesn't matter, because no one in law enforcement gives a flying flip. If they're going to write stealth viruses to take over hundreds of thousands or millions of PCs to act as their conduit for spam, or to act as reverse proxy cache servers for the hidden websites that have the real content, then DNS cache poisoning is a trivially easy step for them. > Wrong. Nonsense. There's organizational security, e.g. topological > authentication, as done by e.g. firewalls. You should be better > informed before propagating such claims. Weak. Spoofable. Easy to work around. Meaningless. These are terms you should become familiar with before you participate in discussions on subjects you do not understand. > And how should anyone else check this? How could anyone else check on this? The only reasonably trustworthy mechanism would involve strong crypto at the core of a secure protocol, and even then that could be subverted by easily guessed passwords (or sniffed passwords), or any of several other attacks. > So tell me how my receiving MTA can check this. What cryptographic > authentication is he using that could be automatically checked > by my machine? At the MTA level, you don't. The best you could do would be to authenticate the connection from the sending MTA to your MTA, in much the same way SSL certification is done today. Oh, wait. We already have this. It's called SMTPAUTH. Then there's TLSSMTP. If you want to authenticate the message itself, you're dependant on the mechanisms that he chooses to put into the message -- PGP, S/MIME, whatever. > How do you want to deploy such a mechanism to countries where > cryptography is not allowed? Do you believe that a billion of > internet users will keep the secret keys on their windows machines > secret? That's absurd. How do you deploy SSL? > DNS security is still much better than SMTP security, because there > is no SMTP security. Spammers using wrong sender addresses do not have > to break any security mechanism by now. If you think there is anything remotely resembling DNS security, you are not familiar with the subject. > Breaking DNS is still not > trivial, especially not for mass mailings. Not at all true. They're already playing these sorts of games. You're just not up-to-date on the techniques they're already using. > That's the universal kiddy-argument against everything. Following you > would mean to leave it just as it is. The current spam traffic might > be suitable to your personal needs, but it isn't to others. No, we are working on actually useful proposals to help deal with the issue. > Aha. AOL has also transported more spam than I will ever see > in my life. So what? If you haven't seen it, you are not likely to be able to come up with ways to successfully combat it. > And what does this mean? That every anti-spam solution requires your > personal approval? No. There are plenty of people who have useful experience to bring to the table. However, I have seen a lot of dain-bramaged ideas in my time, and I am well-suited to pointing out these problems wherever I encounter them. > Aha. And what does this mean? Do you want to tell me that you have the > permission to spam-fight and I don't? No. However, if you're going to try to be part of the solution and not just make a bad situation many orders of magnitude worse, you need to do your homework. You need to do research. You need to talk to people who have more experience in this field, and you need to be willing to learn from them. I have seen no evidence of any of these behaviours on your part. > So what are you proposing? Leave it as it is? If you have any > better and feasible idea, don't hesitate to tell it. World will be > happy to get it. I'm working on that within the auspices of the IETF/IRTF Anti-Spam Research Group (ASRG). As the BCP Coordinator, I'm hoping that we will soon have some "best practices" that we can recommend that sites participate in, and help stem the tide. > I see that you don't like RMX. But I don't see what you want to have. > A different mechanism? No spam protection at all? What do you want? You should see that when the ASRG starts publishing the BCPs. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From johani at autonomica.se Sun Oct 19 17:56:20 2003 From: johani at autonomica.se (Johan Ihren) Date: Sun, 19 Oct 2003 17:56:20 +0200 Subject: [dns-wg] Upcoming change of source AS for i.root-servers.net Message-ID: Friends, As part of the long term ambition to provide the Internet root nameservers with extremely stable homes in all possible respects we plan to change the source autonomous system for i.root-servers.net from AS8674 (NETNOD INTERNET EXCHANGE) to AS29216 (dedicated as I.ROOT-SERVERS.NET). We hope that after this change i.root-servers.net will never have to change source AS again. We intend to implement this change next week during the NANOG29 conference. Please note: a) This is a planned operation, not an emergency. b) We will not change the IP adress of the i.root-servers.net service, only the source AS. c) We will not change any of the several servers providing the i.root-servers.net service in any way. It will be the same servers at the same locations providing exactly the same service as usual. Regards, Johan Ihr?n Autonomica From Ronald.vanderPol at rvdp.org Mon Oct 20 15:28:34 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Mon, 20 Oct 2003 15:28:34 +0200 Subject: [dns-wg] "adding IPv6 glue to root zone" document Message-ID: <20031020132834.GL20204@rvdp.org> At RIPE 46 we presented measurements about the effects of adding IPv6 glue to the root zone. As promised, we made more measurements and have written a document: http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf rvdp From johani at autonomica.se Sun Oct 19 17:56:20 2003 From: johani at autonomica.se (Johan Ihren) Date: Sun, 19 Oct 2003 17:56:20 +0200 Subject: [dns-wg] Upcoming change of source AS for i.root-servers.net Message-ID: Friends, As part of the long term ambition to provide the Internet root nameservers with extremely stable homes in all possible respects we plan to change the source autonomous system for i.root-servers.net from AS8674 (NETNOD INTERNET EXCHANGE) to AS29216 (dedicated as I.ROOT-SERVERS.NET). We hope that after this change i.root-servers.net will never have to change source AS again. We intend to implement this change next week during the NANOG29 conference. Please note: a) This is a planned operation, not an emergency. b) We will not change the IP adress of the i.root-servers.net service, only the source AS. c) We will not change any of the several servers providing the i.root-servers.net service in any way. It will be the same servers at the same locations providing exactly the same service as usual. Regards, Johan Ihr?n Autonomica From henk at ripe.net Mon Oct 20 18:33:09 2003 From: henk at ripe.net (Henk Uijterwaal (RIPE-NCC)) Date: Mon, 20 Oct 2003 18:33:09 +0200 (CEST) Subject: [dns-wg] [kc@caida.org: requesting hard data sources on ramifications of verisign wildcard] (fwd) Message-ID: FYI and apologies for duplicate mails. ----- Forwarded message from k claffy ----- Date: Thu, 16 Oct 2003 12:26:15 -0700 From: k claffy Subject: requesting hard data sources on ramifications of verisign wildcard To: nanog at nanog.org as already mentioned, fascinating public policy theatre is going on in DC on the verisign wildcard issue, see http://secsac.icann.org/ [all video and even transcripts of both meetings online. go icann.] you are encouraged to read through all of it before making public comments on this issue at nanog. (or, hope springs eternal, to this list.) caida has the following request on behalf of icann's secsac committee [an exceptionally competent group who is approaching this issue with impressive speed, equaniminity, and integrity. http://www.icann.org/committees/security/ i believe we're in good hands here. let's give the process a chance and constructively contribute where we can.] a common theme over the last week is an admitted lack of hard data [rather than lists of theoretical breakages, and anecdotal evidence, and predictions] from the operational community on actual loss of stability in Internet performance or functionality. david from XO gave an outstanding talk on 7 oct, http://www.icann.org/presentations/shairer-secsac-dc-07oct03.ppt but, as with many other providers, he deployed the bind patch within 24 hours so he didn't really have useful hard data to put on the table. i get similar comments from others. ben from harvard also gave some hard alexa data, fwiw http://www.icann.org/presentations/edelman-secsac-dc-15oct03.ppt but from a specific vantage point. we need more of these. icann's secsac committee is in a much stronger position to provide technically sound and equitable guidance if we can provide them with as specific, concrete examples (*hard data*) that indicate extent of various types of breakage. please save the arguments regarding the legitimacy and short notice of this request until you've read the hours of discussion about it that has already occurred among many qualified folks in DC (and in any case the meta-issue still stretches AUP of nanog list). the inconvenient reality is that the secsac committee needs concrete data (imagine), in addition to bulleted lists of things that break, for the policy process to work most effectively here. and nanog is in a position to make a difference. you are hereby encouraged to do so. please send any hard data reflecting observed ramifications on security and stability of Internet infrastructure to secsac-comment at icann.org no hard data will be refused service k ----- End forwarded message ----- From paf at cisco.com Sun Oct 26 07:48:45 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sun, 26 Oct 2003 07:48:45 +0100 Subject: [dns-wg] "adding IPv6 glue to root zone" document In-Reply-To: <20031020132834.GL20204@rvdp.org> References: <20031020132834.GL20204@rvdp.org> Message-ID: <721B459E-0780-11D8-BA00-000A959CF516@cisco.com> Nice! I have two follow-up questions: (1) Some DNS servers have added AAAA for their servers. If they run slave servers for some TLD's, those TLD's "suddenly" have AAAA records for one of their nameservers. Maybe these cases are the real world "experiments" we should look closely at? Have we heard any complaints? I am especially thinking of ns.ripe.net which have one A and one AAAA record. (2) In Sweden we are discussing adding AAAA to the zone, and have also made some studies (not run by me, I am a passive participant in the practical tests). We have tested things like possible problems resolver libraries have to send queries to a nameserver IF the nameserver have both A and AAAA records, the resolver have Ipv6 enabled, but not IPv6 connectivity to the nameserver. Will the resolver fall back to IPv4 transport? It should, and what we have found so far is that it does. I hope we can have some data before the next RIPE meeting. Has anyone else looked at potential problems like this? paf On 2003-10-20, at 15.28, Ronald van der Pol wrote: > At RIPE 46 we presented measurements about the effects of adding > IPv6 glue to the root zone. > > As promised, we made more measurements and have written a document: > http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf > > rvdp > From ripe-dbm at ripe.net Mon Oct 27 08:14:32 2003 From: ripe-dbm at ripe.net (ripe-dbm at ripe.net) Date: Mon, 27 Oct 2003 08:14:32 +0100 (MET) Subject: [dns-wg] SUCCESS: re:.@.......z...^.. Message-ID: <200310270714.h9R7EW401924@apple.ripe.net> > From: "dns-wg" > Subject: re:. at .......z...^.. > Date: Mon, 27 Oct 03 07:44:52 .x._........ > Reply-To: dns-wg at ripe.net > Message-ID: <20031027071211.832234EFC8 at postman.ripe.net> SUMMARY OF UPDATE: Number of objects found: 0 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 0 Create: 0 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: re:. at .......z...^.. ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE Database Administration From ripe-dbm at ripe.net Mon Oct 27 08:14:57 2003 From: ripe-dbm at ripe.net (ripe-dbm at ripe.net) Date: Mon, 27 Oct 2003 08:14:57 +0100 (MET) Subject: [dns-wg] SUCCESS: re:.@.......z...^.. Message-ID: <200310270714.h9R7Evf14449@lime.ripe.net> > From: "dns-wg" > Subject: re:. at .......z...^.. > Date: Mon, 27 Oct 03 07:44:52 .x._........ > Reply-To: dns-wg at ripe.net > Message-ID: <20031027071211.832234EFC8 at postman.ripe.net> SUMMARY OF UPDATE: Number of objects found: 0 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 0 Create: 0 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: re:. at .......z...^.. ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE TEST Database Administration