[9fans] stubbing

[9fans] stubbing

[Jack Johnson]

In this glorious age of viruses, trojans, prolific email and spam,
we've been looking at options to improve attachment handling at work. 
Xythos Intellittach came up.

It also occurred to me that using vac might be a nice way to do
attachment stubbing.  Strip the attachment at the mail gateway, vac it
up, use the fingerprint in the URL and send it on.  Then retrieve it
using a script to listen on port 80 and return the file associated
with the fingerprint.

The nicest part about using venti as a backend is that any spam,
viruses, etc. that get through the gateway only exist once in the
system, as does that 100MB PowerPoint that the PHB sends out once a
month.  There are a few commercial systems that do something similar
(ZipLip, etc.) for Sarbanes-Oxley and other compliance.  A related
idea occurred to me before:

http://lists.cse.psu.edu/archives/9fans/2002-July/019109.html

but it seems the general idea of ticket-based ACLs in WebDAV is
picking up steam, so the attachment stubbing scenario might be less
foreign these days.

Having the entire mail store in venti is probably the best way to
handle it, I keep thinking of organizations (like mine) who would
never make that move, but would consider some blended solution to
better manage the runaway mail storage space and the landmine of SMTP
gateways preventing the boss' random attachments from reaching point
B.

-Jack

Re: [9fans] stubbing

[Russ Cox]

For this particular application, venti and vac are overkill.

md5=`{md5sum <$file}
mkdir -p `{echo $md5 | sed 's!(...)(...)!\1/\2!'}
mv $file `{echo $md5 | sed 's!(...)(...)(.*)!\1/\2/&'}

Also, for the particular motivation of rejecting viruses,
I've been very happy with /mail/lib/validateattachment
(called by upas/vf).  I haven't gotten a virus via Plan 9
in months, and I used to get a handful every day.

Russ

Re: [9fans] stubbing

[Steve Simon]

I have been using Geoff's greylisting code for six months and have been
amazed how effective it is - I get one or two pieces of spam a week where
at one point it was a dozen a day.

I also published SPF records which has cut down on the complaints I get
about my address being used in forged From: headers in spam.

-Steve

Re: [9fans] stubbing

[C H Forsyth]

>>I also published SPF records which has cut down on the complaints I get
>>about my address being used in forged From: headers in spam.

i had similar luck with greylisting, validatesender, etc and SPF.
now, if i could just do something about the rbl morons, i'd be happy,
but i doubt it.  people that attempt reverse lookups and not SPF are a
close second.

Re: [9fans] stubbing

[Dave Lukes]

 > i had similar luck with greylisting, validatesender, etc and SPF.

We can't greylist, we'll be validating sender in about a month and
SPF will get done ASA I convince myself I know what it "means".

 > now, if i could just do something about the rbl morons, i'd be happy,

DaveL puts his finger in his ear and says "Rud" backwards.

Charles,
I'm sure we'd all like to hear of a spam-protection system which isn't a 
PITA to administer
and which actually delivers the message before the recipient dies of old 
age:
greylisting is too slow for our business.
Sadly, in reality, I suspect that what we have here (spamassassin and 
blacklists up the eyeballs)
is about as good as it gets:
evidence to the contrary gratefully received.

Our whitelist has about 6 entries on it for important business contacts 
who use dodgy ISPs.

 > but i doubt it. people that attempt reverse lookups and not SPF are a 
close second.

Hysterical reasons for that, like SPF has only existed for <1year,
uses DNS and has badly publicised semantics
(otherwise I'd have jumped on it long ago).

    Dave.

Re: [9fans] stubbing

[Charles Forsyth]

the quality of the blacklists is poor and many entries are completely unrelated
to spam, based on a silly assumption; and it's usually
impossible to correct incorrect data (because the rbl maintainers are morons,
sorry: officious morons). (all right, to be fair, perhaps most are
wonderful and of course i only notice the ones that cause me grief.)

the problem with reverse lookups is that because so many IP addresses
are assigned from bigger blocks, although it's easy to provide A records,
MX, the TXT used for SPF, TXT used for keys, etc., it's often
impossible to provide PTR because the DNS for that isn't under the
same admin as the DNS for names (thanks to DNS design)
and it's often hard even to find the person who could put PTR records
in, or delegate them (and often they don't provide that service).

Re: [9fans] stubbing

[Ronald G Minnich]

Charles Forsyth wrote:
> the quality of the blacklists is poor 


re this, my entire domain (lanl.gov) is blacklisted so that I can not 
post to v9fs-developers.

It may be justified, however, since we have many naive users with 
Windows boxes who may, for all I know, by zombies.

ron

Re: [9fans] stubbing

[Russ Cox]

> re this, my entire domain (lanl.gov) is blacklisted so that I can not
> post to v9fs-developers.
>
> It may be justified, however, since we have many naive users with
> Windows boxes who may, for all I know, by zombies.

This is exactly the problem with blacklisting: you might reject
some bad mail, but you lose a lot of good mail too.
It's like chewing off your arm just because your pinky is broken.

Russ

Re: [9fans] stubbing

[Wes Kussmaul]

> This is exactly the problem with blacklisting: you might reject
> some bad mail, but you lose a lot of good mail too.
> It's like chewing off your arm just because your pinky is broken.
> 
> Russ

ID-PKI

Re: [9fans] stubbing

[Wes Kussmaul]

Dave Lukes wrote:

> I'm sure we'd all like to hear of a spam-protection system which isn't a 
> PITA to administer
> and which actually delivers the message before the recipient dies of old 
> age:
> greylisting is too slow for our business.
> Sadly, in reality, I suspect that what we have here (spamassassin and 
> blacklists up the eyeballs)
> is about as good as it gets:
> evidence to the contrary gratefully received.

Evidence to the contrary:

Premise: A reliable, large-scale, deployable PKI with reliable identity 
credentials that fortify rather than erode privacy will solve most of 
the spam problem.

Relevant cliche': "It's been tried many times. A reliable, large-scale, 
deployable PKI will never happen."

Exhibit A: Skype is a massive, working, worldwide, trouble-free PKI that 
was just bought by a company (eBay) that desperately needs the kind of 
transactional authenticity/integrity that a PKI like Skype can provide.

Exhibit B (to be introduced shortly; will demonstrate that reliable 
identities, while labor intensive, are obtainable)

You're welcome.

Wes


The information contained in this electronic message and any attachments 
to this message are intended for the exclusive use of the addressee(s) 
and may contain confidential or privileged information. If you are not 
the intended recipient, please notify attorney Mort Hapless at Vulner, 
Exposed & Wideopen LLP immediately at either (781) 647-7178, or at 
ohoh@vulex.com, and destroy all copies of this message and any 
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t 
stop reading that confidential stuff about our client you’re in big 
trouble. OK, we’re the ones in trouble but we’ll find a way to go after 
you, or at least we think we may be able to. Look, we’re begging you. 
Just click the delete button and move on to a message that concerns you, 
OK? Please?? We'll buy you lunch...

Re: [9fans] stubbing

[Dave Lukes]

> Evidence to the contrary:
>
> Premise: A reliable, large-scale, deployable PKI with reliable 
> identity credentials that fortify rather than erode privacy will solve 
> most of the spam problem.

... and this helps my current spam problem how?

DaveL

Re: [9fans] stubbing

[Wes Kussmaul]

Dave Lukes wrote:

> ... and this helps my current spam problem how?

Oh, there's that troublesome word "current" again...

Look at it this way. If you have kids, spam will be the least of their 
online problems if we don't do something.

Wes


-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments 
to this message are intended for the exclusive use of the addressee(s) 
and may contain confidential or privileged information. If you are not 
the intended recipient, please notify attorney Mort Hapless at Vulner, 
Exposed & Wideopen LLP immediately at either (781) 647-7178, or at 
ohoh@vulex.com, and destroy all copies of this message and any 
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t 
stop reading that confidential stuff about our client you’re in big 
trouble. OK, we’re the ones in trouble but we’ll find a way to go after 
you, or at least we think we may be able to. Look, we’re begging you. 
Just click the delete button and move on to a message that concerns you, 
OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let The Village Group 
(village.com) ensure that only intended recipients receive your 
confidential messages.

Re: [9fans] stubbing

[Dave Lukes]

> Oh, there's that troublesome word "current" again...

If we don't solve the current problems we'll drown before we have a 
chance to solve the future problems.

> Look at it this way. If you have kids, spam will be the least of their 
> online problems if we don't do something.

If I have kids, online problems will be the least of their problems
(global warming, lack of social responsibility, terrorism ...).

Dave.

Re: [9fans] stubbing

[Wes Kussmaul]

Dave Lukes wrote:

> If we don't solve the current problems we'll drown before we have a 
> chance to solve the future problems.

Solve the current problems with what? Firewalls? Intrusion detection 
systems and whitelists and blacklists? Hey, the ship is going down and 
we are drowning. Shall we ignore that other ship on the horizon as we 
focus on a futile effort to keep this one afloat?

> If I have kids, online problems will be the least of their problems
> (global warming

Global warming? Look closely at what Brian Hancock did with an Inferno 
grid at Rutgers. Think about that as a real workplace, not some cutesy 
virtual collaborative forumy chat roomy IRC with no accountability. Then 
put your Beemer up on eBay.

Reliable online workplaces (Plan 9 / Inferno grids with reliable 
identity credentials and building codes / occupancy permits) displace 
travel.

lack of social responsibility

Yeah, isn't that what happens when you move 6 billion people into a 
(global) village with no system of identity/accountability? Did we 
really expect a village instead of a mob?

  terrorism ...).

Yup, gangs of terrorists, that's who's in charge in a global mob. Your 
manageable village where people can be held responsible just because 
they know each other tops out at a population of about a thousand. Even 
in my little town of 10,000 if I get stopped by a local cop they need to 
see a driver's license. And they call it in (voice over OCSP) as another 
reality check.

Now I have to add, because it always comes up at this point: if done 
right a strong identity credential can be the cornerstone of personal 
privacy rather than an eroder of privacy.

ID-PKI. Thought through and done right. Fixes all that stuff.

Wes

Re: [9fans] stubbing

[erik quanstrom]

dudes,

you went from a little spam to terrorists. i think you
may need a perspecitive check.

- erik

Wes Kussmaul <wes@village.com> writes

| 
| Dave Lukes wrote:
| 
| Global warming? Look closely at what Brian Hancock did with an Inferno 
| grid at Rutgers. Think about that as a real workplace, not some cutesy 
| virtual collaborative forumy chat roomy IRC with no accountability. Then 
| put your Beemer up on eBay.
| 
| Reliable online workplaces (Plan 9 / Inferno grids with reliable 
| identity credentials and building codes / occupancy permits) displace 
| travel.
| 
| lack of social responsibility
| 
| Yeah, isn't that what happens when you move 6 billion people into a 
| (global) village with no system of identity/accountability? Did we 
| really expect a village instead of a mob?
| 
|   terrorism ...).
| 

Re: [9fans] stubbing

[Wes Kussmaul]

Sorry, that was a bit shrill.

Re: [9fans] stubbing

[lucio]

> Now I have to add, because it always comes up at this point: if done 
> right a strong identity credential can be the cornerstone of personal 
> privacy rather than an eroder of privacy.

Wes, I tried to reply privately to this, but I got:

... while talking to mail.village.com.:
>>> DATA
<<< 450 Client host rejected: cannot find your hostname, [192.96.32.135]
<wes@village.com>... Deferred: 450 Client host rejected: cannot find your hostname, [192.96.32.135]
<<< 454 Error: no valid recipients

which is puzzling.  Can you help me figure this one out?  As far as I
know, reverse resolution is OK, it returns:

# nslookup -q=ptr 135.32.96.192.in-addr.arpa. ns1.iafrica.com
Server:  ns1.iafrica.com
Address:  196.7.0.139

135.32.96.192.in-addr.arpa      name = mmm.proxima.alt.za
135.32.96.192.in-addr.arpa      name = wow.proxima.alt.za
135.32.96.192.in-addr.arpa      name = www.anon.co.za
135.32.96.192.in-addr.arpa      name = www.uucp.co.za
135.32.96.192.in-addr.arpa      name = www.plan9.co.za
135.32.96.192.in-addr.arpa      name = www.chinso.co.za
135.32.96.192.in-addr.arpa      name = www.paging.co.za
135.32.96.192.in-addr.arpa      name = www.kestell.co.za
135.32.96.192.in-addr.arpa      name = www.proxima.alt.za
135.32.96.192.in-addr.arpa      name = www.minimall.co.za
135.32.96.192.in-addr.arpa      name = www.tradenet.co.za
135.32.96.192.in-addr.arpa      name = www.minimalls.co.za
135.32.96.192.in-addr.arpa      name = www.easytronic.co.za
135.32.96.192.in-addr.arpa      name = www.karmalodge.co.za
135.32.96.192.in-addr.arpa      name = treacle.proxima.alt.za
135.32.96.192.in-addr.arpa      name = virtual.web.proxima.alt.za
32.96.192.in-addr.arpa  nameserver = ns1.iafrica.com
32.96.192.in-addr.arpa  nameserver = ns2.iafrica.com
32.96.192.in-addr.arpa  nameserver = treacle.proxima.alt.za

a bit rich, but hardly insufficient.

++L

Re: [9fans] stubbing

[lucio]

> Thanks for taking the trouble to let me know about this. Perhaps now 
> that this message is going to you the jailer will accept you as a 
> legitimate visitor!

Sorry to use the list for this, but Wes is otherwise unreacheable to
me.

Wes, here's another one for Bill, from a different host, albeit on the
same physical wire as 192.96.32.135 (can't be helped, yet):

> The original message was received at Tue, 11 Oct 2005 22:41:20 +0200 (SAST)
> from lucio@localhost 
>   
>    ----- The following addresses had transient non-fatal errors -----
> bilsch@village.com
> wes@village.com 
>   
>    ----- Transcript of session follows -----
> ... while talking to mail.village.com.:
> >>> RCPT To:<wes@village.com>   
> <<< 450 Client host rejected: cannot find your hostname, [196.30.44.140]
> wes@village.com... Deferred: 450 Client host rejected: cannot find your hostname, [196.30.44.140]
> >>> RCPT To:<bilsch@village.com>
> <<< 450 Client host rejected: cannot find your hostname, [196.30.44.140]
> bilsch@village.com... Deferred: 450 Client host rejected: cannot find your hostname, [196.30.44.140]
> Warning: message still undelivered after 4 hours
> Will keep trying until message is 1 day old
> 

I'd like to suggest two possible approaches to identify the problem:
this is what the SOA for 32.96.192.in-addr.arpa ought to be, Bill may
be able to determine where his DNS is failing by comparing results:

32.96.192.in-addr.arpa
        origin = ns.proxima.alt.za
        mail addr = lucio.proxima.alt.za
        serial = 2005082301
        refresh = 10800 (3H)
        retry   = 1800 (30M)
        expire  = 3600000 (5w6d16h)
        minimum ttl = 86400 (1D)

and for 44.30.196.in-addr.arpa is

44.30.196.in-addr.arpa
        origin = proxy.iba.co.za
        mail addr = lucio.proxima.alt.za
        serial = 2005092301
        refresh = 10800 (3H)
        retry   = 1800 (30M)
        expire  = 3600000 (5w6d16h)
        minimum ttl = 86400 (1D)

If Bill can't find these RRs, then he must work his way up the hierarchy until he determines where the gap is.  Maybe I can save him some effort:

myrtle:161$ nslookup -q=soa 30.196.in-addr.arpa    
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
30.196.in-addr.arpa
        origin = ns1.iafrica.com
        mail addr = dns-admin.uunet.co.za
        serial = 2005101202
        refresh = 43200 (12H)
        retry   = 3600 (1H)
        expire  = 2592000 (4w2d)
        minimum ttl = 86400 (1D)

Authoritative answers can be found from:
30.196.in-addr.arpa     nameserver = ns1.iafrica.com
30.196.in-addr.arpa     nameserver = ns2.iafrica.com
30.196.in-addr.arpa     nameserver = auth200.ns.uu.net
30.196.in-addr.arpa     nameserver = auth210.ns.uu.net
ns1.iafrica.com internet address = 196.7.0.139
ns2.iafrica.com internet address = 196.7.142.133
auth200.ns.uu.net       internet address = 195.129.12.82
auth210.ns.uu.net       internet address = 195.129.12.74

myrtle:162$ nslookup -q=soa 196.in-addr.arpa    
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
196.in-addr.arpa
        origin = chia.arin.net
        mail addr = bind.arin.net
        serial = 2005101214
        refresh = 1800 (30M)
        retry   = 900 (15M)
        expire  = 691200 (1w1d)
        minimum ttl = 10800 (3H)

Authoritative answers can be found from:
196.in-addr.arpa        nameserver = basil.arin.net
196.in-addr.arpa        nameserver = henna.arin.net
196.in-addr.arpa        nameserver = indigo.arin.net
196.in-addr.arpa        nameserver = epazote.arin.net
196.in-addr.arpa        nameserver = figwort.arin.net
196.in-addr.arpa        nameserver = chia.arin.net
196.in-addr.arpa        nameserver = dill.arin.net
basil.arin.net  internet address = 192.55.83.32
henna.arin.net  internet address = 192.26.92.32
indigo.arin.net internet address = 192.31.80.32
epazote.arin.net        internet address = 192.41.162.32
figwort.arin.net        internet address = 192.42.93.32
chia.arin.net   IPv6 address = 2001:440:2000:1::21
chia.arin.net   internet address = 192.5.6.32
dill.arin.net   internet address = 192.35.51.32

The above ought to suffice for the one IP, the other gives:

myrtle:164$ nslookup -q=soa 96.192.in-addr.arpa
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
96.192.in-addr.arpa
        origin = disa.tenet.ac.za
        mail addr = eosap.tenet.ac.za
        serial = 200509220
        refresh = 3600 (1H)
        retry   = 3600 (1H)
        expire  = 2592000 (4w2d)
        minimum ttl = 86400 (1D)

Authoritative answers can be found from:
96.192.in-addr.arpa     nameserver = ns1.afrinic.net
96.192.in-addr.arpa     nameserver = disa.tenet.ac.za
96.192.in-addr.arpa     nameserver = rain.psg.com
96.192.in-addr.arpa     nameserver = ucthpx.uct.ac.za

myrtle:163$ nslookup -q=soa 192.in-addr.arpa 
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
192.in-addr.arpa
        origin = chia.arin.net
        mail addr = bind.arin.net
        serial = 2005101214
        refresh = 1800 (30M)
        retry   = 900 (15M)
        expire  = 691200 (1w1d)
        minimum ttl = 10800 (3H)

Authoritative answers can be found from:
192.in-addr.arpa        nameserver = chia.arin.net
192.in-addr.arpa        nameserver = dill.arin.net
192.in-addr.arpa        nameserver = basil.arin.net
192.in-addr.arpa        nameserver = henna.arin.net
192.in-addr.arpa        nameserver = indigo.arin.net
192.in-addr.arpa        nameserver = epazote.arin.net
192.in-addr.arpa        nameserver = figwort.arin.net
chia.arin.net   IPv6 address = 2001:440:2000:1::21
chia.arin.net   internet address = 192.5.6.32
dill.arin.net   internet address = 192.35.51.32
basil.arin.net  internet address = 192.55.83.32
henna.arin.net  internet address = 192.26.92.32
indigo.arin.net internet address = 192.31.80.32
epazote.arin.net        internet address = 192.41.162.32
figwort.arin.net        internet address = 192.42.93.32

The other experiment would involve setting the DNS server on Bill's
equipment to act as secondary for the two domains
(44.30.196.in-addr.arpa and 32.96.192.in-addr.arpa) by fetching the
zone files from their respective nameservers.  I would have to grant
access, but it may be worth doing to establish the circumstances that
cause the failure by eliminating some unknowns.

++L