Anyone having trouble getting to/ know of any issues with spamcop.net today?
They seemed to have dropped off the radar from me...
No pings
No traceroute
but they still show registered at 216.127.43.89
Tnx
Marc
macronet.net
One of my customers wrote in today after receiving an email supposedly
promoting spamcop. The email was obviously a joe-job, but it's possible
that either their site has been overwhelmed with traffic or that they've
been shut down (either due to the amount of traffic, or due to
complaints).
Traceroutes are dying for me at 207.246.155.129 (AS11608).
1 66.250.7.245 [AS 16631] 0 msec 0 msec 0 msec
2 66.28.67.245 [AS 16631] 48 msec 4 msec 4 msec
3 66.28.4.74 [AS 16631] 12 msec 12 msec 12 msec
4 66.28.4.93 [AS 16631] 28 msec 208 msec 216 msec
5 66.28.4.146 [AS 16631] 16 msec 12 msec 12 msec
6 198.32.176.19 [AS 3356] 16 msec 12 msec 16 msec
7 207.246.140.57 [AS 11608] 28 msec 32 msec 32 msec
8 207.246.155.129 [AS 11608] 32 msec 28 msec 32 msec
9 * * *
10 * * *
11
Anyone having trouble getting to/ know of any issues with spamcop.net today?
They seemed to have dropped off the radar from me...
No pings
No traceroutebut they still show registered at 216.127.43.89
laptop ~]$ t 216.127.43.89 80
Trying 216.127.43.89...
Connected to 216.127.43.89 (216.127.43.89).
Escape character is '^]'.
GET /
hmm, there isnt anything returning right now, but it connects atleast 
Not for nothing, but there's so much time wasted with all these diversified
spam systems.
I've been reading about Barry Shein's proposals and I have to say I am on board
with a centralized -single- system based on his young, but intelligent, model.
http://www.internetweek.com/breakingNews/INW20021219S0003
I applaud RBL, spamcop, etc., but without funding and consolidation, it's another
waste of offensive time that could be spent on a far more effective defense.
-M
Not for nothing, but there's so much time wasted with all these diversified
spam systems.I've been reading about Barry Shein's proposals and I have to say I am on board
with a centralized -single- system based on his young, but intelligent, model.
One large problem is that people utilize these various lists without
the understanding as to what they really will block. Blocking standard
'your penis can be bigger' messages is one thing, blocking production
email to customers is another 
As of this writing, theyre back up, albeit slowly....thanks everyone who looked into this.
Marc
macronet.net
Thus spake "Martin Hannigan" <hannigan@fugawi.net>
Not for nothing, but there's so much time wasted with all these
diversified spam systems.
Many of these systems have been shown to falsely flag non-spamming sites,
and the more reliable ones unfortunately don't catch a majority of spammers.
This leads to a system where administrators (or users) can locally tune
preferences for the level of paranoia they wish to suffer from. This would
not be possible if there were only one model or provider.
I've been reading about Barry Shein's proposals and I have to say I
am on board with a centralized -single- system based on his young,
but intelligent, model.
If there were any single, centralized organization I trusted to do my
thinking for me, I'd agree. This is also the same problem that PKI faces.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
The only disadvantage I see, is a single point of failure, and a point for concentration of attacks.
Marc
Thus spake "Martin Hannigan" <hannigan@fugawi.net>
Not for nothing, but there's so much time wasted with all these
diversified spam systems.Many of these systems have been shown to falsely flag non-spamming sites,
and the more reliable ones unfortunately don't catch a majority of spammers.
So true. We have a colo client who is a domain name registrar that (curiously) "parks" expired domains on their servers here... basically saying "this domain available" (with something of a "whowas" database showing the last domain holder.) Last I checked over 500,000 expired domains are parked there.
Anyway, if I had a buck for every time some spammer used one of these expired domains for a bogus "unsubscribe URL" or "From:" address I would be able to retire by now. Quite comfortably.
I have thousands of auto-generated complaints from Spamcop, pointing to these domains as being "spamvertised"... and a /25 seemingly forever blacklisted by spews due to this 'false flag' situation. Yes, I have plead my case on news.admin.net-abuse.email ... but as we all know due process is not involved when on trial by spews.
I have a semi-auto reply now to explain the situation to Spamcop subscribers, but I doubt any of them read it, and I know no attempt is made to verify or prevent this event from repeating ad infinitum.
The only disadvantage I see, is a single point of failure, and a point for
concentration of attacks.Marc
Also, it centralizes POWER! There are many different lists with different
policies and criteria. Some are based on technically verifiable issues
(I can prove that x.y.z.q is a promiscuous relay), some are based on
the attitude of the owner of the domain name or netblock, some on
past record. You can pick and choose which one(s) meet the needs of
your network and operation. Using these lists is a policy question for
the network, and I would not like some external, probably unaccountable
single point of policy.
hannigan@fugawi.net (Martin Hannigan) writes:
I applaud RBL, spamcop, etc., but without funding and consolidation, it's
another waste of offensive time that could be spent on a far more
effective defense.
i had no idea that MAPS was unfunded. do tell.
For most purposes, network addresses are involuntarily put on various
"blacklists." So it makes since to design them as a third-party
architecture. And to avoid the problems of centralized control (or
censorship), spread those lists out among many different organizations.
However, there is one purpose these lists are used where it may be
better to "go to the source." Difusing the identification of dialup
addresses, and in today's network other types of dynamic connections,
causes problems with out of date, or mistaken information. Some of
the DNSBL get the dialup information from service providers, but unless
the provider plays favorites with DNSBL providers, its hard to keep
them all up to date. But when problems happen, the DNSBL goes out
of business, accidently lists the wrong addresses, etc; its out of
the service provider's control.
Because dialup identification is generally not "punitive," I think it
makes sense to give providers a mechanism to self-identify dynamic
network addresses without otherwise effecting whatever naming scheme
they want to use for their network, and without depending on
third-parties. Fighting a two-front religious battle isn't necessary.
My proposal would be something along the lines of allowing providers
to use the HINFO field on dynamic network addresses. Since its a
dynamic address, HINFO probaly doesn't have real hardware/operating
system information. So why not register a well-known value with
IANA for dynamic hosts, e.g. HINFO "DYNAMIC DIALUP". Service providers
can set, maintain, update, etc their own DNS files as quickly as
they get address space and start using it. If the service provider
re-purposes the address space, they can change or delete the HINFO
field without the trouble of coordinating changes with multiple
third-parties.
Remote hosts which want to deny service to dynamic hosts, such as
not allowing SMTP connections, would retrieve the HINFO field along
with the other information they get doing DNS lookups. If the value
is HINFO "DYNAMIC WIRELESS" they implement whatever policy they want for
those connections. The service provider is only giving technical
facts about the access method, no personal information, no judgement
about the customer using the connection.
It does no good for a service provider to lie. If they lie, the other
blacklists will pick them up soon enough. If the service provider is
lazy, again the other blacklists will pick them up. Generally the
DNS record for dialup or dynamic networks is under the control of
the service provider, not the customer. But even if the service provider
let customers use dynamic update to change the DNS information, any
other value for HINFO or no HINFO would be treated as unknown.