When I wrote this original message, I was just putting myself in a
spammers shoes, being VERY happy if I could get a 0/0 and it be
legitimate.
Since as a spammer, my friends and I own more netblocks than anyone
else, we could happily reference as many auto-generated domains as we
wanted on pretty much whatever netblock we wanted. It would be very
difficult pin us down.
My next mission would be to find all the +all's or 0/0's that
legitimate namespaces have published, so I can pretend I am them as
well.
Granted, several large domains I will not be able to spoof because they
have limited their cidr's, but that is ok. Just as long as I can still
'look' legitimate, still 'hide' where I am actually coming from, and
still be able to avoid litigation or incarceration from the new
anti-spam laws.
The WORST thing that could happen to a spammer is that our mailers
ignore him.
The best way I could think of to be able to do this, was to limit the
size of the cidr published. It would allow us to specifically ignore
unspecific cidr ranges and even eventually identify specific IP ranges
as spamhauses. The spammer would be 'forced' to use specific cidr's just
so they would not be ignored. That is step one of the master plan. Then
step two of the master plan- start blocking those cidr's where we know
spam is coming from. Then finally- Banish spammers to the corners of the
internet... where we can ignore them. (please reference the WORST thing
that could happen to a spammer)
But, since step two of the master plan requires that I start
identifying these specific cidr's, I want to make sure that some poor
shmoe assigned an IP in the middle of a bunch of spammy ones, isn't
blocked by association- base purely on the numerical value of his IP
address and his inconsiderate spammer neighbor including him in the
spammy cidr.
Ok.. so there was not enough support to put it in the RFC, but there
was enough to agree that it should perhaps be a suggested best practice.
By the way, this means that those DNS services that keep track of DHCP
people will have to rewrite SPF records too.
Ok..... so.. How do I do this?
Propeller-heads to the rescue!
Regards,
Damon Sauer
"If I had a nickel for every spam message I blocked... I would have ALL
the nickels."
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Greg Connor
Sent: Tuesday, June 08, 2004 2:27 PM
To: Edward Lewis
Cc: ietf-mxcomp(_at_)imc(_dot_)org
Subject: RE: Wide-Open MADRID
At 9:42 -0700 6/1/04, Greg Connor wrote:
Publishers SHOULD limit the size of the cidr ranges to no larger than
the ARIN netblock corresponding to the ASN it is in. If the
publisher
wishes to allow multiple ASNs to send mail, they should be listed
individually.
--Edward Lewis <edlewis(_at_)arin(_dot_)net> wrote:
To add some clarification - ARIN does not have information relating
address ranges to AS numbers at the granularity you are probably
assuming.
E.g., an organization may have AS numbers 68432 and 72293 and address
ranges 298.34.245.0/24 and 312.3.312.0/23. There's no record how the
two
ranges are mapped to the autonomous systems. If could be the latter
range is split among the two AS numbers. --
Thanks. Perhaps AS isn't really related to what we want... If the ARIN
response shows the size of the block as ARIN knows it, that should be
enough. I'm pretty sure the block size is in the whois result. Worst
case, look up the first IP and last IP in the MARID range and see if
they
are in the same NETBLK handle.
I think I was thinking about AS in order to avoid going to Whois... if
the
block info could be extracted from DNS that would be better for
performance
reasons. Perhaps looking up the first and last IP in in-addr.arpa to
see
if it is delegated to the same place? Or is there a better way to learn
the size of the ARIN block using only DNS queries?
Thanks
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
*****
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential, proprietary, and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received this in error,
please contact the sender and delete the material from all computers. 113