Re: United.com having DNS issues?

[Christopher L. Morrow]

On Thu, 2 Jun 2005, Henry Yen wrote:

>
> On Thu, Jun 02, 2005 at 12:21:21PM -0400, Henry Yen wrote:
> > On Thu, Jun 02, 2005 at 04:03:17AM +, Christopher L. Morrow wrote:
> > > On Wed, 1 Jun 2005, Henry Yen wrote:
> > > > On Thu, Jun 02, 2005 at 02:56:20AM +, Christopher L. Morrow wrote:
> > > > > Not horribly on topic, but perhaps there is a united.com person 
> > > > > listening:
> > > > >
> > > > > www.united.com's NS servers are -
> > > > >   dns01.uls-prod.com.
> > > > >   dns02.uls-prod.com.
> > > >
> > > > whois and "dig +trace" show that www.united.com's servers are now:
> > > >   dc1lbs1.uls-prod.com
> > > >   dc2lbs1.uls-prod.com
> > > >
> > > > maybe the dns changes were recently made and are still "in-flight"... 
> > > > (ducks)
> > >
> > > i don't think so, the united.com domain was those two earlier today, with
> > > www.united.com NS from dns01/02.uls-prod.com ... though I've seen this
> > > situation change some throughout the day as well with the dcXlbs1 boxes in
> > > the mix as well. Asking direcly from dns01/02 gets you records for SOME
> > > things but not others and servfail 'often' for www.united.com.
> > >
> > > Someone else pointed out that this is not a 'new' situation and has been
> > > the case for about 3-4 weeks so far... their POC's on the domains:
> > >
> > > united.com
> > > ual.com
> > > uls-prod.com
> > >
> > > are all invalid/dead/not-answering... perhaps someone will be watching
> > > nanog, perhaps they will continue to be busted :( Oh well.
>
> maybe it was still on-the-fly after all.  whois united.com now shows
> dcXlbs1 as the name servers, and a flush of the local nameserver here
> now has www.united.com resolving properly.
>

   Registrar Name: REGISTER.COM, INC.
   Registrar Whois...: whois.register.com
   Registrar Homepage: www.register.com

   Domain Name: united.com

  Created on..: Thu, Dec 17, 1998
  Expires on..: Fri, Dec 16, 2011
  Record last updated on..: Fri, Nov 12, 2004


So, some sort of register.com snafu?

Re: United.com having DNS issues?

[Henry Yen]

On Thu, Jun 02, 2005 at 12:21:21PM -0400, Henry Yen wrote:
> On Thu, Jun 02, 2005 at 04:03:17AM +, Christopher L. Morrow wrote:
> > On Wed, 1 Jun 2005, Henry Yen wrote:
> > > On Thu, Jun 02, 2005 at 02:56:20AM +, Christopher L. Morrow wrote:
> > > > Not horribly on topic, but perhaps there is a united.com person 
> > > > listening:
> > > >
> > > > www.united.com's NS servers are -
> > > >   dns01.uls-prod.com.
> > > >   dns02.uls-prod.com.
> > >
> > > whois and "dig +trace" show that www.united.com's servers are now:
> > >   dc1lbs1.uls-prod.com
> > >   dc2lbs1.uls-prod.com
> > >
> > > maybe the dns changes were recently made and are still "in-flight"... 
> > > (ducks)
> > 
> > i don't think so, the united.com domain was those two earlier today, with
> > www.united.com NS from dns01/02.uls-prod.com ... though I've seen this
> > situation change some throughout the day as well with the dcXlbs1 boxes in
> > the mix as well. Asking direcly from dns01/02 gets you records for SOME
> > things but not others and servfail 'often' for www.united.com.
> > 
> > Someone else pointed out that this is not a 'new' situation and has been
> > the case for about 3-4 weeks so far... their POC's on the domains:
> > 
> > united.com
> > ual.com
> > uls-prod.com
> > 
> > are all invalid/dead/not-answering... perhaps someone will be watching
> > nanog, perhaps they will continue to be busted :( Oh well.

maybe it was still on-the-fly after all.  whois united.com now shows
dcXlbs1 as the name servers, and a flush of the local nameserver here
now has www.united.com resolving properly.

-- 
Henry Yen   Aegis Information Systems, Inc.
Senior Systems Programmer   Hicksville, New York

Re: VerizonWireless.com Mail Blacklists

[Brad Knowles]

At 7:21 PM -0700 2005-06-01, John Bittenbender wrote:


We don't provide email services to our customers. We are merely a
 wireless ISP generally used as their secondary connection to use while
 the customer is mobile. Another large portion of our client base are
 enterprises and public services/utilities that use their own systems.


	Do you provide mail servers of any type anywhere at all on your 
network?  Do you provide access to mail servers of any type through 
your network?  If so, then you are an e-mail service provider (even 
if that isn't your primary function).



The reason for our non-participation in Spam-L. We aren't an
 email provider.


	You should most definitely be actively participating in the 
appropriate forums.


	Failure to do so should be considered a corporate statement that 
you implicitly condone any and all such activities that occur on your 
networks.



	However, this discussion should be held in one of those forums 
where it is more appropriate to discuss this subject.  Unfortunately, 
you don't participate in any of them.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: orsc root server?

[bmanning]

On Thu, Jun 02, 2005 at 12:23:25AM -0400, Chris Beggy wrote:
> 
> Is there any alternative to the orsc.org root server at
> 199.166.24.1 ?
> 
> Thanks.
> 
> Chris

have you considered  b.root-servers.net at 192.228.79.201

--bill

orsc root server?

[Chris Beggy]

Is there any alternative to the orsc.org root server at
199.166.24.1 ?

Thanks.

Chris

Re: United.com having DNS issues?

[Henry Yen]

On Thu, Jun 02, 2005 at 04:03:17AM +, Christopher L. Morrow wrote:
> On Wed, 1 Jun 2005, Henry Yen wrote:
> > On Thu, Jun 02, 2005 at 02:56:20AM +, Christopher L. Morrow wrote:
> > > Not horribly on topic, but perhaps there is a united.com person listening:
> > >
> > > www.united.com's NS servers are -
> > >   dns01.uls-prod.com.
> > >   dns02.uls-prod.com.
> >
> > whois and "dig +trace" show that www.united.com's servers are now:
> >   dc1lbs1.uls-prod.com
> >   dc2lbs1.uls-prod.com
> >
> > maybe the dns changes were recently made and are still "in-flight"... 
> > (ducks)
> 
> i don't think so, the united.com domain was those two earlier today, with
> www.united.com NS from dns01/02.uls-prod.com ... though I've seen this
> situation change some throughout the day as well with the dcXlbs1 boxes in
> the mix as well. Asking direcly from dns01/02 gets you records for SOME
> things but not others and servfail 'often' for www.united.com.
> 
> Someone else pointed out that this is not a 'new' situation and has been
> the case for about 3-4 weeks so far... their POC's on the domains:
> 
> united.com
> ual.com
> uls-prod.com
> 
> are all invalid/dead/not-answering... perhaps someone will be watching
> nanog, perhaps they will continue to be busted :( Oh well.

yeah, ok, the situation appears slightly more messed up than originally
surmised.

the dcXlbs1 boxes are the ones pointed to by the root.  unfortunately,
they think the dns0X boxes are the nameservers (though that doesn't matter
if you don't ask dcXlbs1 for NS records).

also of note is the SOA serial number is 20050503 (four weeks ago).
also interesting is that the whois/registry for uls-prod.com says
that it's expired.

-- 
Henry Yen   Aegis Information Systems, Inc.
Senior Systems Programmer   Hicksville, New York

Could someone from broadwing.net DNS ops please email me offlist

[Suresh Ramasubramanian]

As the subject says.

thanks
srs
-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: United.com having DNS issues?

[Christopher L. Morrow]

On Wed, 1 Jun 2005, Henry Yen wrote:

>
> On Thu, Jun 02, 2005 at 02:56:20AM +, Christopher L. Morrow wrote:
> > Not horribly on topic, but perhaps there is a united.com person listening:
> >
> > www.united.com's NS servers are -
> >   dns01.uls-prod.com.
> >   dns02.uls-prod.com.
>
> whois and "dig +trace" show that www.united.com's servers are now:
>   dc1lbs1.uls-prod.com
>   dc2lbs1.uls-prod.com
>
> maybe the dns changes were recently made and are still "in-flight"... (ducks)

i don't think so, the united.com domain was those two earlier today, with
www.united.com NS from dns01/02.uls-prod.com ... though I've seen this
situation change some throughout the day as well with the dcXlbs1 boxes in
the mix as well. Asking direcly from dns01/02 gets you records for SOME
things but not others and servfail 'often' for www.united.com.

Someone else pointed out that this is not a 'new' situation and has been
the case for about 3-4 weeks so far... their POC's on the domains:

united.com
ual.com
uls-prod.com

are all invalid/dead/not-answering... perhaps someone will be watching
nanog, perhaps they will continue to be busted :( Oh well.

Re: United.com having DNS issues?

[Randy Bush]

>> Not horribly on topic, but perhaps there is a united.com person listening:
>> 
>> www.united.com's NS servers are -
>>   dns01.uls-prod.com.
>>   dns02.uls-prod.com.
> 
> whois and "dig +trace" show that www.united.com's servers are now:
>   dc1lbs1.uls-prod.com
>   dc2lbs1.uls-prod.com
> 
> maybe the dns changes were recently made and are still "in-flight"... (ducks)

% host dns01.uls-prod.com
dns01.uls-prod.com has address 209.87.112.200
% host dns02.uls-prod.com
dns02.uls-prod.com has address 209.87.113.200

% host dc1lbs1.uls-prod.com
dc1lbs1.uls-prod.com has address 209.87.112.4
% host dc2lbs1.uls-prod.com
dc2lbs1.uls-prod.com has address 209.87.113.4

love that 2182

Re: United.com having DNS issues?

[Henry Yen]

On Thu, Jun 02, 2005 at 02:56:20AM +, Christopher L. Morrow wrote:
> Not horribly on topic, but perhaps there is a united.com person listening:
> 
> www.united.com's NS servers are -
>   dns01.uls-prod.com.
>   dns02.uls-prod.com.

whois and "dig +trace" show that www.united.com's servers are now:
  dc1lbs1.uls-prod.com
  dc2lbs1.uls-prod.com

maybe the dns changes were recently made and are still "in-flight"... (ducks)

-- 
Henry Yen   Aegis Information Systems, Inc.
Senior Systems Programmer   Hicksville, New York

United.com having DNS issues?

[Christopher L. Morrow]

Not horribly on topic, but perhaps there is a united.com person listening:

www.united.com's NS servers are -
  dns01.uls-prod.com.
  dns02.uls-prod.com.

DNS01 seems 'fine' (responds atleast)
DNS02 seems to return 'servefail' for everything...

Servefail seems to make cache dns servers not attempt lookups from the
other NS's on record. This seems 'bad', if your dns server is busted could
you just null route it or turn it off?

Actually, now as I test both NS's are toasted :( Hope the record's TTL is
long enough for you.

-Chris

Re: VerizonWireless.com Mail Blacklists

[John Bittenbender]

On 6/1/05, Rich Kulawiec <[EMAIL PROTECTED]> wrote:
> On Tue, May 31, 2005 at 04:46:01PM -, John Levine wrote:
> > VZW recently confirmed that their mail system is separate from VZ's,
> > and whatever mistakes they may make, they're not VZ's.
> 
> Okay, fine -- and a look at DNS seems to back this up (unless I'm
> missing something).  And I've no desire to lay VZ's mistakes at VZW's
> feet, or vice versa -- but that still leaves whoever-is-affected (like
> the orginal poster or anyone else out there) to deal with the issues.
> And the lack of participation by VZ and VZW in the leading applicable
> forum (i.e. Spam-L) isn't helping.  At least some of the other folks
> are engaged in dialogue with their peers, even if what they're saying
> isn't to everyone's liking.

Quick point to address here about VZW's email.

   We don't provide email services to our customers. We are merely a
wireless ISP generally used as their secondary connection to use while
the customer is mobile. Another large portion of our client base are
enterprises and public services/utilities that use their own systems.

   The reason for our non-participation in Spam-L. We aren't an
email provider. At most we relay for our own address space and accept
deliveries to and from vtext.com which isn't email/webmail it's only
web accessible SMS messaging so it's not really applicable either.
There are spam guards on vtext but if a customer can't receive his/her
SMS's that were sent to their phone they can call customer service and
get that resolved.

   The issue at the root of this thread was with our corporate mail
servers, not customer email. So it's a different ball of wax and not
really a topic for discussion on NANOG other than as a last cry for
help (which worked in this case).

   And yes, please don't lay VZ's problems at our feet. As was
mentioned a ways up this thread, we are just partially owned by the
same mother ship.

John Bittenbender
Verizon Wireless Netops

bay area cell service: tmo and cingular

[Matt Ghali]

I've noticed in the last ten minutes or so that cingular and tmobile 
users are both unable to make or receive calls; at least in the 
Redwood City and Berkeley (!) areas. Anyone know if something is up?


matto

[EMAIL PROTECTED]<
  The only thing necessary for the triumph
  of evil is for good men to do nothing. - Edmund Burke

NWN / ARCOS-1 please contact me off-list

[Andrew White]

I have been running in circles with the sales folk.  Would an engineer or 
technical sales person from New World Networks / ARCOS-1 please contact me 
off-list to discuss transit between Honduras and USA via the ARCOS-1 
sub-Caribbean fiber ring please?

-Andrew

--
Ing. Andrew White, CTO
Tropico Telephone & Internet, S.A. de C.V.
La Ceiba, Honduras, CA
http://www.tti.hn/ - [EMAIL PROTECTED]

Re: Verizon is easily fooled by spamming zombies

[Steve Sobol]

[EMAIL PROTECTED] wrote:


"Anything from anywhere, even if it's from a hijacked box in Korea, can forward
through our server as long as it has a '[EMAIL PROTECTED]' From: on it,
but if one of our own customers tries to send through the server with a From:
that says '[EMAIL PROTECTED]' they can't even if they pass an SMTP AUTH
check and prove they're ISP.net's customer..."

And that's borked and wrong.


This is old news.

Years old. I think it might have dated back to before @gte.net addresses 
became deprecated.


But I thought VZ had fixed the problem.

--
JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638)
Steven J. Sobol, Geek In Charge / [EMAIL PROTECTED] / PGP: 0xE3AE35ED

"The wisdom of a fool won't set you free"
--New Order, "Bizarre Love Triangle"

RE: Administration Asks Appeals Court To Compel ISP Searches

[Todd Vierling]

On Wed, 1 Jun 2005, Barry Shein wrote:

> A major concern is indemnification and immunity for the ISP.

This sort of power was greatly expanded by a suspiciouly intentioned US
bill-turned-law from 2001 whose name I dare not mention in cleartext (),
which allows such subpoenaless probes into far more information repositories
than they were originally allowed, including banks, many more forms of
communications services, travel services, consumer data, and libraries.
Nearly all of these expansive -- and in some cases completely judiciary
bypassing -- changes are coupled with implicit gag order subsections.

Very little attention was paid (whether accidentally or deliberately I won't
dare question) to the indemnity concerns about those implicit gag order
subsections.  Or, in other words, they have no "out clauses" to allow
disclosure of the probe(s) in a legal case involving the same information.
That means such a situation could indeed leave you...

> way up the creek without a paddle.

-- 
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

RE: Administration Asks Appeals Court To Compel ISP Searches

[Barry Shein]

A major concern is indemnification and immunity for the ISP.

When someone is prosecuted they usually face major legal expenses, and
often are incapable of paying them. The prospect of a lengthy prison
sentence and/or criminal record does not portend well either.

Defense lawyers know this all too well and will go after various deep
pockets to help fund their client's defense, such as an ISP who they
will argue revealed information inappropriately, violated a position
of trust, etc. etc. etc.

A proper subpoena issued by a court of competent jurisdiction and
reasonably fulfilled tends to be slam-dunk defense against such
lawsuits. Likely a judge would just toss any attempt at a lawsuit at
initial hearing if it's obvious you were legally compelled to provide
the information in question.

To me this is at least as big a concern as any vague sense of fair
play.

Add in gag orders and the like, an atmosphere of silence and denial by
LEOs this creates, and one gets the sinking feeling one can find
themselves, as the expression goes, way up the creek without a paddle.

I've certainly had exactly this conversation with LEOs who sent
requests for customer information, even an Ivy League university's
senior legal counsel once when their "police dept" was demanding info
and for some bizarre reason refused to get a subpoena even over a
period of months of ever more heated requests and never had the
slightest doubt expressed that I was exactly correct in my concerns.


-- 
-Barry Shein

Software Tool & Die| [EMAIL PROTECTED]   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD
The World  | Public Access Internet | Since 1989 *oo*

Re: Verizon is easily fooled by spamming zombies (was: Re: VerizonWireless.com Mail Blacklists)

[Christopher L. Morrow]

On Wed, 1 Jun 2005, Patrick W. Gilmore wrote:

>
> On Jun 1, 2005, at 1:54 PM, Christopher L. Morrow wrote:
>
> >> Received: from verizon.net ([63.24.130.230])
> >>
> >> (63.24.130.230 is 1Cust742.an1.nyc41.da.uu.net, HELO'd as
> >> 'verizon.net'
> >> and VZ still relayed it)
> >
> > keep in mind I'm just thinking out loud here, but is it possible that
> > verizon is using someone else for dial access in places? So,
> > perhaps these
> > are VZ customers doing the proper helo based on their funky mail
> > client?
>
> You might be right.
>
> I couldn't get to 63.24.130.230, but from my person server (which has
> no relation to VZ's network):

1Cust742.an1.nyc41.da.uu.net == 63.24.130.230

which is like:

22Cust55.tnt13.tco2.da.uu.net. == 67.206.50.55

*Cust***.DEV.HUB.da.uu.net == dialup user ip. Most times ppp customer,
most times a /24 (or like) per DEV... So, unless someone is logged in at
this time to: 63.24.130.230 there isn't anything to get to...

>
> [EMAIL PROTECTED]/1:59PM% telnet relay.verizon.net 25
> Trying 206.46.232.11...
> Connected to relay.verizon.net.
> Escape character is '^]'.
> 220 sv10pub.verizon.net MailPass SMTP server v1.2.0 - 013105113116JY
> +PrW ready Wed, 1 Jun 2005 12:59:33 -0500
> helo patrick.verizon.net
> 250 sv10pub.verizon.net
> mail from: [EMAIL PROTECTED]
> 250 Sender <[EMAIL PROTECTED]> OK
> rcpt to: [EMAIL PROTECTED]
> 530 5.7.1 Relaying not allowed: [EMAIL PROTECTED]
>
> This is much better than I originally thought.
>
> Still think they should allow sending mail from their network though. :)
>

'their network' I think is the problem for them, again I'm not a VZ
employee (yet?), but I'd bet they have several hundreds of blocks for DSL,
several DIAL providers and distributed smtp acceptance points for their
customers... It seems that SMTPAUTH would be a decent way to get this
resolved though (or ONE decent way).

Re: Verizon is easily fooled by spamming zombies

[Gadi Evron]

> 1) monopoly isps
> 2) standard config
> 3) lack of ability to make 1/2/3 changes here/there/everywhere (config
> drift) for customers not paying more than the 'standard'.
> 
> There are other reasons of course. Also, customers with their own
> SMTP/IMAP services COULD just do tcp/587 'submission'... but we covered
> that ground already I think?

I don't usually send an email just for a one-liner (unless it is very
funny), but a "thank you" is in order.

It was mostly a mis-understanding of the argument on my part, but that
does put some things in light.

Thanks!

Gadi.

Re: Verizon is easily fooled by spamming zombies

[Christopher L. Morrow]

On Wed, 1 Jun 2005, Gadi Evron wrote:
>
> There is no real reason why you should be able to email out with
> [EMAIL PROTECTED] using Verizon's own servers.

perhaps not that, but surely [EMAIL PROTECTED] and if they do/have auth
info they can even see who it was when there are problems.

>
> If you are an advanced enough user to have your own vanity domain then
> you are advanced enough to have your own SMTP server. If port 25 is
> blocked, you can probably sort this out with your ISP (if said ISP is
> responsive to your needs) and/or move an ISP.
>

1) monopoly isps
2) standard config
3) lack of ability to make 1/2/3 changes here/there/everywhere (config
drift) for customers not paying more than the 'standard'.

There are other reasons of course. Also, customers with their own
SMTP/IMAP services COULD just do tcp/587 'submission'... but we covered
that ground already I think?

Re: Verizon is easily fooled by spamming zombies

[Valdis . Kletnieks]

On Wed, 01 Jun 2005 20:51:17 +0400, Gadi Evron said:

> > If the ISP wants to use SMTP AUTH or other mechanisms to lower abuse, 
> > that's fine.  But to say "only allow ISP.net from addresses - but  allow
> > them from anywhere on the 'Net" is kinda ... silly.
> 
> No, it makes perfect sense but that is the one thing I fear we'll have
> to agree to disagree on.

Nope, Patrick is right on this one.  The ruleset that appears to be in effect
is:

"Anything from anywhere, even if it's from a hijacked box in Korea, can forward
through our server as long as it has a '[EMAIL PROTECTED]' From: on it,
but if one of our own customers tries to send through the server with a From:
that says '[EMAIL PROTECTED]' they can't even if they pass an SMTP AUTH
check and prove they're ISP.net's customer..."

And that's borked and wrong.

> > The solution presented here is not only not a solution, it is also a 
> > problem.
> 
> Okay, then I suppose I don't understand the problem. How exactly do you
> mean?

See above - would you consider forwarding mail from outside ISP.net space
without an SMTP AUTH check just because it claims to be 'From @ISP.net'?



pgpE4XMCtOcjk.pgp
Description: PGP signature

Re: Verizon is easily fooled by spamming zombies

[Gadi Evron]

> See above - would you consider forwarding mail from outside ISP.net space
> without an SMTP AUTH check just because it claims to be 'From @ISP.net'?

Yep, I was arguing the wrong point. We're on the same side. Sorry for
the misunderstanding.

Read my statements under that light and you will see they are *almost*
the same although I still disagree on some of the issues.

Thanks

Re: Verizon is easily fooled by spamming zombies (was: Re: VerizonWireless.com Mail Blacklists)

[Patrick W. Gilmore]

On Jun 1, 2005, at 1:54 PM, Christopher L. Morrow wrote:


Received: from verizon.net ([63.24.130.230])

(63.24.130.230 is 1Cust742.an1.nyc41.da.uu.net, HELO'd as  
'verizon.net'

and VZ still relayed it)


keep in mind I'm just thinking out loud here, but is it possible that
verizon is using someone else for dial access in places? So,  
perhaps these
are VZ customers doing the proper helo based on their funky mail  
client?


You might be right.

I couldn't get to 63.24.130.230, but from my person server (which has  
no relation to VZ's network):


[EMAIL PROTECTED]/1:59PM% telnet relay.verizon.net 25
Trying 206.46.232.11...
Connected to relay.verizon.net.
Escape character is '^]'.
220 sv10pub.verizon.net MailPass SMTP server v1.2.0 - 013105113116JY 
+PrW ready Wed, 1 Jun 2005 12:59:33 -0500

helo patrick.verizon.net
250 sv10pub.verizon.net
mail from: [EMAIL PROTECTED]
250 Sender <[EMAIL PROTECTED]> OK
rcpt to: [EMAIL PROTECTED]
530 5.7.1 Relaying not allowed: [EMAIL PROTECTED]

This is much better than I originally thought.

Still think they should allow sending mail from their network though. :)

--
TTFN,
patrick

Re: Verizon is easily fooled by spamming zombies

[Gadi Evron]

> I fear you will have to agree to disagree with just about anyone who 
> runs a large mail server.

Read my other email on that one.

> 1) It is not a solution because it does not stop spam.  In fact, it  is
> easier to send spam through VZ's mail servers than just about  anyone
> else's.

I was not discussing success, I was debating the fact that people should
be able to use their ISP's servers for everything they want. Such
limitations do in fact help, although they are not very bright and shiny
to ISP's. In fact, ISP's hate them. I am surprised Verizon took this
approach.

How Verizon does anti-spam is another matter best left for another thread.

> 2) It is a problem because they do not allow things almost every  other
> ISP does - things which are "standard" and things for which the 
> anti-spam community has been fighting to put in place for many years.

Agreed. I can't and won't argue with that one.

Gadi.

Re: Verizon is easily fooled by spamming zombies

[Gadi Evron]

> If the ISP wants to use SMTP AUTH or other mechanisms to lower abuse, 
> that's fine.  But to say "only allow ISP.net from addresses - but  allow
> them from anywhere on the 'Net" is kinda ... silly.

I think we are arguing the same side of the problem. I think I mis-read
this one sentence.

SMTP AUTH is a great thing, really, but not what it's cracked up to be
in the age of zombies. I am not saying that they should be allowed from
anywhere on the net, I argue quite the opposite.

Gadi.

Re: Verizon is easily fooled by spamming zombies (was: Re: VerizonWireless.com Mail Blacklists)

[Christopher L. Morrow]

On Wed, 1 Jun 2005, Steven Champeon wrote:

>
> on Wed, Jun 01, 2005 at 12:07:33PM -0400, Rich Kulawiec wrote:
> > (As to Verizon itself, since three different people pointed out the
> > relative lack of SBL listings: keep in mind that SBL listings are put
> > in place for very specific reasons, and aren't the only indicator of
> > spam.  Other DNSBLs and RHSBLs, e.g. the CBL, use different criteria
> > and thus provide different measurements (if you will) of spam.  So,
> > to give a sample data point, in the last week alone, there have been
> > 315 spam attempts directed at *just this address* from 194 different
> > IP addresses (list attached) that belong to VZ.  Have I reported them?
> > Of *course* not.  What would be the point in that?)
>
> 
>
> Zombies I expect; what's worse is that they're /obviously/ not even
> doing the most basic checks:
>
> Received: from verizon.net ([63.24.130.230])
>
> (63.24.130.230 is 1Cust742.an1.nyc41.da.uu.net, HELO'd as 'verizon.net'
> and VZ still relayed it)
>

keep in mind I'm just thinking out loud here, but is it possible that
verizon is using someone else for dial access in places? So, perhaps these
are VZ customers doing the proper helo based on their funky mail client?


>
> IOW, VZ isn't even checking to see if a zombie'd host is forging its
> own domain into HELO, regardless of whether it comes from Comcast or
> UUNet, and as long as the forged sender has a verizon.net address, and
> the recipient hasn't blocked VZ's silly callback system, the message
> is relayed. Thanks, Verizon. We can hear you now.
>

or it's a flubb on VZ's part, like I said, just thinking out loud.

Re: Verizon is easily fooled by spamming zombies

[Patrick W. Gilmore]

On Jun 1, 2005, at 12:51 PM, Gadi Evron wrote:


If the ISP wants to use SMTP AUTH or other mechanisms to lower abuse,
that's fine.  But to say "only allow ISP.net from addresses - but   
allow

them from anywhere on the 'Net" is kinda ... silly.



No, it makes perfect sense but that is the one thing I fear we'll have
to agree to disagree on.


I fear you will have to agree to disagree with just about anyone who  
runs a large mail server.




The solution presented here is not only not a solution, it is also a
problem.



Okay, then I suppose I don't understand the problem. How exactly do  
you

mean?


1) It is not a solution because it does not stop spam.  In fact, it  
is easier to send spam through VZ's mail servers than just about  
anyone else's.


2) It is a problem because they do not allow things almost every  
other ISP does - things which are "standard" and things for which the  
anti-spam community has been fighting to put in place for many years.


--
TTFN,
patrick

Re: Verizon is easily fooled by spamming zombies

[Gadi Evron]

> Yes, $50/month.

Then there is the problem. If she pays for the service of sending email
using the vanity domain through the ISP's servers, then it should be,
naturally, allowed.

> No, 100s of 1000s of not-so-clued users have vanity domains.  Have  you
> checked how many domains are registered on a daily basis these days?

Much like they pay for domains, and for hosting, or for iron, or for
bandwidth or whatever your cup of tea is, so should everyone else.
Nothing comes for free and the abuse vs. use ratio is not favorable.

Really, why should they be able to pay for domains and not arrange to
pay an extra buck or 20? Well, we all like freebies.

> Who said "open"?  There are lots of ways to keep spam from your  network
> down.
> 
> If you have a mail server and allow it to send mail, it can be  abused. 
> All you can do is try to make it harder to abuse.  One of  the ways we
> (the collective "we" who run the Internet) have decided  to do this is
> by forcing people to send outbound mail through their  ISP's mail
> server, not through random open relays.

Through _A_ mail server. Paid for or not is another issue, but the
service is still a service.

I get most of my domains hosted on friends' servers, that is still a
service even if I don't pay for it.

> If the ISP wants to use SMTP AUTH or other mechanisms to lower abuse, 
> that's fine.  But to say "only allow ISP.net from addresses - but  allow
> them from anywhere on the 'Net" is kinda ... silly.

No, it makes perfect sense but that is the one thing I fear we'll have
to agree to disagree on.

> The solution presented here is not only not a solution, it is also a 
> problem.

Okay, then I suppose I don't understand the problem. How exactly do you
mean?

Gadi.

Re: Verizon is easily fooled by spamming zombies

[Patrick W. Gilmore]

On Jun 1, 2005, at 12:35 PM, Gadi Evron wrote:


The example given in this thread proves you wrong.  My friend had a
vanity domain, did not have her own mail server.


Okay, and why does she need to use Verizon's servers to send email  
from

her own vanity domain?
Unless I am missing something and Verizon gets paid for this?


Yes, $50/month.



But that's OK, we should tell people one thing (use your ISP's server
to send mail) and do another (block them from sending mail through
their ISP's server).


I believe you are exaggerating, like I usually like to do. My point is
the the vast.. vast.. clueless majority is a direct threat to Internet
survivability (ooh, big words). The 100s of thousands of clued  
users who

has a vanity domains can definitely find an easy way to send mail,
without using the provider's servers.


No, 100s of 1000s of not-so-clued users have vanity domains.  Have  
you checked how many domains are registered on a daily basis these days?



The cost of allowing these servers to stay "open" is extremely  
high, and

we are paying the price every day.


Who said "open"?  There are lots of ways to keep spam from your  
network down.


If you have a mail server and allow it to send mail, it can be  
abused.  All you can do is try to make it harder to abuse.  One of  
the ways we (the collective "we" who run the Internet) have decided  
to do this is by forcing people to send outbound mail through their  
ISP's mail server, not through random open relays.


If the ISP wants to use SMTP AUTH or other mechanisms to lower abuse,  
that's fine.  But to say "only allow ISP.net from addresses - but  
allow them from anywhere on the 'Net" is kinda ... silly.




That's the point, the clueless, vast, vast, majority is happy. They
don't care. They don't know there are 40 Trojan horses and 400 spyware
components installed on their quiet green desktop. All they know is  
that

their email account works. I know that they are threatening the
Internet. Clear and simple.


The solution presented here is not only not a solution, it is also a  
problem.


--
TTFN,
patrick

Re: Verizon is easily fooled by spamming zombies

[Gadi Evron]

> The example given in this thread proves you wrong.  My friend had a 
> vanity domain, did not have her own mail server.

Okay, and why does she need to use Verizon's servers to send email from
her own vanity domain?
Unless I am missing something and Verizon gets paid for this?

> But that's OK, we should tell people one thing (use your ISP's server 
> to send mail) and do another (block them from sending mail through 
> their ISP's server).

I believe you are exaggerating, like I usually like to do. My point is
the the vast.. vast.. clueless majority is a direct threat to Internet
survivability (ooh, big words). The 100s of thousands of clued users who
has a vanity domains can definitely find an easy way to send mail,
without using the provider's servers.

The cost of allowing these servers to stay "open" is extremely high, and
we are paying the price every day.

> Makes the "clueless majority" much happier when even the "techies" 
> can't figure out WTF they are supposed to do.

That's the point, the clueless, vast, vast, majority is happy. They
don't care. They don't know there are 40 Trojan horses and 400 spyware
components installed on their quiet green desktop. All they know is that
their email account works. I know that they are threatening the
Internet. Clear and simple.

Gadi.

Re: Verizon is easily fooled by spamming zombies

[Patrick W. Gilmore]

On Jun 1, 2005, at 12:17 PM, Gadi Evron wrote:


Zombies do both, but my comment wasn't about zombies, it was about
users.  If you are a user with a vanity domain trying to send e-mail
"From: [EMAIL PROTECTED]", you cannot through VZ's system.  Despite
the fact we have spent years telling people they have to use their
local ISP's mail server to send mail out.

Does VZ support SMTP AUTH these days?  (My info is over a year old.)


Verizon has many odd choices in their history, indeed. Still, how many
DSL users actually *need* to use an account other than that given to
them by their ISP?


Many thousands, perhaps 100s of thousands.


I find this extreme measure quite a good step, and in the right  
direction.


I do not.



There is no real reason why you should be able to email out with
[EMAIL PROTECTED] using Verizon's own servers.


Of course not.  But "[EMAIL PROTECTED]" is perfectly reasonable.



If you are an advanced enough user to have your own vanity domain then
you are advanced enough to have your own SMTP server. If port 25 is
blocked, you can probably sort this out with your ISP (if said ISP is
responsive to your needs) and/or move an ISP.


The example given in this thread proves you wrong.  My friend had a  
vanity domain, did not have her own mail server.


But that's OK, we should tell people one thing (use your ISP's server  
to send mail) and do another (block them from sending mail through  
their ISP's server).


Makes the "clueless majority" much happier when even the "techies"  
can't figure out WTF they are supposed to do.


--
TTFN,
patrick

Re: Verizon is easily fooled by spamming zombies

[Gadi Evron]

> Zombies do both, but my comment wasn't about zombies, it was about 
> users.  If you are a user with a vanity domain trying to send e-mail 
> "From: [EMAIL PROTECTED]", you cannot through VZ's system.  Despite 
> the fact we have spent years telling people they have to use their 
> local ISP's mail server to send mail out.
> 
> Does VZ support SMTP AUTH these days?  (My info is over a year old.)

Verizon has many odd choices in their history, indeed. Still, how many
DSL users actually *need* to use an account other than that given to
them by their ISP?

I find this extreme measure quite a good step, and in the right direction.

There is no real reason why you should be able to email out with
[EMAIL PROTECTED] using Verizon's own servers.

If you are an advanced enough user to have your own vanity domain then
you are advanced enough to have your own SMTP server. If port 25 is
blocked, you can probably sort this out with your ISP (if said ISP is
responsive to your needs) and/or move an ISP.

I don't see how this doesn't sit well with telling people to use their
ISP's server? Our problem *is* the clueless majority.

^5 to Verizon.

Gadi.

Re: Verizon is easily fooled by spamming zombies

[Gadi Evron]

> Assuming it does via their systems - most zombies have their own smtp
> engine from what I understand

Yes. Why would they need anything more than a broken SMTP engine that
has been ripped from one sample to another for over 8 years?

I'm exaggerating of course, but you get the picture.

Let's not go back to blocking port 25 again, but that's the only reason
why this would become obsolete so that other methods/attack vectors are
actually necessary.

Gadi.

Re: Verizon is easily fooled by spamming zombies

[Patrick W. Gilmore]

On Jun 1, 2005, at 1:00 PM, Martin Hepworth wrote:


Patrick W. Gilmore wrote:


On Jun 1, 2005, at 12:28 PM, Steven Champeon wrote:


IOW, VZ isn't even checking to see if a zombie'd host is forging its
own domain into HELO, regardless of whether it comes from Comcast or
UUNet, and as long as the forged sender has a verizon.net  
address, and

the recipient hasn't blocked VZ's silly callback system, the message
is relayed. Thanks, Verizon. We can hear you now.

The other half of this is if you are on VZ's network and try to  
send  mail through their system, you cannot unless you have a  
"verizon.net"  from address.  Or at least that was the case when  
my friend with VZ  DSL tried to send e-mail through VZ from her  
personal domain.


Assuming it does via their systems - most zombies have their own  
smtp engine from what I understand


Zombies do both, but my comment wasn't about zombies, it was about  
users.  If you are a user with a vanity domain trying to send e-mail  
"From: [EMAIL PROTECTED]", you cannot through VZ's system.  Despite  
the fact we have spent years telling people they have to use their  
local ISP's mail server to send mail out.


Does VZ support SMTP AUTH these days?  (My info is over a year old.)

--
TTFN,
patrick

Re: Verizon is easily fooled by spamming zombies

[Martin Hepworth]

Patrick W. Gilmore wrote:


On Jun 1, 2005, at 12:28 PM, Steven Champeon wrote:


IOW, VZ isn't even checking to see if a zombie'd host is forging its
own domain into HELO, regardless of whether it comes from Comcast or
UUNet, and as long as the forged sender has a verizon.net address, and
the recipient hasn't blocked VZ's silly callback system, the message
is relayed. Thanks, Verizon. We can hear you now.



The other half of this is if you are on VZ's network and try to send  
mail through their system, you cannot unless you have a "verizon.net"  
from address.  Or at least that was the case when my friend with VZ  DSL 
tried to send e-mail through VZ from her personal domain.




Assuming it does via their systems - most zombies have their own smtp 
engine from what I understand


--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300

**

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.   

**

Re: Verizon is easily fooled by spamming zombies (was: Re: VerizonWireless.com Mail Blacklists)

[Patrick W. Gilmore]

On Jun 1, 2005, at 12:28 PM, Steven Champeon wrote:


IOW, VZ isn't even checking to see if a zombie'd host is forging its
own domain into HELO, regardless of whether it comes from Comcast or
UUNet, and as long as the forged sender has a verizon.net address, and
the recipient hasn't blocked VZ's silly callback system, the message
is relayed. Thanks, Verizon. We can hear you now.


The other half of this is if you are on VZ's network and try to send  
mail through their system, you cannot unless you have a "verizon.net"  
from address.  Or at least that was the case when my friend with VZ  
DSL tried to send e-mail through VZ from her personal domain.


--
TTFN,
patrick

Verizon is easily fooled by spamming zombies (was: Re: VerizonWireless.com Mail Blacklists)

[Steven Champeon]

on Wed, Jun 01, 2005 at 12:07:33PM -0400, Rich Kulawiec wrote:
> (As to Verizon itself, since three different people pointed out the
> relative lack of SBL listings: keep in mind that SBL listings are put
> in place for very specific reasons, and aren't the only indicator of
> spam.  Other DNSBLs and RHSBLs, e.g. the CBL, use different criteria
> and thus provide different measurements (if you will) of spam.  So,
> to give a sample data point, in the last week alone, there have been
> 315 spam attempts directed at *just this address* from 194 different
> IP addresses (list attached) that belong to VZ.  Have I reported them?
> Of *course* not.  What would be the point in that?)



Zombies I expect; what's worse is that they're /obviously/ not even
doing the most basic checks:

Received: from verizon.net ([63.24.130.230])

(63.24.130.230 is 1Cust742.an1.nyc41.da.uu.net, HELO'd as 'verizon.net'
and VZ still relayed it)

Received: from verizon.net ([68.130.237.39])

(68.130.237.39 is 1Cust39.tnt26.mia5.da.uu.net, HELO'd as 'verizon.net'
and VZ still relayed it)

Received: from verizon.net ([68.130.237.35])

(68.130.237.35 is 1Cust35.tnt26.mia5.da.uu.net, HELO'd as 'verizon.net'
and VZ still relayed it)

Received: from verizon.net ([65.34.38.26])

(65.34.38.26 is c-65-34-38-26.hsd1.fl.comcast.net, HELO'd as 'verizon.net'
and VZ still relayed it)

Received: from verizon.net ([65.34.184.15])

(65.34.184.15 is c-65-34-184-15.hsd1.fl.comcast.net, etc.)

IOW, VZ isn't even checking to see if a zombie'd host is forging its
own domain into HELO, regardless of whether it comes from Comcast or
UUNet, and as long as the forged sender has a verizon.net address, and
the recipient hasn't blocked VZ's silly callback system, the message
is relayed. Thanks, Verizon. We can hear you now. 

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!

Re: VerizonWireless.com Mail Blacklists

[Rich Kulawiec]

On Tue, May 31, 2005 at 04:46:01PM -, John Levine wrote:
> VZW recently confirmed that their mail system is separate from VZ's,
> and whatever mistakes they may make, they're not VZ's.

Okay, fine -- and a look at DNS seems to back this up (unless I'm
missing something).  And I've no desire to lay VZ's mistakes at VZW's
feet, or vice versa -- but that still leaves whoever-is-affected (like
the orginal poster or anyone else out there) to deal with the issues.
And the lack of participation by VZ and VZW in the leading applicable
forum (i.e. Spam-L) isn't helping.  At least some of the other folks
are engaged in dialogue with their peers, even if what they're saying
isn't to everyone's liking.

(As to Verizon itself, since three different people pointed out the
relative lack of SBL listings: keep in mind that SBL listings are put
in place for very specific reasons, and aren't the only indicator of
spam.  Other DNSBLs and RHSBLs, e.g. the CBL, use different criteria
and thus provide different measurements (if you will) of spam.  So,
to give a sample data point, in the last week alone, there have been
315 spam attempts directed at *just this address* from 194 different
IP addresses (list attached) that belong to VZ.  Have I reported them?
Of *course* not.  What would be the point in that?)

---Rsk
wbar1.chi1-4-10-118-158.chi1.dsl-verizon.net [4.10.118.158]
hnllhi1-ar6-4-11-039-125.dsl-verizon.net [4.11.39.125]
[EMAIL PROTECTED] [4.3.236.250]
hnllhi1-ar3-4-3-111-154.hnllhi1.dsl-verizon.net [4.3.111.154]
wbar2.wdc2-4.30.100.231.wdc2.dsl-verizon.net [4.30.100.231]
wbar12.sea1-4.32.1.170.dsl-verizon.net [4.32.1.170]
wbar12.sea1-4.32.2.144.dsl-verizon.net [4.32.2.144]
atlnga1-ar2-4-34-191-127.atlnga1.dsl-verizon.net [4.34.191.127]
chcgil2-ar7-4-34-128-080.chcgil2.dsl-verizon.net [4.34.128.80]
wbar7.sea1-4-4-042-075.sea1.dsl-verizon.net [4.4.42.75]
wbar8.sea1-4-4-065-255.sea1.dsl-verizon.net [4.4.65.255]
wbar8.sea1-4-4-073-107.sea1.dsl-verizon.net [4.4.73.107]
hnllhi1-ar3-4-42-103-001.hnllhi1.dsl-verizon.net [4.42.103.1]
hnllhi1-ar3-4-43-152-035.hnllhi1.dsl-verizon.net [4.43.152.35]
lsanca1-ar16-4-46-046-186.lsanca1.dsl-verizon.net [4.46.46.186]
lsanca1-ar19-4-46-077-103.lsanca1.dsl-verizon.net [4.46.77.103]
lsanca1-ar12-4-60-179-045.lsanca1.dsl-verizon.net [4.60.179.45]
lsanca1-ar2-4-60-003-159.lsanca1.dsl-verizon.net [4.60.3.159]
washdc3-ar8-4-62-076-106.washdc3.dsl-verizon.net [4.62.76.106]
evrtwa1-ar5-4-65-000-098.evrtwa1.dsl-verizon.net [4.65.0.98]
lsanca1-ar9-4-65-084-147.lsanca1.dsl-verizon.net [4.65.84.147]
hnllhi1-ar7-4-7-214-201.hnllhi1.dsl-verizon.net [4.7.214.201]
pool-64-222-182-239.man.east.verizon.net [64.222.182.239]
pool-64-223-119-29.burl.east.verizon.net [64.223.119.29]
pool-64-223-82-120.burl.east.verizon.net [64.223.82.120]
pool-68-160-165-106.bos.east.verizon.net [68.160.165.106]
pool-68-160-190-103.bos.east.verizon.net [68.160.190.103]
pool-68-160-210-53.ny325.east.verizon.net [68.160.210.53]
pool-68-161-112-23.ny325.east.verizon.net [68.161.112.23]
pool-68-161-167-156.ny325.east.verizon.net [68.161.167.156]
pool-68-161-42-244.ny325.east.verizon.net [68.161.42.244]
pool-68-161-59-43.ny325.east.verizon.net [68.161.59.43]
pool-68-162-13-70.nwrk.east.verizon.net [68.162.13.70]
pool-68-162-145-6.pitt.east.verizon.net [68.162.145.6]
static-68-162-251-148.bos.east.verizon.net [68.162.251.148]
static-68-162-85-97.phil.east.verizon.net [68.162.85.97]
pool-68-163-151-181.bos.east.verizon.net [68.163.151.181]
pool-68-163-66-254.res.east.verizon.net [68.163.66.254]
static-68-236-207-121.nwrk.east.verizon.net [68.236.207.121]
pool-68-237-213-60.ny325.east.verizon.net [68.237.213.60]
pool-68-238-16-251.rich.east.verizon.net [68.238.16.251]
pool-68-239-58-165.bos.east.verizon.net [68.239.58.165]
pool-70-104-104-209.chi.dsl-w.verizon.net [70.104.104.209]
pool-70-104-119-185.chi.dsl-w.verizon.net [70.104.119.185]
pool-70-105-12-148.rich.east.verizon.net [70.105.12.148]
pool-70-105-207-214.scr.east.verizon.net [70.105.207.214]
pool-70-106-208-58.chi.dsl-w.verizon.net [70.106.208.58]
pool-70-107-198-95.ny325.east.verizon.net [70.107.198.95]
static-70-107-239-188.ny325.east.verizon.net [70.107.239.188]
pool-70-108-31-161.res.east.verizon.net [70.108.31.161]
pool-70-109-107-92.alb.east.verizon.net [70.109.107.92]
pool-70-110-186-17.phil.east.verizon.net [70.110.186.17]
pool-70-16-121-96.scr.east.verizon.net [70.16.121.96]
pool-70-16-137-90.phil.east.verizon.net [70.16.137.90]
pool-70-17-10-94.balt.east.verizon.net [70.17.10.94]
pool-70-17-197-159.balt.east.verizon.net [70.17.197.159]
pool-70-17-75-173.res.east.verizon.net [70.17.75.173]
pool-70-18-148-156.norf.east.verizon.net [70.18.148.156]
pool-70-18-215-41.ny325.east.verizon.net [70.18.215.41]
pool-70-19-255-63.bos.east.verizon.net [70.19.255.63]
pool-70-20-192-78.phil.east.verizon.net [70.20.192.78]
pool-70-20-241-84.phil.east.verizon.net [70.20.241.84]
pool-70-20-45-51.man.east.verizon.net [70.20.45.51]
pool-70-20-54-159.man.east.verizon.net [70.20.54.15

Paul Mockapetris recieves ACM SIGCOMM lifetime award

[Fergie (Paul Ferguson)]

http://news.bbc.co.uk/1/hi/technology/4599147.stm

[and]

http://www.nominum.com/popupPressRelease.php?id=344

- ferg


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or [EMAIL PROTECTED]
 ferg's tech blog: http://fergdawg.blogspot.com/

RE: Administration Asks Appeals Court To Compel ISP Searches

[Hannigan, Martin]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Owen DeLong
> Sent: Wednesday, June 01, 2005 1:31 AM
> To: Jason Frisvold; Fergie (Paul Ferguson)
> Cc: nanog@merit.edu
> Subject: Re: Administration Asks Appeals Court To Compel ISP Searches
> 
> 

[ SNIP ]
 
> I have never seen an NSL and have never received one. 

IANAL, and I haven't seen one post yet, so I'd suggest
that if anyone has a question on the process or how it
affects them, _they contact a real lawyer_.

Latest publicly available NSL:

http://www.aclu.org/nsl/legal/NSL_formletter_080404.pdf


Latest FBI Memo on authority and filling out an NSL:

http://www.aclu.org/patriot_foia/FOIA/Nov2001FBImemo.pdf

Summary: Subpoena like, still requires internal approval,
not part of FISA, but statutory authority under the
Foreign Intelligence Surveillance Court.

Myth: Wiretap means voice surveillance. It insinuates it, but
voice intercept is least used out of the CALEA punclist, believe
it or not. Wiretap is used as a descriptor for all.

-M<

Re: port 25 connections up?

[Network Fortius]

http://isc.sans.org/port_details.php?port=25

Stef
Network Fortius, LLC

On May 31, 2005, at 8:21 PM, Jim Popovitch wrote:



I've seen an almost astronomical increase in bogus smtp connections
("did not issue MAIL/EXPN/VRFY/ETRN during connection to") within the
past 18 hours.  Up to +1100 today vs the usual 4 or 5.

Anyone else?

-Jim P.

Re: Administration Asks Appeals Court To Compel ISP Searches

[Kevin]

On 6/1/05, Chris Kuethe <[EMAIL PROTECTED]> wrote:
> On 5/31/05, Owen DeLong <[EMAIL PROTECTED]> wrote:
> > Not having received one, I have no gag order, so, I am free to tell you I
> > haven't received one.
> >
> > Owen
> 
> This assumes that the new breed of NSL doesn't require you to deny
> having received an NSL when questioned, unless you want to have some
> nebulous obstruction of justice, yadda yadda, mail fraud charge waved
> at you...

I've never received a NSL, just a few really badly written subpoenas. But
then I got out of the large-scale public ISP business a long time ago.

It'd take a heck of a gag order to compel the recipient to outright lie
about the fact that they are under a gag order;  when directly questioned
on the subject -- you must refuse to answer.  That doesn't mean you go
out of your to reveal the fact of the gag order, as in the above posts.

YMMV, IANAL, etc.


Kevin Kadow
--
As of June 1st, 2005 I am not under any court-imposed gag order.

Re: Administration Asks Appeals Court To Compel ISP Searches

[Chris Kuethe]

On 5/31/05, Owen DeLong <[EMAIL PROTECTED]> wrote:
> Not having received one, I have no gag order, so, I am free to tell you I
> haven't received one.
> 
> Owen

This assumes that the new breed of NSL doesn't require you to deny
having received an NSL when questioned, unless you want to have some
nebulous obstruction of justice, yadda yadda, mail fraud charge waved
at you...

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?