Re: Lazy network operators

[Stewart, William C (Bill), RTSLS]

As far as your own incoming mail is concerned,
you get the same results by either requiring almost every ISP in the world
to block outgoing SMTP from almost all of their users, 
or by using a blocking list that blocks the same users.
The blocking list approach preserves the end-to-end behavior of the Internet,
and lets the end users decide whose opinions to follow about
which Internet users are first-class citizens vs. second-class citizens.
 
Of course, I was planning to write that comparison before
the recent complaints about how bad a job SORBS is doing
on deciding who to block. :-)  But it's still equivalent.

If an ISP wants to be "responsible" about preventing untrustworthy users
from sending SMTP that bothers people, they can contribute to blocking lists
rather than dropping the users' packets, and the blocking lists can provide
some convenient mechanism for the ISPs to update them.  

Where the two approaches diverge is that the recipient-based approaches
can also support whitelists, either individually run or 
shared exception systems such as Habeas or bonded sender things,
while the ISP-blocking approach isn't something you can easily override,
except by doing tunneling or other protocol-heavy workarounds.

 Bill Stewart, [EMAIL PROTECTED]

Re: Lazy network operators

[Iljitsch van Beijnum]

On 15-apr-04, at 2:45, Paul Vixie wrote:

preventing DDoS and IP source address forgery each also break what the
IAB calls "the end-to-end model".
How so?

(dunno if you heard, but in spite of 128 bits of
address space, the enterprise user community is now asking for IPv6 
NAT.)
I hadn't, pointer please?

Re: SORBS Insanity

[Matthew Sullivan]

In case you didn't know, SORBS admins do populate this list from time to 
time, so I might be worth going through a few things...

Jeremy Kister wrote:

I became aware that just about all of 64.115.0.0/16, a network that I (among
others) run, has been listed as "dynamic ip space" in sorbs as of April 2nd.
On
April 6th I sent my first email (via web-form) to sorbs telling them they
were mistaken.
What address did you use?  What tracking number did you get?

 Finding no documentation on how they deem networks "dynamic" or
"static" I changed my rDNS scheme from ppp-64-115-x-x to 64-115-x-x  Note
to all: "ppp" in no way signifies dial-up; we run ppp over almost every
circuit we have -- from dialup to OC12, to Ethernet and ATM.
I also stated how all of our network was scanned twice a day for open-relay
mail servers.  Being a bigish ISP, we are _huge_ on our abuse policies, and
our abuse bucket [usually] has only memories of tumbleweed blowing by.
On april 10th I again wrote, only to be ignored further.

Again, tracking number please?  Address you used?

The reason I am asking is I only fine one ticket from the address you 
posted from.

Yesterday, April 13th, One of my customers opened a trouble ticket stating
that he had successfully received a response from SORBS, and had forwarded
me the conversation.  I sent an email to [EMAIL PROTECTED] (the author of the
email) quoting what they had written one of my customers.  They said to my
customer that I had to either provide custom reverse DNS for each customer
who was not dynamic, or I had to provide sorbs with POCs for all my
non-dynamic customers.  I stated how this was absurd, and that there was
already a functioning medium for this task -- rwhois.
In this same email, I also stated:
1.  exactly which 64.115 networks were dynamic
I gather then you are not actually '[EMAIL PROTECTED]' then (see 
below)...

2.  that to prevent further hysteria, I had changed the reverse dns from
 ppp-64-115-x-x to static-64-115-x-x and dynamic-64-115-x-x,
 respectively.
And yet the mail I received from '[EMAIL PROTECTED]' - which I 
found oddly worded for a professional - stated there are no dynamic 
blocks in the entire /16  Which is it?

3.  their blindness was very unprofessional, deeming SORBS a Worthless
 Project ran by Ignorant Half-Wits
..who are unpaid, for both answering tickets, and the time in dealing 
with obnoxious people who threaten various amounts of legal action... 
not to mention the cost involved in running the services to both the 
owner and those who generously give resourses to the SORBS project

Actually the instructions I have given to those answering the DUHL 
tickets are that if there is no rDNS or rDNS that may indicate the 
address space is not static then they are to accept requests only from 
the confirmed RIR PoC... This is specifically because every man and his 
dog come to us explaining how their part of the net is not dynamic.

As of this date I have not received a response from anyone at sorbs, and do
not expect one.   Our support crew is overwhelmed with upset customers who
cant send email to their associates.  Our only response to them is that we
have tried to resolve the issue, but could not, and that the remote ISP
should stop using sorbs.
Funny the person logging the first ticket also said that...

I am upset that they blindly blacklisted most of 64.115.0.0/16 because some
of the reverse dns was generic.  64.115.47.0/25, for example, hasnt very
much generic rDNS at all, but was blacklisted just the same.
It was blacklisted because of a tipoff from someone from who is widely 
known at trusted.  I checked up on the tip, and in this case I either 
didn't look close enough, or your rDNS has changed significantly for the 
network

I hope all stop using SORBS.  I especially hope Mr. Vixie reconsiders his
helpfulness to such a harmful organization.
 

Now I'm not going to reveal details of the actual comments in the 
tickets unless you grant your permission and indicate which ticket(s) 
are yours...

I will say though as there are no indications of any dynamic ranges in 
any of the tickets logged, I spent all day yesturday going through the 
rDNS logs for the entire /16 (yes we do go through the entire dump), and 
had I not spent until the early hours of the morning this morning 
tracking a DoS attack, and then most fo the day in my dayjob I would 
have already have fixed this... but I guess by your post that doesn't 
matter.

Yours

Matthew

Re: SORBS Insanity

[Matthew Sullivan]

Jeff Kell wrote:

Jeremy Kister wrote:
[... giant snip ...]
We are a former user of SORBS.  Our issue was not that of dynamic IPs, 
but rather their spamtrap listings.  A few weeks ago, at least two of 
Comcast's legitimate mail servers was blacklisted.  As Comcast has a 
majority of the cable service in our area, we have a lot of users that 
use Comcast as their ISP.  Needless to say, listing several of 
Comcast's prominent mail servers caused our mailers to reject the mail 
with the SORBS bounce reply.  We have since ceased using SORBS and 
cured the Comcast problem, as well as a couple of other unrelated (and 
previously unreported) problems. 
I do recommend anyone using the complete DB to whitelist any major 
mailservers 'near' them.  If you can't do this I recomend you use 
tagging and/or use 'safe.dnsbl.sorbs.net' which doesn't contain the spam 
DB, but does contain all other DBs.

But I have/had a considerable degree of respect for SORBS, and as part 
of our abuse department, I dutifully report all of our reported spam 
deliveries to SpamCop.  When SpamCop does it's analysis and notes that 
the spam in question was listed in SORBS, I now cringe.  It would have 
been blocked.

So currently I'm considering asking for partial zone transfers of some 
of their blocks (our mailer doesn't discriminate against the DNS 
return address being 127.0.0.x or 127.0.0.y, a hit is a hit) and 
omitting at least the 'spamtrap' portion (for the same reason we don't 
use SpamCop directly -- the knee-jerk false positives outweigh the 
real hits to upset a considerable portion of our user base). 
safe.dnsbl.sorbs.net - available on all the public DNS servers and by 
using the zonefiles.

From the opposite standpoint in acting on spam that originates in our 
domain, everything to date has been a compromised machine and/or virus.
If SpamCop lists our registered mailers, I can at least respond from 
the abuse address that the problem has been corrected and there are no 
further interruptions in our mail service.  I can only imagine the 
problems if you end up blacklisted by SORBS if their response time and 
effort is really this low for cleaning up their lists.  While the big 
ISPs may not act immediately (or at all) on compromised hosts with 
trojan proxies, we do keep a tight lid on it (and block SMTP from 
end-users at egress, but that is another discussion). 
You will note my post before Christmas about the up and coming 
whitelisting mechanism - I am still collecting details for people 
wanting to use it - unfortunately for a variety of reasons the 
whitelisting mechanism is still not ready to go public.

Yours

Matthew

Re: SORBS Insanity

[Joe Maimon]

Matthew Sullivan wrote:


You will note my post before Christmas about the up and coming 
whitelisting mechanism - I am still collecting details for people 
wanting to use it - unfortunately for a variety of reasons the 
whitelisting mechanism is still not ready to go public.

Yours

Matthew


Speaking about whitelistingcomp.mail.sendmail google 
link...Reproduced below..

http://groups.google.com/groups?q=sendmail+whitelist+dns&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=ac4e9990.0311250514.65c4e614%40posting.google.com&rnum=9

Hello all,

I was wondering if any of you use *dns* lists for whitelisting purposes.
I have found a couple of whitelists online (bondedsenders) and their
m4 was far from satisfactory. I have found that the below (trivial)
modification to dnsblaccess.m4 allows me to specify that a specific
return value from the access map will *whitelist* the connection.
Has anyone gone in this direction before?

Joe M

--- dnsblaccess.m4  Sun May 19 17:30:06 2002
+++ /usr/lib/*sendmail*-cf/hack/dnsblaccess.m4Tue Nov 18 08:03:14
2003
@@ -90,5 +90,6 @@
R $*$#error $@ $1.$2.$3 $: $4
R $* $#error $: $1
R $*  $#discard $: discard
+R<*WHITELIST*> $*$#OK
R<$*> $*   $#error $@ 5.7.1 $: _EDNSBL_MSG_
divert(-1)

Re: SORBS Insanity

[Matthew Sullivan]

Jeremy Kister wrote:

I became aware that just about all of 64.115.0.0/16

In this same email, I also stated:
1.  exactly which 64.115 networks were dynamic
Ok now I have settled into another night of fixing things...  I see no 
mails from yourself in the ticketting system which indicate dynamic 
ranges - all seem to just demand delisting of all the blocking the /16 
statin gthey are all static (I have not looked at tickets owned by 
the other SORBS staff)

In your mail you indicated some of the rDNS is clear in that it 
indicates what address ranges are dynamic, and you also say above you 
have stated them - so I have removed the /16, now lets see a little help 
and give us this list, and I will then be able to list them 
otherwise I will have to go back to analysing the rDNS dump and guessing 
which are which again.

Yours

Mat

Re: SORBS Insanity

[jlewis]

On Thu, 15 Apr 2004, Joe Maimon wrote:

> Speaking about whitelistingcomp.mail.sendmail google
> link...Reproduced below..
>
> http://groups.google.com/groups?q=sendmail+whitelist+dns&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=ac4e9990.0311250514.65c4e614%40posting.google.com&rnum=9

ok...you've now drifted way off-topic for NANOG IMO.  This belongs in
spam-tools or spam-l.

> I was wondering if any of you use *dns* lists for whitelisting purposes.

Yes...for several years.

> I have found a couple of whitelists online (bondedsenders) and their
> m4 was far from satisfactory.

Why?  I came up with essentially the same rules (modified dnsbl.m4 to
support DNSWLs) as them back in 2001 and have been using it ever since at
multiple sites with privately maintained DNSWLs.  For that usage, it works
fine.  If you want to use it with someone else's DNSWL and they have
different 127.x.y.z return codes for different whitelisting reasons, sure,
it's too primitive, and you'll likely need to modify enhdnsbl.m4 to make
your own enhdnswl.m4, or do something similar.  Why the sendmail folks
have chosen to support DNSBLs but not DNSWLs, is still a mystery to
me...but this has little to do with network operations.

--
 Jon Lewis [EMAIL PROTECTED]|  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Lazy network operators

[John Payne]

--On Thursday, April 15, 2004 2:10 AM -0500 "Stewart, William C (Bill), 
RTSLS" <[EMAIL PROTECTED]> wrote:

or by using a blocking list that blocks the same users.
Unless you're using an AT&T nameserver it seems...

Re: Lazy network operators

[E.B. Dreger]

JA> Date: Wed, 14 Apr 2004 10:07:30 -0400
JA> From: Joe Abley

JA> There's a slight wrinkle with that for people who want to
JA> submit mail over SSL.
JA>
JA> Several graphical, consumer-grade mail clients let you select
JA> a port for "outgoing mail (SMTP)" and also have a checkbox
JA> for "use a secure connection (SSL)".

It gets worse:  OE/Outlook offer a "use Secure Password Auth"
option, which is _not_ SSL.

Although SMTP auth is orthogonal to SSL, they tend to be used
together.  When Netscape Communicator 4.7 is offered the chance
to authenticate, it _insists_ on authenticating.

Then certain Eudora versions have quirks IIRC...


Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
  DO NOT send mail to the following addresses :
  [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

Re: Lazy network operators

[E.B. Dreger]

JD> Date: Wed, 14 Apr 2004 12:16:46 -0700
JD> From: JC Dill

JD> We need to stop whining that it's "hard" or "expensive" do to
JD> the right thing and close loopholes that are abused by
JD> spammers.  It's much harder Aand more expensive long term to
JD> NOT do the right thing.

Leave it for future generations.  It works in politics.

(Detection of sarcasm is left as an exercise for the reader.)


Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
  DO NOT send mail to the following addresses :
  [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

Re: SPAM Directly from AT&T Data Networking

[Peter Galbavy]

John Curran wrote:
> incidents from almost every router vendor on the planet (and simply
> don't buy from the ones that fail to correct the problem).

Yep, that's the important one to me. Most of the time I don't really care
when a "brand" makes a stupid mistake, what I judge the company on is then
how they correct their mistake. Many in my personal experience (AMEX &
Orange in particular for me) fail to do anything and hope that you just go
away. So I do. Oh, I then make sure anyone who asks for my opinion in that
sector get my real views.

Peter

Re: TTY phone fraud and abuse

[Laurence F. Sheldon, Jr.]

Sean Donelan wrote:

On Sat, 10 Apr 2004, Scott Call wrote:

My point was that my $20 GE telephone cannot be made into a liability for
my telephone provider without my explicit participation, whereas a $20 a
month dialup (or $50 a month DSL, etc) customer can be a liability for me
just by being turned on.
Although Bell Labs avoided publishing papers about weakness in the
telephone system, it doesn't mean they don't exist.  The Communications
Fraud Control Assocation has a decent publication on communications
fraud.
Seems like John Draper had the corner on that market for a very long
time--1960's wasn't it when we had modify all the SF's?
--
Requiescas in pace o email

Gambling on power: Learning lessons

[Sean Donelan]

The power at the Bellagio failed for about three days.  The failure
involved about 1,000 feet of internal primary power cable.  Although
the Bellagio had emergency and backup power, because it was an internal
cable, the backup generators couldn't supply power either.  The Las Vegas
Sun has one of the best general media coverage I've seen of a technical
issue involving power failures.

Some data centers and colo facilities would be vulnerable to the same
type of problem.  Its difficult and expensive to protect against
everything in a single location.  Geographic diversity is almost always
and advantage.

http://www.lasvegassun.com/sunbin/stories/gaming/2004/apr/15/516694304.html

   The power outage that shut down the Bellagio and caused the evacuation
   of thousands of employees and customers could happen at any resort on
   the Las Vegas Strip and at any time, Clark County's top building
   inspector said Wednesday.

Re: SORBS Insanity

[Matthew Sullivan]

Jeremy Kister wrote:

Hi Matthew,

I highly appreciate your time in replying to my emails. I further
appreciate you removing 64.115.0.0/16 from the sorbs duhl.
One of my partners in crime sent the first email (via web-form) to sorbs on
April 6th. On april 10th, I repeated. both were addressed from
[EMAIL PROTECTED]  I havent received anything further about these.
Most of the time we investigate them first - if the contact is from the 
RIR PoC we contact them immediately (as soon as we get to the ticket of 
course)

On april 11th i helped a friend who is using 64.115.47.0/24 by filling out
the web-form, addressed from [EMAIL PROTECTED] i received
sorbs.net # 5799 on this. but again, this was only for that /24.
That's the one that I saw.

on april 13th at about 7pm, i sent the following email to [EMAIL PROTECTED]
from [EMAIL PROTECTED]
Ok didn't see this one - but it depends on the subject - I searched on 
the IP in the subject in this case.

true dynamic ranges out of the 64.115.0.0/16 are:
   



Got them and fixed up the DUHL.

to prevent further hysteria, dns now shows
"static-64-115-x-x.isp.broadviewnet.net".   it would have been quite
simple to send an email to {abuse,ipadmin,[EMAIL PROTECTED]
(as listed in ARIN lookup), call our support line (as listed in ARIN,
whois, and our web site), or send us a letter (as listed on our web site,
and whois information) to confirm your unfounded opinions about our
network.  Next time, you should give it a try; you may not receive such
emotional emails from frustrated Systems Engineers trying to deal with
worthless projects ran by ignorant half-wits.
As you can see I was quite frustrated at the time, and may have been a bit
harsh. At that point i was dealing with the problem for 10 days -- and saw
no end in sight.
End is awlways in sight, unfortunately not fast enough for some people - 
there is always the option of mailing me direct - the problem is (as 
always) I am probably the most busiest person at SORBS and have the 
least time to deal with tickets - the last 48-72 hours have have left me 
with time to answer 3 tickets.

All done now, I'll fix up the ticket closures when I get a chance.

Yours

Mat

Re: Lazy network operators

[Paul Vixie]

> > preventing DDoS and IP source address forgery each also break what the
> > IAB calls "the end-to-end model".
> 
> How so?

I was thinking of RFC 1958:

   An end-to-end protocol design should not rely on the maintenance of
   state (i.e. information about the state of the end-to-end
   communication) inside the network.

While this is given as an argument in favour of datagrams (vs. circuits)
as the best transport model, any stateful NAT or firewall violates it,
any router or loadbalancer flow-quota violates it, and pretty much anything
that can be done to protect against DDoS violates it.

I misspoke when I said that preventing IP source address forgery violates it.

> > (dunno if you heard, but in spite of 128 bits of address space, the
> > enterprise user community is now asking for IPv6 NAT.)
> 
> I hadn't, pointer please?

 comes to mind.  but
moreso the folks looking at deployment who absolutely don't want another
IPv4-like lockin, where provider-assigned addresses mean a huge renumbering
effort in order to change upstreams, and the expectation that globally
routeable address blocks will not be available, or will not be cost
effective, for enterprise or small-ISP use.  nowadays ietf is working on
what they call NAT-PT as a "transition" strategy, with a new set of heads
stuffed into the same old sand, whereby the designers think that network
owners are only going to use it until the ipv6 transition is complete.

it ain't so.  ipv4 CIDR was absolutely necessary to grow the internet, and
the wayback designers who thought that 12 million class C nets could ever
have been instantiated and routed were obviously not thinking about scale.
but ipv4 CIDR also had the effect of making end users fear their provider-
assigned IP addresses, and the real incentive for ipv4 NAT deployment
wasn't a lack of ipv4 address space but rather a lack of interest in
provider-assigned ("lockin") addressing.  it's still quite astounding to
me that when we finish deploying ipv6 we'll still have provider assigned
addresses that customers are afraid to use beyond the edge of their campus,
and we'll still have the age-old tension between "i could get global routing
for that address block" and "i could qualify with my RIR to obtain that
address block (and afford the fees)".

anyway, there will absolutely be NAT in ipv6 enterprise networks, but the
reason for it won't be a shortage of globally unique address space.