Speaking of joe-jobs, what's the "proper" proceedure
for >dealing with such? The company I work for is
currently >undergoing an admitedly minor joe-job.
(about 300 or so >bounces that I've seen since mid >
last week or so.)
Any suggestions for dealing with this?
What domains are you seeing the joe-jobs from? We >
see alot of joe jobbing attacks from the large webmail
providers eg. yahoo.com, hotmail.com, aol.com,
netscape.net, etc. A promising response that we've
been following is Sender Permitted From
http://spf.pobox.com . It's basically a reverse RBL.
The owner of a domain identifies ip's that are allowed
to send mail for that domain in a TXT DNS record. The
rest are tagged with a wildcard deny or probably
softdeny initially. If yahoo.com, hotmail.com etc alone
just added the DNS records, we'd all be able to
identify joe-jobbers of these domains. It won't help
their own spam situation but it'd help our massive
attacks of spoofed email. Spammers seem to use these
big providers since blocking all of hotmail.com or
yahoo.com is tough for other providers.
I'm looking for a clueful person either inside of AOL's NetOps
or someone else that can help us.
Problem;
Using AOL Dial-Up, through AOL Browser or MSIE
users can connect to our web servers and our clients
web servers via normal http with no problem.
If they connect to a secure site (https://) they
get 'page can not be displayed' and other errors.
We have this issue with Linux/Apache as well as
MSIE servers.
Sniffing such connections, we get one of two scenerios:
1. A connection is opened from an AOL proxy server
(172.151.135.3 for example) yet no data is transmitted.
2. A connection is opened from an AOL proxy server.
what looks like a request is sent (580 bytes)
and some response is sent back (5k bytes)
Yet the clients browser never gets a website..
The webserver logs an 'error 408' from the request,
Which is a request timeout.
2 test websites to try from AOL:
https://www.krystal.net MS
https://www.onrope1.com Linux/Apache
Clue Bat's welcome. Thank You --Mike--
Last time I checked, SSL connections do not get proxied through the AOL
caching servers.
They go directly from the client.
172.151.135.3 is not an AOL proxy server, it is an end user IP address that
a AOL user gets when they dial in.
cache-rf03.proxy.aol.com is an AOL proxy.
Thanks, It seems when the connection swaps from a proxy/cache connection,
that the AOL browser gets redirected to another AOL address first,
and then goes out. There is a noticable delay (a second or two)
from when the request gets sent, to when we see it on our network..
like an overloaded cache/proxy. Perhaps AOL is using some kind of
"transparent" proxy.. or maybe it's the Dept of Homeland Security's
mystery sniffer (just speculating in wild paranoid mode).
Or maybe it's something on our network mangling packets..
But calls to AOL get me no-where..