|
|
| Author |
Message |
| 25 new of 251 responses total. |
russ
|
|
response 193 of 251:
| 
Feb 24 22:33 UTC 2003 |
Re #192: My correspondent got that last error from a telnet session
to the smtp port; that may have triggered the spam-trap. However,
it wouldn't account for spurious mailbox-full indications (which may
actually be mail-filesystem full - I don't know).
|
mdw
|
|
response 194 of 251:
|
Feb 25 04:16 UTC 2003 |
"One generation passeth away"... indicates a failure to follow certain
basic parts of RFC 822. I wasn't patient enough to find Russ's
attempts, but I found a spammer using
ntsaga007231.saga.nt.adsl.ppp.infoweb.ne.jp and
adsl-65-71-169-27.dsl.tpkaks.swbell.net who ran afoul of this trying to
send spam to russ.
Most of the spam checks (including this one) don't care which grex
mailbox is named. There is one check for "generic" mailboxes -- ie,
outside machines supplying a RFC 823 To: field of "you@grex.org" and so
forth. Note even this check isn't looking at the forward path where the
mail will actually be sent, it's looking to see if spammers have used a
generic "somewhere at the realm in question" -- and this is no longer so
common since most people have caught on to this.
The "mailbox is full" message is separate logic (well, as separate as it
can be given it's one big monolithic program). It will be generated if
and only if your loginid is named in /var/adm/badmail . A better way to
check to see if your mailbox is full is to say
!umailck
In addition to seeing if you're on the list, this can actually take you
off the list if you were on it, but have managed to free up enough
mailbox space to receive more mail. If your mailbox is full when you
log in, login will spit out a message that includes information on how
to run umailck. There is also an automatic process that will remove you
from /var/adm/badmail if you free up space, but forget how to run
umailck .
|
scott
|
|
response 195 of 251:
|
Mar 2 20:13 UTC 2003 |
Grex was down for several hours - apparently a power blip last night tripped
up our UPS (plans to replace the batteries are in the works).
|
aruba
|
|
response 196 of 251:
|
Mar 2 21:23 UTC 2003 |
Do you mean the UPS failed to work, Scott?
|
keesan
|
|
response 197 of 251:
|
Mar 2 21:46 UTC 2003 |
Several of our clocks were blinking '4:45' this morning around 7:00.
|
scott
|
|
response 198 of 251:
|
Mar 2 22:09 UTC 2003 |
I don't know exactly what the UPS does, but the last few reboots have required
power-cycling the UPS because it was stuck in some kind of fault mode. There
was some kind of power blip last night; I heard both my UPSs go off but none
of my clocks were affected.
|
rksjr
|
|
response 199 of 251:
|
Mar 2 22:12 UTC 2003 |
Currently entering:
lynx, g http://www.cyberspace.org
yields:
Alert!: Unable to connect to remote host.
|
remmers
|
|
response 200 of 251:
|
Mar 2 22:17 UTC 2003 |
Can't connect to any remote host. The proxy server might not be
running. If I knew how to start it, I would.
|
keesan
|
|
response 201 of 251:
|
Mar 3 16:16 UTC 2003 |
RK, if you use Lynx frequently and want a backup for it, contact me.
This sort of proxy server problem has occurred before at grex.
|
rksjr
|
|
response 202 of 251:
|
Mar 3 22:35 UTC 2003 |
Re. #201: Thank you. I'll keep your offer in mind.
|
cross
|
|
response 203 of 251:
|
Mar 3 22:38 UTC 2003 |
This response has been erased.
|
scott
|
|
response 204 of 251:
|
Mar 4 03:02 UTC 2003 |
Seems like apply a patch would be somewhat easier.
|
cross
|
|
response 205 of 251:
|
Mar 4 04:32 UTC 2003 |
This response has been erased.
|
other
|
|
response 206 of 251:
|
Mar 4 07:41 UTC 2003 |
All versions since 5.79 are affected. What version are we running?
|
other
|
|
response 207 of 251:
|
Mar 4 07:46 UTC 2003 |
X-Force has demonstrated that this vulnerability is exploitable in
real-world conditions on production Sendmail installations. This
vulnerability is readily exploitable on x86 architecture systems, and may
be exploitable on others as well.
Protection mechanisms such as implementation of a non-executable
stack do not offer any protection from exploitation of this
vulnerability. Successful exploitation of this vulnerability does not
generate any log entries.
http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21950
|
gull
|
|
response 208 of 251:
|
Mar 4 14:15 UTC 2003 |
Re #206: Unless they've set sendmail up to lie about its version in its
connection banner (a good idea, IMHO), you can find that out yourself
pretty easily.
|
cross
|
|
response 209 of 251:
|
Mar 4 16:31 UTC 2003 |
This response has been erased.
|
gull
|
|
response 210 of 251:
|
Mar 4 17:03 UTC 2003 |
Incidentally, it appears this isn't exploitable on some systems. It
depends on how the binary is structured, so it may vary from build to build.
|
gull
|
|
response 211 of 251:
|
Mar 4 17:07 UTC 2003 |
I've always wondered a little if postfix is really more secure, or just
less common (and hence under less scrutiny.) I'm always a little
suspicious of claims of (in)security based on the number of *discovered*
bugs.
|
cross
|
|
response 212 of 251:
|
Mar 4 21:09 UTC 2003 |
This response has been erased.
|
jhudson
|
|
response 213 of 251:
|
Mar 4 22:49 UTC 2003 |
I'm going to get a good laugh when somebody tries to exploit that
bug against us! I don't think very many hackers can write
SunOS shellcode.
|
cross
|
|
response 214 of 251:
|
Mar 4 23:34 UTC 2003 |
This response has been erased.
|
tsty
|
|
response 215 of 251:
|
Mar 6 08:35 UTC 2003 |
script-kiddies suck.
|
dpc
|
|
response 216 of 251:
|
Mar 6 14:49 UTC 2003 |
So is it correct to assume that the widely-reported bug
in sendmail doesn't affect us?
|
cross
|
|
response 217 of 251:
|
Mar 7 07:25 UTC 2003 |
This response has been erased.
|
