Re: Monitoring dark address space?

[Andrew - Supernews]

> "Paul" == Paul Vixie <[EMAIL PROTECTED]> writes:

 Paul> since this space has no dns records pointing into it, the only
 Paul> traffic it will see is from errors/typo's, and network
 Paul> scanners.

And blowback from other people forging your addresses as sources.

(We've had quite a few goober-with-firewall reports of that type -
especially from a certain manufacturer of networking equipment who
shall remain nameless, even though they ought to know better.)

 >> 3) What sort of threshold metrics for considering something to be 
 >> malicious have you found to be good?  (ports/second, ip/second, etc)

 Paul> the false positives are less than one in ten million.
 Paul> "blackhole 'em all."

If you're actually going so far as to accept the connections, yes. If
you're just counting packets, then a little more caution is possibly
indicated.

 Paul> it's a l-l-lotta d-d-data, m-m-man.  otoh, between this and
 Paul> postprocessing my maillogs looking for wormspoor, i have a
 Paul> personal blackhole list with almost a million hosts on it now,
 Paul> and about 20% of the ones who probe my smtpk (which always
 Paul> accepts all mail you send it) later try to spam my main mail
 Paul> server (which is in a different netblock).

Oh. _Very_ interesting.

-- 
Andrew, Supernews

Re: Lazy network operators

[Rob Nelson]

Steve, you're authorized if you say you are and agree to accept 
responsibility.
Most corporations would readily provide the addresses of their mail servers;
anyone on DSL or cable connection could do the same.  But by changing the
default behavior to block port 25 until requested, you could readily 
address the
spam problem.   It would take some work on the part of operator community
(hence the subject), and doesn't fit in the world wide commune perspective
of networking, but it would make the Internet far more useful for everyone.
(I realize I'm a few days late on this, been travelling all week)

What about that small business with a remote site on a cable modem? All 
they want is their local server to talk to the one upstream, and they'd 
rather pay, say, Time Warner $50 a month on a dynamic instead of $200 for a 
single static IP. Can't really blame them, can you? Is this 
authorization-filter-scheme going to account for servers on dynamic IP?

Rob Nelson
[EMAIL PROTECTED]

IDDB: Companion Domains Database to IADB (and IADB Update)

[Anne P. Mitchell, Esq.]

All,

We have not yet announced, but have made available, the IDDB - ISIPP 
Domains Database.  This is a companion database to IDDB, and allows 
queriers to do a query by domain name;  if the domain name is listed, 
it will return a list of IP addresses from which the domain is properly 
allowed to mail, along with the listee's IADB registration number for 
cross reference.  Obviously, the resulting IP addresses can than be 
plugged into an IADB query to get the IADB data about the sender's 
status, opt-in policies, etc..

This is _not_ intended as a replacement for SPF, MS Caller ID for 
Email, Domain Keys, etc..  Rather it is simply a companion database to 
IADB, which we are offering at the request of both senders and 
receivers who wanted this ability.

IADB is also growing, now offering additional information (the newest 
is the data code which means "the only email which comes from this IP 
address is mailing list email, and that mailing list email is entirely 
confirmed (double) opt-in"), and providing such information to ISPs, 
spam filters, and other queriers for more than 325million pieces of 
email per month.  The full list if current information provided by an 
IADB lookup is at http://www.isipp.com/iadbquery.php

Querying IDDB, as with IADB, is free (and always will be), and can be 
done by filling out a short form at 
http://www.isipp.com/iadb_query_sign_up.php   We hope that you will get 
good use out of IDDB as well as IADB, and I want to thank those of you 
already supporting it.

Anne

Re: Monitoring dark address space?

[Hank Nussbacher]

At 09:06 AM 16-04-04 -0500, David A.Ulevitch wrote:

NANOG,

I was wondering how many of you are running some sort of detection tool on 
"dark address" space on your network?  In an effort to curb malicious 
outbound non-spoofed traffic from "owned" client machines I think one of 
the easiest methods we have is to look for scans in what should be dead 
space.  The source-address spoofed traffic is easy to drop, the "legal" 
traffic is a bit more complex and I'm looking for non-inline methods of 
curbing this traffic.

My questions are:

1) Are you doing this and if so, what tools are you using?  Some sort of 
simple listening device with thresholds would probably do the trick if one 
machine monitored an entire /24 or some random /32's out of a /16.
We run one on a /16.  You can find details here:
http://noc.ilan.net.il/research/riverhead/
We also know of the SWITCH dark address monitor at:
http://www.switch.ch/security/services/IBN/
I'd be interested in knowing of any others.
The stats haven't been updated in a while but that will change over the 
next few months.

-Hank


2) What techniques seem to be better? Monitoring an entire /24 or picking 
a distributed selection of IPs from a /16? (using a /24 or /25 is much 
easier on the administrative end of things from where I sit...)

3) What sort of threshold metrics for considering something to be 
malicious have you found to be good?  (ports/second, ip/second, etc)

4) Are there downsides to this (aside from false positives, which would 
hopefully be rare in truly dark address space).

Off-list replies are fine and I'll summarize after a few days.

thanks,
davidu

  David A. Ulevitch - Founder, EveryDNS.Net
  Washington University in St. Louis
  http://david.ulevitch.com -- http://everydns.net

Re: Anyone alive at ALTDB?

[Jason Lixfeld]

On Apr 14, 2004, at 2:47 PM, Robert E. Seastrom wrote:

Jason Lixfeld <[EMAIL PROTECTED]> writes:

messages to db-admin have so far gone unanswered.
I spoke with the "db-admin"; he advises as follows:

1) you sent a single message to create a maintainer object, about 24
hours before posting to NANOG.  The turnaround time that you have
experienced is well within historical norms for creating new maint
objects.  Please be patient.
There was no documentation anywhere specifying the turnaround time for 
maintainer object creation.  Had there been a message returned with the 
object saying "hold your horses for 3 days", I would have.

Re: Anyone from AT&T here? (AT&T bogus DNSBL answers)

[jlewis]

Steve Linford wrote:

> AT&T customers have contacted us saying they can't reach any of our
> DNSBLs, seems AT&T have defined a fake sbl.spamhaus.org zone in their
> DNS servers so when AT&T customers ask AT&T's NS 12.149.189.2 for
> sbl.spamhaus.org they get:
> ...

I was looking at this some more last night, and noticed this appears to
have been some kind of mistaken identity issue.  Check the whois and
PTR for 12.149.189.2.  It certainly doesn't appear to be an AT&T
maintained DNS server.

If there really are/were AT&T customers who couldn't resolve the various
popular DNSBLs, I wonder, was the issue caused by something else?  Are
they setup to query the wrong DNS servers...perhaps 12.149.189.2 used to
be an AT&T DNS server before 2001-09-05, but since then, it's been an AT&T
customer's machine.  Maybe that customer is getting hammered with queries
from old AT&T customers and is trying to encourage them to go elsewhere
for DNS service.

--
 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: Anyone from AT&T here? (AT&T bogus DNSBL answers)

[Steve Linford]

At 16:06 -0400 (GMT) 17/4/04, [EMAIL PROTECTED] wrote:
 Steve Linford wrote:

 AT&T customers have contacted us saying they can't reach any of our
 DNSBLs, seems AT&T have defined a fake sbl.spamhaus.org zone in their
 DNS servers so when AT&T customers ask AT&T's NS 12.149.189.2 for
 sbl.spamhaus.org they get:
 ...
 I was looking at this some more last night, and noticed this appears to
 have been some kind of mistaken identity issue.  Check the whois and
 PTR for 12.149.189.2.  It certainly doesn't appear to be an AT&T
 maintained DNS server.
No mistake, although 12.149.189.2 is a customer's NS it uses AT&T's 
NS as the resolver. We've have complaints from other AT&T users about 
the same thing, as does another DNSBL (SpamCop), and there's now an 
answer from AT&T to one of their customers who forwarded AT&Ts 
response:

"I finally talked to someone who knows what the problem is.  Your sbl sites
have been blocked by the standard DNS forwarders supplied by ATT. This is
due to the workload being generated on them from mailservers."
--
  Steve Linford
  The Spamhaus Project
  http://www.spamhaus.org

Re: Anyone alive at ALTDB?

[Joe Abley]

On 17 Apr 2004, at 14:48, Jason Lixfeld wrote:

There was no documentation anywhere specifying the turnaround time for 
maintainer object creation.  Had there been a message returned with 
the object saying "hold your horses for 3 days", I would have.
Ask for your money back :-)

Re: Anyone from AT&T here? (AT&T bogus DNSBL answers)

[Raymond Dijkxhoorn]

Hi!

> No mistake, although 12.149.189.2 is a customer's NS it uses AT&T's 
> NS as the resolver. We've have complaints from other AT&T users about 
> the same thing, as does another DNSBL (SpamCop), and there's now an 
> answer from AT&T to one of their customers who forwarded AT&Ts 
> response:
> 
> "I finally talked to someone who knows what the problem is.  Your sbl sites
> have been blocked by the standard DNS forwarders supplied by ATT. This is
> due to the workload being generated on them from mailservers."

Duh! This is really dumb. 

Will they also block microsoft in their forwarders when there are new 
patches like last week, thats also generating NS traffic... 

Unbelievable.

Bye,
Raymond.

Re: Lazy network operators

[Rob Nelson]

Spammers are users too. You can't spell "abuser" without "user." You
are inherently trying to diminish the power of the abuser users. No
spam mitigation solution can ever answer, "yes," to that question
without the qualification that at least some users, the abusers, will be
disempowered. The equation will always come to balancing how hard you
hit the spammers versus minimizing the collateral damage. Or it's another
classic example of security versus usability.


But speaking of usability, email becomes IMMEDIATELY unusable if there is a 
technological "anti-spam" measure in place, be it something client-side 
like spamassassin or another RFC implemented server-side, that prevents 
even a single wanted email from getting to you. Especially if you are, for 
example, sitting at home on the phone with another person saying "Email me 
that file, again" and it's not going anywhere. At that point, email is 100% 
dead.

Rob Nelson
[EMAIL PROTECTED]
Rob Nelson
[EMAIL PROTECTED]

Re: Lazy network operators

[Paul Jakma]

On Fri, 16 Apr 2004, Paul Vixie wrote:

> 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.

Hmmm, or rather, there just wont be any demand for IPv6 deployment,
at least from the edges (consumers, small/medium networks). Why
bother changing if, despite the (almost indefinitely) availability of
sparse address space, one can not claim a tiny piece as ones' own?
Which is IPv4's only problem, at least as seen from the edges.

Provider independence (to some degree, even by DNS A6 or otherwise)  
for all should have been IPv6's biggest selling point. It doesnt have
it, judging by multi6 it's not likely it ever will, and hence it's
similarly unlikely there ever will be any real demand for v6.

(i write this hoping it won't be so, but i'm not very optimistic
about it).

regards,
-- 
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
warning: do not ever send email to [EMAIL PROTECTED]
Fortune:
consultant, n.:
Someone who knowns 101 ways to make love, but can't get a date.

Re: Anyone alive at ALTDB?

[Steve Rubin]

There was no documentation anywhere specifying the turnaround time for 
maintainer object creation.  Had there been a message returned with the 
object saying "hold your horses for 3 days", I would have.
Maybe there is no auto responder because of the huge amount of spam 
auto-dbm receives?

RE: Lazy network operators

[Michel Py]

> Paul Jakma wrote:
> Hmmm, or rather, there just wont be any demand for
> IPv6 deployment, at least from the edges (consumers,
> small/medium networks).

Oh oh I see another one taking the path that leads to the dark side.


_.-'~~`-._
/  ||  \
   /   ||   \
  ||||
  | ___||___ |
  |/ - \/ - \|
 /  ( )  ( )  \
/ \  - () -  / \
   /   \  /||\  /   \
  / \/\/ \
 /   \  /||\  /   \
/_\oo/_\
  `--...__|`-._  _.-'|__...--'
  |`'|

Re: Lazy network operators - NOT

[Doug White]

:
: >Ok, you have eloquently described the problem, now, please be good enough to
: >give your solution
:
:
: There is no easy solution. That's why we still have problems with spam in
: postal mail, and that's been around for how many centuries? I'd go so far
: as to say there's no easy solution, either. If there's authentication, then
: new worm/trojans will focus on breaking the auth scheme or the auth
: servers. If there's a blackout on port 25, then they'll use other ports. If
: there's a list of trusted hosts, that list will be attacked.
:
: The only chance in hell of making a dent in spam is making a dent in its
: profitability. If the guy sending the spam gets hassled once in a while, he
: probably thinks it's worth it considering the new house and stable of
: sports cars he has. If he's getting hassled AND he's just as poor or rich
: as when he started, then and only then will it not be worth the hassles to
: the spammer.
:
: Honestly, I don't understand how the spammers make money at all, so I can't
: comment on it. However, I'd definitely suggest any solution look at the
: profitability of spam, not the feasibility.
:
:
: Rob Nelson
: [EMAIL PROTECTED]
:
:
:
Cost transference.  The cost of Spam via postal mail is borne by the sender.
When sent via email, the cost is shouldered by the recipient.

Spamming is pervasive mainly due to the inattention or failure to enforce
acceptable use policies by the service provider.  A response rate of .0001 is
sufficient for the spammer to profit because of being able to take advantage of
the recipient bearing the cost of delivery.  There is no "only chance."  What
seems to be required is the blended approach.

Educating that user who does respond to UCE is a monumental, if not impossible
task, while the safety and protection of individual networks is a need which is
far more immediate.  That education task is beyond the resources and capability
of the offended mail server administrator.

There is a plethora of methodology, and suggestions as to how best to combat the
spew, and most of us have accepted the risk of the occasional false positive,
especially when your correspondent chooses to continue to do business with a
black hat provider.

We have resorted to trying to get the customer to bring his own pressure on his
provider, we have tried to pressure providers to be more responsive,
unfortunately with mixed results.  Especially when legislation and rules are
formulated that can be at odds with the advertising campaigns of the providers
themselves.

All in all though we are trying to fight the good fight, and believe in
technology, not legislation.

cheers.

Doug

==
We can get rid of spam on your domain! , Anti-spam solutions
http://www.clickdoug.com/mailfilter.cfm
For hosting solutions http://www.clickdoug.com
==

RE: Lazy network operators

[Paul Jakma]

On Sat, 17 Apr 2004, Michel Py wrote:

> Oh oh I see another one taking the path that leads to the dark side.

Well, let's be honest, name one good reason why you'd want IPv6
(given you have 4)? And, to be more on-topic, name one good reason
why a network operator would want it? Especially given that, apart
from the traditional bleeding edges (academic networks), no customers
are asking for it.

As Paul Vixie points out, without a multihoming solution beyond that
offered by 4, v6 networks will look just v4 - most of it will be on
non-global address space and NAT. Not really interesting..

[snip darth vader]

I know, what's worse is that I know it need not be so. (how's your
MHAP doing?  How's Iljitsch's geo-assigned addressing proposal?)
 
regards,
-- 
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
warning: do not ever send email to [EMAIL PROTECTED]
Fortune:
One nice thing about egotists: they don't talk about other people.

Re: Lazy network operators - NOT

[John Curran]

At 9:42 PM -0500 4/17/04, Doug White wrote:
>
>Spamming is pervasive mainly due to the inattention or failure to enforce
>acceptable use policies by the service provider.

It's pervasive because its profitable.  It's been profitable because even a few weeks
of a high-speed circuit can generate millions of messages which don't need much of a
response rate to generate revenue.  The problem now is that a growing percentage
of spam is originating from distributed farms of broadband connected users
(Commtouch says 80% in one article, but I'm not yet convinced its that high -
)
This would suggest that spam is pervasive largely because of the large number
of insecure systems available for origination (via port 25 :-), not because of
providers failing to close barn doors after the fact...

/John

Re: Lazy network operators

[Paul Vixie]

> > ...
> > 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.
> 
> Hmmm, or rather, there just wont be any demand for IPv6 deployment, at
> least from the edges (consumers, small/medium networks). Why bother
> changing if, despite the (almost indefinitely) availability of sparse
> address space, one can not claim a tiny piece as ones' own?  Which is
> IPv4's only problem, at least as seen from the edges.

ipv6 solves problems that large providers have, or speculate that
they'll have, and at some point the edge/enterprise will adopt a dual
stack approach just to be reachable by 3G-etc, assuming that 3G-etc
ever stops having the 6to4/ISATAP/etc features it'll have to have
before it has v6 at all.  so, theoretically, there's a tipping point
where dualstack or even v6-only will make sense even to someone who
refuses the lockins and stays with a NAT-based or proxy-based design.

> Provider independence (to some degree, even by DNS A6 or otherwise)
> for all should have been IPv6's biggest selling point. It doesnt have
> it, judging by multi6 it's not likely it ever will, and hence it's
> similarly unlikely there ever will be any real demand for v6.

provider independence is not a clear virtue in the eyes of those powerful
enough to sway vendors toward implementation -- that is, people with
billion dollar annual capital budgets.  it may not even be a clear virtue
in the eyes of the edge/enterprise consumers who want to avoid lockin,
since they've gotten comfortable with NAT and proxies over the years, and
since in a post-CIDR world, everybody knows that the equilibrium between
can-route and can-qualify has to be more toward can-route and the people
who can't-qualify just need to make other arrangements.

i dearly wish i had understood this market equation at the time i was
pushing for A6/DNAME, since at that time i stupidly thought that this was
a technical problem and the people on the other side of the argument just
didn't understand the technical issues well enough.  (oops.)

Re: Lazy network operators - NOT

[Paul Vixie]

[EMAIL PROTECTED] (John Curran) writes:
> ...
> This would suggest that spam is pervasive largely because of the large
> number of insecure systems available for origination (via port 25 :-),
> not because of providers failing to close barn doors after the fact...

I don't know why it's taken me so long to come to a conclusion about this,
especially since VJS has been making noises like this for a long time and
I know enough to pay attention.

So-called "broadband" user populations (cable, dsl, fixed wireless, mobile
wireless) are full time connected, or nearly so.  They are technically
unsophisticated, on average.  The platforms they run trade convenience for
security, and must do so in order to remain competitive/relevant.  Margin
pressure makes it impossible for most "broadband" service providers to even
catalogue known-defect customer systems or process complaints about them.

Those facts are not in dispute.  And so, today, I began rejecting all e-mail
from all roadrunner, attbi, interbusiness.it, comcast, and rogers customers.
And as I discover the next several thousand /16's which contain this kind
of user community I will reject their e-mail also.  MAPS DUL doesn't go
nearly far enough, nor do any of its lookalikes, not even SORBS DUHL.

You are all going to have to do this also, because the cost to you of keeping
a list of which /32 is running malware at any given moment is too high when
the numbers get into the millions, and even if your bots assume the worst
(that is, don't even bother probing for malware) you'll still have to handle
exception processing on the first spam (or the first few dozen spams).

IETF MARID could be a scalable way of performing this mass e-mail rejection,
and it could be a way that legit e-mail servers can live inside "broadband"
address blocks rather than having to tunnel to  or
other clue-dense address space where technical sophistication is the norm...
but I can't imagine that happening at all, let alone happening in 2004/2005.

I was blind, but now I see.  These netblocks are like foreign airports without
metal detectors, and I've been handling the occasional transferring passenger
(who's armed with things they shouldn't be) on an exception basis, including
all kinds of per-incident damage, where what I need to do is land those planes
outside my security perimeter and make them go through local metal detectors
before they're allowed to transfer onto planes I'm responsible for.

MAPS or SORBS or somebody needs to set up a "BBL" (broad band list) which is
just a list of "broadband" customer netblocks, with no moral/value judgement
expressed or implied.  If it's complete and updated frequently, I'd pay for
a feed because of all the work it would save me personally and in my dayjob.
(Apropos of JCurran's comments above, it wouldn't matter if netblocks on this
"BBL" disabled outbound TCP/25, or not, so, they probably just wouldn't, but,
they probably aren't going to, no matter whether a "BBL" exists or not.)

The new motto here is: "Blackhole 'em all and let market forces sort 'em out."
-- 
Paul Vixie

Re: Monitoring dark address space?

[Paul Vixie]

> > since this space has no dns records pointing into it, the only
> > traffic it will see is from errors/typo's, and network scanners.
> 
> And blowback from other people forging your addresses as sources.

Actually, not.  Very few modern MTA's correctly implement "@[dot.ted.qu.ad]"
parsing, and other than zone file typo's, no MX points into this address
space.  So the blowback comes to my real MX's, not to this "dark space".

> (We've had quite a few goober-with-firewall reports of that type -
> especially from a certain manufacturer of networking equipment who
> shall remain nameless, even though they ought to know better.)

Apropos of that, I'm appending my current list of antivirus spoor in postfix
format.  Antivirus vendors know that viruses usually have forged sources, but
they get to spam you for free using their customers' own e-mail servers, all
in the guise of telling you that their product filtered something bad and by
the way here's the URL if you want more information about their product.  As
it turns out, if you blackhole the servers who send you this crap, the customer
who installed the antivirus software calls YOU.  If on the other hand you
reject it at SMTP level you cause a "double bounce" to the customer's own
"postmaster" account, and the customer calls THEM (the antivirus sw-vendor.)

> > false positives are less than one in ten million.  "blackhole 'em all."
> 
> If you're actually going so far as to accept the connections, yes.  If
> you're just counting packets, then a little more caution is possibly
> indicated.

Packet counting _never_ helps you.  Simply put, probitive malware does not
have to send enough packets that it'll show up on quantitative IDS "radar".
And for that matter, a number of non-malware systems (like some IRC nets I
know of) will do a virus probe with no ill intent.  Unless you're going to
accept the connection (and perform a transaction successfully, such as
pretending to accept some mail or sending them some web data), you cannot
learn anything about the vileness of the initiator's intentions, or even
the level of technical sophistication of the initiating host's owner/op.)



Here are my current lists of postfix body, and then header, AV regexes.
(An award goes to Symantec who spells their avspam in so many ways, though
we all hope this is not being done in order to avoid patterned rejection.)



/^Sorry Dangerous Attachment has been Removed/  REJECT avbody
/ is removed from here because it contains a virus$/REJECT avbody
/^WARNING: This e-mail has been altered by MIMEDefang/  REJECT avbody
/^Norton AntiVirus deleted the following email message/ REJECT avbody
/^Diagnostic\-Code\: 550 5\.7\.1 Virus detected by ClamAV/ REJECT avbody
/^This is a machine-generated message, please do not reply/ REJECT avbody
/^Las partes del mensaje que estaban infectadas no han sido/ REJECT avbody
/^Your email was not properly addressed/REJECT avbody



/^Subject:.*ALERTE \- Vous avez envoye un mail avec virus/  REJECT avhead
/^Subject:.*ALERTE\: un virus a /   REJECT avhead
/^Subject:.*ALERT\! Virus found in your mail/   REJECT avhead
/^Subject:.*Anti-Virus Notification/REJECT avhead
/^Subject:.*Antigen found VIRUS/REJECT avhead
/^Subject:.*Antigen Notification/   REJECT avhead
/^Subject:.*AntiVir ALERT/  REJECT avhead
/^Subject:.*Antivirus stopped your message/ REJECT avhead
/^Subject:.*Antivirus found VIRUS/  REJECT avhead
/^Subject:.*Anti\-Virus Notification/   REJECT avhead
/^Subject:.*BANNED FILENAME/REJECT avhead
/^Subject:.*BitDefender found an infected object/   REJECT avhead
/^Subject:.*Content violation/  REJECT avhead
/^Subject:.*Disallowed attachment type found/   REJECT avhead
/^Subject:.*Email Quarantined Due to Virus/ REJECT avhead
/^Subject:.*Failed to clean virus file/ REJECT avhead
/^Subject:.*File blocked - ScanMail for Lotus/  REJECT avhead
/^Subject:.*Inflex scan report \[\d+\]/ REJECT avhead
/^Subject:.*InterScan NT Alert/ REJECT avhead
/^Subject:.*MailMarshal has detected a Virus in your message/   REJECT avhead
/^Subject:.*MailSure Virus Alert/   REJECT avhead
/^Subject:.*Mail Warning \(Attachment Removal\)/REJECT avhead
/^Subject:.*message .* contains a virus/REJECT avhead
/^Subject:.*Message deleted/REJECT avhead
/^Subject:.*MMS Notification/   REJECT avhead
/^Subject:.*MxShield Virus Notification/   

Re: Lazy network operators - NOT

[Sean Donelan]

On Sun, 18 Apr 2004, Paul Vixie wrote:
> MAPS or SORBS or somebody needs to set up a "BBL" (broad band list) which is
> just a list of "broadband" customer netblocks, with no moral/value judgement
> expressed or implied.  If it's complete and updated frequently, I'd pay for
> a feed because of all the work it would save me personally and in my dayjob.
> (Apropos of JCurran's comments above, it wouldn't matter if netblocks on this
> "BBL" disabled outbound TCP/25, or not, so, they probably just wouldn't, but,
> they probably aren't going to, no matter whether a "BBL" exists or not.)

Third-party lists are not the way to go.  As you point out, mixing moral
judgements with other information causes a lot of side-effects.  People
constantly confusing a listing on DUL with being a "spam provider," which
has the negative effect of some providers not going out of their way to
add more addresses to various dialup lists.  And the constant problem
of multiple lists being out-of-date.  Who is the "official" keeper
of the bad list this year?  Is every service provider expected to support
every third-party list.

The telephone network has the LIDB, which tells you which phone numbers
belong to payphones, prisons, residential, busines, etc.  It doesn't make
a judgement about the callers.  Providers supply information for other
people to make a decision based on information about the lines, not the
callers.

I suggested using something like HINFO in the in-addr.arpa address zones
for service providers to give similar information about IP addresses.
Yes, I know, using DNS for yet something else.  LDAP or RWHOIS or any
other global mechanism could be used.

HINFO
PUB - Public address (unauthenticated user)
DYN - Dynamic address (indeterminate user)
K12 - School
PRI - Prison/Jail
UCT - University/College/Trade school
HOI - Hotel/Inn
RES - Residential
BUS - Business
ISP - Internet Service Provider

If you don't want to accept connections from indeterminate or
unauthenticated addresses, its your choice.  If you are a porn vendor
and don't want K12 users to accidently stumble on to your web site,
its your choice.  If you are a credit card vendor and don't want
to accept credit card orders from prisons or jails, its your choice.