Re: antivirus in smtp, good or bad?

> "Suresh" == Suresh Ramasubramanian <[EMAIL PROTECTED]> writes: Suresh> exim -bpru|grep frozen|awk {'print $3'}|xargs exim -Mr Woops. missed a "m" at the end. # exim -bpru|grep frozen|awk {'print $3'}|xargs exim -Mrm srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEF

Re: Unbelievable Spam.

> "Michael" == Michael Dillon <[EMAIL PROTECTED]> writes: Michael> When will we realize that SPAM is a social problem and it Michael> needs a social solution? When will the major email Michael> providers sit down around a table and agree to some Michael> guidelines for email e

Re: Latest IE patch breaking non username:password@encoded websites?

On Tue, 3 Feb 2004, Alexei Roudnev wrote: > So, instead of changing 'visialization' part of IE, MS give up and decided > to drop important piece of standard? Placing the username and password in a URL has been deprecated for HTTP. From RFC 2616: 3.2.2 http URL The "http" scheme i

Re: antivirus in smtp, good or bad?

Stephen J. Wilcox wrote: Hi, When investigating our mail queue it seems we have quite a lot of mails which are stuck in transit... Whats happening is we're accepting the mail as the primary MX for the domain but the user has setup a forwarding to another account at another ISP, they have antivir

Re: Latest IE patch breaking non username:password@encoded websites?

So, instead of changing 'visialization' part of IE, MS give up and decided to drop important piece of standard? Ok, you can always show HOST name in URL, dim user name, and position location so that you can see real host. You can show a warning, if user name looks like real domain name (have . in

Re: Latest IE patch breaking non username:password@encoded websites?

I rather treat this patch as a _bug_. user:[EMAIL PROTECTED] format is used (I have 3 or 4 instances in monitoring system, to allow automatic proxy onto the system with 'guest' user name, for example). To block scam, it was sufficient to restrict username length, or to set up a checkbox in explor

Re: Strange public traceroutes return private RFC1918 addresses

On Tue, Feb 03, 2004 at 11:02:16AM -0500, Leo Bicknell wrote: > While the rate of request is still very low, I would say we get > more and more requests for jumbo frames everyday. The pressing > application today is "larger" frames; that is don't think two hosts > talking 9000 MTU frames to each

Re: Poor connectivity to new b.root-servers.net address?

> Hi! > > > > Hope this helps, its broken somewhere at the end for sure. > > > > > > Bye, > > > Raymond. > > > > > no, it doesn't. please provide the origin IP address that > > the trace was initiated from. > > I submitted all the ASes but ok, here we go: > > Not ok: AS8341 -> 213.

Re: Poor connectivity to new b.root-servers.net address?

Hi! > > Hope this helps, its broken somewhere at the end for sure. > > > > Bye, > > Raymond. > > >no, it doesn't. please provide the origin IP address that > the trace was initiated from. I submitted all the ASes but ok, here we go: Not ok: AS8341 -> 213.73.255.243 Not ok: AS2

Re: Strange public traceroutes return private RFC1918 addresses

> From: "Terry Baranski" <[EMAIL PROTECTED]> > Date: Tue, 3 Feb 2004 16:42:55 -0600 > Sender: [EMAIL PROTECTED] > > > Leo Bicknell wrote: > > > Since most POS is 4470, adding a jumbo frame GigE edge makes > > this application work much more efficiently, even if it doesn't > > enable jumbo (9k)

Re: Poor connectivity to new b.root-servers.net address?

> 16 67.30.130.66 (67.30.130.66) 151.593 ms 150.796 ms 150.023 ms > 17 130.152.181.66 (130.152.181.66) 150.680 ms 152.805 ms 151.527 ms > 18 b.root-servers.net (192.228.79.201) 157.921 ms 151.542 ms 157.816 ms > > Hope this helps, its broken somewhere at the end for sure. > > Bye, >

Re: Poor connectivity to new b.root-servers.net address?

> On Wed, 4 Feb 2004, Erik-Jan Bos wrote: > > > Looks OK from SURFnet (AS1103) through Level3: > > > > [...] > > Hm - both through 3561 (CW) and 3549 (GBLX) in Europe (tracing from > source-IP's on our border routers from the respective providers' > netblocks, and our own IP's), we have no conne

Re: Poor connectivity to new b.root-servers.net address?

Hi! > > Still we have enough root servers to be going on with while it is fixed, > > lets just hope no one hijacked it. > > Looks OK from SURFnet (AS1103) through Level3: Also some other traces, 2 broken, 1 ok: > [...] > 13 so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 165.036 ms 165.507

Re: Poor connectivity to new b.root-servers.net address?

On Wed, 4 Feb 2004, Erik-Jan Bos wrote: > Looks OK from SURFnet (AS1103) through Level3: > > [...] Hm - both through 3561 (CW) and 3549 (GBLX) in Europe (tracing from source-IP's on our border routers from the respective providers' netblocks, and our own IP's), we have no connectivity. Both path

Re[2]: B.root-servers renumbering

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Daniel, Friday, January 30, 2004, 9:51:24 AM, you wrote: DK> On Jan 30, 2004, at 4:26 AM, John L Crain wrote: DK> >> New Hints files can be found at: >> >> ftp://rs.internic.net/domain/db.cache >> ftp://rs.internic.net/domain/named.cache

Re: Poor connectivity to new b.root-servers.net address?

Simon Waters wrote: NANOG Digest wrote: 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 178.710 ms 178.529 ms 178.500 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 177.340 ms 177.246 ms 177.298 ms 16 * * * I see something similar to this coming out of Level3 from Demon's directi

Re: Poor connectivity to new b.root-servers.net address?

NANOG Digest wrote: > > 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 178.710 ms 178.529 ms > 178.500 ms > 14 * * * > 15 130.152.181.66 (130.152.181.66) 177.340 ms 177.246 ms 177.298 ms > 16 * * * I see something similar to this coming out of Level3 from Demon's direction. The w

RE: Strange public traceroutes return private RFC1918 addresses

Leo Bicknell wrote: > Since most POS is 4470, adding a jumbo frame GigE edge makes > this application work much more efficiently, even if it doesn't > enable jumbo (9k) frames end to end. The interesting thing > here is it means there absolutely is a PMTU issue, a 9K edge > with a 4470 core.

Re: antivirus in smtp, good or bad?

At 06:16 AM 2/3/2004, Daniel Senie wrote: Many viruses (most of the recent ones) forge the sender information. It seems to me that this can be replaced with "Today's viruses almost invariably forge the sender information." and that it no longer makes any sense whatsoever to send a virus alert not

RE: Poor connectivity to new b.root-servers.net address?

I've read about similar requests on Frnog, the french equivalent of Nanog. They've been having issues since the ip change. -e ---Snip--- Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote a message of 65 lines which said: > Comme vous le savez, B.root-servers.net a changé d'adresse IP cette > nu

Re: Poor connectivity to new b.root-servers.net address?

the problem seems to be in the level3/cenic/losnettos path. juniper -ge- gsr -ge- foundary -ge- foundary -ge- foundary -100m- 7513 the IP path is: juniper - 7513 more as we unearth the problems... > > > I have two sites (in AS 2116 and 3307) here in Norway which canno

Re: Unbelievable Spam.

On Tue, 03 Feb 2004 13:31:28 PST, "Tom (UnitedLayer)" <[EMAIL PROTECTED]> said: > > They are smart criminal gangs which have not only managed to keep their > > schemes running for several years in the face of great public animosity, > > they have also managed to sabotage the efforts that supposed

Poor connectivity to new b.root-servers.net address?

I have two sites (in AS 2116 and 3307) here in Norway which cannot reach the new b.root-servers.net address, 192.228.79.201. No answers to DNS requests, no ping replies, traceroute times out. Everything works normally from a third site, in AS 224. Both prefixes (193.71.0.0/16 and 194.19.0.0/17) o

Re: Unbelievable Spam.

On Tue, 3 Feb 2004 [EMAIL PROTECTED] wrote: > Spammers are not stupid. I would suggest a statement of "All spammers are not stupid" instead of the above. Some spammers are quite dumb/naive, some are middle of the road, some are very smart and organized. Just like any other profession, there is al

Re: Strange public traceroutes return private RFC1918 addresses

Leo Bicknell wrote: Google and Akamai are just two examples of companies with hundreds of thousands of machines where they move large amounts of data between them and have control of both ends. Many corporations are now moving off-site backup data over the Internet, in large volumes between two e

Re: Strange public traceroutes return private RFC1918 addresses

On Tue, 3 Feb 2004, Petri Helenius wrote: > Stephen J. Wilcox wrote: > > >>Why large MTU then? Most modern ethernet controllers don´t care if you´re > >>sending 1500 or 9000 byte packets. (with proper drivers taking advantage of > >>the features there) If you´re paying for 40 byte packets anyway

Re: Strange public traceroutes return private RFC1918 addresses

In a message written on Tue, Feb 03, 2004 at 09:53:30PM +0200, Petri Helenius wrote: > Sure, if you control both endpoints. If you don´t and receivers have > small (4k,8k or 16k) window > sizes, your performance will suffer. > > Maybe we should define if we´re talking about record breaking attemp

Re: Strange public traceroutes return private RFC1918 addresses

Niels Bakker wrote: Just like the extra chopping up of the data you want to send into more packets, it's things you have to do a few extra times. That takes time. There is no way around this. What Leo wrote is in no way wrong. Maybe we need to define what the expression "huge difference"

Re: Strange public traceroutes return private RFC1918 addresses

Stephen J. Wilcox wrote: Why large MTU then? Most modern ethernet controllers don´t care if you´re sending 1500 or 9000 byte packets. (with proper drivers taking advantage of the features there) If you´re paying for 40 byte packets anyway, there is no incentive to ever go beyond 1500 byte MTU.

Re: Strange public traceroutes return private RFC1918 addresses

> Leo Bicknell wrote: >> because at the higher data rates (eg 40 gige) it makes a huge difference >> in host usage. You can fit 6 times in the data in a 9K packet that you >> can in a 1500 byte packet, which means 1/6th the interrupts, DMA >> transfers, ACL checks, etc, etc, etc. * [EMAIL PROTECT

RE: Latest IE patch breaking non username:password@encoded websites?

Sorry - Mostly non-password encoded forms that don't refresh when you hit submit. After Submitting 3 or 4 times they seem to work. Like most ISP's, we take calls when somebody's web site doesn't work, even if we don't even host it. On Tue, 2004-02-03 at 12:24, Conrad Golightly wrote: > Can yo

Re: antivirus in smtp, good or bad?

> I think we have all agreed in previous threads that if a mail anti virus > scanner does not know how to differentiate between a virus that spoofs > the sender and one that doesnt, it should silently discard all virus > infected email -- OR notify the local administrator/user at their > choos

Re: Strange public traceroutes return private RFC1918 addresses

> Why large MTU then? Most modern ethernet controllers don´t care if you´re > sending 1500 or 9000 byte packets. (with proper drivers taking advantage of > the features there) If you´re paying for 40 byte packets anyway, there is no > incentive to ever go beyond 1500 byte MTU. I think its partial

Re: Strange public traceroutes return private RFC1918 addresses

In a message written on Tue, Feb 03, 2004 at 08:40:22PM +0200, Petri Helenius wrote: > If you're paying for 40 byte packets anyway, there is no incentive to > ever go beyond 1500 With a 20 byte IP header: A 40 byte packet is 50% data. A 1500 byte packet is 98.7% data. A 9000 byte packet is 99.

Re: Strange public traceroutes return private RFC1918 addresses

bill wrote: got me... although I could fabricate a rational. 40 byte packets @ 40Gig is a wonder to contemplate. the whole ATM argument (53byte "cells" over 100Meg) being an egregious overhead expense for segmentation/ reassembly is amplified here. There are more cell-based fixed access

Re: Strange public traceroutes return private RFC1918 addresses

Leo Bicknell wrote: because at the higher data rates (eg 40 gige) it makes a huge difference in host usage. You can fit 6 times in the data in a 9K packet that you can in a 1500 byte packet, which means 1/6th the interrupts, DMA transfers, ACL checks, etc, etc, etc. This is wrong. Interrupt mo

Re: Strange public traceroutes return private RFC1918 addresses

Niels Bakker wrote: * [EMAIL PROTECTED] (Petri Helenius) [Tue 03 Feb 2004, 15:42 CET]: Me wonders why people ask for 40 byte packets at linerate if the mtu is supposedly larger? Support for the worst-case scenario. Same why you spec support for a BIGINT-line ACL without excessive impact o

Re: Latest IE patch breaking non username:password@encoded websites?

On Tue, 3 Feb 2004, Jeff Workman wrote: > My guess is that too many people were getting burned by URLs like this: > > http://[EMAIL PROTECTED] > > -Jeff Right but the bug wasn't basic auth in a URL it was that the %01 character stopped Outlook and IE from displaying the rest of the URL, so http:

RE: Latest IE patch breaking non username:password@encoded websites?

> Yes they broke basic auth in a URL. > > I am uncertain as to why it was necessary to remove this functionality. > > Bryan Apparently, there were ways to use this to make one URL look like the URL of another site. According to Microsoft, it isn't just '[EMAIL PROTECTED]/foo', but there

Re: Latest IE patch breaking non username:password@encoded websites?

--On Tuesday, February 03, 2004 11:34 AM -0600 Bryan Heitman <[EMAIL PROTECTED]> wrote: Yes they broke basic auth in a URL. I am uncertain as to why it was necessary to remove this functionality. My guess is that too many people were getting burned by URLs like this: http://[EMAIL PROTECTED]

Re: Latest IE patch breaking non username:password@encoded websites?

Herman Harless [2/3/2004 10:56 PM] : We're starting to take complaints from folks who have installed the latest IE patch about various broken website functionality. The complaints are not related to folks trying to use the username:password@ functionality that was removed by the patch. Is anyone

Re: [OT] Need Comcast Contact

> Well sure, they are sent on a date that doesn't exist. Feb 31 can never > happen. Pardon, that should have read Sunday, Feb 01 2004 AD (Chinese year of the monkey). =] -- Tim Wesemann Voicenet Systems Administration

Re: Latest IE patch breaking non username:password@encoded websites?

Yes they broke basic auth in a URL. I am uncertain as to why it was necessary to remove this functionality. Bryan - Original Message - From: "Herman Harless" <[EMAIL PROTECTED]> To: "nanog" <[EMAIL PROTECTED]> Sent: Tuesday, February 03, 2004 11:26 AM Subject: Latest IE patch breaking n

RE: Latest IE patch breaking non username:password@encoded websites?

Yes. From MS: (a registry-based fix is detailed in the KB article) This Internet Explorer cumulative update also includes a change to the functionality of a Basic Authentication feature in Internet Explorer. The update removes support for handling user names and passwords in HTTP and HTTP with

does your ISP need more peering?

A nationwide ISP I work with has decided to switch to all-transit, no-peering. They are interested in finding someone to buy or take over: an AS number, routers (and in some cases rack space) at MAE ATM East, PAIX Virginia, NYIIX, AADS NAP, MAE ATM West, and PAIX Palo Alto, along with the existi

[OT] Need Comcast Contact

Emails sent *from residential comcast subscribers* to any '@voicenet.com' address have been disappearing in the Comcast network since Sunday, Feb 31. There are no bounces or errors of any kind. Mail sent directly to other domains with the same MX record and even to individual machines within the M

Latest IE patch breaking non username:password@encoded websites?

We're starting to take complaints from folks who have installed the latest IE patch about various broken website functionality. The complaints are not related to folks trying to use the username:password@ functionality that was removed by the patch. Is anyone taking similar calls / seeing simila

Re: antivirus in smtp, good or bad?

Daniel Senie wrote: At 10:13 AM 2/3/2004, Joe Maimon wrote: Daniel Senie wrote: At 08:58 AM 2/3/2004, you wrote: Why must systems accept mail that's virus laden or otherwise not desired at a site? The "bounce" you refer to invariably ends up going to the wrong person(s), so that's an

Re: Unbelievable Spam.

Hi, ...on Tue, Feb 03, 2004 at 10:31:00AM +, [EMAIL PROTECTED] wrote: > When will we realize that SPAM is a social problem and it > needs a social solution? I agree insofar as a solution is needed that helps making the criminals accountable. But then, the low barriers are probably the m

Re: antivirus in smtp, good or bad?

At 10:13 AM 2/3/2004, Joe Maimon wrote: Daniel Senie wrote: At 08:58 AM 2/3/2004, you wrote: Why must systems accept mail that's virus laden or otherwise not desired at a site? The "bounce" you refer to invariably ends up going to the wrong person(s), so that's an exceptionally BAD idea. M

Re: Strange public traceroutes return private RFC1918 addresses

* [EMAIL PROTECTED] (Petri Helenius) [Tue 03 Feb 2004, 15:42 CET]: > Me wonders why people ask for 40 byte packets at linerate if the mtu > is supposedly larger? Support for the worst-case scenario. Same why you spec support for a BIGINT-line ACL without excessive impact on forwarding capacity.

Re: Strange public traceroutes return private RFC1918 addresses

In a message written on Tue, Feb 03, 2004 at 08:15:13AM -0600, Terry Baranski wrote: > The performance gain achieved by using jumbo frames outside of very > specific LAN scenarios is highly questionable, and they're still not > standardized. Are "jumbo" Internet MTUs seen as a pressing issue by >

Re: Unbelievable Spam.

On Tue, Feb 03, 2004 at 10:31:00AM +, [EMAIL PROTECTED] wrote: > > inject large volumes of email into the system? The existing > non-hierarchical email exchange network is not scalable. > I hope that everyone on this list can understand what the > email exchange overlay network is and recogni

Re: antivirus in smtp, good or bad?

Joe Maimon [2/3/2004 9:19 PM] : What I was really trying to say is that it is far from a simple topic. yup, and if someone has a simple solution to this problem they are probably wrong (paraphrasing what [i think] Dave Crocker told me some months back when we met at ISPCON) -- srs (postmaster

Re: antivirus in smtp, good or bad?

Suresh Ramasubramanian wrote: Joe Maimon [2/3/2004 8:43 PM] : What you are saying is that every mailhost on the Internet should run up to date and efficient virus scanning? Pattern matching and header filtering? Should the executable attachmant become outlawed on the Internet? Recognize whe

Re: Unbelievable Spam.

Spam is VERY EFFECTIVE. It _really_ increase sales. People (yes, and me too -:)) read SPAM and sometimes find interesting things. (Example - yopu can hate spam, but if you call Europe every day, and you see $.03/minute adv for long distance, you will remember it). Problem is, that spam is not sel

Re: Strange public traceroutes return private RFC1918 addresses

On Tue, 03 Feb 2004 06:39:33 PST, Joel Jaeggli said: > edge networks that are currently jumbo enabled for the most part do just > fine when talking to the rest of the internet since they can do path mtu > discovery... Well, until you hit one of these transit providers that uses 1918 addresses fo

Re: antivirus in smtp, good or bad?

Joe Maimon [2/3/2004 8:43 PM] : What you are saying is that every mailhost on the Internet should run up to date and efficient virus scanning? Pattern matching and header filtering? Should the executable attachmant become outlawed on the Internet? Recognize when a "to be bounced email" is a sp

Re: Strange public traceroutes return private RFC1918 addresses

[EMAIL PROTECTED] wrote: If RFC1918 addresses are used only on interfaces with jumbo MTUs on the order of 9000 bytes then it doesn't break PMTUD in a 1500 byte Ethernet world. And it doesn't break traceroute. We just lose the DNS hint about the router location. I'm confused about your tracerout

Re: antivirus in smtp, good or bad?

Daniel Senie wrote: At 08:58 AM 2/3/2004, you wrote: Why must systems accept mail that's virus laden or otherwise not desired at a site? The "bounce" you refer to invariably ends up going to the wrong person(s), so that's an exceptionally BAD idea. Many viruses (most of the recent ones) fo

RE: Strange public traceroutes return private RFC1918 addresses

>> A more important question is what will happen as we move out >> of the 1500 byte Ethernet world into the jumbo gigE world. It's >> only a matter of time before end users will be running gigE >> networks and want to use jumbo MTUs on their Internet links. >The performance gain achieved by using

Re: Strange public traceroutes return private RFC1918 addresses

> bill wrote: > > > for some, yes. running 1ge is fairly common and 10ge is > > maturing. bleeding edge 40ge is available ... and 1500byte > > mtu is -not- an option. > > > Me wonders why people ask for 40 byte packets at linerate if the mtu is > supposedly > larger? > > Pete

Re: antivirus in smtp, good or bad?

Stephen J. Wilcox [2/3/2004 8:13 PM] : Ok I just realised what I'm doing here, 550 is a permanent fail and at this point as I am holding the mail on my server I should decide to return it to the sender. This isnt actually whats filling my queue and actually the reason I have some of these with

RE: Strange public traceroutes return private RFC1918 addresses

On Tue, 3 Feb 2004, Terry Baranski wrote: > > > A more important question is what will happen as we move out > > of the 1500 byte Ethernet world into the jumbo gigE world. It's > > only a matter of time before end users will be running gigE > > networks and want to use jumbo MTUs on their Intern

Re: antivirus in smtp, good or bad?

On Tue, 3 Feb 2004, Suresh Ramasubramanian wrote: > Stephen J. Wilcox [2/3/2004 7:28 PM] : > > > Whats happening is we're accepting the mail as the primary MX for the domain but > > the user has setup a forwarding to another account at another ISP, they have > > antivirus service on that other

Re: Strange public traceroutes return private RFC1918 addresses

bill wrote: for some, yes. running 1ge is fairly common and 10ge is maturing. bleeding edge 40ge is available ... and 1500byte mtu is -not- an option. Me wonders why people ask for 40 byte packets at linerate if the mtu is supposedly larger? Pete

Re: Strange public traceroutes return private RFC1918 addresses

> > > > A more important question is what will happen as we move out > > of the 1500 byte Ethernet world into the jumbo gigE world. It's > > only a matter of time before end users will be running gigE > > networks and want to use jumbo MTUs on their Internet links. > > The performance gain achi

Re: antivirus in smtp, good or bad?

At 08:58 AM 2/3/2004, you wrote: Hi, When investigating our mail queue it seems we have quite a lot of mails which are stuck in transit... Whats happening is we're accepting the mail as the primary MX for the domain but the user has setup a forwarding to another account at another ISP, they ha

RE: Strange public traceroutes return private RFC1918 addresses

> A more important question is what will happen as we move out > of the 1500 byte Ethernet world into the jumbo gigE world. It's > only a matter of time before end users will be running gigE > networks and want to use jumbo MTUs on their Internet links. The performance gain achieved by using jumb

Re: antivirus in smtp, good or bad?

Stephen J. Wilcox [2/3/2004 7:28 PM] : Whats happening is we're accepting the mail as the primary MX for the domain but the user has setup a forwarding to another account at another ISP, they have antivirus service on that other account. So we get the mail, spool it and try to forward it but then

antivirus in smtp, good or bad?

Hi, When investigating our mail queue it seems we have quite a lot of mails which are stuck in transit... Whats happening is we're accepting the mail as the primary MX for the domain but the user has setup a forwarding to another account at another ISP, they have antivirus service on that other

Re: Strange public traceroutes return private RFC1918 addresses

>Which (as discussed previously) breaks things like Path MTU Discovery, >traceroute, If RFC1918 addresses are used only on interfaces with jumbo MTUs on the order of 9000 bytes then it doesn't break PMTUD in a 1500 byte Ethernet world. And it doesn't break traceroute. We just lose the DNS hint

Re: Unbelievable Spam.

>> Spam Hosting - from 20$ per mounth. >> Fraud Hosting - from 30$ per mounth. >> Stoln Credit Cards, Fake ID, DL's. >This is known as "Rule #3" on n.a.n-a.e... Spammers are stupid. Stupid!? These spammers are not stupid. There are very few legitimate businesses which can actually turn a profit

Re: Strange public traceroutes return private RFC1918 addresses

[EMAIL PROTECTED] disait : > Search the archives, Comcast and other cable/DSL providers use the > 10/8 for their infrastructure. The Internet itself doesn't need to be > Internet routable. Only the edges need to be routable. It is common > practice to use RFC1918 address space inside the ne

Re: updated root hints file

Randy Bush wrote: > let's face it. we should be looking at the front page > of the site to find root hints. there > we find , which seems > to be missing a link to the signed root hints. > > iana, could you please fix that? thanks. Good