|
|
| Author |
Message |
| 25 new of 547 responses total. |
mdw
|
|
response 403 of 547:
| 
Jun 4 05:53 UTC 2003 |
Kerberos does 3 things for us: gives a more graceful way to deal with
our existing password hash data, allows us to start developing
distributed applications (such as file service, mail, conferencing,
etc.), and eventually (if standards and availability permit) may allow
us to offload client side stuff to user workstations. The first is
immediately useful to us all on its own. The 2nd could be useful in the
next 1-5 years. The 3rd is "pie in the sky" for now, but not
impossible.
|
janc
|
|
response 404 of 547:
|
Jun 4 13:33 UTC 2003 |
Did I misunderstand that? The modified password hash algorithm was justified
because it would ease the transition to Kerberos. Now Kerberos is justified
because it works better with the modified password hash algorithm? Seems
like the case for kerberos has to rest on points two and three.
|
cross
|
|
response 405 of 547:
|
Jun 4 17:11 UTC 2003 |
Again, I think it would be easier to use the BSD login API to deal with
the custom hash algorithm now, and find some other way to transition to
a standard Kerberos KDC. Particularly if you're not considering moving
to distributed services for another 1 to 5 years.
|
jp2
|
|
response 406 of 547:
|
Jun 4 20:34 UTC 2003 |
This response has been erased.
|
mdw
|
|
response 407 of 547:
|
Jun 5 02:31 UTC 2003 |
The first is the reason to do kerberos now rather than wait another 1-5
years. The second is the reason we want to do kerberos. The third is
the biggest but longest term and least likely win.
kerberos 5 does do md5. But the md5 there has nothing to do with Unix
md5 password hash. The unix md5 password hash was an early example of
"computationally expensive" hash logic -- see above.
|
cross
|
|
response 408 of 547:
|
Jun 5 03:22 UTC 2003 |
It's an extremely bad idea to take the hashed passwords from /etc/shadow
and use them as keys in a Kerberos KDC. I already advocated a method for
solving this problem cleanly and easily, but Marcus basically ignored it.
See item 134 in the Garage conference.
|
dang
|
|
response 409 of 547:
|
Jun 6 03:48 UTC 2003 |
(Spamassassin can be used to reject mail in the MTU, rather than via
procamail. This is not as good as the spam rejection we do now, because
the entire mail must be on Grex to run spamassassin against it.
However, it will reject considerably more spam. It's a tradeoff.)
|
aruba
|
|
response 410 of 547:
|
Jun 6 04:19 UTC 2003 |
Yeah, I gotta say, the spam-rejection we're doing now is letting a whole lot
of spam through.
|
cross
|
|
response 411 of 547:
|
Jun 6 05:49 UTC 2003 |
Maybe it's best to delay this discussion until we know exactly what
the mail filters do now....
|
scg
|
|
response 412 of 547:
|
Jun 6 07:07 UTC 2003 |
I should note that one of the places I receive mail through runs SpamAssassin,
and most of the spam I get scores considerably lower on the SpamAssassin
scores than most of my legitimate mail. Of course, I never see the mail
SpamAssassin does catch, and that's probably a considerable quantity of mail.
Rejecting spam in the MTA is obnoxious. If you're receiving the spam directly
from the sender, it probably makes a lot of sense. In general, though, most
of the spam I receive is forwarded through other lists and aliases, and the
return addresses are generally invalid, so bouncing spam just forwards it to
the postmaster of whatever mail server was forwarding it, disguised as bounce
messages of a sort the postmaster might actually need to look at. Spam
filters should throw the spam away silently, with the caveat that you have
to be really careful to err on the side of assuming mail is legitimate, since
the sender of legitimate mail won't know the mail isn't getting through. In
addition, if you're tagging spam in SpamAssassin and letting procmail do the
discarding, you give individual users some control over how much is being
deleted.
My complaint about SpamAssassin letting through too much spam doesn't mean
it's any worse than Grex's current filtering. I started automatically
discarding all my Grex mail because more spam was coming through than I could
manage.
|
cross
|
|
response 413 of 547:
|
Jun 6 07:33 UTC 2003 |
A good amount of the spam I receive these days comes through grex.
I don't bother forwarding it back to grex's uce alias since most of it
is the standard type of junk one typically sees. That is, I doubt anyone
is going to learn anything from it that isn't already common knowledge.
I will note that spamassassin now includes a Bayesian filter that can
be `trained' to recognize real spam. Running it and letting it do the
tagging can't hurt much.
There might be something to be said about generating bounces to
postmasters who are running open mail relays, but I tend to doubt it.
|
mdw
|
|
response 414 of 547:
|
Jun 6 07:51 UTC 2003 |
It's extremely difficult to collect good statistics about the
effectiveness of many anti-spam measures. Spammers tend not complain
when they can't send spam, so we don't know how many gave up. Natural
selection has clearly favored the evolution of spammers who get by
grex's defenses.
The problem with bayesian filters is it has to be trained on an
individual basis to give the good results people quote. It's not enough
to give it spam, it also have to be given ham, and each person's spam
and ham are different enough that a filter trained to one person's ham
isn't going to do so good at another's ham. A group of people with
common interests may get acceptable results even so; and in a work
environment defining "common" may even be possible. But I doubt there's
enough commonality amongst all grex users to achieve results of any
great value.
|
janc
|
|
response 415 of 547:
|
Jun 6 13:14 UTC 2003 |
Case in point: I'd be perfectly happy with a spam filter that rejects all
mail written in any languages other than English and German. If I trained
a Bayesian filter, that's probably part of what it would do. However, there
are lots of other users on Grex who for some strange reason like foriegn
language main. A suitable Bayesian filter for them would be very different
than one for me.
|
gull
|
|
response 416 of 547:
|
Jun 6 13:28 UTC 2003 |
Re #412: If a postmaster's site is acting as a spam relay, they deserve
to be annoyed.
Re #414: Where I work we're currently using a Bayesian filter with a
site-wide corpus, with pretty good results. But this is a small
company, with about 30 employees that tend to make similar decisions
about what is and isn't spam. (The majority of our spam is, for some
reason, for porn sites and penis enlargment products, which no one
admits to wanting in their work accounts.) We also don't bounce
messages based on the filter, just tag them for later filtering with
each user's mail client. I seriously doubt this approach would work for
Grex, because the user base here is too diverse.
To me, it's far, far more important that legitimate mail to my Grex
account not be rejected than that spam be blocked. For that reason I'd
oppose any heavy-handed spam filtering unless it was configurable on an
individual user basis. I'd also oppose any spam filtering that silently
dropped messages instead of bouncing them, because it's far better if a
legitimate message bounces than if it just disappears. People are
conditioned to assume that if an email doesn't bounce back, it arrived
intact.
|
cross
|
|
response 417 of 547:
|
Jun 6 14:31 UTC 2003 |
A global installation of spamasassin can be use each individual user's
preferences. That is, it can be run by default and use a target users
data; there doesn't have to be a system wide immutable setting. Also,
spamassassin doesn't automatically delete spam, it just tags it and
let's the user decide what to do with it. I dump mine into a special
MH folder that I scan once or twice a day to pull out any false positives.
|
carson
|
|
response 418 of 547:
|
Jun 6 17:06 UTC 2003 |
(when installing spamassassin on a system, it's a good idea to run it in
a "learning" mode before using it to block mail. because it works using
Bayesian filters, it needs time to A) learn what to block and B) prove
that it's not dumping legitimate mail at an unacceptable rate.)
(Marcus wrote somewhere [I don't remember where off-hand] recently
indicating that, if Grex were to use an open relay blocking list, it would
occasionally reject mail to itself because Grex sometimes appears on RBL
lists. I'm not sure why he caem to that conclusion. while I've
occasionally seen Grex on DNS blacklists, I've yet to see it on an open
relay list. at any rate, it seems trivial [to me, anyway] that, if Grex
were to use outside blacklists, it would be on its own local whitelist.)
(Scott Vintinner wrote a document on how to set up an anti-spam gateway
using a combination of OpenBSD, Postfix, Amavisd-new, SpamAssassin, Vipul's
Razor, and DCC. it's at http://lawmonkey.org/anti-spam.html . he makes
some choices in implementation that we likely would not. still, it
provides a start, and there are some useful suggestions in the document
that are valid in and of themselves. the one question I'd have about the
gateway set-up is "how resource-intensive is it?", but I keep reminding
myself that NextGrex is more powerful than the current model and will
likely surprise us with what it can and can't handle.)
|
scg
|
|
response 419 of 547:
|
Jun 6 21:26 UTC 2003 |
re 416:
There's a rather large difference between an open relay forwarding spam
in random directions, and a well secured mail server handling mailing lists
or .forward files.
As a case in point, I used to host the Grex staff mailing lists on my mail
server. That is, people would send mail to the staff@grex.org address or some
other less publicized aliases, and it would be forwarded to my mail server,
which would then forward it on to the individual staffers on mail servers all
over the place. Then a couple of staff members started using spam filtering
that rejected spam in MTA, thus sending the spam back to the postmaster of
the mail server that was trying to deliver it to them, in this case me. One
staffer had this imposed on him by his mail provider, and didn't have much
of a choice in it, while another staff member had configured it himself and
refused to fix it. The result was that running a mailing list that sent mail
to those people was more trouble than it was worth.
|
dang
|
|
response 420 of 547:
|
Jun 10 18:19 UTC 2003 |
My provider dedided a while ago to start bouncing mail with
SpamAssassin. For whatever reason, this was catching a lot of mail that
I wanted, and people were complaining. I left them and went to a site
that didn't block spam, as I run my own spam filters (a combination of
spamassassin with custom rules and bogofilter). Just a datapoint.
|
i
|
|
response 421 of 547:
|
Jun 21 13:13 UTC 2003 |
There was a decent item on SlashDot yesterday about noting the tuple of
sender, recipient, & IP address at the the start of a SMTP session and
putting the e-mail off an hour (with "try again later" or some such) if
the tuple isn't in a kept-on-the-side database of tuples seen more than
one hour but less than 36 days ago.
This does a passable job of blocking most try-once-quickly-and-move-on
spam, but little try-again-per-the-RFC real e-mail (according to the
author). The 1 hour and 36 days were adjustable parameters; there were
other details & some real-use-experience statistics.
This sounds like it has a number of features we're looking for in an
anti-spam tool for Grex...any thoughts?
|
other
|
|
response 422 of 547:
|
Jun 21 17:05 UTC 2003 |
Whatever will help stem the flow...
|
gull
|
|
response 423 of 547:
|
Jun 23 14:17 UTC 2003 |
It would tend to increase the network load. (Each valid message that
wasn't high-traffic would require two connections and attempts intead of
one.) Is the majority of spam really "try once and move on?" I imagine
that's probably true of direct-to-MX spam, but probably not true of open
relay spam.
|
keesan
|
|
response 424 of 547:
|
Jun 23 21:06 UTC 2003 |
I get the same spams numerous times.
|
cross
|
|
response 425 of 547:
|
Jun 23 21:33 UTC 2003 |
Perhaps, but it's not clear to me that the load on the network link
is excessive right now. It's thought to be, but no one's ever measured
it. I'd think the latency in getting email would be more troublesome.
Spam isn't a problem that's solved by adding arbitrary delays into the
mix.
|
i
|
|
response 426 of 547:
|
Jun 24 00:39 UTC 2003 |
We're close to having this ready for production use at work. Very early
results suggest that most spam doesn't come back to retry delivery later.
|
russ
|
|
response 427 of 547:
|
Jun 24 03:49 UTC 2003 |
It might be easier to deal with spam by accepting the first N pieces
of mail from a novel host, then delaying the rest; if the mail starts
showing up in the UCE bin, further mail from that host is refused for
an extended period (or perhaps permanently). This takes care of
hijacked relays as well, while passing the occasional e-mail from an
odd host without any delays at all.
While spam may not be a big bandwidth load, it sure isn't going to
stay small unless we act; it really behooves us to frustrate spammers
if we can.
Jan, is there any way to get Backtalk to salt its pages with fake
e-mail addresses that would be picked up by spam harvesters? That
would be one way to be certain that a host was sending spam to Grex.
|
