Re: Fun new policy at AOL

. in an assymetric warfare situation where the good guys follow the above policy and the bad guys do not, it's a slaughter. -- Paul Vixie

Re: Fun new policy at AOL

> That's why we must encourage all ISPSs to be good guys, because we don't > want Government Regulators setting standards in these areas, do we? if recent activity in the VoIP market is any indication, then we here won't have much input as to when and how the ISP market get

Re: Fun new policy at AOL

arge ISPs > don't use the same SMTP servers for incoming as for outgoing.) see below. IndependentPaul Vixie (Ed.) Request for Comments: Category: Experimental June 6, 2002 Repudiating MAIL FROM

Re: On the back of other 'security' posts....

e blackhole lists are good things, since these kids are usually spam victims and almost never spam perps. -- Paul Vixie

Re: On the back of other 'security' posts....

uot;Edge" (or sometimes "customer"), and their security policies are generally, by long standing tradition, inconsistent. the rest of the paper is also germane to this thread. just fya, we keep rehashing the UNimportant part of this argument, and never progressing. (from this, i deduce that we must be humans.) -- Paul Vixie

Re: What do you want your ISP to block today?

as a hobby. the problem microsoft has with software quality that they have no competition, and their marketing people know that ship dates will drive total dollar volume regardless of quality. (when you have competition, you have to worry about quality; when you don't, you don't.) -- Paul Vixie

Re: On the back of other 'security' posts....

end with this as a checklist item in incoming rfp's, it'll see fast deployment even in bankrupt high-inertia "backbone" networks like uunet. -- Paul Vixie

Re: What were we saying about edge filtering?

.81.10.in-addr.arpa. (38) 16:34:47.905254 192.168.128.4.53 > 192.5.5.241.53: 614 PTR? 30.128.168.192.in-addr.arpa. (45) 16:34:47.919143 10.1.0.3.53 > 192.5.5.241.53: 26579 A? www.symantec.com. (34) 16:34:47.926353 10.2.3.39.1030 > 192.5.5.241.53: 12388 SOA? 12.2.10.in-addr.arpa. (38) 16:34:47.981405 172.20.1.1.3436 > 192.5.5.241.53: 8189[|domain] ^C 3205 packets received by filter 0 packets dropped by kernel -- Paul Vixie

bind patch? (Re: What *are* they smoking?)

you should give it another try, since it has gotten faster of late, and so have cpus/memory/motherboards. -- Paul Vixie

Re: News of ISC Developing BIND Patch

, and in some cases root-servers.net. -- Paul Vixie

Re: Root Server Operators (Re: What *are* they smoking?)

accept) it. root server operators (see www.root-servers.org for details) include verisign as one of 11 organzations worldwide. the dot-com and dot-net zones, by comparison, are only served by verisign's own servers, and i do not think that verisign will refuse to accept them. -- Paul Vixie

Re: Not the best solution, but it takes VeriSign out of the loop

don't cooperate. > > I agree that it's a good idea at this point. I see nothing else as a > serious long-term technical solution. sounds like mob rule to me -- count me out. so, block me first, i guess? -- Paul Vixie

Re: Root Server Operators (Re: What *are* they smoking?)

> Anyone have a magic named.conf incantation to counter the verisign > braindamage? zone "com" { type delegation-only; }; zone "net" { type delegation-only; }; > Or does this require a patch to bind? yes, it does. to be released shortly. -- Paul Vixie

Re: News of ISC Developing BIND Patch

> I trust your assessment of the DNS techs. But what about [their] bosses? the ones i've met in recent years seemed like reasonable people. > They ordered some pretty lumpy things be done with .com and .net. > Given that track record, whats to stop them from ordering [the techs] > from doing so

Re: Root Server Operators (Re: What *are* they smoking?)

> Can you also program something to do this for all root zones, > i.e. something like 'zone ".*" { type deligation-only; };' no. not just because that's not how our internal hashing works, but because "hosted" tld's like .museum have had wildcards from day 1 and the registrants there are perfect

Re: Root Server Operators (Re: What *are* they smoking?)

> So, Verisign just returns a NS pointer to another name server Verisign > controls which then answers the queries with Verisign's "helpful" web > site. > > Half-life of the patch: 1 day? i don't think so. verisign is on public record as saying that the reason they implemented the wildcard was

Re: Root Server Operators (Re: What *are* they smoking?)

> Following Internet Standards and to improve performance for all Internet > users, what if Verisign decided to start including other A records > directly in the .COM/.NET zones? > > For example, the A records for the servers for the .COM/.NET zones? funnily enough, that would work fine, since i

Re: Root Server Operators (Re: What *are* they smoking?)

> > : zone "com" { type delegation-only; }; > > : zone "net" { type delegation-only; }; > > My first reaction to this was: 'yuck'. mine also. > I'm not sure of the side-effects this will introduce. Anyone? if verisign served a subdomain of com or net on the same server they use for com or net,

Re: Root Server Operators (Re: What *are* they smoking?)

> Something like this can be seen on www.airow.com: > $ dig www.airow.com @a.gtld-servers.net > ... looks good to me, man. ; <<>> DiG 8.3 <<>> @f.6to4-servers.net www.airow.com a ; (2 servers found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status:

Re: public resolver (was: bind patch? (Re: What *are* they smoking?))

f the f.6to4-servers.net server, and if it's not working for you then please send "dig" results and we'll check it out. (not "host", and probably not to "nanog".) -- Paul Vixie

Re: Change to .com/.net behavior

> I've implemented the official ISC Bind hack on every single one of my > name servers and am pushing it and the configuration changes out to my > customers as a *required* upgrade. that seems a bit extreme. shouldn't they get to decide this for themselves? -- Paul Vixie

BIND 9 (Re: ISC Patches)

re. bind9 is what f-root runs, and also all of our recursive servers, some of which are tru64. try it, you'll like it. > but I would suggest any discussion about that move over to the BIND list > or the USENET gateway comp.protocols.dns.bind. agreed, other than to clear up the above in the same forum where it was heard. -- Paul Vixie

Re: Change to .com/.net behavior

> > ... shouldn't they get to decide this for themselves? > > Returning NXDOMAIN when a domain does not exist is a basic > requirement. Failure to do so creates security problems. It is > reasonable to require your customers to fix known breakage that > creates security problems. that so

Re: Change to .com/.net behavior

> How about rewriting all DNS responses to your liking? :-) > > Like if you ask for www.register.com, you would get the A record for > www.verisign.com ? done. #fh:i386# ping -c 1 www.register.com PING www.register.com (216.21.229.101): 56 data bytes 64 bytes from 216.21

Re: Change to .com/.net behavior

> > i'm not sure how many people inside verisign, us-DoC, and icann agree > > that COM and NET are a public trust, or that verisign is just a caretaker. > > If there's a disagreement on this concept, we have *BIGGER* problems than > just DNS b0rkage. yes. i'm sorry, i thought you knew that. we

Re: Root Server Operators (Re: What *are* they smoking?)

> > i don't think so. verisign is on public record as saying that the > > reason they implemented the wildcard was to enhance the services > > offered to the internet's eyeball population, who has apparently > > been clamouring for this. > > My question is, if this was to serve some need of inte

Re: Root Server Operators (Re: What *are* they smoking?)

but delegations unless it's .museum or a non-root non-tld". i guess the ietf has a lot to think about now. re: > Date: Wed, 17 Sep 2003 09:58:40 -0500 > From: Jack Bates <[EMAIL PROTECTED]> > User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 &

Sven-Haegar Koch: Re: Root Server Operators (Re: What *are* they smoking?)

forwarding as requested. --- Begin Message --- On Thu, 18 Sep 2003, Paul Vixie wrote: *can't post to nanog, feel free to forward it* > actually, i had it convincingly argued to me today that wildcards in root > or top level domains were likely to be security problems, and that dom

bind patches++ (Re: Wildcards)

w running this if you want to try before you, um, buy. thanks very much to the membership of the bind forum who make this possible. -- Paul Vixie

Re: bind patches++ (Re: Wildcards)

t, 20 Sep 2003 14:22:57 -0400 (EDT) > From: "Mr. James W. Laferriere" <[EMAIL PROTECTED]> > To: Paul Vixie <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: bind patches++ (Re: Wildcards) > > Hello Paul , Am I correct in the understanding th

Re: VeriSign SMTP reject server updated

or the > list; I will summarize the former. i chose to send this to the list since some folks have been wondering if i'm a verisign apologist lately and i believe that open debate is better for this kind of thing. -- Paul Vixie

Re: VeriSign SMTP reject server updated

> Is it possible for the client resolver code to distinguish between a > wildcard answer and an explicit answer? no. > If this was available, it would mail clients and other things > interested in the specific domain name could get the answers they > want. While other stuff would get the wildca

Re: When is Verisign's registry contract up for renewal

llow for in terms of requirements for open accounting, uniform dealing, and nonconflict with the public's interest. -- Paul Vixie

Re: Appreciation for Bind patches

> I have been following the various threads relating to Verisign and wanted > to make one comment that I feel has been missing. Simply put, I would like > to publicly express my appreciation to Mr. Vixie for taking the time to add > the "root-delegation-only" patch for Bind. I'm fairly new to NA

Re: When is Verisign's registry contract up for renewal

rse than anything else on the table or in existence today. -- Paul Vixie

Re: When is Verisign's registry contract up for renewal

> > > website: www.alt-servers.org. > > > > what a BAD idea. worse than anything else on the table or in > > existence today. > > Splitting the root you mean? I'm not sure there was enough info on that > site to come to any other conclusion, but I wanted to make sure. this is just dns piracy, d

Re: Verisign Responds

n with security and stability. and it does seem rather urgent that if a wildcard in the root domain or in a top level domain is dangerous and bad, that the ietf say so out loud so that icann has a respected external reference to include in their contracts. -- Paul Vixie

Re: bind 9.2.3rc3 successful

Are others having similar luck? What needs to be done to make this a > standard feature set? Is somebody working on an RFC? i do not expect the ietf to say that root and tld zones should all be delegation-only. but good luck trying. -- Paul Vixie

Re: Verisign Responds

> ... > We recommend that any and all TLDs which use wildcards in a manner > inconsistent with this guideline remove such wildcards at the earliest > opportunity." > > What else does the IETF need to do here? issue an rfc. iab is not a representative body, and their opinions are not "refereed."

Re: bind 9.2.3rc3 successful

> Now all I need is a patched version of the 9.3 snapshot tree, so I > don't need to kill my dnssec stuff :P (And it's time for a > non-snapshot bind version with full dnssec capabilities anyway :) if you ask that question on [EMAIL PROTECTED], i promise to answer. but i do not think details of t

Re: bind patches++ (Re: Wildcards)

> Hello Paul , All , Is there a url listing the TLD's that > officially use wild cards in their deployment ? nope. right now you just have to know. we're trying to keep a list of places that either use wildcards and have been accepted by the community, or don't use wildcards but ru

Re: Verisign Responds

> I wonder btw why Verisign didn't catch the "typo's" in their > own domains if they think it is that important: > ... > ;; QUESTION SECTION: > ;.verisign.com. IN A wildcards don't work that way. there are ns rr's in .com for verisign.com, so you get a referral to those serv

Re: [Fwd: monkeys.dom UPL DNSBL being DDOSed to death]

[EMAIL PROTECTED] (Matthew Sullivan) writes: > ... That leave 2 proxy DNSbls left - SORBS and DSBL... well, and, there's the MAPS OPL, which is also part of the RBL+. (just 'cuz i'm not operationally involved with maps doesn't mean i stopped subscribing.) -- Paul Vixie

Re: Verisign Responds

hat can be changed every day or even loadbalanced through four /16's that may have real hosts in them seems like the wrong way forward. -- Paul Vixie

Re: Verisign Responds

> See the NANOG archives for my post reguarding wildcard caching and set > comparison with additional resolver functionality for requesting if the > resolver wishes to receive wildcards or NXDOMAIN. oh... that wasn't a joke, then? there won't be a protocol change of that kind, not in a million y

Re: Verisign Responds

e it to namedroppers, but before you do, please read rfc's 1033, 1034, 1035, 2136, 2181, and 2317. -- Paul Vixie

Re: New CA Law

the point of the story. but like most threads on nanog this week, this one is offtopic. -- Paul Vixie

workaround published for BIND8 and delegation-only

so far, the BIND8 code itself has been resistant to this feature, but... see the current http://www.isc.org/products/BIND/delegation-only.html page.

Re: A list of (mostly) technical consequences of TLD wildcards

carding rules. see [4.3.2]. What this means is, there is no such thing as a wildcard CNAME. -- Paul Vixie

Re: A list of (mostly) technical consequences of TLD wildcards

> > What this means is, there is no such thing as a wildcard CNAME. > > Funny... > > $ host -t cname \*.TD > *.TD is an alias for www.nic.TD. just because bind does it doesn't make it a standard. -- Paul Vixie

someone from attbi please contact me regarding host 24.129.84.175

noc@ and abuse@ are ignoring me as usual, so i'm spamming nanog@ in hopes of locating attbi clue. i need somebody who can educate one of your customers who is dns-updating me. re: [fh:i386] grep -c 'client 24.129.84.175.*update.*denied' messages 74 [fh:i386] zgrep -c 'client 24.129.84.175.*upda

Re: Annoying dynamic DNS updates (was Re: someone from attbi please

nd today. They will at least talk about their role in the situation, so they're more responsible than Comcast this week. -- Paul Vixie

Re: Annoying dynamic DNS updates (was Re: someone from attbi please contact me ...)

or message popups telling them to go to MSN and buy a real domain name. That is, they could be making money here rather than just giving my syslogd a headache. If MSFT would behave more greedily then their customer PCs would be contacting them rather than me, right? -- Paul Vixie

Re: ISPs blocking port 53? (was Re: Annoying dynamic DNS updates)

> How should an ISP tell the difference between "good" DNS packets and "bad" > DNS packets? the bad ones are the ones people complain about. > You aren't complaining about your dynamic update packets or even all > dynamic updates. You are complaining about someone sending you packets > you don't

Re: ISPs blocking port 53? (was Re: Annoying dynamic DNS updates)

> > the whole end-to-end argument depends on uniform clue distribution > > for scale. > ... > Getting vendors to supply more appropriate defaults offers better > scaling possibilities. Your complaint might fix one user's computer, > Microsoft updating the default behaivor would fix tens of millio

Re: Unauthorized DNS updates

> Is there a way to configure bind so that when an **unauthorized** update > comes in it enstates an address of the owner's choice? well, i'm thinking of setting up a wildcard A RR pointing at 127.255.255.255. -- Paul Vixie

Re: ISPs blocking port 53? (was Re: Annoying dynamic DNS updates)

> whats disturbing is how many contact addresses for both whois and AS#'s > bounce sure, i agree, that's disturbing. however, it's a different problem than having mail get ignored or ignorebotted and then depref'd so low that nobody even bothers to call you or let you know whether a human ever

Re: ISPs blocking port 53? (was Re: Annoying dynamic DNS updates)

> ... probably most of the Abuse issues (especially via email) would > continue to be ignored. Noone wants to handle that stuff. But > someone(s) must handle that stuff. the underlying question is, "or else what?" this is an assymetric-benefit situation. when folks ignore reports from noncustom

Re: Will reverting DNS wildcard have any adverse affects?

> well, thats up to the zone admin. :) > my concern is mostly along the lines of folks who will do things like: > > zone "waw.pl" { type delegation-only; }; > > to random zones that they think -SHOULD- be delegation-only, regardless > of what the zone admin specifies. "and remember, kids, all power tools can kill." -- Paul Vixie

Re: Will reverting DNS wildcard have any adverse affects?

ions already. Four revisions in the first two days, none since. -- Paul Vixie

i'm missing my copy of "why a wildcard MX won't help sitefinder"

x27;t find it now. can someone privately send it to me if you've got it? -- Paul Vixie

i'd like to know your opinions on the com/net wildcard issue

see http://sa.vix.com/~vixie/comnetsurv/ this is not an icann thing btw, it's just me.

Re: i'd like to know your opinions on the com/net wildcard issue

> > see http://sa.vix.com/~vixie/comnetsurv/ > > An incentive to take the survey: If you fill it out, it'll tell you the > aggregated results so far, which are, lemme tell you, pretty surprising. > Who knew that NANOG subscribers would anonymously admit they were > clueless? :-) that's jus

Re: [Fwd: [IP] VeriSign to revive redirect service]

lication. Popular browsers have already started ... i think i agree with where this was going, but it would be a fine thing if we all stop calling this NXDOMAIN. the proper term is RCODE 3. when you say NXDOMAIN you sound like you've only read the BIND sources and not the RFC's. NXDOMAIN is a BINDism, whereas RCODE 3 refers to the actual protocol element. -- Paul Vixie

Re: [Fwd: [IP] VeriSign to revive redirect service]

the early patches to bind8 and djbdns that i saw were dependent on the sitefinder address, and as such, would have enabled nameserver administrators to break _sitefinder_. isc's patches for bind9 enable nameserver administrators to break only the _redirection_ to sitefinder. -- Paul Vixie

Re: False information: CEO of Versign facts are wrong

and then acted as if this investment had been solely for the benefit of their a-root and j-root servers, which is not the case at all. all in all a most disappointing exposition. -- Paul Vixie

Re: False information: CEO of Versign facts are wrong

nominum was doing it. sorry rodney. sloppy editing. -- Paul Vixie

sclavos interview (Re: data request on Sitefinder)

"root server operators" it really should say "name server operators", like http://oarc.isc.org/ does. but the reporter really "got it right" on everything else. -- Paul Vixie

opinions on the com/net wildcard issue

my survey is over. see http://sa.vix.com/~vixie/comnetsurv/ for the results.

Re: 'Net security gets root-level boost

parently, testing is a way of life. (sadly for me personally, they didn't give dates or times that these tests had been run, nor did they say they would preannounce future tests, so nobody but verisign will be able to synchronize other measurements with these tests.) -- Paul Vixie

Re: Portscans/PROXY scans

ystem needs *more* resources, not fewer. -- Paul Vixie

Re: Portscans/PROXY scans

h, and then they'll (surprise!) call and complain about it. funny assymetry. anyway, when they call, and they learn that it was a legit port scan, then they can learn of the need to shut down wormridden customer hosts. so no matter what, it's good to listen to complaints, and good to complain. -- Paul Vixie

Re: The Internet's Immune System

des. if you're feeling holier than thou for any reason, find out if your peering agreements require your peers to permanently disconnect repeat abuse sources, and to temporarily disconnect first time abuse sources. assuming that $YOU do these things, but that $YOUR_PEERS do not, then what have you really accomplished? -- Paul Vixie

Re: looking for pull traffic

wers have decided our 95/5 traffic slit needs to move closer to > 60/40 (transit pricing). > > I'm looking for legitimate ways to generate a significant amount of pull > traffic, including partnerships with Southern California ISPs. > > Thanks. -- Paul Vixie

Re: looking for pull traffic

> Ahh, but are you saying that current blow-based transit pricing is stable? ah. no. current transit pricing is way way lower than a non-bankrupt provider can afford to do it for on an ROI that the public markets would find worthy of their praise. eventually, all kinds of flies are going to hi

Re: RBLs in use

and then there's the granddaddy of them all, MAPS. see www.mail-abuse.org. -- Paul Vixie

Re: incorrect spam setups cause spool messes on forwarders

is either a spammer or the output side of a proxy (which might be hard to detect). so it turns out that ignoring 5XX is like sending up a flare, "blackhole me!". -- Paul Vixie

Re: incorrect spam setups cause spool messes on forwarders

themselves, and the overall system. consider what would happen if everybody did callbacks; first, what would happen to the load on the world's nonabusing mail servers, and then, what would the spammers do in response if this was effective? -- Paul Vixie

Re: Root Authority

) that having been said, f-root got its start as NS.ISC.ORG and the man who said it was ok for us to be a root name server was jon postel. i'm not sure he had any "authority" either, but folks "pointed at" him and so what he said was relevant in spite of any authority he mightn've had. -- Paul Vixie

Re: Extreme spam testing

e-mail | transport, and thus ought to have the strongest voice in | what's sent (or not) to them. Besides which, such an argu- | ment presumes that there's a piece of mail that a sender | isn't certain was solicited. Our advice is: don't send it | then!. (note, i coauthored both the book and the referenced website.) -- Paul Vixie

a note to those who would automate their rejection notices

today AOL thoughtfully supplied the following to [EMAIL PROTECTED]: [EMAIL PROTECTED] SMTP error from remote mailer after initial connection: host mailin-02.mx.aol.com [64.12.137.89]: 554-(RLY:B1) The information presently available to AOL indicates this 554-server is generatin

Re: a note to those who would automate their rejection notices

> pv> of the foundational principles which made the internet > pv> possible and which made it different from alternatives such as > pv> OSI, very few remain. > > Would SPF be a bit less destructive than many > other proposals to counter "trivial forgery". No.

Re: Upcoming change to SOA values in .com and .net zones

isign would have had to coordinate a change like this according to the rules of DNS, implementation-specific rules of BIND and whatever else was running then, and the group's coordination and monitoring rules. those days are gone. verisign isn't doing anything wrong in this change, and it's probably going to work out just fine. -- Paul Vixie

Re: What's the best way to wiretap a network?

versions, plus combos. i'm fairly sure that this is what law enforcement uses for wiretap warrants. -- Paul Vixie

Re: sniffer/promisc detector

ell-known script-based attack a very remote possibility. that's just not so. ask me about it in person and i might tell you stories. > For most other people a trivial packet-filtering firewall, lack of > Windoze, and a switch instead of a hub will do just fine. this part, i agree with. -- Paul Vixie

Re: Nachi/Welchia Aftermath

using one in commerce or production gives me cold shivers.) -- Paul Vixie

Re: Nachi/Welchia Aftermath

> > more generally... "if you want routing, buy a router." > > amen. > imho there can't be a better routing equipment than a real router :) i guess i need to explain in more detail. keep in mind that i'm technophobic and that when VLANs first appeared i was convinced that the end of

Re: Outbound Route Optimization

toward you. (experience says they're not going to trust your MEDs even if they're close enough to hear them.) -- Paul Vixie

Re: Outbound Route Optimization

> > ... depends on your isp, and whether their routing policies (openness > > or closedness of peering, shortest vs. longest exit, respect for MEDs) > > are a good match for their technology/tools, skills/experience, and > > resources/headroom. > > In practice, all of the above just turn out to b

in case nobody else noticed it, there was a mail worm released today

my copies (500 or so, before i filtered) are in a ~7MB gzip'd mailbox file called http://sa.vix.com/~vixie/mailworm.mbox.gz (plz don't fetch that unless you need it for comparison or analysis). there's a high degree of splay in the smtp/tcp peer address, and the sender is prepared to try backup M

here are some postfix patterns i found useful today

what you do is, install postfix 2.0 or later, set header_checks to some filename (in your main.cf), and in that file, you put the following: /^Subject: Anti-Virus Notification/ REJECT av01 /^Subject: BANNED FILENAME/ REJECT av02 /^Subject: File blocked - ScanMail f

Re: Unbelievable Spam.

ood and bad intent, good and bad providers, etc. the spam/antispam battleground is all just mud now. -- Paul Vixie

Re: here are some postfix patterns i found useful today

several of you thanked me privately for the earlier post on this thread, and in the time since then i have been inundated with even more variations of antivirus messages, so i'm posting an update. the bad news is, you have to use body checks as well as header checks. the good news is, i don't th

Re: question on ptr rr

he tipping point went by a while ago, and that anyone who wants their e-mail to be accepted will make sure their mail relay has a PTR and that that this PTR holds the same name used in the SMTP HELO command. -- Paul Vixie

Re: question on ptr rr

>> I've run all my mailers with aggressive PTR checks for about a year, and >> while some of my guests aren't getting all the e-mail that's sent to them, >> it's had no impact on me other than that periodically I have to tell some >> remote postmaster that their PTR's are missing or that they don'

Re: question on ptr rr

ose AOL, MNN, Yahoo, etc agree to accept mail from each other and not > from other people. This is pretty much how the world worked from > 1980-1990. CompuServe, MCIMail, The Source, Delphi, etc. fine by me. the people i want to exchange mail with aren't AOL users anyway. -- Paul Vixie

Re: Dumb users spread viruses

a user who thinks they should not have to know how to protect their computer from virus infections. If we (the community who provides them service and software) can't make it safe-by-default, then the problem rests with us, not with the end users. -- Paul Vixie

Re: question on ptr rr

> >I think the tipping point went by a while ago, and that anyone who wants > >their e-mail to be accepted will make sure their mail relay has a PTR and > >that that this PTR holds the same name used in the SMTP HELO command. > > Of course, not all that long ago AT&T Worldnet got crucified -- on

Re: Dumb users spread viruses

> Uneducated users should live with the slowness. It's protecting the rest of > the world from their blissful ignorance. if it protected them or anybody else i'd say you were right, but since it's a pattern matcher it always takes 2 to 24 hours for a new pattern file to be developed and distribu

Re: question on ptr rr

enting a set of well-known and consistent controls. ...is not practical. Remember the true street-level definition of spam: "spam is e-mail you didn't want that wasn't sent by me or my customers." Trying to form an E-S-C under those conditions is unthinkable or useless. -- Paul Vixie

<    1   2   3   4   5   6   7   8   9   >