the mother of all credit card data thefts

[william(at)elan.net]

Get ready for even more scripkiddies stolen cc signups for ISP and other
services

-- Forwarded message --
Date: Sat, 18 Jun 2005 00:17:27 -0400
From: David Farber <[EMAIL PROTECTED]>
To: Ip ip 
Subject: [IP] the mother of all credit card data thefts?

Begin forwarded message:

From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
Date: June 17, 2005 6:38:57 PM EDT
To: [EMAIL PROTECTED]
Subject: the mother of all credit card data thefts?

MasterCard reported that over 40,000,000 credit card numbers, less
than half of which are MasterCards, may have been stolen.  CardSystems
Solutions, which processes transactions for merchants and banks,
was infected with a script that that targeted certain kinds of
transactions.  That is, this wasn't the usual carelessness, it was
a targeted attack by a sophisticated adversary.

The MasterCard statement is at
http://www.mastercardinternational.com/cgi-bin/newsroom.cgi?id=1038 .

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

-
You are subscribed as [EMAIL PROTECTED]
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/

New IANA IPv4 allocations to ARIN (74/8, 75/8, 76/8) and LACNIC (189/8, 190/8)

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

This is to inform you that on 17 June 2005 the IANA has
allocated the following two (2) IPv4 /8 blocks to LACNIC:

189/8, 190/8

and three (3) IPv4 /8 blocks to ARIN:

74/8, 75/8, 76/8

For a full list of IANA IPv4 allocations please see:


- --
Doug Barton
General Manager, The Internet Assigned Numbers Authority
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFCs2C8wtDPyTesBYwRAscHAKCQEWrG96z/1FmhZWl1Mrt13hzBngCeNUCF
SldR9Wbc4WTNoLoI7dJlKJc=
=cq00
-END PGP SIGNATURE-

Re: Email peering

[Mike Leber]

On Fri, 17 Jun 2005 [EMAIL PROTECTED] wrote:
> > Similar concept, same scaling problems; it just hides the explicit 
> routing
> > from the user (as would any modern "peering" system, presumably).
> 
> Then you are presuming wrongly. Nowhere in what I wrote have
> I suggested any changes in the existing email technology. I am
> not suggesting that we drop SMTP in favour of your favourite
> old dusty protocol. I am suggesting that we need a system of
> accountability for people who run Internet email servers based
> on contracts and SLAs, i.e. peering agreements.

In between the choice of accepting mail from *anybody* by default which we
have now and the choice of accepting mail from *nobody* by default that
explicit peering agreements represents there is another solution; which is
to accept mail only from IPs that have *some relation* to the sender's
>From domain, for example by MX record or by reverse DNS (we implemented
that test and call it MX+).

Here is a downloadable reference implementation for use with procmail:

http://mxplus.org/

The example program mxplus is code that was carved out of the mail server
software we use and made standalone.  It's an antispam option that works
well for many users.  The example includes sender email address
validation, which is another test like MX+ that works well for most users
and breaks under usually acceptable circumstances when senders do bad
things like send email with an invalid From address.  YMMV.

Mike.

+- H U R R I C A N E - E L E C T R I C -+
| Mike Leber   Direct Internet Connections   Voice 510 580 4100 |
| Hurricane Electric Web Hosting  Colocation   Fax 510 580 4151 |
| [EMAIL PROTECTED]   http://www.he.net |
+---+

Telephone pedestals

[james edwards]

I am looking for a seller of outdoor Telephone pedestals. I plan to install
a DSLAM, post splitters
and associated cross connect gear in this enclosure. Can anyone suggest a
dealer for this sort of gear ?

James H. Edwards
Routing and Security Administrator
At the Santa Fe Office: Internet at Cyber Mesa
[EMAIL PROTECTED]  [EMAIL PROTECTED]
http://www.cybermesa.com/ContactCM
(505) 795-7101

NANOG Program Committee Announcement

[Steve Feldman]

I am pleased to announce that the three new members of the
NANOG Committee are:
 
Joe Abley
Henry (Hank) Kilmer
Christopher Morrow

Although we had many fine, well-qualified candidates to choose among,
we were only able to select people for the three openings.

Please join me in welcoming Joe, Hank, and Chris to the PC.
As always, our focus now turns to producing the finest possible
program for the October meeting in Los Angeles.

For the PC,
Steve Feldman
chair

Weekly Routing Table Report

[Routing Table Analysis]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to [EMAIL PROTECTED]

If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>.

Routing Table Report   04:00 +10GMT Sat 18 Jun, 2005

Analysis Summary


BGP routing table entries examined:  165397
Prefixes after maximum aggregation:   95434
Unique aggregates announced to Internet:  79395
Total ASes present in the Internet Routing Table: 19882
Origin-only ASes present in the Internet Routing Table:   17316
Origin ASes announcing only one prefix:8118
Transit ASes present in the Internet Routing Table:2566
Transit-only ASes present in the Internet Routing Table: 73
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  24
Prefixes from unregistered ASNs in the Routing Table:17
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space: 15
Number of addresses announced to Internet:   1401700320
Equivalent to 83 /8s, 140 /16s and 63 /24s
Percentage of available address space announced:   37.8
Percentage of allocated address space announced:   59.4
Percentage of available address space allocated:   63.7
Total number of prefixes smaller than registry allocations:   78031

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:34130
Total APNIC prefixes after maximum aggregation:   15802
Prefixes being announced from the APNIC address blocks:   32016
Unique aggregates announced from the APNIC address blocks:15851
APNIC Region origin ASes present in the Internet Routing Table:2291
APNIC Region origin ASes announcing only one prefix:670
APNIC Region transit ASes present in the Internet Routing Table:344
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 17
Number of APNIC addresses announced to Internet:  187147392
Equivalent to 11 /8s, 39 /16s and 164 /24s
Percentage of available APNIC address space announced: 69.4

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911
APNIC Address Blocks   58/7, 60/7, 124/7, 126/8, 202/7, 210/7, 218/7,
   220/7 and 222/8

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes: 89145
Total ARIN prefixes after maximum aggregation:54093
Prefixes being announced from the ARIN address blocks:69679
Unique aggregates announced from the ARIN address blocks: 25491
ARIN Region origin ASes present in the Internet Routing Table:10019
ARIN Region origin ASes announcing only one prefix:3671
ARIN Region transit ASes present in the Internet Routing Table: 937
Average ARIN Region AS path length visible: 4.3
Max ARIN Region AS path length visible:  18
Number of ARIN addresses announced to Internet:   250583808
Equivalent to 14 /8s, 239 /16s and 155 /24s
Percentage of available ARIN address space announced:  71.1

ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
   3354-4607, 4865-5119, 5632-6655, 6912-7466
   7723-8191, 10240-12287, 13312-15359, 16384-17407
   18432-20479, 21504-23551, 25600-26591,
   26624-27647, 29696-30719, 31744-33791
   35840-36863
ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/6, 198/7, 204/6,
   208/7 and 216/8

RIPE Region Analysis Summary


Prefixes being announced by RIPE Region ASes: 31449
Total RIPE prefixes after maximum aggregation:21642
Prefixes being announced from the RIPE address blocks:28502
Unique aggregates announced from the RIPE address blocks: 19126
RIPE Region origin ASes present in the Internet Routing Table: 6755
RIPE Region origin ASes announcing only one prefix:3554
RIPE Region transit ASes present in the Internet Routing Table:1118
Average RIPE Region AS path length visible: 5.2
Max RIPE Region AS path length visible:  24
Number of RIPE addresses announced to Internet: 

[NON-OPERATIONAL] Re: NANOG Evolution

[Daniel Golding]

Randy,

People's employers are posted at http://www.nanog.org/candidates05.html.

It gets a bit complicated because some folks work at "infrastructure"
companies - collocation/peering or DNS (Mark, Bill, Josh, Marty). Others do
significant consulting work for large providers or hosters, but aren't
actually employed by any of them at present (at least Steve and myself,
probably some others). It gets more fun because sometimes folks who work for
operators or hosters are actually researchers who don't do lots of
operational things (and other times, they are researchers who actually DO
lots of operational things).

I'd guess folks can look at the bios and figure it all out for themselves :)

- Dan

On 6/17/05 10:55 AM, "Randy Bush" <[EMAIL PROTECTED]> wrote:

> 
>> The candidates for the Steering Committee are:
>>Joe Abley
>>Randy Bush
>>Christopher Chin
>>Ron da Silva
>>Vince Fuller
>>Steve Gibbard
>>Dan Golding
>>Martin Hannigan
>>Dorian Kim
>>Mark Kosters
>>Jared Mauch
>>Chris Morrow
>>William B. Norton
>>Philip Smith
>>Josh Snowhorn
>>Dave Wodelet
>>Lixia Zhang
> 
> could you annotate which of these candidates actually work
> at an isp or large content provider?
> 
> randy
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

RE: AT&T outage?

[Jonathan M. Slivko]

I should probbably say my equipment on AT&T's IP network - not the core
network.

--
  Jonathan M. Slivko - [EMAIL PROTECTED]
"Linux: The Choice for the GNU Generation"
  - http://www.linux.org/ -

Don't fear the penguin.
  .^.
  /V\
/(   )\
 ^^-^^
   He's here to help. 

-Original Message-
From: Matt Taber [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 17, 2005 1:14 PM
To: [EMAIL PROTECTED]
Subject: Re: AT&T outage?

Where in GR did you see that alarm for AT&T?

~
Matt Taber [EMAIL PROTECTED]
WMIS Internet http://www.wmis.net
616-281-9647   1-888-482-9647
   "Accelerate ... It's a Speed Thing"
~


Jonathan M. Slivko wrote:
> H. I saw some alarms on equipment on AT&T's IP network in Grand
> Rapids, MI a while ago. The alarm only lasted 10-15 minutes though.
> 
> --
>   Jonathan M. Slivko - [EMAIL PROTECTED]
> "Linux: The Choice for the GNU Generation"
>   - http://www.linux.org/ -
> 
> Don't fear the penguin.
>   .^.
>   /V\
> /(   )\
>  ^^-^^
>He's here to help. 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Tom
> Sands
> Sent: Friday, June 17, 2005 12:57 PM
> To: Jim McBurnett
> Cc: nanog@merit.edu
> Subject: Re: AT&T outage?
> 
> 
> Only issue we've seen is a number of people connecting Cogent to AT&T in 
> DFW.
> 
> 
> Jim McBurnett wrote:
> 
> 
>>Has anyone seen a major issue out of Atlanta with AT&T...
>>
>>Thanks,
>>Jim
>>
>> 
>>
> 
> 

Re: Email peering

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]
om>, [EMAIL PROTECTED] writes:
>
>> Similar concept, same scaling problems; it just hides the explicit 
>routing
>> from the user (as would any modern "peering" system, presumably).
>
>Then you are presuming wrongly. Nowhere in what I wrote have
>I suggested any changes in the existing email technology.

Quite apart from anything else, this requires an email routing protocol.
Getting the policy statements right in such a protocol is a non-trivial 
task; it will make BGP look simple, because of the implied liability a 
mail sender would incur under this scheme.

Let me be very specific.  I own a 1U server in a rack somewhere.  (The 
concept has been discussed here many times, of course; thanks to some 
friends, I can actually do it.)  How do I send email?

Well, maybe the colo operator has a mail server.  Maybe the rack 
operator has mail-forwarding contracts with his upstream IP (i.e., BGP) 
peering providers.  To whom can they send mail?  More precisely, with 
whom have they signed contracts that will let them deliver mail, and 
under what conditions?  Maybe one of the upstreams has better contracts 
in some countries than the other does, or maybe the other will charge 
me less for delivering my email, but with a hefty chargeback to me if 
it's found to be spam.  Or maybe one of them won't talk to (or listen 
to) mailers in certain parts of the world -- we've seen that alleged 
and/or bragged about on this list -- because of perceptions of where 
spam comes from.  But the better mail server I'd prefer to use is down 
today, because of a fiber cut/DDoS attack/spam overload.  How do I 
know, and how do I fall back to an alternate?

We can all invent more scenarios.  I think we can all see the analogies 
to BGP, too -- and we all know how hard it is to get that to do what we 
want.

The scheme you're suggesting might work without new protocols in a 
purely hierarchical world.  It might even work with a fully-connected 
cluster of Tier 1s, each of which is a tree root.  But the Internet 
doesn't work that way, or we'd all be using EGP for routing.

Besides, as I mentioned the other day, there are policy side-effects.  
See 
http://news.com.com/Your+ISP+as+Net+watchdog/2100-1028_3-5748649.html?tag=nefd.top
for an example of the kind of thing I'm worried about.  

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

RE: AT&T outage?

[Jonathan M. Slivko]

H. I saw some alarms on equipment on AT&T's IP network in Grand
Rapids, MI a while ago. The alarm only lasted 10-15 minutes though.

--
  Jonathan M. Slivko - [EMAIL PROTECTED]
"Linux: The Choice for the GNU Generation"
  - http://www.linux.org/ -

Don't fear the penguin.
  .^.
  /V\
/(   )\
 ^^-^^
   He's here to help. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom
Sands
Sent: Friday, June 17, 2005 12:57 PM
To: Jim McBurnett
Cc: nanog@merit.edu
Subject: Re: AT&T outage?


Only issue we've seen is a number of people connecting Cogent to AT&T in 
DFW.


Jim McBurnett wrote:

>Has anyone seen a major issue out of Atlanta with AT&T...
>
>Thanks,
>Jim
>
>  
>

-- 
--
Tom Sands   
Chief Network Engineer  
Rackspace Managed Hosting  
(210)447-4065   
--

Re: AT&T outage?

[Tom Sands]

Only issue we've seen is a number of people connecting Cogent to AT&T in 
DFW.



Jim McBurnett wrote:


Has anyone seen a major issue out of Atlanta with AT&T...

Thanks,
Jim

 



--
--
Tom Sands   
Chief Network Engineer  
Rackspace Managed Hosting		   
(210)447-4065		   	

--

Re: Email peering

[Ben Hubbard]

[EMAIL PROTECTED] said:

> That's strange because you just finished describing how
> SOME companies are already engaging in email peering on
> a piecemeal basis. And how these companies ARE finding
> this to be beneficial in reducing costs. So please explain
> why my suggestion about widespread email peering agreements
> won't work?

Because I don't think "some companies" == "the entire population of email
users", or even a sizable (ie widespread) part of that population.

A large number of people are fine with the current system, and thus won't
pay more for something else. Me, for example.

Those who are unhappy will pay more for a better solution, and some small
number with really deep pockets may be at that point where they will pay
for something like "business class" email, in addition to the "tourist
class" email they already have.

You seem to repeatedly describe a solution that becomes so big that it (at
least substantially) replaces 25/SMTP. That's what I don't think will
work, or is needed.

> And please don't suggest that webs of trust are not
> scalable. Given the techniques of scaling that we have
> in the 21st century, I simply don't believe that.

I don't think either are relevant to this discussion. In the utility model
you seem to talk about (and that I was talking about) all you care about
is the provider. If you contract with them for traceable, trusted spam
free email, and they give you something less than that, they pay a
penalty. The utility knows, and has a contractual relationship with, each
endpoint, and presumably can keep track of traffic in its own network.
Problem solved.

And the whole thing doesn't need to scale, because there are a severely
limited number of companies that would be willing to pay the costs for
such a service. But they are out there, and one might be able to make a
business out of it.


Best,
Ben

Re: Email peering

[Michael . Dillon]

> Many large organizations already have already, in a case by case way, 
set
> up private mail peering with others they exchange large volumes of mail
> with. This "trusted traffic" is often able to bypass the expense and 
delay
> of the spam-filter farm, making the cost and hassle of a parallel mail
> infrastructure worthwhile to them, and everyone is happy.

Sounds good.

> I don't think what you have been talking about so far will work, and I
> don't think I'm alone in that. 

That's strange because you just finished describing how 
SOME companies are already engaging in email peering on
a piecemeal basis. And how these companies ARE finding
this to be beneficial in reducing costs. So please explain
why my suggestion about widespread email peering agreements
won't work?

And please don't suggest that webs of trust are not 
scalable. Given the techniques of scaling that we have
in the 21st century, I simply don't believe that.

--Michael Dillon

Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's SenderIDAuthentication......?]

[Ben Hubbard]

[EMAIL PROTECTED] said:

> That is something that businesses will pay for.
>
> But first, ISPs have to put their hands up and take
> collective responsibility for Internet email as a service
> that has value and not just as some kind of loss leader
> for Internet access services.

Many large organizations already have already, in a case by case way, set
up private mail peering with others they exchange large volumes of mail
with. This "trusted traffic" is often able to bypass the expense and delay
of the spam-filter farm, making the cost and hassle of a parallel mail
infrastructure worthwhile to them, and everyone is happy.

There is no reason you can't pick another port, modify one of the many
FOSS mail servers out there to do whatever it is you are proposing, and
start providing this kind of thing on a more formal basis. Call it an
email toll-road.

(hm, would a toll-road be troll free? I might pay for that).

If you are able to create a solution that works, and that people will pay
for, then you'll be happy. Since it works in parallel, it won't disrupt
anyone who doesn't want to play along, so they won't be anymore unhappy
than they are now.

I don't think what you have been talking about so far will work, and I
don't think I'm alone in that. But hey, prove me wrong, and maybe someday
I'll be writing a check to you to make sure I get email every day.

Best,
Ben

Re: The Cidr Report

[Hank Nussbacher]

I was hoping the report would be cleaned up by now but it hasn't so sorry
for the multiple list post.  The Bogon section is IMHO, broken.

Taking just the 1st line as an example:
Prefix Origin AS   AS Description Unallocated block
3.0.0.0/8   AS80   GE-CRD - General Electric Company 0.0.0.0 - 3.0.0.0

3.0.0.0/8 is allocated, as is AS80.  I suspect the algorithm, which
determines the unallocated block of 0.0.0.0 - 3.0.0.0 to be somewhat
broken.

There are thousands of lines like that.

The bogus AS section also appears to be broken.

-Hank

Re: NANOG Evolution

[Randy Bush]

> The candidates for the Steering Committee are:
>Joe Abley
>Randy Bush
>Christopher Chin
>Ron da Silva
>Vince Fuller
>Steve Gibbard
>Dan Golding
>Martin Hannigan
>Dorian Kim
>Mark Kosters
>Jared Mauch
>Chris Morrow
>William B. Norton
>Philip Smith
>Josh Snowhorn
>Dave Wodelet
>Lixia Zhang

could you annotate which of these candidates actually work
at an isp or large content provider?

randy

NANOG Evolution

[Betty Burke]

Hello Everyone:>

We are very happy to report the next steps in the evolution of NANOG are 
underway. We welcome your support and feed-back.


The new NANOG charter is available at:
http://www.nanog.org/charter.html
changes in the new charter include:

Section 5:  added a parenthetical clause so the text now reads: "Anyone who 
has registered for a NANOG meeting in the previous two years (as of the 
opening date of voting) may vote in any matter which comes before the 
community for a vote."


Section 6:  moved two sentences to section 6.3:  "No action may be taken by 
the committee unless at least four members of the committee are present. 
Those items on which the Steering Committee votes will be decided by 
absolute majority."


Section 6.2.1 - old version:  "Because a large Program Committee will be 
better able to handle the heavy workload, the Program Committee will 
consist of 16 members (plus one member appointed by Merit)."


New version: "The Program Committee will consist of 16 members appointed by 
the Steering Committee plus one member appointed by Merit."

-

The candidates for the Steering Committee are:
  Joe Abley
  Randy Bush
  Christopher Chin
  Ron da Silva
  Vince Fuller
  Steve Gibbard
  Dan Golding
  Martin Hannigan
  Dorian Kim
  Mark Kosters
  Jared Mauch
  Chris Morrow
  William B. Norton
  Philip Smith
  Josh Snowhorn
  Dave Wodelet
  Lixia Zhang
Further information found at:
http://www.nanog.org/candidates05.html
--

Community members eligible to vote in the 2005 NANOG Steering Committee 
election are found at:

http://www.nanog.org/voters05.html
To qualify, you must have attended at least one NANOG meeting in the past 
two years, i.e., between fall 2003 (Chicago, NANOG 29) and spring 2005 
(Seattle, NANOG 34).
Email addresses will be used to authenticate voters during the election. 
Voters for whom Merit does not have an email address are marked with ***. 
If your name is marked, or if you're not listed and believe you should be, 
please send e-mail to [EMAIL PROTECTED]

--

A new email list, [EMAIL PROTECTED], for discussion of the 
elections has been created.  Merit will handle moderation of the new list 
per the aup found at:

http://www.nanog.org/aup.elections.html
(Everyone on nanog-futures is automatically subscribed, and we'll also 
subscribe all eligible voters for whom we have email addresses.) 
Information regarding the election process will be sent to this list is a 
few days.

-

Information regarding the NANOG list moderation committee is found at:
http://nanog.org/listadmins.html
-

Lastly, very soon, Steve Feldman (current PC Chair) will be sending 
information regarding the new Program Committee members.

-

In summary, THANK YOU to so many for their support, extra time and 
assistance.  Merit and the NANOG community are very grateful.  As always, 
please feel free to send email or call if you have questions regarding this 
email or the NANOG evolution process.


All the best!:>

Betty Burke and Susan Harris
Merit Network

AT&T outage?

[Jim McBurnett]

Has anyone seen a major issue out of Atlanta with AT&T...

Thanks,
Jim

Re: Email peering

[Suresh Ramasubramanian]

On 17/06/05, Joe Maimon <[EMAIL PROTECTED]> wrote:
> DNSWL -- this is already being done. It is not widely viewed as being in
> any way similar to a peering concept. What would be more similar would
> be a consortium of large providers providing such a whitelist. That
> would be something I would welcome.

Something that is already being setup, and that tends to add a slight
amount of reputation to any authentication schemes that might be used,
is a "feedback loop"

Kind of like what we do, or what AOL does (http://postmaster.info.aol.com/fbl/)

Not public as such, but well it is as much like peering as anything in
the smtp email world can be. [e&oe gateways to uucp and x400]

-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: Email peering

[Joe Maimon]

[EMAIL PROTECTED] wrote:
Similar concept, same scaling problems; it just hides the explicit 


routing


from the user (as would any modern "peering" system, presumably).







One way that it COULD be implemented is for people accepting
incoming email on port 25 to check a whitelist before accepting
email. Only operators who have signed a peering agreement would
be on the whitelist. Presumably, the whitelist would be served
up by your regional association and they would have some means 
of relaying queries (or synchronizing their database) with the
other 4 regions. 



DNSWL -- this is already being done. It is not widely viewed as being in 
any way similar to a peering concept. What would be more similar would 
be a consortium of large providers providing such a whitelist. That 
would be something I would welcome.


I would settle for having aol,msn,yahoo,earthlink,cablevision or any 
half dozen providers making public THEIR whitelists.


The problem is that there does not appear to be any incentive for them 
to do so -- fee or no fee.


In fact, I would encourage anyone planning on ragging on DNSBL's to put 
up AND shut up, namely operate a DNSWL.


Existing public whitelists include:

exemption.ahbl.org
bondedsender.org
habeas.com


To use it with sendmail:

jlewis's http://njabl.org/dnswl.m4
http://groups-beta.google.com/group/comp.mail.sendmail/msg/a26d1cbd1c739626

To use it with spamassassin:

header XXX_DNSWL eval:check_rbl('xxx-firsttrusted', 'xxx.ttec.net')
score XXX_DNSWL -5


Anyone else with a public DNS whitelist?

Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]

[Michael . Dillon]

> > The thousands of bilateral BGP peering contracts are most
> > definitely comparable to the email peering that I am 
> > proposing.
> 
> Dude, it's 2005.  You can put down the X.400 crack pipe now.

Why does fixing the SMTP email architecture by applying some
lessons learned from BGP peering lead people to talk about
X.400, UUCP, Bitnet, Fidonet and other obsolete protocols?

You're right, it's 2005 and we have suffered from email
SPAM for 10 years now, getting worse every year. So when
are we going to admit that SMTP-based email is *NOT* the
superior solution for email that we all thought it was
in 1995? 

--Michael Dillon

Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]

[Michael . Dillon]

> There are, however, three very big problems.  First, it forces people to 

> pay for services that they don't pay for today. 

Businesses often pay, not for services, but for accountability.
They want someone else to take responsibility for a problem
even if it costs them more money than taking that responsibility
on themselves. Insurance, maintenance contracts, etc.

Today, if Joe Business gets lots of spam, it is not his
ISP's responsibility. He has no-one to take responsibility
for this problem off his hands. But if he only accepts
incoming email through an operator who is part of the
email peering network, he knows that somewhere there is
someone who will take responsibility for the problem.

That is something that businesses will pay for.

But first, ISPs have to put their hands up and take
collective responsibility for Internet email as a service
that has value and not just as some kind of loss leader
for Internet access services.

--Michael Dillon

Re: Email peering

[Michael . Dillon]

> Similar concept, same scaling problems; it just hides the explicit 
routing
> from the user (as would any modern "peering" system, presumably).

Then you are presuming wrongly. Nowhere in what I wrote have
I suggested any changes in the existing email technology. I am
not suggesting that we drop SMTP in favour of your favourite
old dusty protocol. I am suggesting that we need a system of
accountability for people who run Internet email servers based
on contracts and SLAs, i.e. peering agreements.

I haven't specified how it would be implemented because I expect
that the companies negotiating such agreements would specify this
in some kind of operational best-practices document.

One way that it COULD be implemented is for people accepting
incoming email on port 25 to check a whitelist before accepting
email. Only operators who have signed a peering agreement would
be on the whitelist. Presumably, the whitelist would be served
up by your regional association and they would have some means 
of relaying queries (or synchronizing their database) with the
other 4 regions. 

Let's face it, people have described a lot of best practices
for running SMTP based email services but there has never
been a concerted effort to implement these in some methodical
way. It has always been a case of preaching to the converted
at NANOG or on some lists. And it just does not scale!

--Michael Dillon