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

>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 oth

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

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 c

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

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 PROTE

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

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

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

> 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 . If you are thinking about RFC 3363,

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

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 > ht

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

> > 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 . yes, and ISC-TN-2002-1 (see www.isc.org/pubs/tn/)

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

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]

> 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]

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? Non

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

> 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]

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

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

> 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. Well someone has to stand up for the small shops. Size

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

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 (dra

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

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 "

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

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

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 "anonym

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 databas

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

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. (

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

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 kn

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

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

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

> 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

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 hav

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

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. > >

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

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

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

> 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 dat

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

> 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 whistle

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

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 recipien

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

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, a

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

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

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

> 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 regi

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

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 > scoped-to-

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

> 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 answer the question. > If you care about the domain, keep the whois data up to date and accur

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

> 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 t

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

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 use

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

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)

> 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 r

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

> 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 a

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

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 i

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

> 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 discussi

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

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; i

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

On Wed, 12 Jan 2005 10:59:43 EST, Steven Champeon said: > 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? For that matter, how do you define 'non-gene

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

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 e

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

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 ag

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

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

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

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 indicat

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

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

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

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 > >

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

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 attempti

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

>> 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 u

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

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! http:/