|
|
| Author |
Message |
| 25 new of 248 responses total. |
mdw
|
|
response 87 of 248:
| 
Oct 23 04:53 UTC 2002 |
I'm guessing that gull got a relatively quick "Connection reset by peer"
and not a slow "Connection timed out". This is one of those cases where
small wording differences in the error message can mean drastically
different things. In fact, grex is likely to work better with firewalls
that silently drop packets than ones that "reject" connections.
Unfortunately, for "reject" some firewalls return ICMP UNREACH messages,
instead of TCP reset (which would be the "expected" behavior if there
were in fact no listener on the port), and grex interprets this to mean
everything on the remote host is now unreachable, rather than just that
one connection. (Granted, there is a icmp subcode that can be used to
further distinguish cause - unfortunately the original bsd tcp/ip code
doesn't check this.) A firewall that rejects ident connections using
TCP reset should work fine with grex, and some are indeed capable of
doing this. Unfortunately, the sort of mentality that blocks ident
connections using a firewall instead of simply not running an ident
service is also the sort that is not likely to understand the difference
between ICMP UNREACH and a TCP reset.
|
gull
|
|
response 88 of 248:
|
Oct 23 14:53 UTC 2002 |
The usual recommended firewall practice is to block everything, then
only enable what you need, instead of trying to block things piecemeal.
I understand the problem with ICMP UNREACH vs. TCP reset, but I don't
have control over how developers choose to implement their firewalls.
Linux iptables, for example, can only respond with ICMP or by silently
dropping the packets. It *is* set to respond with
ICMP-port-unreachable, not ICMP-host-unreachable, by default.
In the case of the mail server I set up, I solved the problem by opening
the identd port specifically, but I don't have the ability to do that on
the mail server of everyone who wants to send me mail. Fortunately only
a minority seem to have this problem, but I expect it'll only get worse.
I also expect fewer and fewer sites will be running identd, since it
leaks information to potential hackers. You can, for example, use it to
determine what userid servers are running as.
|
keesan
|
|
response 89 of 248:
|
Oct 24 01:19 UTC 2002 |
Lynx is not letting me reset my options and save them to disk (I can reset
but it does not stay set despite checking off 'save to disk'). The tab to
next link has never worked and it still redraws the pages up to 5 times, but
reset used to work, I think. I am tired of having labels for images turned
on permanently (bluedot.gif bluedot.gif.....). 2.8.4 version.
|
davel
|
|
response 90 of 248:
|
Oct 29 14:56 UTC 2002 |
Attempts to send mail to Grex are timing out. Grex is up (obviously) and not
entirely off the net - I can telnet in. But attempting to connect to the
sendmail port just hangs until it times out.
Of course, this may be (say) a load-based restriction that will correct itself
eventually, or something like that. Grex feels slow enough to make that seem
all too likely.
|
keesan
|
|
response 91 of 248:
|
Oct 29 17:23 UTC 2002 |
I have not had trouble receiving mail at grex, but I am unable to send to a
particular address since late yesterday. I keep getting back rejected mail
notices. Has something changed at grex, or at their end? I could send
mail to them earlier yesterday.
From MAILER-DAEMON@cyberspace.org Tue Oct 29 12:16:01 2002
Date: Tue, 29 Oct 2002 09:09:24 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON@cyberspace.org>
To: keesan@grex.cyberspace.org
Subject: Returned mail: Service unavailable
The original message was received at Tue, 29 Oct 2002 09:09:11 -0500
from keesan@localhost
----- The following addresses had delivery problems -----
<hold@shadow.net> (unrecoverable error)
----- Transcript of session follows -----
... while talking to mail.shadow.net.:
>>> DATA
<<< 552-MessageWall: Message score (1) has reached or exceeded maximum (1):
<<< 552- 1 RFC822/REJECT: keesan@grex.cyberspace.org: Source address must be
in From header <<< 552 MessageWall: This message is being rejected 554
<hold@shadow.net>... Service unavailable
----- Original message follows -----
[ Part 2: "Included Message" ]
Date: Tue, 29 Oct 2002 09:09:07 -0500 (EST)
Lynx also won't accept the command r while viewing the bookmarks file to
remove a line. I have to type e and edit it out instead.
|
albaugh
|
|
response 92 of 248:
|
Oct 29 17:38 UTC 2002 |
This isn't a problem, per se, but an inquiry: A grex account I have personal
knowledge and control of was sent a SPAM e-mail (from a yahoo.com account),
and this grex account has never sent an e-mail, posted in bbs, or participated
in party. So how was the spammer able to know about the existence of this
grex account? Is /etc/passwd exposed or something?
|
tpryan
|
|
response 93 of 248:
|
Oct 29 17:47 UTC 2002 |
1, 2 and 3 letter logins are easy to mass-email. Does the account
fall into this list?
|
keesan
|
|
response 94 of 248:
|
Oct 29 17:53 UTC 2002 |
I have received spam sent to keesan at a number of ISPs, some of them not very
well known. I think they just take logins and combine them with ISP names
and send spam out that way.
Shadow.net knows what the problem is. Yesterday they improved their spam
filter to reject headers of a certain format. They have had complaints from
a few other people who tried to mail their customers from shell accounts, and
they will fix the problem pronto. The phone was answered immediately (no
menu, no wait) by a really knowledgeable support person who spoke perfect
English with a Spanish accent and who diagnosed the problem at once. It is
nice to know some ISPs are competent (unlike AOL, Earthlink....). I recommend
them to anyone living in South Florida.
Webmail might be a good temporary solution to grexers who cannot send mail
to places with this sort of spam filter.
|
albaugh
|
|
response 95 of 248:
|
Oct 29 17:57 UTC 2002 |
The account in question has its ID formed by a common 7-character first name
followed by a 1-character last name (e.g. robertoa). So I guess it's possible
the spammer just got lucky when constructing a target account name. But I'm
still wondering if the information could have come from grex...
|
gull
|
|
response 96 of 248:
|
Oct 29 18:17 UTC 2002 |
It could have. The person would have to be a user first. But it's more
likely it was just random coincidence.
|
albaugh
|
|
response 97 of 248:
|
Oct 29 18:24 UTC 2002 |
OK, so let's say the user *was* a grex user - how does that help him find out
info about other user accounts which are inconspicuous due to lack of
participation? If you don't wish to say because this will encourage other
spammers, I'll understand...
|
gelinas
|
|
response 98 of 248:
|
Oct 29 18:44 UTC 2002 |
The password file can be read by anyone on grex:
} Respond, pass, forget, quit, or ? for more options? !ls -lFg /etc/passwd
} -rw-r--r-- 1 root wheel 2075714 Oct 29 13:29 /etc/passwd
It is kinda big, but there it is.
|
other
|
|
response 99 of 248:
|
Oct 29 19:44 UTC 2002 |
wtmp?
|
albaugh
|
|
response 100 of 248:
|
Oct 29 20:12 UTC 2002 |
OK, yes, that's the standard way one would get the user list.
|
mdw
|
|
response 101 of 248:
|
Oct 29 22:10 UTC 2002 |
Today's high load average was due to a chain of logins created from one
particular place. This appears to be some sort of file sharing scheme -
I'm not sure of the exact mechanism (which in any case probably invovles
client-side software which we don't have) - but the usual result is the
account gets disabled due to "high ftp volume", which then results in a
high cpu load as the client-side software is apparently too stupid to
give up on a login failure, but just tries again, over and over and
over...
|
davel
|
|
response 102 of 248:
|
Nov 1 21:50 UTC 2002 |
Re 80, 81, 85, 87, 88, and maybe more:
I'm recently seeing email to Grex hanging in a mail queue with the message
"Deferred: Connection timed out with grex.cyberspace.org.". It appears
that almost every message I send to accounts on Grex times out and retries
at least once or twice. I'm pretty sure this didn't used to happen. I have
to suspect that something in the way Grex handles mail, probably relating to
the reverse lookup, has changed to make this vastly slower (on the order of
a minute or two). When the queue starts processing the message, it's at least
that long before it times out again.
|
glenda
|
|
response 103 of 248:
|
Nov 1 22:22 UTC 2002 |
I have yelled at STeve for not replying to email and been told that he did
reply then have it show up several hours later. Time stamps show that he did
send it when he said he did. Yesterday he sent a reply at 14:00, it arrived
here around 19:00, another was sent around 17:30 to arrive around 20:50. I
have been talking to contractors via email and was wondering about one of them
being interested in the job since he didn't respond. Time stamps show that
it arrived here about 36 hrs after he sent it.
|
mdw
|
|
response 104 of 248:
|
Nov 2 00:30 UTC 2002 |
Nothing has changed on grex recently that would affect any of this. If
there is a high load average on grex, grex will temporarily stop
receiving mail - it's been doing this at least since we were on the
sun-3. A timeout of a minute or so for the reverse lookup probably
means something is up with somebody's DNS server - if this is important
to you, you might want to figure out which IP address and DNS server is
being slow. "slow" behavior can be hard to recognize due to name
caching, so there are a lot of sloppy system administrators out there.
I don't know enough about the path STeve's mail takes to reach Glenda to
speculate why it might be slow.
|
gelinas
|
|
response 105 of 248:
|
Nov 2 01:17 UTC 2002 |
Right; look at the "Received:" lines, comparing timestamps, to see where it
got delayed.
|
uw
|
|
response 106 of 248:
|
Nov 2 02:34 UTC 2002 |
when i try to change my password, it says 'changing password for user grease."
and then that our uids dont match, of course.
weird.
|
gull
|
|
response 107 of 248:
|
Nov 2 06:15 UTC 2002 |
I'm getting a lot of mailing list messages twice, or out of order, lately.
I also had someone complain mail they were trying to send me bounced the
first time they tried, because Grex wasn't responding. I'd guess it's
probably the unusually high load averages lately doing it.
|
mcnally
|
|
response 108 of 248:
|
Nov 2 06:18 UTC 2002 |
Mail to mcnally@umich.edu forwards to grex and to an archival mailbox
on a webmail service that I don't often check. Lately I find that
messages frequently show up in this other mailbox a full day before
they arrive in my Grex mailbox. Something is going on with our mail
reception that wasn't happening before.
|
russ
|
|
response 109 of 248:
|
Nov 2 07:03 UTC 2002 |
I have also noticed large delays in receiving e-mail; sometimes
my inbox almost looks shuffled, as time of arrival has little
relationship to time sent. Some days I get very little e-mail,
and then later I get a flood of things sent during the dry spell.
It looks like Grex needs to do something about mail priority.
|
cmcgee
|
|
response 110 of 248:
|
Nov 2 19:39 UTC 2002 |
yes, i was surprised that an email sent to me at 5 pm yesterday showed up
today, but was certainly not iin my mailbox when i sent that erson mail at
10 pm last night.
|
keesan
|
|
response 111 of 248:
|
Nov 3 01:33 UTC 2002 |
I would like to thank whoever fixed several problems with lynx: it no longer
loads pages 2-5 times, r works to remove lines in the bookmarks file, and I
can set options and save to disk.
|
