ron
why not just strip *all* of the email addresses or replace them with a dummy address.
I'd go along with that.
If you really need someone's address you can always look it up in the archives
Not a bad idea. Not a bad idea at all, actually. The more I think
about it the more I like it.
Tiit
There's still the web archive and my experience is that spammers
can and do find it. Moreover, it doesn't honor X-No-archive the
way google does and you can't get messages removed.
I nominate the dummy address rav...@ssz.com.
Be carefull for what you wish for. You won't like the consequences one
damn bit.
-- --
God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
Andre Weil, in H. Eves, Mathematical Circles Adieu
rav...@ssz.com jch...@open-forge.com
www.ssz.com www.open-forge.com
no way. what's that ben franklin quote about liberty and security?
like Brass Balls Obradovitch i refuse to give up.
The 9grid technique might work among cooperating plan 9 sites if we
can figure out how to make the authentication require less effort by
the site administrators. It's really easy when the authentication is
set up; to deliver mail to user@machine,
import -bp machine /mail/box
mail user
It just works. No SMTP involved, just local delivery. Thanks, Dave.
For those who can't talk 9P, I'm trying the experiment of asking
friends to also listen on an alternate port for SMTP; I'm already
doing so. Once we get a few sites doing it, a few lines in rewrite
can select the alternate port for those sites. I'm not publishing the
port number in public, to discourage spamming. Mail arriving on the
alternate port gets less scrutiny and eventually mail to port 25 might
get tossed into a `probably crap' mailbox.
Oh, there's a sick idea: revive UUCP over TCP.
in my sig.
--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin
ooh, i _like_ unorthodox solutions.
i'll do it, with dans' net in ny.
yup that's it, donc je refuse de ne pas publier mon vrai mél.
Sounds like the opposite of the current US policy.
T-shirt?
a disadvantage of this approach is that without more work it makes
visible the names of all users on machine, details of their mail
boxes, and the contents of its /mail/lib and /mail/queue*
(not to mention /mail/tmp).
it works wonderfully well. acme mail from an imported /mail/box is
fantastic to use.
ron
if you can import it, you can already cpu to the machine. I'm not sure
it's an issue.
ron
oh, there's a heap of 'em in _task force dagger_ which i'm reading now.
There will be times of swift, dramatic action. There will be times
of steady, quiet progress. Over time, with patience and precision,
the terrorists will be persued. The will be isolated, surrounded,
cornered, until there is no place to run or to hide.
-- little george, oct 11 2001
take your pick.
well yeah, but if it's all owned by upas and stuff owned by none
is append+write only other the worst (i think) is that someone will
fill up /mail -- which they are already doing.
kill 'em at the smtp level. it'd even work on lunix.
not everybody can wear a XXL T-shirt.
as i've said before, i can't cope with acme, but /bin/mail works great,
since i got spamoff to keep the infidels out of my mail file.
i'm with you, captain ...
if you can cpu to the machine then why not utilise that machines smtp system which respects the users pipefrom and other configuration options ?
i said:
take your pick [of any of the sentences]
> if you can cpu to the machine then why not utilise that machines smtp
> system which respects the users pipefrom and other configuration options
> ?
this discussion has come full circle. The whole point of what we're doing
is to try out an SMTP-free mail system. I don't want anonymous messages
(99% of which are spam at this point) even darkening my door. If you are
filtering them, you've already lost (in my view anyway).
I don't want to take part in the filter wars. I don't want their messages
in my pipeto. I want them locked out.
ron
yeah! no more smtp, just import from people you like.
'local' delivery. simple solution and it will 'raise the bar' a lot,
until they see that 9p is in the clear. then we go to styx.
well the auth ain't, and they can hijack the tcp connection
and as soon as they do that we go to styx.
fuck 'em.
1. get a static IP address
2. host my own mail service
3. have the ability to reject incoming mail based on:
3.1 size
3.2 attachment type, if any
3.3 reg. expr. match of sender/recipient
4. bayseian filter on anything that gets through -- not
automatically reject these, but flag them for possible
wholesale deletion of suspected messages
This would save me a lot of time, considering the latest rash
of mail-from-microsoft, and I couldn't cuss brain-damaged,
inflexible ISP filtering any more.
A lot depends on one's definition of "spam."
Don
I thought the point of the CPUing was to cut out the anonymous messages
> I don't want their messages in my pipeto. I want them locked out.
my point was that once you've the them through the gate via CPU/import
then they should use the normal channels to continue to deliver the
message, not have write access to some mailbox file. Unless, of
course, you are proposing to drop the RFC 2822 format ?
> I thought the point of the CPUing was to cut out the anonymous messages
CPUing and running acme is painful. Importing /mail/box is delightful.
rno
even people you like might not like you enough to want to give you
access to more than you need to send mail to a specified user (and
it's not necessarily true that just because you can import you can
cpu).
one approach is to have a service that presents a mail-sending name space
through which mail can be sent, and the name space can
then be exported, with authentication. it also insulates sender and
recipient from detailed knowledge of current mbox conventions.
for reading mail, import seems fine, because given authentication it's presumably the
owner (or someone authorised by the owner) that's reading it.
we need some terms first:
Pok = probability that it's ok to deliver
Pspam = means spam
Pgood = some value <= Pspam
i think Pspam = 1 - Pok and Pok == 0.001 [1/1000, 1 message in a 1000]
Pbip = probability of a bad IP address
Pbm = probability of a bad sender/address/message [MAIL FROM <...>]
so then we need a black and a white list (per user or global or a mix).
these must be small, otherwise we have a 9 mil round in the foot.
black list:
seeded with a small number of open smtp relays/whatever IP
addresses [dotted quads] which a human can administer.
white list:
seeded with a small number (or none) people you 'like' which
a human can administer.
both lists are a key/value pair. the key is the dotted quad or the person
you like. the value is a number.
so as soon as we get the MAIL FROM we calculate [dc follows]:
Pbip Pbm * Pbip Pbm * 1 Pbip - 1 Pbm - * + /
and we call that Pgood
and if the result is:
> Pspam it gets returned
<= Pspam it gets delivered
now, before you say 'division by zero':
- iff the IP address is not found Pok is returned
- iff the 'person' you like is not found Pok is returned
Pbip = 1 1 n / - iff n > 1
Pbm = 1/n iff n > 1
0 means 'not found' and in this and all other cases Pok is returned.
if you've got this far then the interesting stuff happens:
law 1: it MUST fail safe
a message that has Pgood <= Pspam gets delivered and 2 things
happen when the Pgood is evaluated:
1) Pgood > Pspam : 'bad' dotted quads have their n++
2) Pgood <= Pspam : good 'people's have there n++, ['bad' dotted quads could
have their n---]
well it's more than that, 'cos you can say in the case where
Pgood > Pspam that the dotted quad is _automatically_
added to the black list.
using these techniques i believe it can 'learn'.
when Pgood > Pspam we kill 'em, potentially auditing the transaction, BUT
also sending a reply (iirc MAIL FROM <> is for that) so they can say i'm
not a T [bad guy] in a form that a machine/program could not (or it would
take a significant effort defeat).
this is the moat. the filter is the castle walls.
i would more than appreciate mail of the form:
boyd, you fuckhead, you overlooked this case
this stuff is hard. i know what i know, but;
i'm just a small town white boy
tryin' ta make ends meet
going back to 'law 1' any 'spam' must be saved in an easily retrievable form;
upas/deliver can do this. but it's double edged sword, but disk is cheap.
the purpose is to get the machine to do '1 shot 1 kill', so you don't wind
up with a bunch of shit to sift through.
voilà
(c) Boyd Roberts <bo...@insultant.net> (All Rights Reserved)
ps. i blame it all on 4 hours sleep, new 'zep DVD and red -- Kashmir!!
yes. it should be sliced to pieces. only good thing about it
is that groups used to smash 猶loth UAs.
i'm with you captain ...
yada, yada, yada. can i have my DES back that runs in vita's inferno?
maybe i don't want vita to use it anymore.
Sound good to me. I can't use it myself, though - my account here at
cooper is accessed either via pine or squirelmail :-(
I'm trying to get approval to install p9 on an old machine, and if that
works I'll try boyd's idea or the bayes scripts, but classes don't leave
much time for playing. Sigh..
Big thank you to boyd, russ, nemo, and anyone else who is working on spam
obliteration.
--Joel
when i was on good terms with vix ('cos we talked a lot about it, until i
flamed some 'old family' prick in boston) his EBGP spam killer was cool.
but the DNS and blendmail (sic) have gone to shit since it was delegated
to lesser mortals -- that stuff is hard.
and, as Van Halen say:
you can't get this stuff no more
So is dog shit.
> Adding tokens or auth is trading this for temporary security.
No, it's solving the problem the only way it can be solved.
- Dan C.
This will work for a time, but it's just a bandaid....
> Oh, there's a sick idea: revive UUCP over TCP.
It's been done.
- Dan C.
- Dan C.
i'm thinkin' along the lines of an MC-130 gunship ...
http://www.fas.org/irp/agency/dod/socom/sof-ref-2-1/SOFREF_Ch5.htm
come on, dan, he's an old guy. give him a chance. it'd be fair fight
if he had an M-79 :)
and they'd probably chop him to pieces with a MAC-10 :) :)
To do it on a larger scale, where you may not trust everyone who wants
to send you mail to cpu into your machine, it is.
I might want someone to send me mail without logging into my machine.
- Dan C.
this would be true if we imported /mail, but my (working) example is:
> import -bp machine /mail/box
which reveals much less.
> one approach is to have a service that presents a mail-sending name
> space through which mail can be sent, and the name space can then be
> exported, with authentication. it also insulates sender and recipient
> from detailed knowledge of current mbox conventions.
right, this is what i actually suggested as a Future Direction in the
RSMTP paper; `import /mail/box' is just a first-cut approximation that
requires no new code. i don't think it's worth implementing the
synthetic mail-receiving file system until we've figured out how to
make the cross-domain authentication less manual.
"There ought to be limits to freedom"
--at a Press conference at the Texas State House, May 21, 1999, referring to GWBush.com
I had same feeling this morning.
When too much of boyd, and Jim Choate, we have to be careful. ☺
Kenji