Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-25 Thread Markus Stumpf
On Tue, Jan 25, 2005 at 09:41:08AM +1100, Mark Andrews wrote: Lots. I'm sure that there are lots of ISPs/IAPs on NANOG that do RFC 2317 style delegations for their customers. How many is lots? And how often do the IP addresses of (outgoing) Mailservers change within a subnet? None

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-25 Thread Mark Andrews
On Tue, Jan 25, 2005 at 09:41:08AM +1100, Mark Andrews wrote: Lots. I'm sure that there are lots of ISPs/IAPs on NANOG that do RFC 2317 style delegations for their customers. How many is lots? Does it really matter? Even if it was only one site the problem

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-25 Thread Markus Stumpf
On Wed, Jan 26, 2005 at 07:31:44AM +1100, Mark Andrews wrote: Does it really matter? Yes it does. (As we all know at least since the Godzilla movie size does matter ;-) It has direct influence on the deployment. Even if it was only one site the problem would still have to

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-25 Thread Markus Stumpf
On Wed, Jan 26, 2005 at 09:26:04AM +1100, Mark Andrews wrote: You are adding a prefix not a type. If you added a type there would be no issue. It would work with existing RFC 2317 sytle delegations. The issue would be deployment. Design Choices When Expanding DNS

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-24 Thread Markus Stumpf
On Fri, Jan 14, 2005 at 10:05:05AM +1100, Mark Andrews wrote: What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be converted to use DNAME instead of CNAME which requires all the delegating

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-24 Thread Mark Andrews
On Fri, Jan 14, 2005 at 10:05:05AM +1100, Mark Andrews wrote: What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be converted to use DNAME instead of CNAME which requires all the delegating

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-14 Thread Eric Brunner-Williams in Portland Maine
Because there is no data protection on many databases (such as .com registrars who are forced to sell the data if requested), people lie when registering, because it is the only tool they have to protect their privacy. Yup. Our ICANN contracts both require us to sell bulk registrant data,

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-14 Thread Mark Andrews
That's bad sincd DNAME is deprecated and has been removed from BIND. Owen Really? Thats news to me. RFC 2672, Non-Terminal DNS Name Redirection, is still a proposed standard http://www.ietf.org/iesg/1rfc_index.txt. If you are thinking about RFC 3363,

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-14 Thread Eric Brunner-Williams in Portland Maine
The current pretense of privacy is nothing more than a convenient mechanism for registrars to pad their wallets and evade responsible for facilitating abuse. As an aside, I used a (wicked big) competitor's privacy service to regsiter a domain for a political worker who wanted to whistleblow

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-14 Thread Todd Vierling
On Fri, 14 Jan 2005, Suresh Ramasubramanian wrote: That's bad sincd DNAME is deprecated and has been removed from BIND. No, its A6 that is to be depreciated (and too bad because its superior to ), but last I heard DNAME stays as standard RR. Cue DJB's kill A6 page

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-14 Thread Paul Vixie
That's bad sincd DNAME is deprecated and has been removed from BIND. Really? Thats news to me. RFC 2672, Non-Terminal DNS Name Redirection, is still a proposed standard http://www.ietf.org/iesg/1rfc_index.txt. yes, and ISC-TN-2002-1 (see www.isc.org/pubs/tn/) is

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-13 Thread Andre Oppermann
Steven Champeon wrote: on Thu, Jan 13, 2005 at 10:25:18AM +0530, Suresh Ramasubramanian wrote: On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: In general, that's what dkeys/iim and csv (and maybe spf) are

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-13 Thread Stephane Bortzmeyer
On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 0) for the love of God, Montresor, just block port 25 outbound already. If there is no escape / exemption (as proposed by William Leibzon), then, as a consumer, I scream OVER

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-13 Thread Stephane Bortzmeyer
On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. (Most do, many do not. There is NO reason why

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-13 Thread Stephane Bortzmeyer
On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed from the root dbs) immediately and their owners contacted. Because

RE: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-13 Thread Joseph Johnson
Basically a call to operators to adopt a consistent forward and reverse DNS naming pattern for their mailservers, static IP netblocks, dynamic IP netblocks etc. ...and to ISPs to facilitate the process by supporting their users who want to run mail servers, and helping the rest of us use

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-13 Thread Rich Kulawiec
On Thu, Jan 13, 2005 at 12:26:47PM +0100, Stephane Bortzmeyer wrote: 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed from the root dbs) immediately and their owners contacted. Because there is no data protection on many databases

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-13 Thread Valdis . Kletnieks
On Thu, 13 Jan 2005 12:21:04 +0100, Stephane Bortzmeyer said: American bias but remember the Internet is worldwide. I do not know how it is in the USA but there are many parts of the world where ISP do not have a delegation of in-addr.arpa and therefore cannot pass it to their customers. (It

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of an

2005-01-13 Thread Stephane Bortzmeyer
On Thu, Jan 13, 2005 at 10:21:20AM -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote a message of 45 lines which said: Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, Of course, I know that.

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-13 Thread Steven Champeon
on Thu, Jan 13, 2005 at 12:21:04PM +0100, Stephane Bortzmeyer wrote: On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-13 Thread Steven Champeon
on Wed, Jan 12, 2005 at 04:51:34PM -0800, william(at)elan.net wrote: ...a very long and useful and informative message, for which I thank him. Off to go decipher the madness that is RFC3982, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us!

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of an

2005-01-13 Thread Eric Brunner-Williams in Portland Maine
Of course, I know that. I just mentioned Africa because, in many countries in Africa, it is simply impossible to get a PTR record. That's a fact, there are many reasons behind. Howdy Stephane, It is also an area where many cctld operators maintain their registration data using spreadsheets,

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-13 Thread Owen DeLong
Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, to any higher degree of certainty than when you just had the IP address. What he was pointing out her is that a majority of African ISPs do not even have

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym

2005-01-13 Thread Valdis . Kletnieks
On Thu, 13 Jan 2005 11:35:23 PST, Owen DeLong said: Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, to any higher degree of certainty than when you just had the IP address. What he was

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-13 Thread Mark Andrews
What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be converted to use DNAME instead of CNAME which requires all the delegating servers to be upgraded to support DNAME. There are

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of an

2005-01-13 Thread Barry Shein
On January 13, 2005 at 17:41 [EMAIL PROTECTED] (Stephane Bortzmeyer) wrote: Of course, I know that. I just mentioned Africa because, in many countries in Africa, it is simply impossible to get a PTR record. That's a fact, there are many reasons behind. That's because one of their leader's

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-13 Thread Owen DeLong
That's bad sincd DNAME is deprecated and has been removed from BIND. Owen --On Friday, January 14, 2005 10:05 +1100 Mark Andrews [EMAIL PROTECTED] wrote: What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-13 Thread william(at)elan.net
On Thu, 13 Jan 2005, Owen DeLong wrote: That's bad sincd DNAME is deprecated and has been removed from BIND. Owen No, its A6 that is to be depreciated (and too bad because its superior to ), but last I heard DNAME stays as standard RR. -- William Leibzon Elan Networks [EMAIL

Re: fixing insecure email infrastructure (was: Re: [eweek article]

2005-01-13 Thread Suresh Ramasubramanian
On Thu, 13 Jan 2005 22:43:24 -0800 (PST), william(at)elan.net [EMAIL PROTECTED] wrote: On Thu, 13 Jan 2005, Owen DeLong wrote: That's bad sincd DNAME is deprecated and has been removed from BIND. No, its A6 that is to be depreciated (and too bad because its superior to ), but last I

fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon
on Wed, Jan 12, 2005 at 01:52:43PM +, [EMAIL PROTECTED] wrote: I think that a secure email infrastructure is a good thing to have, in and of itself. By secure, I mean one in which messages get to their destination reliably, i.e. not lost in some spam filter, and one in which a recipient

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Chris Adams
Once upon a time, Steven Champeon [EMAIL PROTECTED] said: 7) all ISPs MUST act on ANY single abuse report (including being informed of infected customer machines, which MUST be removed from the Internet ASAP. No excuses) One problem I have with this one is people do forge reports, and

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon
on Wed, Jan 12, 2005 at 10:32:13AM -0600, Chris Adams wrote: Once upon a time, Steven Champeon [EMAIL PROTECTED] said: 7) all ISPs MUST act on ANY single abuse report (including being informed of infected customer machines, which MUST be removed from the Internet ASAP. No excuses)

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine
4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed ... All? Even those unpublished and therefore non-resolving? Sensible for the scoped-to-totality trademarks weenies who argue that the stringspace is a venue for dilution, whether the

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon
on Wed, Jan 12, 2005 at 12:55:06PM +, Eric Brunner-Williams in Portland Maine wrote: 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed ... All? Even those unpublished and therefore non-resolving? Sensible for the

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Adi Linden
0) for the love of God, Montresor, just block port 25 outbound already. What is wrong with dedicating port 25 to server to server communication with some means of authentication (DNS?) to ensure that it is indeed a vaild mail server. Mail clients should be using port 587 to submit messages to

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon
on Wed, Jan 12, 2005 at 01:49:53PM +, Eric Brunner-Williams in Portland Maine wrote: Why would it matter if you deactivated an unpublished/non-resolving domain? How do you deactivate an unpublished/non-resolving domain? You may borrow a registrar or registry hat if that is useful to

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon
on Wed, Jan 12, 2005 at 12:41:44PM -0600, Adi Linden wrote: 0) for the love of God, Montresor, just block port 25 outbound already. What is wrong with dedicating port 25 to server to server communication with some means of authentication (DNS?) to ensure that it is indeed a vaild mail

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine
Numerous (as in at least hundreds, probably more) of spam gangs are purchasing domains and burning through them in spam runs. In many cases, there's a pattern to them; in others, if there's a pattern, it's not clear to me what it might be. From my point of view, pattern is which registars

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine
I suppose it depends on how you define 'unpublished'; and how you define 'non-resolving'. Your opening remark was that policy foo must be applied to all domains. This doesn't accomplish anything for the set of domains that will never be published (registry reserved strings), nor those that

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon
on Wed, Jan 12, 2005 at 05:28:45PM +, Eric Brunner-Williams in Portland Maine wrote: All is too blunt a tool. So, then, when registering a domain, there should be a little checkbox saying I intend to abuse the Internet with this domain? It makes no sense to have a universal policy if it is

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine
Why is it considered such a crazy proposition that domains should have valid and correct whois data associated with them? There is no relationship between data and funcion. The data is not necessary to implement function-based policy. Bah. You're saying that you're uninterested in discussing

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon
on Wed, Jan 12, 2005 at 04:24:42PM +, Eric Brunner-Williams in Portland Maine wrote: (quoting Anonymous): Numerous (as in at least hundreds, probably more) of spam gangs are purchasing domains and burning through them in spam runs. In many cases, there's a pattern to them; in others,

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine
Taking your comment in reverse order. Or, alternately, you're simply saying that those who care about net abuse are shackled by ICANN's bylaws and therefore we can do nothing. I don't think you have a monopoly on care (or clue) about net abuse, but it is pretty clear that you're not tall

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread william(at)elan.net
On Wed, 12 Jan 2005, Steven Champeon wrote: In a sense, I am suggesting a similar reallocation of resources. Rather than put those resources into filtering spam, I'd suggest that we will get a better result by shifting the resources into mail relaying and managing mail peering

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Dave Crocker
On Wed, 12 Jan 2005 17:40:10 -0500, [EMAIL PROTECTED] wrote:    1) any legitimate mail source MUST have valid, functioning, non-generic   rDNS indicating that it is a mail server or source.   And how, exactly, does it indicate it's a mail server or source? In general, that's what dkeys/iim

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Valdis . Kletnieks
On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: On Wed, 12 Jan 2005 17:40:10 -0500, [EMAIL PROTECTED] wrote:    1) any legitimate mail source MUST have valid, functioning, non-generic   rDNS indicating that it is a mail server or source.   And how, exactly, does it indicate it's a

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Suresh Ramasubramanian
On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide. Yes, but he asked for a rDNS solution specifically... I think Steve

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon
on Thu, Jan 13, 2005 at 10:25:18AM +0530, Suresh Ramasubramanian wrote: On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: In general, that's what dkeys/iim and csv (and maybe spf) are attempting to