Re: namedroppers, continued

[Doug Royer]

D. J. Bernstein wrote:

Bush stuck the following note into the top of my latest message to
namedroppers:
...
You're perfectly aware
that many senders don't read messages to the list.

>...

Yet - you must be reading the list or you would not have seen it.

Please cry elsewhere.

--

 Doug Royer |   http://INET-Consulting.com
 ---|-
 [EMAIL PROTECTED] | Office: (208)612-INET
 http://Royer.com/People/Doug   |Fax: (866)594-8574
|   Cell: (208)520-4044

We Do Standards - You Need Standards



smime.p7s
Description: S/MIME Cryptographic Signature

Re: namedroppers, continued

[Keith Moore]

[recipient list trimmed.]

> Furthermore: Stop delaying messages. The delay is unacceptable. The
> excuse for the delay, namely manual review, is also unacceptable.

I think the other suggestions are worth considering, but can't agree 
with this one.  Spam significantly reduces the signal-to-noise ratio
of a list to the point that it's impossible to get work done, and at
present we don't have a good way of effectively filtering the list
while keeping the list open to contributions from outsiders that doesn't 
involve human perusal of such messages, hence delay.

To me it seems unlikely to be vital that messages from a non-subscriber
reach the list immediately - as long as the message gets forwarded within
a day or two, and as long as messages that experience such delays are
given adequate consideration by the working group.  So if there's a 
working group last call that ends on day X, and the non-subscriber's
message doesn't show up until day X+3 due to delay, it should still
be considered as relevant input to the group.  

But except for such deadlines, what is that non-subscriber responding to 
that can't wait a day or two, if not some activity on the list?
No working groups that I'm familar with make decisions that quickly.

As for the legal arguments, the place to decide those - if it's really
important enough to go to the trouble - is in a court of law.  Arguments 
about such matters by engineers are rarely fruitful.

Keith

Re: namedroppers, continued

[D. J. Bernstein]

Keith claims that allowing ``contributions from outsiders'' requires
delay and manual review. That claim is absurd. Immediately bounce the
message to the ``outsider,'' with instructions explaining how to have
the message sent to subscribers; end of problem.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

RE: namedroppers, continued

[Bill Strahm]

Silly question,

But you DO know what it will take to get your message to be immediately
seen by the list, you just aren't willing to do it... 

I believe the problem is in your court, easily solved and it is not time
to move on to something that might be slightly productive

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of D.
J. Bernstein
Sent: Friday, November 29, 2002 3:22 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: namedroppers, continued


Keith claims that allowing ``contributions from outsiders'' requires
delay and manual review. That claim is absurd. Immediately bounce the
message to the ``outsider,'' with instructions explaining how to have
the message sent to subscribers; end of problem.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Re: namedroppers, continued

[Keith Moore]

> Keith claims that allowing ``contributions from outsiders'' requires
> delay and manual review. That claim is absurd. Immediately bounce the
> message to the ``outsider,'' with instructions explaining how to have
> the message sent to subscribers; end of problem.

Well, as long as the method for getting the message to the subscribers
(a) is simple and not onerous, and 
(b) cannot be automated
then I'd probably agree that this is an acceptable solution.

I've seen lists for which the way that this was accomplished -
subscribing or getting on the "acceptable posters" list - involved 
several email round-trips to get the address of the list bot,
get the help file, send a command, get back a cookie, send back
the cookie, find out that the list bot won't accept subscribe
requests and/or cookies from a different address than that for
which the subscription is requested, etc.  Basically it amounted
to a considerable barrier to posting by outsiders.

These days, with a web interface, that level of complexity is
no longer necessary.

But if you make the process automatable spammers _will_ game it.

Keith

Re: namedroppers, continued

[Pekka Savola]

On 29 Nov 2002, D. J. Bernstein wrote:
> Keith claims that allowing ``contributions from outsiders'' requires
> delay and manual review. That claim is absurd. Immediately bounce the
> message to the ``outsider,'' with instructions explaining how to have
> the message sent to subscribers; end of problem.

No, it's not 'end of problem'.

If I cross-post a reply to some message with was cross-posted to a list
I'm subscribed at and a list I'm not, in the general case I do *not* want
to subscribe to the other list to be able to send my cross-post reply to
both.

Waiting for moderator approval is just fine for me, much better than
requiring to subscribe or do something else.

It's not black and white.

-- 
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

RE: namedroppers, continued

[Hallam-Baker, Phillip]

This whole discussion should be taken to the
YWKTIEDNWWFALNORIBNLTICSADEWSIFOSTFSTNOML working group. (yes we know
that internet email does not work well for a large number of reasons,
including but not limited to, incorrect code, spam and dare we say it
failure of smtp to fully support the needs of mailing lists).

The only way to resolve this issue properly would be to require every
submission to an IETF mailing list to be cryptographically signed (PGP
or S/MIME), to require the subscribers to register their signing key and
to then filter the mail sent out on the list so that only signed mail
gets through.

While this would require a moderate degree of work on the part of the
list users it would eliminate the need for moderator action. Problem
posters could be dealt with by means of  a formal process.

Thawte still provides free S/MIME certificates, however for the purposes
of this proposal it would suffice to use a self signed certificate.

SPAM is becomming a serious problem - as Bersnteins own rather offensive
spam protection measures atest. The only way to resolve that problem in
the long run is to start authenticating the good signal at source. The
strategy of attempting to isolate the bad signal from the good is
failling progressively as the spam companies employ counter measures.

The relevance of this to DNS is that the ability to authenticate an SRV
record provides an imense amount of leverage in automating this process.
For example I can have some form of information service set up linked to
the DNS that tells people that I sign every one of my emails without
exception and that any unsigned mail message can be rejected.

SPAM is a security problem. If we don't fix it the signal to noise ratio
will fall way below acceptable levels for many users.

Phill


> -Original Message-
> From: Pekka Savola [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 30, 2002 8:00 AM
> To: D. J. Bernstein
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: namedroppers, continued
>
>
> [ post by non-subscriber.  with the massive amount of spam,
> it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish
> to regularly
>   post from an address that is not subscribed to this mailing
> list, send a
>   message to [EMAIL PROTECTED] and ask to have
> the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
> On 29 Nov 2002, D. J. Bernstein wrote:
> > Keith claims that allowing ``contributions from outsiders'' requires
> > delay and manual review. That claim is absurd. Immediately
> bounce the
> > message to the ``outsider,'' with instructions explaining
> how to have
> > the message sent to subscribers; end of problem.
>
> No, it's not 'end of problem'.
>
> If I cross-post a reply to some message with was cross-posted
> to a list
> I'm subscribed at and a list I'm not, in the general case I
> do *not* want
> to subscribe to the other list to be able to send my
> cross-post reply to
> both.
>
> Waiting for moderator approval is just fine for me, much better than
> requiring to subscribe or do something else.
>
> It's not black and white.
>
> --
> Pekka Savola "Tell me of difficulties surmounted,
> Netcore Oy   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
>
>
>
>
> --
> to unsubscribe send a message to
> [EMAIL PROTECTED] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>



smime.p7s
Description: application/pkcs7-signature

Re: namedroppers, continued

[Aaron Swartz]

Hallam-Baker, Phillip wrote:

The only way to resolve this issue properly would be to require every
submission to an IETF mailing list to be cryptographically signed
[and] to require the subscribers to register their signing key


And how do we prevent spammers from registering their signing key? Are
you suggesting that we change the IETF's open enrollment policy?

--
Aaron Swartz [http://www.aaronsw.com]

RE: namedroppers, continued

[Hallam-Baker, Phillip]

First off, the problem of SPAM is one of the perfect being the enemy of
the good. If we can cut the spam by 95% then that is a pretty useful
achievement.

So, no I don't think that the folk selling feather luggage, herbal
viagra, p0rn etc are likely to go to that length in great numbers,
unless that is the Internet as a whole adopts the same type of measure
following our lead.


However I have thought ahead to the issues of scale here, let us imagine
that a large number of groups use the same scheme, that email agents
that filter based on signatures are available and widely used.

First, consider the effect of a minor authentication requirement on
certificate issue, the ability to read email sent to the address
specified in the certificate. Using that technique we could eliminate
spams with bogus addresses which itself would be a major advance. The
amount of spam that comes through with a valid email address is
vanishingly small.

Second consider that if the whole internet follows our lead and starts
to use cryptography routinely there are a lot of additional steps that
then become possible that are not practical until most people have a
public key and there is a means of discovering that via a DNS linkage.

Third one of the things we could do in an extended enrollment process
would be to get participants to agree to the following set of terms:

1) Thou shalt not SPAM.
2) Thou shalt permit your messages to be posted in the archives.
3) Thou shalt provide timely notice of any intellectual property
claims.
4) Thou shalt not take the name of the chair in vain unless she
deserves it.
5) etc.

Then we could sue the b*#*@#&ds if they spammed after that. People have
been looking for a test case for digital signatures for ages, so don't
worry about the cost.


A side benefit of this is that it would cause a lot of people to start
using secure email and thus start to create some critical mass for email
security.

What we need is for someone to take Majordomo or the like and merge in
some sort of filter to check S/MIME and PGP signatures. Then find a
group that wanted to serve as a guinea pig (S/MIME or PKIX perhaps?).

Alternatively we should perhaps form a group 'Deployment of secure
email' which could apply this rubric.


Phill


> -Original Message-
> From: Aaron Swartz [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 02, 2002 1:43 PM
> To: Hallam-Baker, Phillip
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: namedroppers, continued
>
>
> Hallam-Baker, Phillip wrote:
> > The only way to resolve this issue properly would be to
> require every
> > submission to an IETF mailing list to be cryptographically signed
> > [and] to require the subscribers to register their signing key
>
> And how do we prevent spammers from registering their signing
> key? Are
> you suggesting that we change the IETF's open enrollment policy?
>
> --
> Aaron Swartz [http://www.aaronsw.com]
>



smime.p7s
Description: application/pkcs7-signature

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 02 Dec 2002 08:28:57 PST, "Hallam-Baker, Phillip" said:

> The only way to resolve this issue properly would be to require every
> submission to an IETF mailing list to be cryptographically signed (PGP
> or S/MIME), to require the subscribers to register their signing key and
> to then filter the mail sent out on the list so that only signed mail
> gets through.

OK.. Almost plausible.  However note that currently, the PGP web-of-trust
covers only a small percentage of the subscribers to the IETF list, and
there's no *really* good PKI for S/MIME yet (hint - we don't seem to even
understand how to apply 'basicConstraints', so if you think we're going to
have working CRLs anytime soon, please share the name and address of your
pharmaceutical supplier.. ;)

> Thawte still provides free S/MIME certificates, however for the purposes
> of this proposal it would suffice to use a self signed certificate.

Unfortunately, although a self-signed cert works really nicely for some
purposes (for instance, it's quite sufficient to get an SSL tunnel started
so passive snooping doesn't work), it's inadequate here.

The problem is that there's no good way to tell my self-signed cert from
Dan Bernstein's self-signed cert from J. Slimy Spammer's self-signed cert.
I'd be interested in knowing what quality of a self-signed cert would
denote that the poster was possessed of the Non-Spammer Nature.

I propose to you that using a Thawte free S/MIME cert proves approximately
zero - a spammer can just get one for each run (and remember that no matter
how much a spammer tries to hid their identity, they *still* have to provide
a working way to reach them (via smtp or http or whatever) or they don't get
any feedback)

/Valdis



msg09571/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 02 Dec 2002 11:12:36 PST, "Hallam-Baker, Phillip" said:

> First, consider the effect of a minor authentication requirement on
> certificate issue, the ability to read email sent to the address
> specified in the certificate. Using that technique we could eliminate
> spams with bogus addresses which itself would be a major advance. The
> amount of spam that comes through with a valid email address is
> vanishingly small.

You don't need a cert for this - a simple "OK this magic cookie" confirmation
scheme (as supported by almost all mailing-list management software) is enough.

> Then we could sue the b*#*@#&ds if they spammed after that. People have
> been looking for a test case for digital signatures for ages, so don't
> worry about the cost.

People have been looking for somebody ELSE to be the test case for ages.
The EFF is in the business of raising money to fight legal battles. The
IETF isn't.  You might want to ask the IESG if they have the budget for
this - and remember that quite often, there *isnt* case law about some
interesting point because one party or the other decides it's easier and
cheaper to just settle rather than take it to court.
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09572/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 02 Dec 2002 14:33:16 PST, "Hallam-Baker, Phillip" said:

> If the spammer wants to perform custom operations for each 
> constituency they want to spam. 

No - you need a single custom cert/identity for each spamming run of several
million.  Unless you were *really* intending to cross-check the 3,000
spams they dropped on the IETF lists against the ones they sent to
yahoo.com's mailers, and the ones to AOL, and the ones to MSN, etc etc..

The worst part is that they would then present the *same* credentials to
the main IETF list and all the working groups.  This ends up leveraging one
of the strong points of digital signatures - if a signature is "well known"
because it's seen widely, it gets taken more seriously.  And there's no really
good way to tune this - I'm sure I post more to IETF lists than most spammers
do, so you can't even say "if they post more than X/day they're spammers"

> I don't think they do, they have to be able to spam millions 
> of people at a time or the response rate is simply too low.
> Reported response rates are in the thousandths of a percent,
> so spamming the entire IETF gets less than a tenth of a customer.

But they got a tenth of a customer for *ONE* piece of outbound mail.
Which is an extraordinary response rate.
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09577/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 02 Dec 2002 14:33:16 PST, "Hallam-Baker, Phillip" said:

> OCSP scales fine for revocation checking. We can use the same
> platform that currently serves 6 billion DNS queries a day.

The fact that OCSP scales fine for revocation checking doesn't mean that
you have a system that scales fine for the *TOTAL PROCESS*.  Remember - the
tough part isn't checking the list - the tough part is getting entries
*INTO* the list in a secure manner.  Go back and re-read the issue at
http://www.cert.org/advisories/CA-2001-04.html and ask yourself if a CRL
would have been handled any differently.  Remember - it was a *process*
failure, not a software failure.

The DNS may answer 6 billion DNS queries a day.  But I can name some DNS
registrars that would take *MONTHS* to correctly transfer a domain. (The
continuing refrain for *years* on NANOG: "Has *anybody* ever gotten PGP auth to
work with these bozos?")

Also, there's the added issue that the DNS cuts down on traffic by way of
caching.  Unfortunately, that's the LAST thing you want a CRL to be doing
(in particular, negative caching is an extreme no-no). You can tell the ISP's
DNS server to cache the SOA and NS entries for amazon.com.  You can't tell
the ISP's OCSP server to cache the fact that there aren't any CRLs for
the SSL cert that www.amazon.com uses.

/Valdis



msg09578/pgp0.pgp
Description: PGP signature

RE: namedroppers, continued

[Hallam-Baker, Phillip]

> OK.. Almost plausible.  However note that currently, the PGP
> web-of-trust
> covers only a small percentage of the subscribers to the IETF
> list, and
> there's no *really* good PKI for S/MIME yet (hint - we don't
> seem to even
> understand how to apply 'basicConstraints', so if you think
> we're going to
> have working CRLs anytime soon, please share the name and
> address of your
> pharmaceutical supplier.. ;)

OCSP scales fine for revocation checking. We can use the same
platform that currently serves 6 billion DNS queries a day.

I don't have a pharmaceutical supplier at hand, however I can
provide you with the name of a company that has a nice line
in herbal viagra if you are interested.


> I propose to you that using a Thawte free S/MIME cert proves
> approximately
> zero - a spammer can just get one for each run (and remember
> that no matter
> how much a spammer tries to hid their identity, they *still*
> have to provide
> a working way to reach them (via smtp or http or whatever) or
> they don't get
> any feedback)

If the spammer wants to perform custom operations for each
constituency they want to spam.

I don't think they do, they have to be able to spam millions
of people at a time or the response rate is simply too low.
Reported response rates are in the thousandths of a percent,
so spamming the entire IETF gets less than a tenth of a customer.


Phill



smime.p7s
Description: application/pkcs7-signature

RE: namedroppers, continued

[Hallam-Baker, Phillip]

> The fact that OCSP scales fine for revocation checking
> doesn't mean that
> you have a system that scales fine for the *TOTAL PROCESS*.

Stop blustering, you clearly did not know the difference between
a CRL and OCSP and certainly have no real world experience of
operating PKI on which to base your broad assertions.


> Also, there's the added issue that the DNS cuts down on
> traffic by way of
> caching.

The ATLAS cluster that runs the core DNS (.com, .net, .org) is
supporting six billion queries a day. The caching in the secondary
servers goes some way to reduce load but not as much as many think.


> Unfortunately, that's the LAST thing you want a CRL
> to be doing
> (in particular, negative caching is an extreme no-no).

No it is not. If you knew what a CRL is you would know that
they are issued on a periodic basis and that caching is
therefore exactly what Windows or any other sensible O/S
does with a CRL.

You appear to be confusing CRLs with OCSP. Try reading the OCSP
spec, I wrote the original section on caching responses.


Phill



smime.p7s
Description: application/pkcs7-signature

Re: namedroppers, continued

[Valdis . Kletnieks]

On Tue, 03 Dec 2002 08:21:22 PST, you said:

> Stop blustering, you clearly did not know the difference between
> a CRL and OCSP and certainly have no real world experience of
> operating PKI on which to base your broad assertions.

I said "total process".  The process failure described in the CERT
advisory didn't care if it was a CRL, OCSP, a X.509 certificate, or
a piece of paper scotch-taped to one end of a tin-cans-and-string link
that says "Don't use unless your name is Fred".

I admit I don't do any PKI per se.  What I *do* have is over 2 decades
of making a good living at cleaning up the mess when people misconfigure
things.  So I'm reading RFC2560 and see this in section 5:

A denial of service vulnerability is evident with respect to a flood
   of queries. The production of a cryptographic signature significantly
   affects response generation cycle time, thereby exacerbating the
   situation. Unsigned error responses open up the protocol to another
   denial of service attack, where the attacker sends false error
   responses.

and I combine that with the research out of CAIDA I cited earlier that showed
98% of DNS queries to a root nameserver being broken, and my experience
tells me that This Is A Train Wreck Waiting To Happen.

The only mitigating factor here is that section 2.5 allows the precomputing
of a response and associated signature.

> You appear to be confusing CRLs with OCSP. Try reading the OCSP
> spec, I wrote the original section on caching responses.

Hmm... I've checked RFC2560, and didn't find anything significant about caching
other than "beware HTTP proxies with broken caching" (or did you mean the
precomputation of responses in section 2.5)?  Also, is there a spec for a DNS
RR to supplement the serviceLocator extension of 2560 section 4.4.6?  That
would also help to minimize and distribute the load (as the OCSP RR could be
lumped in with the other DNS RR's for DNSSEC processing - handing back the OCSP
info in an "additional info" field then saves you another resource hit when an
OCSP query gets made.
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09608/pgp0.pgp
Description: PGP signature

RE: namedroppers, continued

[Hallam-Baker, Phillip]

One of the main reasons why anti-spam measures are failing is that the
spam-artists are fraudulently hijacking people's email addresses so as
to bypass anti-spam filters.

My reading of the open enrollement policy is that anyone can contribute.

I don't think that a secondary manual filter by which the first post to
the list by an individual was only forwarded after moderation would
breach that principle - but it would be one heck of a lot less work for
the chairs than having to moderate every message.

I certainly do not consider it an imposition on those who want to
pontificate on Internet protocols to require them to actualy eat the
company dog food and sign their messages with either PGP or S/MIME.

I am not pushing a corporate interest here, a self signed certificate
would be fine. I think that one of the problems for the PKI world is
that the perfect has been the enemy of the good. OK you can argue that
it would not exactly hurt VRSN if more people started to use security
routinely, I don't think that would hurt the IETF either.


Phill


> -Original Message-
> From: Aaron Swartz [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 02, 2002 10:43 AM
> To: Hallam-Baker, Phillip
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: namedroppers, continued
>
>
> Hallam-Baker, Phillip wrote:
> > The only way to resolve this issue properly would be to
> require every
> > submission to an IETF mailing list to be cryptographically signed
> > [and] to require the subscribers to register their signing key
>
> And how do we prevent spammers from registering their signing key? Are
> you suggesting that we change the IETF's open enrollment policy?
>
> --
> Aaron Swartz [http://www.aaronsw.com]
>



smime.p7s
Description: application/pkcs7-signature

Re: namedroppers, continued

[Randy Bush]

> From: "D. J. Bernstein" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: namedroppers, continued
> ...
> Okay, Bush: Put [EMAIL PROTECTED] on the list of addresses from which
> submissions are automatically accepted.

sorry bernstein.  as your message also was addressed to lists to
which i subscribe, the copy to namedroppers-owner was deleted
locally due to dupe message-id: detection.  erik and harald pointed
it out, and rob just forwarded a copy to me.  so i have done the
addition.

thanks, as approving all your postings was becoming a pain in the
butt.

randy

RE: namedroppers, continued

[Dean Anderson]

How much spam is going to namedroppers?

I haven't seen any. So, don't you think this has gone a little of the deep
end?

--Dean

On Fri, 6 Dec 2002, Hallam-Baker, Phillip wrote:

> One of the main reasons why anti-spam measures are failing is that the
> spam-artists are fraudulently hijacking people's email addresses so as
> to bypass anti-spam filters.

RE: namedroppers, continued

[Randy Presuhn]

Hi -

> Message-Id: <[EMAIL PROTECTED]>
> Date: Fri, 06 Dec 2002 13:41:52 -0800
> To: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
> From: Fred Baker <[EMAIL PROTECTED]>
> Subject: RE: namedroppers, continued
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> In-Reply-To: <[EMAIL PROTECTED]
>  .com>
...
> I would be in favor of that, personally, as long as we can ensure that the 
> appropriate signature facility (be it RSA, PGP, or whatever) is freely 
> available to all who need to use it. The issue here is not us corporate 
> types who have a business reason to buy the software, it is the students 
> who often lack the funds. The big issue would be the procedures for posting 
> one's key to the appropriate place - what is to stop a spammer from posting 
> a key and sending the spam anyway? I'm not proposing a mechanism, but 
> someone who is good at such things might well find it of value.
...

At least for now, the stuff with forged addresses aimed at
the IETF lists I handle can be stopped simply by blocking
multipart/alternative, multipart/mixed, and text/html.
Is this generally true, or am I working with a particularly
old-fashioned subscriber base?

On non-IETF lists I manage, I've had to permit these types, and
resort to finer-grained (read costlier) spam-blocking measures.

 --
 Randy Presuhn  BMC Software, Inc.  SJC-1.3141
 --
 My opinions and BMC's are independent variables.
 --

RE: namedroppers, continued

[Fred Baker]

At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote:

The only way to resolve this issue properly would be to require every
submission to an IETF mailing list to be cryptographically signed (PGP
or S/MIME), to require the subscribers to register their signing key and
to then filter the mail sent out on the list so that only signed mail
gets through.


I would be in favor of that, personally, as long as we can ensure that the 
appropriate signature facility (be it RSA, PGP, or whatever) is freely 
available to all who need to use it. The issue here is not us corporate 
types who have a business reason to buy the software, it is the students 
who often lack the funds. The big issue would be the procedures for posting 
one's key to the appropriate place - what is to stop a spammer from posting 
a key and sending the spam anyway? I'm not proposing a mechanism, but 
someone who is good at such things might well find it of value.

It doesn't address the "off topic" issue. As you say, that could be left to 
a working group chair equiped with formal procedures developed by consensus 
within the work group or adopted by the working group from a more general 
place (ie, the IETF could suggest a procedure, and the WG could adopt it if 
it didn't feel another procedure would be better).

I have had a private exchange, over the past few days, with someone who 
wished that the IETF would please document some good spam-elimination 
procedure, so that it could be used world-wide to completely eliminate 
spam. I think that boils down to "provide a global PKI" in this solution, 
and presumes that spammers are incapable of using one. That might be a 
great research topic. Too bad nobody has ever thought of it before; we 
could really use the outcome of that research. (OK, so it's a lame attempt 
at humor...)

I think it was Steve Bellovin that suggested a procedure for reducing the 
utility of spoofing source addresses in emails; if not, it was me and I 
happened to suggest something his favorite algorithm fit into, by having a 
host in each mail domain (mailid.example.com) be able to assert that its 
domain had or had not sent an email within a given recent  time period 
whose MD5 hash, when divided by  resulted in 
. I could write that up in an internet draft if folks 
think it makes sense. That would be a more global procedure that didn't 
require a PKI and only addressed spoofed addresses. 

Re: namedroppers, continued

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Fred Bake
r writes:
>At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote:
>>The only way to resolve this issue properly would be to require every
>>submission to an IETF mailing list to be cryptographically signed (PGP
>>or S/MIME), to require the subscribers to register their signing key and
>>to then filter the mail sent out on the list so that only signed mail
>>gets through.
>
>I would be in favor of that, personally, as long as we can ensure that the 
>appropriate signature facility (be it RSA, PGP, or whatever) is freely 
>available to all who need to use it. The issue here is not us corporate 
>types who have a business reason to buy the software, it is the students 
>who often lack the funds. The big issue would be the procedures for posting 
>one's key to the appropriate place - what is to stop a spammer from posting 
>a key and sending the spam anyway? I'm not proposing a mechanism, but 
>someone who is good at such things might well find it of value.
>
Well, it's also the availability of the right signature facility in the 
myriad email clients people use.
>
>I think it was Steve Bellovin that suggested a procedure for reducing the 
>utility of spoofing source addresses in emails; if not, it was me and I 
>happened to suggest something his favorite algorithm fit into, by having a 
>host in each mail domain (mailid.example.com) be able to assert that its 
>domain had or had not sent an email within a given recent  time period 
>whose MD5 hash, when divided by  resulted in 
>. I could write that up in an internet draft if folks 
>think it makes sense. That would be a more global procedure that didn't 
>require a PKI and only addressed spoofed addresses. 
>
Wasn't me...

--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)

RE: namedroppers, continued

[Marc Schneiders]

On Fri, 6 Dec 2002, at 13:41 [=GMT-0800], Fred Baker wrote:

> I think it was Steve Bellovin that suggested a procedure for reducing the
> utility of spoofing source addresses in emails; if not, it was me and I
> happened to suggest something his favorite algorithm fit into, by having a
> host in each mail domain (mailid.example.com) be able to assert that its
> domain had or had not sent an email within a given recent  time period
> whose MD5 hash, when divided by  resulted in
> . I could write that up in an internet draft if folks
> think it makes sense. That would be a more global procedure that didn't
> require a PKI and only addressed spoofed addresses.

Spammers would be the first to set up your mailid host. They will have
had years of experience to find holes in the system before you've
convinced everyone to adopt or accept the mailid.

It might be easier to write a new protocol to succeed email, instant
messaging, mobile phones (something useful in itself) with built-in
abuse control from the start.

RE: namedroppers, continued

[Hallam-Baker, Phillip]

> How much spam is going to namedroppers?

Well none since Randy Bush and a bunch of others turned
on the moderator bit.

The problem here is that having Randy Bush moderate is
not a scalable solution to the problems of Spam in general.


Phill





smime.p7s
Description: application/pkcs7-signature

RE: namedroppers, continued

[Ayyasamy, Senthilkumar (UMKC-Student)]

> Too bad nobody has ever thought of it 
> before; we  could really use the outcome 
> of that research
while researchers has not thought about global
PKI, their are research which focus on spam 
elimination.

this is the work all about (yesterday's seminar in a MIT group)

" If I don't know you, and you want your e-mail to appear in my
  inbox, then you must attach to your message an easily verified
 "proof of computational effort", just for me and just for this
 message.

If the proof of effort requires, say, 10 seconds to compute, then the
economics of sending spam are radically altered, as a single machine
can send only 8,000 messages per day.

The recent proliferation of spam has lead to a renewed interest in
these ideas.  This  work is about both the choice of
functions that can be used to yield easily verifiable proofs of
computational effort, and architectures for implementing the proof of
effort approach.  Filtering and/or forcing senders to pay in other
currencies, such as human attention and money, will be covered as time
permits"


for more details http://research.microsoft.com/research/sv/PennyBlack

RE: namedroppers, continued

[Vernon Schryver]

> From: Fred Baker <[EMAIL PROTECTED]>

>   ... I think that boils down to "provide a global PKI" in this solution, 
> and presumes that spammers are incapable of using one. That might be a 
> great research topic. Too bad nobody has ever thought of it before; we 
> could really use the outcome of that research. (OK, so it's a lame attempt 
> at humor...)

It's been years since it was possible to be amused by the number of
people who assume that spammers are more ignorant and less competent
than they are, and so propose spam "solutions" predicated on spammers
being unable to register as many names, keys, identities, or whatever
as needed or as many as everybody else can.

> ...
> host in each mail domain (mailid.example.com) be able to assert that its 
> domain had or had not sent an email within a given recent  time period 
> whose MD5 hash, when divided by  resulted in 
> . I could write that up in an internet draft if folks 
> think it makes sense. That would be a more global procedure that didn't 
> require a PKI and only addressed spoofed addresses. 

That's not a powerful solution, because it assumes the existence of
a central mail authenticator for every domain that might send mail.
As long as most SMTP clients don't have such authenticators, the
spammers would simply avoid the few that do, just as they already
avoid providers that break the financial kneecaps of spammers.

As far as I can tell, the familiar claim that most spam carrying
surprising header or envelope From adddresses is forged is mostly wrong.
The claim seems to be based in large part on the knowingly misleading
descriptions of the situation by free mail providers.  The free providers
claim that almost all spam implicating them is "forged." If you read
the fine print in their announcements of terminated accounts, responses
to spam reports, and related messages, you'll discover that free provider
spam is "forged" in the same sense your picture postcards would be if
you were evicted from your home while travelling.

That suggests that such authenticator servers would help reduce spam
using free provider drop-boxes.  However, a better solution that does
not involve the rest of the network subsidizing the advertising agencies
that are the free providers is to reject all mail apparently from free
providers.  Doing extra processing that is made necessary only because
the free providers cannot be bothered enforce sufficiently painful
terms and conditions on their users is a subsidy.  The free providers
could stop spammers from using their services if they would launch
lawyers, require bonds (e.g. creditcard numbers), or any of many
other things, but anything would cost them money.


Vernon Schryver[EMAIL PROTECTED]

RE: namedroppers, continued

[Vernon Schryver]

> From: Marc Schneiders <[EMAIL PROTECTED]>

> ...
> It might be easier to write a new protocol to succeed email, instant
> messaging, mobile phones (something useful in itself) with built-in
> abuse control from the start.

That's another stupid crackpot "spam solution" that just won't go away.

You cannot have "abuse control" built into a protocol that allows
strangers to send each other mail.  Any mail protocol that lets you
receive mail from a stranger must also let the stranger send the same
message to you and to 30,000,000 of your closest friends.  On the
other hand, if you want to only accept mail from people who are not
strangers, you can use any of the many official and ad hoc SMTP
extensions to ensure you only receive mail from them.

If your computer system, mail protocol, or whatever knows that a
stranger is not a spammer, then the stranger is not really a stranger.


Vernon Schryver[EMAIL PROTECTED]

Re: namedroppers, continued

[Valdis . Kletnieks]

On Fri, 06 Dec 2002 14:34:14 PST, "Hallam-Baker, Phillip" said:

> The problem here is that having Randy Bush moderate is
> not a scalable solution to the problems of Spam in general.

We could clone him, but that's probably not scalable either



msg09660/pgp0.pgp
Description: PGP signature

RE: namedroppers, continued

[william]

I'v been saying about need for more radical change in mail protocol for
years now on mailing lists. I'd rather work on smtp itself, but some 
people who were involved in original protocol do not want any serious 
changes to what they'v done, though its clear that abuse and other holes 
with current system is creating too many problems.

In any case, by next ietf meeting in san francisco, I'll bring complete
proposal for new protocol and might even try some practical tests. I do still 
believe that smtp can be saved, but not without more complex authentication
system during delivery of email and that can't be done with current 
protocol design or current available extension process. 

Also were there any discussions or more complete discription of this 
algorithm for checking if host had sent an email and if so is this 
available on website or archive to read more about? If answer is yes, can 
somebody send me url or approximate date of discussions so I could lookup 
in archives. 

And am I correct here in understanding what was proposed is that smtp 
conversation id be such that receiving mail server could verify with 
sender (callback?) that it deed indeed initiate the email. If so I do not 
quite understand how MD5 helps there, plus I see quite a few problems with 
creating some special mx-like record in dns just for verification. If 
this is indeed what was proposed its better to go with paul vixie's 
proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or
http://www.ietf.org/internet-drafts/draft-church-dns-mail-sender-02.txt

On Fri, 6 Dec 2002, Marc Schneiders wrote:

> On Fri, 6 Dec 2002, at 13:41 [=GMT-0800], Fred Baker wrote:
> 
> > I think it was Steve Bellovin that suggested a procedure for reducing the
> > utility of spoofing source addresses in emails; if not, it was me and I
> > happened to suggest something his favorite algorithm fit into, by having a
> > host in each mail domain (mailid.example.com) be able to assert that its
> > domain had or had not sent an email within a given recent  time period
> > whose MD5 hash, when divided by  resulted in
> > . I could write that up in an internet draft if folks
> > think it makes sense. That would be a more global procedure that didn't
> > require a PKI and only addressed spoofed addresses.
> 
> Spammers would be the first to set up your mailid host. They will have
> had years of experience to find holes in the system before you've
> convinced everyone to adopt or accept the mailid.
> 
> It might be easier to write a new protocol to succeed email, instant
> messaging, mobile phones (something useful in itself) with built-in
> abuse control from the start.

RE: namedroppers, continued

[william]

This is note quite right. While its impossible to built open system that 
would prevent all abuse, you can first of all built system that would 
provide good verification of who sender is and you can do a lot to make it 
difficult to send thousands of same emails or at least make it easy to 
identify who is doing it and give tools for sysadmins to monitor and 
prevent such activity.

On Fri, 6 Dec 2002, Vernon Schryver wrote:

> > From: Marc Schneiders <[EMAIL PROTECTED]>
> 
> > ...
> > It might be easier to write a new protocol to succeed email, instant
> > messaging, mobile phones (something useful in itself) with built-in
> > abuse control from the start.
> 
> That's another stupid crackpot "spam solution" that just won't go away.
> 
> You cannot have "abuse control" built into a protocol that allows
> strangers to send each other mail.  Any mail protocol that lets you
> receive mail from a stranger must also let the stranger send the same
> message to you and to 30,000,000 of your closest friends.  On the
> other hand, if you want to only accept mail from people who are not
> strangers, you can use any of the many official and ad hoc SMTP
> extensions to ensure you only receive mail from them.
> 
> If your computer system, mail protocol, or whatever knows that a
> stranger is not a spammer, then the stranger is not really a stranger.
> 
> 
> Vernon Schryver[EMAIL PROTECTED]

RE: namedroppers, continued

[Joe Baptista]

On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote:

> proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or

I've had a look at vixies proposal and it's a good one.  I certainly would
welcome something like the mailfrom dns record.

regards
joe baptista

Re: namedroppers, continued

[Paul Vixie]

it's difficult to imagine a mailing list for which this thread is on-topic.

> I think it was Steve Bellovin that suggested a procedure for reducing the
> utility of spoofing source addresses in emails; if not, it was me and I
> happened to suggest something his favorite algorithm fit into, by having a
> host in each mail domain (mailid.example.com) be able to assert that its
> domain had or had not sent an email within a given recent  time period
> whose MD5 hash, when divided by  resulted in
> . I could write that up in an internet draft if folks
> think it makes sense. That would be a more global procedure that didn't
> require a PKI and only addressed spoofed addresses. --

here was my attempt at this, which i didn't really know where to go next with:







   IndependentPaul Vixie (Ed.)
   Request for Comments:  Category: Experimental
   June 6, 2002

Repudiating MAIL FROM

   Status of this Memo

  This memo describes an experimental procedure for handling received
  e-mail.  It does not specify an Internet standard of any kind.
  Distribution of this memo is unlimited.

   Copyright Notice

  Copyright (C) The Internet Society (2002).  All Rights Reserved.

   Abstract

  At the time of this writing, more than half of all e-mail received by
  the author has a forged return address, due to the total absence of
  address authentication in SMTP (see [RFC2821]).  We present a simple
  and backward compatible method whereby cooperating e-mail senders and
  receivers can detect forged source/return addresses in e-mail.

   1 - Introduction and Overview

   1.1. Internet e-mail return addresses are nonrepudiable by design of the
   relevant transport protocols (see [RFC2821]).  Simply put, there is no
   cause for ANY confidence in the proposition "this e-mail came from where
   it says it came from."

   1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail
   routinely use this designed-in lack of source/return authenticity to
   hide their point of origin, which usually involves forging a valid
   return address belonging to some highly visible and popular ISP (for
   example, HOTMAIL.COM).

   1.3. Recipients who wish to reject unwanted bulk e-mail containing
   forged source/return addresses are prevented from doing so since the
   addresses, as presented, are nonrepudiable by design.  Simply put, there
   would be too many false positives, and too much valid e-mail rejected,
   if one were to program an e-mail relay to "reject all e-mail claiming to
   be from HOTMAIL.COM" since, statistically, most e-mail claiming to be
   from HOTMAIL.COM is actually from somewhere else.  HOTMAIL.COM, in this
   example, is a victim of forgery.



   Vixie Experimental  [Page 1]

   RFC   Repudiating MAIL FROM May 26, 2002


   1.4. What's needed is a way to guaranty that each received e-mail
   message did in fact come from some mail server or relay which can
   rightfully originate or relay messages from the purported source/return
   address.

   1.5. Approaches of the form "use PGP" and "use SSL" are not scalable in
   the short term since they depend on end-to-end action and there are just
   too many endpoints.  An effective solution has to be applicable to mail
   relay, not just final delivery.

   1.6. Valid ("wanted") e-mail must not be rejected by side effect or
   partial adoption of this proposal.  Source/return authenticity must be a
   confidence effector, as in "we can be sure that this did not come from
   where it claims" and simple uncertainty must remain in effect otherwise.

   2 - Behaviour

   2.1. Domain owners who wish their mail source/return information to be
   repudiable will enter stylized MX RR's into their DNS data, whose owner
   name is "MAIL-FROM", whose priority is zero, and whose servername
   registers an outbound (border) relay for the domain.  For example, to
   tell the rest of the Internet who they should believe when they receive
   mail claiming to be from [EMAIL PROTECTED], the following DNS MX RR's should
   be entered:

  $ORIGIN isc.org.
  MAIL-FROM MX 0 rc
MX 0 rc1

   In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as
   appropriate places to originate mail from @ISC.ORG.  Note that this
   differs from the normal inbound MX RRset for this example domain:

  $ORIGIN isc.org.
  @ MX 0 rc
MX 0 isrv4

   So, the inbound mail server set partially overlaps with, but differs
   from, the example outbound mail server set.  This is quite common in the
   Internet, and is the reason why the normal inbound mail server set
   described by a domain's apex MX RRset cannot be used for repudiation
   purposes.






   Vixie Experimental  [Page 2]

   RFC  

Re: namedroppers, continued

[Keith Moore]

> > proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or
> 
> I've had a look at vixies proposal and it's a good one.  I certainly would
> welcome something like the mailfrom dns record.

actually I'd call it a nonstarter in its current form.  given that

- mail from is used for nondelivery reports and other notifications;
  users need to make sure it gets set to an address that they'll read

- nomadic users have valid reasons to post from random places on the net 
  (including multiple ISPs) and keep the same mail from address.

- many ISPs won't let you forward or submit mail through someone else's 
  SMTP server, even if you have permission to do so.  so you can't 
  forward your mail through your "home" ISP's mail server to allow the
  "mail from" check to work.

trying to reuse any of the existing return addresses in email as a 
spam identifier just won't fly.  a separate identifier might work.
(actually Sender is the closest thing to what is needed here, 
unfortunately it's routinely munged by mailing lists)

Keith

Re: namedroppers, continued

[ned . freed]

> > > proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or
> >
> > I've had a look at vixies proposal and it's a good one.  I certainly would
> > welcome something like the mailfrom dns record.

> actually I'd call it a nonstarter in its current form.

I would have to agree.

>  given that

> - mail from is used for nondelivery reports and other notifications;
>   users need to make sure it gets set to an address that they'll read

> - nomadic users have valid reasons to post from random places on the net
>   (including multiple ISPs) and keep the same mail from address.

> - many ISPs won't let you forward or submit mail through someone else's
>   SMTP server, even if you have permission to do so.  so you can't
>   forward your mail through your "home" ISP's mail server to allow the
>   "mail from" check to work.

In addition to these valid concerns I'd add that various sorts of
autoforwarding exist that don't change the MAIL FROM. These would also tend to
break if such a scheme were implemented.

I'm also concerned about the management aspects of having lists of authorized
"multistage relays" and all that implies.

> trying to reuse any of the existing return addresses in email as a
> spam identifier just won't fly.  a separate identifier might work.

But there's also a problem with NOT using the MAIL FROM -- one of the things
that's being counted on here is that mailing list expanders will (optionally)
check the MAIL FROM against this new DNS record, but then change it
unconditionally to an address associated with the list expander rather than
with the originator.

> (actually Sender is the closest thing to what is needed here,
> unfortunately it's routinely munged by mailing lists)

To the extent that sender is munged by mailing lists to refer to the 
list expander it would actually be a feature here, not a bug. But just
as you cannot count on it being left alone, you also cannot count on it
being changed.

Perhaps the real problem here isn't the use of MAIL FROM but rather the
assumption that binding ipsource to the MAIL FROM domain is a useful 
validation check. A specific ipsource is just not a property a legitimate user
of a given domain can be expected to have. Although I am reluctant to suggest
anything involving public key crypto, another approach would be to put a
public key in the MAIL-FROM DNS record and add a new header field containing a
signature covering the message's  MAIL FROM and the current date.

Ned

Re: namedroppers, continued

[Paul Vixie]

[EMAIL PROTECTED] (Keith Moore) writes:

> > I've had a look at vixies proposal and it's a good one.  I certainly would
> > welcome something like the mailfrom dns record.
> 
> actually I'd call it a nonstarter in its current form.  given that
> 
> - mail from is used for nondelivery reports and other notifications;
>   users need to make sure it gets set to an address that they'll read

that problem doesn't change.  all the mailfrom draft says is that you
need to be coming from a designated server to be able to set MAIL FROM.

> - nomadic users have valid reasons to post from random places on the net 
>   (including multiple ISPs) and keep the same mail from address.

then, i'm sorry that i'm such a poor writer.  i tried to cover this case:

   3.3. Roaming hosts such as laptop computers will probably not be able to
   be listed in the MAIL-FROM MX RR for their return address domain name,
   and may be forced to use an intermediary for outbound e-mail.  STARTTLS
   or an SSL/SSH tunnel back "home" may become a necessary first hop for
   mobile e-mail.

> - many ISPs won't let you forward or submit mail through someone else's 
>   SMTP server, even if you have permission to do so.  so you can't 
>   forward your mail through your "home" ISP's mail server to allow the
>   "mail from" check to work.

in that case you'd be wise to not insert a MAIL-FROM MX for your domain.
-- 
Paul Vixie

Re: namedroppers, continued

[Paul Vixie]

[EMAIL PROTECTED] writes:

> > actually I'd call it a nonstarter in its current form.
> 
> I would have to agree.
> ...
> In addition to these valid concerns I'd add that various sorts of
> autoforwarding exist that don't change the MAIL FROM. These would also
> tend to break if such a scheme were implemented.

i apologize for being such a poor writer.  what the "draft" actually says is:

   3.2. Transport-level e-mail forwarding must be more explicit under this
   specification.  For example if [EMAIL PROTECTED]'s account has a
   ".forward" file pointing at [EMAIL PROTECTED], then e-mail sent to the
   former will be received by the latter, but with no change in the payload
   of SMTP MAIL FROM.  Thus, ISC's inbound relays would have to be
   configured to implicitly add NETBSD's outbound mail relays as
   "multistage inbound relays."  This could scale poorly and may add
   pressure toward transport remailing (with a new envelope) rather than
   transport forwarding (reusing the old envelope.)

> I'm also concerned about the management aspects of having lists of
> authorized "multistage relays" and all that implies.

then you probably would not want to insert a MAIL-FROM MX in your domain.

> Perhaps the real problem here isn't the use of MAIL FROM but rather the
> assumption that binding ipsource to the MAIL FROM domain is a useful
> validation check. A specific ipsource is just not a property a legitimate
> user of a given domain can be expected to have. Although I am reluctant
> to suggest anything involving public key crypto, another approach would
> be to put a public key in the MAIL-FROM DNS record and add a new header
> field containing a signature covering the message's MAIL FROM and the
> current date.

i love that plan.  we all know that ip source addresses make poor passwords.
however, it has to be an envelope thing, not a header thing, since it's hop
by hop.  perhaps "MAIL FROM:<$address> $sig" as an ESMTP thing?
-- 
Paul Vixie

Re: namedroppers, continued

[Keith Moore]

> > - nomadic users have valid reasons to post from random places on the net
> >   (including multiple ISPs) and keep the same mail from address.
> 
> then, i'm sorry that i'm such a poor writer.  i tried to cover this case:
> 
>3.3. Roaming hosts such as laptop computers will probably not be able to
>be listed in the MAIL-FROM MX RR for their return address domain name,
>and may be forced to use an intermediary for outbound e-mail.  STARTTLS
>or an SSL/SSH tunnel back "home" may become a necessary first hop for
>mobile e-mail.
> 
> > - many ISPs won't let you forward or submit mail through someone else's
> >   SMTP server, even if you have permission to do so.  so you can't
> >   forward your mail through your "home" ISP's mail server to allow the
> >   "mail from" check to work.
> 
> in that case you'd be wise to not insert a MAIL-FROM MX for your domain.

what this seems to require is to have different sets of domains for 
use in MAIL FROM addresses - those for which source verification can
be expected and those for which it cannot.  there are some current
domains which are naturally and exclusively in the former category - 
say hotmail.com; but most domains are probably not exclusively in 
either category.  so it would require establishment of new domains and 
reconfiguration of systems to use those domains to be effective - along 
with the educational effort that this entails.  and it would still
leave a significant portion of mail without a way to identify its source.

Keith

Re: namedroppers, continued

[Paul Vixie]

> > > - many ISPs won't let you forward or submit mail through someone else's
> > >   SMTP server, even if you have permission to do so.  so you can't
> > >   forward your mail through your "home" ISP's mail server to allow the
> > >   "mail from" check to work.
> > 
> > in that case you'd be wise to not insert a MAIL-FROM MX for your domain.
> 
> what this seems to require is to have different sets of domains for 
> use in MAIL FROM addresses - those for which source verification can
> be expected and those for which it cannot.

yes.

> there are some current domains which are naturally and exclusively in
> the former category - say hotmail.com; but most domains are probably
> not exclusively in either category.

yes.

> so it would require establishment of new domains and reconfiguration
> of systems to use those domains to be effective - along with the
> educational effort that this entails.

i think most of the reconfiguration effort would be around existing domains.

> and it would still leave a significant portion of mail without a way
> to identify its source.

so far, working toward a single solution that covers all cases and is easy
("low cost") for spam victims and infrastructure owners to take part in, has
not worked.  what you see in the mailfrom "draft" is just a "point solution."

i am reminded by this thread that the most powerful force on the internet
continues to be a single voice saying that something cannot be done.

Re: namedroppers, continued

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Dean An
derson writes:
>This seems clever, however, it will also take significant computational
>effort to verify the computational effort was actually done. Even if a
>class of functions are found that are "easier" to verify than to compute,
>they will no doubt still take up a significant fraction of time.

In fact, that's the easy part.  You could demand that the sender 
compute 1,000,000 HMACs of the text, the envelope, the time of day, and 
a counter.  The verifier could check 100 randomly-chosen ones -- if any 
fail, there's a forgery.  (Well, you probably wouldn't want those 
values, since 1,000,000 HMACs would be a lot of data to transmit.  But 
you get the general idea.)

--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)

Re: namedroppers, continued

[Keith Moore]

> i am reminded by this thread that the most powerful force on the internet
> continues to be a single voice saying that something cannot be done.

well, I've certainly seen it happen.  (though I think the most
powerful force on the internet is large numbers of voices insisting
that something be done whether or not it makes sense - not that this
is what is happening here.)

I don't want to discourage you from developing the mail from dns idea 
further, but neither do I think it will help the spam problem much.
my biggest concern is that it will be used as an excuse to constrain
where people can send mail from, and at a time when ill-conceived spam 
countermeasures are already a serious operational problem and probably
the most significant cause of failure to deliver legitimate mail.

Keith

Re: namedroppers, continued

[Vernon Schryver]

> From: Paul Vixie <[EMAIL PROTECTED]>

> ...
> i am reminded by this thread that the most powerful force on the internet
> continues to be a single voice saying that something cannot be done.

No, what you are seeing is something that has always been true on the
Internet.  Anything that depends on the actions of third parties who
will not gain by it takes a long time.  To hope for something to take
off, it must be worthwhile from the start.  This proposal costs many
people and organizations now (new software) and forever (MX, .forward,
mailing list, and mobile hassles) and benefits no one for at least
the first year or so.

What's in it for the owners of the domains most commonly (not really)
"forged" into Mail_From values, the free mail providers?  The main
effect for them is that they both be forced to process more out-going
mail and see their user base reduced.  Many users who now use a free
mail provider Mail_From value would either have arrange to send through
the free mail provider or switch to a return address based on IP
bandwidth provider.

What is the difference in the short and medium term between your
proposal and teaching your MTA to check that one of the A records for
the reverse DNS name of the SMTP clients contains the IP address of
the client?  A major difference is that you can install this check
today without waiting for anyone else to do anything.  We all (well,
some of us) can name a raft of reasons why such checking is a bad idea
in general, but you could easily do it only for the domains you think
might eventually provide the new DNS RR and that have a significant
(so called) "forgery" problem, the free mail providers.

For that matter, why not simply blacklist any and all mail with From
values pointing at free providers.  With a white list of your friends
who use free providers, that is an extremely effective spam filter.


Vernon Schryver[EMAIL PROTECTED]

Re: namedroppers, continued

[ned . freed]

> In message <[EMAIL PROTECTED]>, Dean An
> derson writes:
> >This seems clever, however, it will also take significant computational
> >effort to verify the computational effort was actually done. Even if a
> >class of functions are found that are "easier" to verify than to compute,
> >they will no doubt still take up a significant fraction of time.

> In fact, that's the easy part.  You could demand that the sender
> compute 1,000,000 HMACs of the text, the envelope, the time of day, and
> a counter.  The verifier could check 100 randomly-chosen ones -- if any
> fail, there's a forgery.  (Well, you probably wouldn't want those
> values, since 1,000,000 HMACs would be a lot of data to transmit.  But
> you get the general idea.)

The exmaple given in the Microsoft paper was square roots in a finite field.
These are computationally difficult to compute (lots of multiplication mod p)
but easy to check (single multiplication mod p).

I'm sure there are other examples -- finding candidate functions of this
sort is *much* easier than finding, say, a public key algorithm.

Ned

Re: namedroppers, continued

[Valdis . Kletnieks]

On Fri, 06 Dec 2002 16:48:46 CST, "Ayyasamy, Senthilkumar (UMKC-Student)" said:

> If the proof of effort requires, say, 10 seconds to compute, then the
> economics of sending spam are radically altered, as a single machine
> can send only 8,000 messages per day.

Those of us who run mail servers that are currently resource-constrained
while doing 8K msgs/hour worry anytime we hear that sort of idea.
On the other hand, I wouldn't mind taking a 10-second hit every time *I*
send a message.

Possibly what is needed is a hybrid approach:

1) If you're a "big" mail server, you can probably prevail on your DNS
admins to list you in whatever DNS-based verification system (in our entire
2 /16s of address space, there are less than 10 boxes that would have a major
resource issue, but would benefit froma DNS-based solution.

2) If you're not listed in the DNS, you have to do a compute-intensive proof.

What would people think of that idea?
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09679/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Vernon Schryver]

> From: [EMAIL PROTECTED]

> ...
> Possibly what is needed is a hybrid approach:
>
> 1) If you're a "big" mail server, you can probably prevail on your DNS
> admins to list you in whatever DNS-based verification system (in our entire
> 2 /16s of address space, there are less than 10 boxes that would have a major
> resource issue, but would benefit froma DNS-based solution.
>
> 2) If you're not listed in the DNS, you have to do a compute-intensive proof.
>
> What would people think of that idea?

Is the goal to block spam?  If so, what do you do about third case of
senders that don't participate with either #1 or #2?  For the first
years, most of the 10,000,000s of legitimate SMTP clients (sending
mail servers) will do neither #1 or #2, because their operators will
not have heard about it.  You will have to configure your receiving
mail servers to require #1 or #2 only in exceptional cases.  When the
operators of the other 10,000,000s of servers finally hear about the
new regime, they'll generally to not get around to installing either
sort of proof of virtue, because their mail is working without it and
they have real problems to worry about, from installing the latest
security patches to thinking about considering IPv6.  Even people who
turn on requirements for #1 or #2 for incoming mail to reduce spam
will often delay supporting it on outgoing mail, because no one
competent likes to break things that are working.

In other words, such tactics might work for the exceptional cases of
biggest, otherwise hopeless sources of (not really) forged spam such
as Hotmail as a sort of half-blacklisting, but I can't see it working
in general.


Moore's law causes a bunch of problems for the computing idea.  There
is at at least a factor of 100 in CPU speeds of current hosts.  How
do you ensure that the fastest commodity CPU that a spammer might use
is forced to slow down more than the limit already imposed by network
bottlenecks without making old systems useless?


Vernon Schryver[EMAIL PROTECTED]

Re: namedroppers, continued

[Bill Cunningham]

- Original Message -
From: "Lloyd Wood" <[EMAIL PROTECTED]>
To: "Ayyasamy, Senthilkumar (UMKC-Student)" <[EMAIL PROTECTED]>
Cc: "Fred Baker" <[EMAIL PROTECTED]>; "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, December 08, 2002 5:29 PM
Subject: RE: namedroppers, continued


> On Fri, 6 Dec 2002, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:
>
> > " If I don't know you, and you want your e-mail to appear in my
> >   inbox, then you must attach to your message an easily verified
> >  "proof of computational effort", just for me and just for this
> >  message.
> >
> > If the proof of effort requires, say, 10 seconds to compute, then
> > the economics of sending spam are radically altered, as a single
> > machine can send only 8,000 messages per day.
>
> tracking moore's law could be a problem.
>
> > The recent proliferation of spam has lead to a renewed interest in
> > these ideas.  This work is about both the choice of functions that
> > can be used to yield easily verifiable proofs of computational
> > effort, and architectures for implementing the proof of effort
> > approach.  Filtering and/or forcing senders to pay in other
> > currencies, such as human attention and money, will be covered as
> > time permits"
>
> "Sender pays" is good. The penny black stamp effectively introduced a
> flat-rate tax on sending letters, rather than a variable-rate tax on
> receiving them, effectively turning mail into a common good available
> to all society.

Lloyd, in the US we pay .37 to mail a first-class letter. I don't know how
many pence you pay in the UK but we still have "spam" bulk rate unwanted
solicitations. Forcing the sender to pay doesn't solve a spam problem. I
don't see how in could. It would force everyone to have to pay a price.


> The government also undercut private messaging operators and
> effectively put them out of business, but could use money earned
> towards other services for society (having simplified and saved on its
> operational costs along the way).
>
> So, computing as a social good - you want to send an email to someone
> you're unknown to, you've got to provide proof that you're
> participating in SETI@home, searching for big primes, in a distributed
> crypto challenge, working on processing public GIS information,
> autocomparing versions of typed ascii out-of-copyright texts (or raw
> CD rips?) for accuracy, processing gene data or archived NASA tapes or
> otherwise doing good things -- guess this would make each computing
> charity (give us your spare cycles) the ticket server or PKI manager,
> although you might want to try distributing that too.
>
> > for more details
> > http://research.microsoft.com/research/sv/PennyBlack
>
> I don't see any discussion there of the computation as a social good,
> or computational functions as utility functions. Microsoft, eh?
>
> http://www.glassinesurfer.com/f/gsrowlandhill.shtml
> -- and here's the obligatory mention of Jeremy Bentham.
>
> L.
>
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[EMAIL PROTECTED]>
>
>

Re: namedroppers, continued

[Valdis . Kletnieks]

On Sun, 08 Dec 2002 17:02:44 MST, Vernon Schryver <[EMAIL PROTECTED]>  said:

> Is the goal to block spam?  If so, what do you do about third case of
> senders that don't participate with either #1 or #2?  For the first
> years, most of the 10,000,000s of legitimate SMTP clients (sending
> mail servers) will do neither #1 or #2, because their operators will
> not have heard about it.

The bootstrap problem will exist no matter what scheme we decide on.

The point I was addressing was that there's been two major classes of
scheme proposed so far, with interesting characteristics:  at least for my
user community, each class (local computation and DNS) of proposal will
work very nicely for one subset of my users, and create major hassles for the
complementary subset.

However, the partitions created by each scheme are quite complementary,
so although I can't support a "be registered in DNS" solution because it
will not cover my desktop/roaming users, and I can't support a "use resources"
solution because it breaks my large servers, I *can* support a "either A or B"
scheme, as I have essentially no systems that couldn't do either one (at least
in theory, assuming software is available).

> Moore's law causes a bunch of problems for the computing idea.  There
> is at at least a factor of 100 in CPU speeds of current hosts.  How
> do you ensure that the fastest commodity CPU that a spammer might use
> is forced to slow down more than the limit already imposed by network
> bottlenecks without making old systems useless?

I'm still pondering that one. ;)

It may not be as big of a problem as we think.  Rough back-of-envelope
calculations now:  Let's say we assume a function X designed to take 10
seconds of CPU on my laptop (which has a 1.6Gz P-4 in it) to limit it to 8K
messages/day. Now, this same function will take around 2 minutes on a 133mz
processor and be restricted to 800 mails/day.  And yes, a spammer with a
100-node Beowolf could still send 800K mails/day, but the cost of the cluster
changes the economics considerably.

Now how many people are still using a 133 system to do that much outbound mail
themselves (and *NOT* just relaying all outbound mail to a smarthost)?  And
even *MORE* to the point, what are the chances that a system that old will be
upgraded software-wise to support a scheme, even if it takes zero additional
CPU? I strongly suspect that the *big* issue in getting said box to play nice
won't be the CPU, it will be trying to find a way to upgrade whatever
creeping-horror bletchware mailer they're using on Windows 3.1 ;)


-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09683/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Valdis . Kletnieks]

On Sun, 08 Dec 2002 20:09:24 EST, Bill Cunningham said:

> Lloyd, in the US we pay .37 to mail a first-class letter. I don't know how
> many pence you pay in the UK but we still have "spam" bulk rate unwanted
> solicitations. Forcing the sender to pay doesn't solve a spam problem. I
> don't see how in could. It would force everyone to have to pay a price.

On the flip side, although I still receive a fair number of postal bulk
rate advertisements, they differ in several respects from e-mail spam:

1) They tend to be much more targeted, and as a result more likely to be
of interest.  I get flyers from local supermarkets that I don't actually
shop at, but at least I don't get flyers for supermarkets 3 time zones away.

2) The cost per item tends to keep the total volume down.

3) Almost all the postal advertisements I receive are for legitimate groups
who wish to engage in legitimate business (or sometimes charity) transactions.
Very little of the e-mail spam strikes me as legitimate

The price-per-item is the main driving force on all three (although with the
third, the fact that large-scale fraud via the mails can get you prison time
helps control that problem as well).

Remember - in 6,000 years (and probably longer) we have yet to find a way to
totally stop scams and con artists.  However, we've gotten fairly good at
at least curtailing their activities to the point that society can function.

We don't need a 100% perfect anti-spam solution.  Like most societal ills,
if we can fix 98% of it, we can move on.
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09684/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Vernon Schryver]

> From: [EMAIL PROTECTED]

> ...
> The bootstrap problem will exist no matter what scheme we decide on.

There are many spam solutions that do not have the bootstrapping
problem.  Examples include effective laws and honest intent and action
by ISPs.  Before saying those are hopeless, please note that the many
bootstrap-limited proposals don't have proven prospects.

> The point I was addressing was that there's been two major classes of
> scheme proposed ...

> However, the partitions created by each scheme are quite complementary,
> ...

Your observation of how those two solutions fit together is
interesting...or would be if they did not suffer from other problems.


> ...
> > Moore's law causes a bunch of problems for the computing idea. ...

> It may not be as big of a problem as we think.  Rough back-of-envelope
> calculations now:  Let's say we assume a function X designed to take 10
> seconds of CPU on my laptop (which has a 1.6Gz P-4 in it) to limit it to 8K
> messages/day.

http://www.intel.com/home/desktop/pentium4/ suggests state of the commodity
art is about twice that, which lets a spammer send 16K msgs/day. 
Moore's law is still a treadmill that you don't want to fight.

>   Now, this same function will take around 2 minutes on a 133mz
> processor and be restricted to 800 mails/day. ...

I would put the lower limit at around 48 MHz on 80486s, or ~8 times
slower than a 133 MHz Pentium.  Such machines go back less than 10 years. 
Would you expect your conservative correspondents to spend 15 minutes
to send you a message, or would you just white-list them? 
Once you start white-listing, it's hard to have much enthusiasm for
more fancier solutions.


> Now how many people are still using a 133 system to do that much outbound mail
> themselves (and *NOT* just relaying all outbound mail to a smarthost)?

I think recent FreeBSD and sendmail would still work fine at 48 MHz,
although you probably want to stuff the thing to the gills with 64 MByte
of RAM, or more if it can take it.  There are many computing tasks that 
don't need 3 GHZ and 3 GByte.

Aren't busy smarthosts significantly busier than 80K msgs/day?
>From my old experience, that was true even when they were running
at less than 50 MHz and with perhaps 100 MByte.

Besides, no matter what inmates of glass houses and big ISPs would
have you think, SMTP is a peer-to-peer protocol.  A major damage spam
is doing is helping government commissars and ISP salescritters convince
people that the ancient Compuserve/AOL/Prodigy/whatever dumb-terminal-
connected-to-central-servers is the only way to do public networking
and computing.

  And
> even *MORE* to the point, what are the chances that a system that old will be
> upgraded software-wise to support a scheme, even if it takes zero additional
> CPU? ...

Would you whitelist it for the next 10 years?  If there are very
few, white-listing works.  If not, you've got that bootstrapping problem,
and you've invited the white-listing camel into your tent.


Vernon Schryver[EMAIL PROTECTED]

Re: namedroppers, continued

[Bill Cunningham]

How about passing a law that makes eveyone install a BIOS patch to block out
spam. ;-)

On the serious side Vernon has a point. Even with snail mail you can go
to the post office and the USPS will provide you with a form to fill out and
they will not put advertisements into your mail. If ISPs would only do the
same. As of yet, if all else fails, deleting a email box is easier and more
effective than taking a ballbat to a snail mail box.

--Bill
- Original Message -
From: "Vernon Schryver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 12:09 AM
Subject: Re: namedroppers, continued


> > From: [EMAIL PROTECTED]
>
> > ...
> > The bootstrap problem will exist no matter what scheme we decide on.
>
> There are many spam solutions that do not have the bootstrapping
> problem.  Examples include effective laws and honest intent and action
> by ISPs.  Before saying those are hopeless, please note that the many
> bootstrap-limited proposals don't have proven prospects.
>
> > The point I was addressing was that there's been two major classes of
> > scheme proposed ...
>
> > However, the partitions created by each scheme are quite complementary,
> > ...
>
> Your observation of how those two solutions fit together is
> interesting...or would be if they did not suffer from other problems.
>
>
> > ...
> > > Moore's law causes a bunch of problems for the computing idea. ...
>
> > It may not be as big of a problem as we think.  Rough back-of-envelope
> > calculations now:  Let's say we assume a function X designed to take 10
> > seconds of CPU on my laptop (which has a 1.6Gz P-4 in it) to limit it to
8K
> > messages/day.
>
> http://www.intel.com/home/desktop/pentium4/ suggests state of the
commodity
> art is about twice that, which lets a spammer send 16K msgs/day.
> Moore's law is still a treadmill that you don't want to fight.
>
> >   Now, this same function will take around 2 minutes on a
133mz
> > processor and be restricted to 800 mails/day. ...
>
> I would put the lower limit at around 48 MHz on 80486s, or ~8 times
> slower than a 133 MHz Pentium.  Such machines go back less than 10 years.
> Would you expect your conservative correspondents to spend 15 minutes
> to send you a message, or would you just white-list them?
> Once you start white-listing, it's hard to have much enthusiasm for
> more fancier solutions.
>
>
> > Now how many people are still using a 133 system to do that much
outbound mail
> > themselves (and *NOT* just relaying all outbound mail to a smarthost)?
>
> I think recent FreeBSD and sendmail would still work fine at 48 MHz,
> although you probably want to stuff the thing to the gills with 64 MByte
> of RAM, or more if it can take it.  There are many computing tasks that
> don't need 3 GHZ and 3 GByte.
>
> Aren't busy smarthosts significantly busier than 80K msgs/day?
> >From my old experience, that was true even when they were running
> at less than 50 MHz and with perhaps 100 MByte.
>
> Besides, no matter what inmates of glass houses and big ISPs would
> have you think, SMTP is a peer-to-peer protocol.  A major damage spam
> is doing is helping government commissars and ISP salescritters convince
> people that the ancient Compuserve/AOL/Prodigy/whatever dumb-terminal-
> connected-to-central-servers is the only way to do public networking
> and computing.
>
>
And
> > even *MORE* to the point, what are the chances that a system that old
will be
> > upgraded software-wise to support a scheme, even if it takes zero
additional
> > CPU? ...
>
> Would you whitelist it for the next 10 years?  If there are very
> few, white-listing works.  If not, you've got that bootstrapping problem,
> and you've invited the white-listing camel into your tent.
>
>
> Vernon Schryver[EMAIL PROTECTED]
>

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 09 Dec 2002 03:14:43 GMT, Lloyd Wood said:

> The act of subscribing to a list indicates that you know the list, and
> you're less likely to reject mail from people you don't know that
> comes or also comes via the list, since you're interested in reading
> that list -- unless the list is a simple exploder with no filtering
> mechanisms itself, in which case, subscribers pester each other
> (rather than the list) for computational proofs until the list
> implements spam filtering.

Let's look at some of the headers of the message I'm replying to:

Received: from fan.cc.vt.edu [198.82.161.8] by localhost with POP3 
(fetchmail-5.9.0)for valdis@localhost (single-drop); Sun, 08 Dec 2002 22:41:03 
-0500 (EST)

This is where my laptop picked up my mail via POP3.  My laptop can be aware of
the fact that I'm subscribed to IETF.  However, this is too late to make the
check effectively - it's already hit our central mail server.

Received: from steiner.cc.vt.edu ([10.1.1.14])  by gkar.cc.vt.edu (Sun Internet Mail 
Server sims.3.5.2001.05.04.11.50.p10)  with ESMTP id <[EMAIL PROTECTED]>; 
Sun,  8 Dec 2002 22:43:06 -0500 (EST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])  by steiner.cc.vt.edu 
(Mirapoint Messaging Server MOS 3.2.1-GA)  with ESMTP id ATX04442; Sun, 08 Dec 2002 
22:42:56 -0500 (EST)

Unfortunately, steiner is the machine which *should* be doing the filtering
(in fact, it's one of our front-end virus scanners).  But there's no good way
for it to know what I'm subscribed to - and a good case can be made that often
the mail server should *not* know what I'm subscribed to (for privacy reasons).

You *could* sell me on a concept where I tell the mail server "accept any mail
that presents a token that hashes to ", where I provide a test that
doesn't provide any information regarding the sender.

Why?  Because I don't trust my government to resist the temptation. (Nor do I
trust any OTHER national goverment, for that matter).
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09687/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 09 Dec 2002 00:47:45 EST, Bill Cunningham <[EMAIL PROTECTED]>  said:
> How about passing a law that makes eveyone install a BIOS patch to block out
> spam. ;-)

There exist systems that don't have a BIOS. ;)

(Making this reply mostly because there's been serious DRM proposals
that have this same exact problem).



msg09688/pgp0.pgp
Description: PGP signature

RE: namedroppers, continued

[Dean Anderson]

Every domain would have to have a public key that the public could find.
Then every mailserver would have to check every message.

And spammers could still send spam, because they are authorized to send
email from some ISP, using that ISP's domain, and that ISP mailserver will
sign their email.

Spam isn't a security problem that can be solved technically.

Spam is the exact same problem as when Randy Bush harrasses someone by
abusing his privileges as administrator. There isn't a technical solution,
other than removing the privileges. Then the new administrator could abuse
the privileges, if they were so inclined.  There isn't a technical way to
give someone privileges that they can't abuse, if so inclined.

--Dean

On Fri, 6 Dec 2002, Fred Baker wrote:

> [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to [EMAIL PROTECTED] and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
> At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote:
> >The only way to resolve this issue properly would be to require every
> >submission to an IETF mailing list to be cryptographically signed (PGP
> >or S/MIME), to require the subscribers to register their signing key and
> >to then filter the mail sent out on the list so that only signed mail
> >gets through.
>
> I would be in favor of that, personally, as long as we can ensure that the
> appropriate signature facility (be it RSA, PGP, or whatever) is freely
> available to all who need to use it. The issue here is not us corporate
> types who have a business reason to buy the software, it is the students
> who often lack the funds. The big issue would be the procedures for posting
> one's key to the appropriate place - what is to stop a spammer from posting
> a key and sending the spam anyway? I'm not proposing a mechanism, but
> someone who is good at such things might well find it of value.
>
> It doesn't address the "off topic" issue. As you say, that could be left to
> a working group chair equiped with formal procedures developed by consensus
> within the work group or adopted by the working group from a more general
> place (ie, the IETF could suggest a procedure, and the WG could adopt it if
> it didn't feel another procedure would be better).
>
> I have had a private exchange, over the past few days, with someone who
> wished that the IETF would please document some good spam-elimination
> procedure, so that it could be used world-wide to completely eliminate
> spam. I think that boils down to "provide a global PKI" in this solution,
> and presumes that spammers are incapable of using one. That might be a
> great research topic. Too bad nobody has ever thought of it before; we
> could really use the outcome of that research. (OK, so it's a lame attempt
> at humor...)
>
> I think it was Steve Bellovin that suggested a procedure for reducing the
> utility of spoofing source addresses in emails; if not, it was me and I
> happened to suggest something his favorite algorithm fit into, by having a
> host in each mail domain (mailid.example.com) be able to assert that its
> domain had or had not sent an email within a given recent  time period
> whose MD5 hash, when divided by  resulted in
> . I could write that up in an internet draft if folks
> think it makes sense. That would be a more global procedure that didn't
> require a PKI and only addressed spoofed addresses.
>
>
>
> --
> to unsubscribe send a message to [EMAIL PROTECTED] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
>

RE: namedroppers, continued

[Dean Anderson]

And how much before Randy was moderator?

I'm on other large, subscriber-restricted, public lists, where this isn't
a significant problem.

--Dean

On Fri, 6 Dec 2002, Hallam-Baker, Phillip wrote:

>
> > How much spam is going to namedroppers?
>
> Well none since Randy Bush and a bunch of others turned
> on the moderator bit.
>
> The problem here is that having Randy Bush moderate is
> not a scalable solution to the problems of Spam in general.
>
>
>   Phill
>
>
>

RE: namedroppers, continued

[John C Klensin]

--On Friday, 06 December, 2002 16:22 -0700 Vernon Schryver
<[EMAIL PROTECTED]> wrote:


From: Marc Schneiders <[EMAIL PROTECTED]>



...
It might be easier to write a new protocol to succeed email,
instant messaging, mobile phones (something useful in itself)
with built-in abuse control from the start.


That's another stupid crackpot "spam solution" that just won't
go away.

You cannot have "abuse control" built into a protocol that
allows strangers to send each other mail.  Any mail protocol
that lets you receive mail from a stranger must also let the
stranger send the same message to you and to 30,000,000 of
your closest friends.  On the other hand, if you want to only
accept mail from people who are not strangers, you can use any
of the many official and ad hoc SMTP extensions to ensure you
only receive mail from them.

If your computer system, mail protocol, or whatever knows that
a stranger is not a spammer, then the stranger is not really a
stranger.


Actually, Vernon, there is a well-known, established
implementation of this approach.  It depends on no one being
able to deliver mail to anyone else except through a network of
trusted intermediaries, who are interconnected with bilateral
agreements.  Each of those intermediaries is essentially
required to authenticate any user sending a message, which they
naturally tend to do because the system strongly assumes a
per-message and per-recipient charging model with settlements
between the originating and receiving intermediary systems.

If spammers tried to use it, they would rapidly become
discouraged, first of all because the per-message charging would
destroy their "free to us, steal resources from others" business
model and second because the accounting and authentication
machinery that is essential to the business models of the
intermediary system vendors (let's call them "ADMDs" for short)
would make tracking them down fairly easy.  And, of course, the
bilateral agreements would make it fairly easy to isolate and
punish an ADMD who didn't control its spammers or pay it
settlement bills.

I suppose I can leave the name of this high-quality,
significantly overengineered, widely-deployed system as an
exercise.

Been there, wasted a lot of time, energy, and resources, gave up.

   john

RE: namedroppers, continued

[Hallam-Baker, Phillip]

Don't discount the unexloited features already supported in the deployed
base.

In particular most mail servers support inline SSL connection upgrades,
or can be upgraded to do so with minimal hassle.

Another instance in which a self signed cert is possibly sufficient
authentication - although when you consider the security you get from
upgrading the connection to SSL the price of the cert is kinda de
minimis but I'll play along with the rulling IETF assumption of millions
for hardware, not a cent for software.


Phill

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 06, 2002 3:59 PM
> To: Marc Schneiders
> Cc: Fred Baker; Hallam-Baker, Phillip; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: namedroppers, continued
>
>
> I'v been saying about need for more radical change in mail
> protocol for
> years now on mailing lists. I'd rather work on smtp itself, but some
> people who were involved in original protocol do not want any serious
> changes to what they'v done, though its clear that abuse and
> other holes
> with current system is creating too many problems.
>
> In any case, by next ietf meeting in san francisco, I'll
> bring complete
> proposal for new protocol and might even try some practical
> tests. I do still
> believe that smtp can be saved, but not without more complex
> authentication
> system during delivery of email and that can't be done with current
> protocol design or current available extension process.
>
> Also were there any discussions or more complete discription of this
> algorithm for checking if host had sent an email and if so is this
> available on website or archive to read more about? If answer
> is yes, can
> somebody send me url or approximate date of discussions so I
> could lookup
> in archives.
>
> And am I correct here in understanding what was proposed is that smtp
> conversation id be such that receiving mail server could verify with
> sender (callback?) that it deed indeed initiate the email. If
> so I do not
> quite understand how MD5 helps there, plus I see quite a few
> problems with
> creating some special mx-like record in dns just for verification. If
> this is indeed what was proposed its better to go with paul vixie's
> proposal of mailfrom dns record -
http://www.vix.com/~vixie/mailfrom.txt or
http://www.ietf.org/internet-drafts/draft-church-dns-mail-sender-02.txt

On Fri, 6 Dec 2002, Marc Schneiders wrote:

> On Fri, 6 Dec 2002, at 13:41 [=GMT-0800], Fred Baker wrote:
>
> > I think it was Steve Bellovin that suggested a procedure for
reducing the
> > utility of spoofing source addresses in emails; if not, it was me
and I
> > happened to suggest something his favorite algorithm fit into, by
having a
> > host in each mail domain (mailid.example.com) be able to assert that
its
> > domain had or had not sent an email within a given recent  time
period
> > whose MD5 hash, when divided by  resulted
in
> > . I could write that up in an internet draft
if folks
> > think it makes sense. That would be a more global procedure that
didn't
> > require a PKI and only addressed spoofed addresses.
>
> Spammers would be the first to set up your mailid host. They will have
> had years of experience to find holes in the system before you've
> convinced everyone to adopt or accept the mailid.
>
> It might be easier to write a new protocol to succeed email, instant
> messaging, mobile phones (something useful in itself) with built-in
> abuse control from the start.





smime.p7s
Description: application/pkcs7-signature

Re: namedroppers, continued

[Stephen Sprunk]

Vernon Schryver wrote:
> It's been years since it was possible to be amused by the number of
> people who assume that spammers are more ignorant and less competent
> than they are, and so propose spam "solutions" predicated on spammers
> being unable to register as many names, keys, identities, or whatever
> as needed or as many as everybody else can.

The problem I've seen repeatedly, including in an off-list discussion I'm
having about this topic, is people confusing authentication with
authorization.

Even if you can authenticate every sender of every piece of email, that
gains us virtually nothing -- not to mention it's a reasonably well-solved
problem, e.g. PGP, S/MIME.  As Vernon notes, spammers can create authentic
credentials just as easily as anyone else.

The devil is in determining what senders are authorized once we've
authenticated them.  My fear is the only effective solution may turn out to
be closed lists with permission grants, such as the IM services introduced
to keep spammers out.  That will greatly reduce the utility of email.

S

Re: namedroppers, continued

[Stephen Sprunk]

Paul Vixie wrote:
>> - many ISPs won't let you forward or submit mail through someone
>>   else's SMTP server, even if you have permission to do so.  so you
>>   can't forward your mail through your "home" ISP's mail server to
>>   allow the "mail from" check to work.
>
> in that case you'd be wise to not insert a MAIL-FROM MX for your
> domain.

The vast majority of users do not have the ability to make that decision.

The curious thing is that it is in an ISP's best interests _not_ to
implement this draft, since doing so will likely mark nomadic users' email
as suspect and potentially lose a customer.  Most companies only support the
"public good" to the extent it doesn't cost them any revenue.

S

RE: namedroppers, continued

[Hallam-Baker, Phillip]

> Well, it's also the availability of the right signature
> facility in the
> myriad email clients people use.

I disagree here, I believe it is a case of supporting the
overwhelming majority of the platforms with software that
is freely available and free.

I don't believe that we should consider support for Open
Genera to be a 'must support' issue. Years ago people used
to whinge when someone sent a MIME attachment of 10K or
so because it took too long to download over a 300 baud
modem.

I don't think it is a bad thing to consider that high
bandwidth connectivity is still a constrained resource
absent in many less developed parts of the world. However
the complaints about using MIME never come from those
quarters.


> I could write that up in an internet
> draft if folks
> >think it makes sense. That would be a more global procedure
> that didn't
> >require a PKI and only addressed spoofed addresses.
> >
> Wasn't me...

The problem is not the PKI, the problem is the directory.

Deployment of PKI is easy. It is the Directory baggage that
people foisted onto PKI that is the failure. X.500 has set
us back more than the NSA crypto export regulations ever did.
LDAP merely compounds the problem, building failure on top
of failure.

We need a DNS linked PKI, not a directory linked PKI.

We need a PKI that only cares about the addresses the
applications route on. The idea of using human names for
PKI is bogus.

The directory PKI model fails for the Internet for many
reasons. First taxonomic organization is a broken concept.
No real world information is stuctured in that fashion,
not even genealogies (cousins marry cousins). The reason
that so many enterprise directory projects are fiascos
is that they are trying to fit data into a representation
that is simply inappropriate.

The other main reason that directories are a failure for
Internet PKI is that they are exclusively an internal
data resource. VeriSign has an employee directory accessible
from the inside of the company. There is no way it is
ever going to be accessible from the outside.

At the Internet level trust relationships are complex,
they are certainly not hierarchical. Trying to store that
data in a taxanomic sturcture then do path discovery is
nonsense on stilts.


Linking the PKI to the DNS completes the picture. I want
to send Fred Baker an email, well I had better know his
email address first. My email client can follow an SRV
record from cisco.com to find an XKMS service for cisco.com
where I can ask 'what key should I use to send an
encrypted S/MIME email to [EMAIL PROTECTED]'.

Allowing organizations to find out that [EMAIL PROTECTED] is still
working for Cisco is actually a security improvement. It
means that Office Max can shut off his personal stationary
account ordering privs the minute he leaves Cisco.


Don't reject the leverage that public key provides just
because you don't like the package people tried to wrap
arround it. The protocol you describe requires state and
is simply not deployable for large systems like hotmail.

It would be nice if the IETF could get ahead of the curve
this time instead of being the brake. We still have members
of the IESG speaking to security forums disputing the
utility of network security measures such as firewalls
even after Steve became a security area director.

We need to shift towards a comprehensive multi-level
security approach which accepts that there are problems
that cannot be addressed by the end to end argument.

Real users are saying that SPAM is their number one
internet related problem today. Classify it how you like
but deal with it with a security mentality. The spamers
are seriously degrading the utility of email. We need
a short term approach to mitigate the problem (filtering)
and long term approaches that have the potential to
put them out of business. Authenticating the good signal
is completely complimentary with rejecting the bad.

Phill



smime.p7s
Description: application/pkcs7-signature

RE: namedroppers, continued

[Dean Anderson]

This seems clever, however, it will also take significant computational
effort to verify the computational effort was actually done. Even if a
class of functions are found that are "easier" to verify than to compute,
they will no doubt still take up a significant fraction of time.

Also, all outgoing messages would need this computation, since a
mailserver does not know who it has sent mail to in the past, and whether
they are still in receipt of the verification.  So then you would only be
able to send 8000 messages a day, too.

Clearly, that doesn't scale very well.

It seems unlikely that this would change the percentage of spam, since it
would merely reduce the total amount of mail sent.

I haven't observed a recent proliferation of spam, however. Spam seems to
be level.

--Dean

On Fri, 6 Dec 2002, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:
> this is the work all about (yesterday's seminar in a MIT group)
>
> " If I don't know you, and you want your e-mail to appear in my
>   inbox, then you must attach to your message an easily verified
>  "proof of computational effort", just for me and just for this
>  message.
>
> If the proof of effort requires, say, 10 seconds to compute, then the
> economics of sending spam are radically altered, as a single machine
> can send only 8,000 messages per day.
>
> The recent proliferation of spam has lead to a renewed interest in
> these ideas.  This  work is about both the choice of
> functions that can be used to yield easily verifiable proofs of
> computational effort, and architectures for implementing the proof of
> effort approach.  Filtering and/or forcing senders to pay in other
> currencies, such as human attention and money, will be covered as time
> permits"
>
>
> for more details http://research.microsoft.com/research/sv/PennyBlack
>
>
>
> --
> to unsubscribe send a message to [EMAIL PROTECTED] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
>

Re: namedroppers, continued

[Dean Anderson]

This doesn't adequately describe backup relays.  If uunet is providing an
alternate relay service, then all or any of uunet's relays might be
providing that service. So it would have to be able to recursively look up
uunets mail-from mx's, and the mail-from mx's of any subdomains listed by
uunet.  This process might contain loops.

Additionally, the mail forwarding behavior is highly undesirable.  A large
mail site does not want to have to manually configure essentially the
whole of the internet as possible multi-stage mail relays so that its
users can forward mail from other servers to their mailbox. Indeed, even a
relatively small site would not want to do that.

However, even this approach won't stop spam, since a spammer will still be
able to use their ISP's mailservers, with a stolen, or disposable account.
There are plenty of KLEZ viruses out there, and plenty of stolen
passwords. And it won't have any effect at all on spam from real
commercial operators like Exactis who don't forge the from addresses.

Essentially, I'm convinced after years of interaction with some radical
anti-spammers that most of the non-commercial spam (and quite a lot of the
forged-address spam) is sent by anti-spammers trying to essentially
terrorize their way to some kind of technical solution that they think
exists. However, no such solution exists.  If there were such a solution,
we could prevent all kinds of evils, like government corruption,
embezzlement, misuse of all kinds of property.  But there is no substitute
for honesty and responsibility. If someone has possession of a privilege,
(however that privilege was obtained--it may have been stolen), and they
are so inclined to abuse that privilege, the only way to stop them is to
remove the privilege.

--Dean

On Sat, 7 Dec 2002, Paul Vixie wrote:

> it's difficult to imagine a mailing list for which this thread is on-topic.
>
> > I think it was Steve Bellovin that suggested a procedure for reducing the
> > utility of spoofing source addresses in emails; if not, it was me and I
> > happened to suggest something his favorite algorithm fit into, by having a
> > host in each mail domain (mailid.example.com) be able to assert that its
> > domain had or had not sent an email within a given recent  time period
> > whose MD5 hash, when divided by  resulted in
> > . I could write that up in an internet draft if folks
> > think it makes sense. That would be a more global procedure that didn't
> > require a PKI and only addressed spoofed addresses. --
>
> here was my attempt at this, which i didn't really know where to go next with:
>
>
>
>
>
>
>
>IndependentPaul Vixie (Ed.)
>Request for Comments:  Category: Experimental
>June 6, 2002
>
> Repudiating MAIL FROM
>
>Status of this Memo
>
>   This memo describes an experimental procedure for handling received
>   e-mail.  It does not specify an Internet standard of any kind.
>   Distribution of this memo is unlimited.
>
>Copyright Notice
>
>   Copyright (C) The Internet Society (2002).  All Rights Reserved.
>
>Abstract
>
>   At the time of this writing, more than half of all e-mail received by
>   the author has a forged return address, due to the total absence of
>   address authentication in SMTP (see [RFC2821]).  We present a simple
>   and backward compatible method whereby cooperating e-mail senders and
>   receivers can detect forged source/return addresses in e-mail.
>
>1 - Introduction and Overview
>
>1.1. Internet e-mail return addresses are nonrepudiable by design of the
>relevant transport protocols (see [RFC2821]).  Simply put, there is no
>cause for ANY confidence in the proposition "this e-mail came from where
>it says it came from."
>
>1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail
>routinely use this designed-in lack of source/return authenticity to
>hide their point of origin, which usually involves forging a valid
>return address belonging to some highly visible and popular ISP (for
>example, HOTMAIL.COM).
>
>1.3. Recipients who wish to reject unwanted bulk e-mail containing
>forged source/return addresses are prevented from doing so since the
>addresses, as presented, are nonrepudiable by design.  Simply put, there
>would be too many false positives, and too much valid e-mail rejected,
>if one were to program an e-mail relay to "reject all e-mail claiming to
>be from HOTMAIL.COM" since, statistically, most e-mail claiming to be
>from HOTMAIL.COM is actually from somewhere else.  HOTMAIL.COM, in this
>example, is a victim of forgery.
>
>
>
>Vixie Experimental  [Page 1]
>
>RFC   Repudiating MAIL FROM May 26, 2002
>
>
>1.4. What's needed is a way to guaranty that each received e-mail
>mes

RE: namedroppers, continued

[Ketil Froyn]

On Fri, 6 Dec 2002, Ayyasamy, Senthilkumarwrote:

> If the proof of effort requires, say, 10 seconds to compute, then the
> economics of sending spam are radically altered, as a single machine
> can send only 8,000 messages per day.

Wouldn't something like this cause problems for (large/free) email
providers?  They would probably need a lot of extra hardware to do all
this computation. And until something like this is included in the
standard, the receiver must accept mail from senders that don't implement
this yet.

I personally like the idea behind qconfirm (http://smarden.org/qconfirm/)
and TMDA (http://tmda.net/). If I receive an email that I do not recognize
or otherwise find to be authentic, a mail is sent back to the sender,
requesting that they send a verification mail to a unique secret address.
When a mail is received at this secret address, the original mail is
delivered to me, and the secret address is removed. For a spammer, it is
too expensive to receive and reply to all these mails.

Ketil

Re: namedroppers, continued

[Dean Anderson]

To make them do all the work, and you do little to verify, you need a lot
of things done independently, so that a random sample can be selected that
is much smaller than the work they had to do. This will get bulky.  The
less they send, the larger the fraction of work you have to do in relation
to theirs.  And of course, you have to do the same amount of work on your
outgoing messages as they do.

The result is that it costs you much more than it costs the spammer.
(since you have to do the work for both sending and receiving, and the
spammer only has to do the work for sending.

This would not result in a reduction of spam, as a percent of total mail.
If everyone used this, it might (at best or worst) reduce the total mail
sent, since the billions of legitimate messages sent each day would
require significantly more work to send.

Further, it would open one up to a denial of service type attack where
garbage is sent, and you have to do the work to check the (invalid)
signature, thereby wasting your cpu resources.

Essentially, this shoots oneself in the foot. Or perhaps the CPU.

--Dean

On Sat, 7 Dec 2002, Steven M. Bellovin wrote:

> In message <[EMAIL PROTECTED]>, Dean An
> derson writes:
> >This seems clever, however, it will also take significant computational
> >effort to verify the computational effort was actually done. Even if a
> >class of functions are found that are "easier" to verify than to compute,
> >they will no doubt still take up a significant fraction of time.
>
> In fact, that's the easy part.  You could demand that the sender
> compute 1,000,000 HMACs of the text, the envelope, the time of day, and
> a counter.  The verifier could check 100 randomly-chosen ones -- if any
> fail, there's a forgery.  (Well, you probably wouldn't want those
> values, since 1,000,000 HMACs would be a lot of data to transmit.  But
> you get the general idea.)
>
>   --Steve Bellovin, http://www.research.att.com/~smb (me)
>   http://www.wilyhacker.com ("Firewalls" book)
>
>
>
> --
> to unsubscribe send a message to [EMAIL PROTECTED] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
>

RE: namedroppers, continued

[Dean Anderson]

On Sun, 8 Dec 2002, Lloyd Wood wrote:
> "Sender pays" is good. The penny black stamp effectively introduced a
> flat-rate tax on sending letters, rather than a variable-rate tax on
> receiving them, effectively turning mail into a common good available
> to all society.

You assume this really means "the spammer pays" [more]. But that isn't the
case.  This is based on the myth that somehow the receiver pays the entire
cost of a spam message. This isn't true, and never was true. The sender is
already paying, whether they are spammer or mailing list operator, or
regular end user.  The fact is that email is so cheap that it costs almost
nothing per message to send and receive.  It gets cheaper every day, as
disks and bandwidth get cheaper and cheaper. The receiver doesn't pay any
more than the sender pays. Real commercial spam happens because the cost
of sending spam is less than the cost of sending letters or postcards.

If you artificially made email expensive, it would be expensive for list
operators and regular people as well. You mentioned a rate of one cent per
message.  That would not be enough to deter spam. A rate of ten cents per
message would still be cheaper than postal mail, and so spammers would
still exist.  Much non-commmercial spam is sent by KLEZ or Nimda viruses.
This sort of abuse would not be affected whatsoever.  Note that KLEZ
infections are already illegal.

Think how much it would cost to send out namedroppers, (and the entire
bulk of IETF standards related email) if each message to each recipient
cost, say $0.10.  Or even one cent per message per recipient.  This
proposal would essentially wipe out many if not most mailing list
operators, and most ISPs.

I made a proposal back in 1997 that would not eliminate spam, but would
keep it out of your mailbox. My proposal was rejected because radicals
demanded a complete ban on spam. In 1998, there was an opportunity to get
anti-spam legislation passed.  Unreasonable anti-spam radicals passed up
that opportunity when they insisted on unrealistic demands, and
exaggerated and factually wrong assertions about the cost of spam.  They
assumed they could "shout down" any opposition, as they shouted down more
reasonable proposals.  They were understandably and easily crushed by the
Direct Marketing Association (DMA).  You can still see my proposal at
http://www.av8.com/H.4581/better.html This proposal would have been
difficult for the DMA to challenge since they already accept these
restrictions on postal mail.  You have the radical anti-spam leadership to
thank for your spam, and the fact that you don't have a universal opt-out
list.

The anti-spam effort was for all practical purposes completely crushed
when Exactis successfully sued MAPS and demonstrated that blacklists are
subject to the Sherman Anti Trust Act and that blacklists weren't
protected by the First Amendment.  I told Vixie this would happen in 1997.
He assured me that anti-spammers could win by technical means. If it
wasn't clear that he was wrong in 1997, (and it seemed pretty obvious even
then), it is now painfully obvious that Vixie and the rest were very
wrong.

It is really time for new, reasonable, anti-spam leadership, not artifical
changes to the cost of email, or schemes to try to make sending mail more
expensive for the senders, and certainly not gyrations in the sending of
namedroppers.

Thanks to the ineptitude, lack of foresight, irrationality, and general
unreasonableness of the anti-spam leadership, spam is here to stay. It is
just a matter of degrees of how bad it will be.  I note there is some
legislation before the house and senate (HR 1017) on spam control, that
reportedly isn't opposed by the DMA. However, these only control
fraudulent spam.  HR 1017 proposes extensions of 18 USC 1030, which makes
it a fraudulent spam a crime, but the FBI probably won't bring charges for
small violations. There is no provision for a civil action.

Another bill (S.630) would require each spammer to maintain an opt-out
list.  You would have to contact each spammer, and have your email address
added to their list, one by one. There would be thousands of spammers to
contact.

Note that my proposal would had a single opt-out list (the Post Office
already maintains such a list for postal junk mail), and my proposal
probably could have been passed into law in 1998.

--Dean

Re: namedroppers, continued

[Vernon Schryver]

> From: "Stephen Sprunk" <[EMAIL PROTECTED]>

> ...
> The problem I've seen repeatedly, including in an off-list discussion I'm
> having about this topic, is people confusing authentication with
> authorization.
> ...

Yes, that's a good way of putting the problem, but only for those able
and willing to see the differences among authorization, authentication,
confidentiality, non-repudiation, and so forth.

It's sad that weak as dishwater authentication as authorization (and
everything else) snake oil sells so well, as witnessed by Verisign's
PKI and Microsoft's ActiveX.


>   ...My fear is the only effective solution may turn out to
> be closed lists with permission grants, such as the IM services introduced
> to keep spammers out.  That will greatly reduce the utility of email.

That has already happened about as much as it is going to happen or
could happen, as witnessed by the IETF lists.  The variations in
effectiveness and mechanisms among the IETF lists are minor details.
The notion of limiting submissions to known authors was once very
controversial here, but it's now accepted as necessary and desirable.
I don't see any reduction in  utility as a result.

Individual mailboxes differ.  Because people value its utility, personal
addresses will continue to accept mail from strangers who might be
sending the same message to 100,000 others.  Various technical and
administrative defenses will limit spam.

Except for those few of us who are obsessed with spam, filters that
are sufficent and require little effort will be used.  Popular choices
will be what people can do for themselves such as private and DNS white-
and blacklists, SpamAssassin, Brightmail, Postinni, Cloudmark/Razor, and
the DCC.  ("Do for themselves" includes hiring a competent ISP.)  Filters
that require joint actions by the sender and receiver, including the
computing-cost and authenticating DNS RR proposals, will never be popular.
Because they won't be popular, installations that start to use them will
switch to sufficient equivalents such as simple white-listing.  Sufficient
existing protocols are never vulnerable to slightly better replacements.

Joint action is an enormous barrier.  It is a cost that is justified
only in special cases.  That is why we are not routinely using PGP or
S-MIME for our private mail.  That's also why I see many more SMTP-TLS
connections to my SMTP server than I expected (many including from
spammers), and why almost none of them are authenticated.  To use
SMTP-TLS you need only install and configure a current SMTP server.
To use authenticated SMTP-TLS, you must use PKI or exchange keys.


Vernon Schryver[EMAIL PROTECTED]

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 09 Dec 2002 11:52:26 CST, Stephen Sprunk <[EMAIL PROTECTED]>  said:

> The problem I've seen repeatedly, including in an off-list discussion I'm
> having about this topic, is people confusing authentication with
> authorization.

Authentication:  Yes, you seem to be Jeffrey Dahlmer.
Authorization:   You say you'd like to borrow a steak knife?

Usually clears up the confusion in all but the most sluggish mind.. ;)

However, "authorization" usually implies "authentication" beforehand.
Does anybody  have a reference on an authorization scheme that
doesn't imply any authentication?
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09712/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Stephen Sprunk]

Thus spake <[EMAIL PROTECTED]>
> Authentication:  Yes, you seem to be Jeffrey Dahlmer.
> Authorization:   You say you'd like to borrow a steak knife?
>
> Usually clears up the confusion in all but the most sluggish mind.. ;)

That's a very clear example, thanks.

> However, "authorization" usually implies "authentication" beforehand.
> Does anybody  have a reference on an authorization scheme that
> doesn't imply any authentication?

In a sense:  the IETF lists (and most others) use a null authentication
method, i.e. you trust whatever is in the message.  After that (null) step,
we apply weak authorization, i.e. whether the sender is on the approved
list.

I've seen lots of proposals to improve the former-- hardly difficult -- but
none for the latter.  Perhaps using precise terminology will help focus
efforts in the right area.

S

Re: namedroppers, continued

[Edward Lewis]

At 16:53 -0500 12/9/02, [EMAIL PROTECTED] wrote:

However, "authorization" usually implies "authentication" beforehand.
Does anybody  have a reference on an authorization scheme that
doesn't imply any authentication?


World readable files.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis  +1-703-227-9854
ARIN Research Engineer

Re: namedroppers, continued

[Bill Cunningham]

I haven't personally tried myself to opt out. But I've read they have the
form. If they told you they don't have a form to sort out junk mail for you
I'd say they were full out it. I'd call the Postmaster General's office.

- Original Message -
From: "Stephen Sprunk" <[EMAIL PROTECTED]>
To: "Bill Cunningham" <[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 12:56 PM
Subject: Re: namedroppers, continued


> Can you tell me where to get this form?  When I spoke to the USPS, they
said
> they're legally obligated to deliver all junk mail addressed to me,
> regardless of whether I want it.
>
> Now, the DMA (not the USPS) does have an opt-out list you can join, but
> unfortunately that only drops about half the junk mail I get -- many local
> mailers don't join the DMA because of cost.
>
> S
>
>
> Bill Cunningham wrote:
> > How about passing a law that makes eveyone install a BIOS patch to
> > block out spam. ;-)
> >
> > On the serious side Vernon has a point. Even with snail mail you
> > can go to the post office and the USPS will provide you with a form
> > to fill out and they will not put advertisements into your mail. If
> > ISPs would only do the same. As of yet, if all else fails, deleting a
> > email box is easier and more effective than taking a ballbat to a
> > snail mail box.
> >
> > --Bill
> > - Original Message -
> > From: "Vernon Schryver" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, December 09, 2002 12:09 AM
> > Subject: Re: namedroppers, continued
> >
> >
> >>> From: [EMAIL PROTECTED]
> >>
> >>> ...
> >>> The bootstrap problem will exist no matter what scheme we decide on.
> >>
> >> There are many spam solutions that do not have the bootstrapping
> >> problem.  Examples include effective laws and honest intent and
> >> action by ISPs.  Before saying those are hopeless, please note that
> >> the many bootstrap-limited proposals don't have proven prospects.
> >>
> >>> The point I was addressing was that there's been two major classes
> >>> of scheme proposed ...
> >>
> >>> However, the partitions created by each scheme are quite
> >>> complementary, ...
> >>
> >> Your observation of how those two solutions fit together is
> >> interesting...or would be if they did not suffer from other problems.
> >>
> >>
> >>> ...
> >>>> Moore's law causes a bunch of problems for the computing idea. ...
> >>
> >>> It may not be as big of a problem as we think.  Rough
> >>> back-of-envelope calculations now:  Let's say we assume a function
> >>> X designed to take 10 seconds of CPU on my laptop (which has a
> >>> 1.6Gz P-4 in it) to limit it to 8K messages/day.
> >>
> >> http://www.intel.com/home/desktop/pentium4/ suggests state of the
> >> commodity art is about twice that, which lets a spammer send 16K
> >> msgs/day. Moore's law is still a treadmill that you don't want to
> >> fight.
> >>
> >>>   Now, this same function will take around 2 minutes on
> >>> a 133mz processor and be restricted to 800 mails/day. ...
> >>
> >> I would put the lower limit at around 48 MHz on 80486s, or ~8 times
> >> slower than a 133 MHz Pentium.  Such machines go back less than 10
> >> years. Would you expect your conservative correspondents to spend 15
> >> minutes to send you a message, or would you just white-list them?
> >> Once you start white-listing, it's hard to have much enthusiasm for
> >> more fancier solutions.
> >>
> >>
> >>> Now how many people are still using a 133 system to do that much
> >>> outbound mail themselves (and *NOT* just relaying all outbound mail
> >>> to a smarthost)?
> >>
> >> I think recent FreeBSD and sendmail would still work fine at 48 MHz,
> >> although you probably want to stuff the thing to the gills with 64
> >> MByte of RAM, or more if it can take it.  There are many computing
> >> tasks that don't need 3 GHZ and 3 GByte.
> >>
> >> Aren't busy smarthosts significantly busier than 80K msgs/day?
> >>> From my old experience, that was true even when they were running
> >> at less than 50 MHz and with perhaps 100 MByte.
> >>
> >> Besides, no matter what inmates of glass houses and big IS

Re: namedroppers, continued

[Matt Crawford]

> Does anybody  have a reference on an authorization scheme that
> doesn't imply any authentication?

"You will deliver the satchel to the one who presents the matching
half of this hundred-euro note."

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 09 Dec 2002 17:47:58 EST, Edward Lewis said:

> >Does anybody  have a reference on an authorization scheme that
> >doesn't imply any authentication?
> 
> World readable files.

We know how to do that already ;)

I was thinking more along the lines of a zero-knowledge proof or
something like that - a scheme where you can prove you're authorized to
do something(*) without having to prove who you are first.

(*) and explicitly ruling out the 'null check, everybody is allowed' case ;)

/Valdis




msg09723/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[John C Klensin]

--On Monday, 09 December, 2002 16:17 -0600 Stephen Sprunk
<[EMAIL PROTECTED]> wrote:

> Thus spake <[EMAIL PROTECTED]>
>> Authentication:  Yes, you seem to be Jeffrey Dahlmer.
>> Authorization:   You say you'd like to borrow a steak knife?
>> 
>> Usually clears up the confusion in all but the most sluggish
>> mind.. ;)
> 
> That's a very clear example, thanks.
> 
>> However, "authorization" usually implies "authentication"
>> beforehand. Does anybody  have a reference on an
>> authorization scheme that doesn't imply any authentication?
> 
> In a sense:  the IETF lists (and most others) use a null
> authentication method, i.e. you trust whatever is in the
> message.  After that (null) step, we apply weak authorization,
> i.e. whether the sender is on the approved list.

Actually, it is a very common situation:

Think about almost any case in which possession of a token
authorizes one to do something, but no identification/
authentication is implied.  For what is perhaps one of the older
examples, can you go to a store where you are not known, in some
part of your country where you are not frequently present, and
buy something.  Of course you can: you pass an authorization
token, typically called "cash" across the counter and get some
merchandise in return.  The quantity of tokens you possess and
their value even determines the extent of your authorization.

Credit card companies often draw an analogy to that situation,
which is one of the reasons they have stayed far out of the
_public_ part of the PKI business: they don't really care who
you are, or who uses the credit card, as long as the bill gets
paid.  Anything they do or require that involves authentication
has to do with the "the bill will get paid without protest"
property, not your identity.

 john

Re: namedroppers, continued

[Ofer Inbar]

[EMAIL PROTECTED] wrote:
> Does anybody  have a reference on an authorization scheme that
> doesn't imply any authentication?

From:-line based email filters.

  --  Cos (Ofer Inbar)  --  [EMAIL PROTECTED] http://cos.polyamory.org/
  --  WBRS (100.1 FM)   --  [EMAIL PROTECTED] http://www.wbrs.org/
   "OSI is a beautiful dream, and TCP/IP is living it!"
 -- Einar Stefferud <[EMAIL PROTECTED]>, IETF mailing list, 12 May 1992

Re: namedroppers, continued

[Dave Crocker]

Stephen,


Monday, December 9, 2002, 9:52:26 AM, you wrote:
Stephen> The devil is in determining what senders are authorized once we've
Stephen> authenticated them.

The concept of being "authorized" to send someone mail has good logic, but
goes against established human communication practises for mail and
telephone.  (Filtering is common to both, but is different from
"authorization".)

Some time ago, Mike O'Dell put forward the idea of "accountable", in the
sense of being able to reach back to the sender, to hold them accountable
for their actions.

The general idea behind pursuing simple authentication presumes that the
really nasty spammers would not want to be identified.  It's not clear how
valid this presumption really would be.

d/
-- 
 Dave Crocker  
 TribalWise 
 t +1.408.246.8253; f +1.408.850.1850

Re: namedroppers, continued

[Michael Froomkin - U.Miami School of Law]

Blinded coins a la digicash
http://www.law.miami.edu/~froomkin/articles/oceanno.htm#xtocid583124

On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote:

> On Mon, 09 Dec 2002 17:47:58 EST, Edward Lewis said:
> 
> > >Does anybody  have a reference on an authorization scheme that
> > >doesn't imply any authentication?
> > 
> > World readable files.
> 
> We know how to do that already ;)
> 
> I was thinking more along the lines of a zero-knowledge proof or
> something like that - a scheme where you can prove you're authorized to
> do something(*) without having to prove who you are first.
> 
> (*) and explicitly ruling out the 'null check, everybody is allowed' case ;)
> 
> /Valdis
> 
> 

-- 
Please visit http://www.icannwatch.org
A. Michael Froomkin   |Professor of Law|   [EMAIL PROTECTED]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
-->It's warm here.<--

Re: namedroppers, continued

[John C Klensin]

--On Monday, 09 December, 2002 17:49 -0500 Bill Cunningham
<[EMAIL PROTECTED]> wrote:

> I haven't personally tried myself to opt out. But I've read
> they have the form. If they told you they don't have a form to
> sort out junk mail for you I'd say they were full out it. I'd
> call the Postmaster General's office.

Bill,

For the US Post Office, they don't have the form.  In another
context, I've been over this with the Postal Inspection Service.
They have two other forms and models, one of which is probably
getting confused with this.

(1) You can decline to receive the particular form of junk mail
that is addressed to "occupant", "boxholder", or similar generic
terms.  For that, there is a form.

(2) You can also decide that particular types of materials,
identifed by specific description (nearly impossible in most
cases) or source is obscene.  Once you do that, and perform the
relevant rituals, it becomes illegal for identified sources to
send the stuff to you.  In general, you can't get the post
office to open all of your mail and do content filtering to be
sure it doesn't meet your criteria for obscenity.   And you
probably wouldn't want to, since that would require authorizing
them to open and read all of your mail.  But it can be an
effective way to prevent a particular sender for sending you
specific kinds of materials, since the penalties for sending
obscene materials through the mails are quite severe.

If it is addressed to you, by name and matching address, they
are, as Stephen indicated, legally required to deliver it
(unless it falls under the prohibitions of (2) above).  So,
oddly, you can opt out of "untargeted" mailings, but not out of
"targeted" ones.

john 

Re: namedroppers, continued

[Bill Cunningham]

- Original Message -
From: "John C Klensin" <[EMAIL PROTECTED]>
To: "Bill Cunningham" <[EMAIL PROTECTED]>
Cc: "Stephen Sprunk" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 9:16 PM
Subject: Re: namedroppers, continued


>
>
> --On Monday, 09 December, 2002 17:49 -0500 Bill Cunningham
> <[EMAIL PROTECTED]> wrote:
>
> > I haven't personally tried myself to opt out. But I've read
> > they have the form. If they told you they don't have a form to
> > sort out junk mail for you I'd say they were full out it. I'd
> > call the Postmaster General's office.
>
> Bill,
>
> For the US Post Office, they don't have the form.  In another
> context, I've been over this with the Postal Inspection Service.
> They have two other forms and models, one of which is probably
> getting confused with this.
>
> (1) You can decline to receive the particular form of junk mail
> that is addressed to "occupant", "boxholder", or similar generic
> terms.  For that, there is a form.
>
> (2) You can also decide that particular types of materials,
> identifed by specific description (nearly impossible in most
> cases) or source is obscene.  Once you do that, and perform the
> relevant rituals, it becomes illegal for identified sources to
> send the stuff to you.  In general, you can't get the post
> office to open all of your mail and do content filtering to be
> sure it doesn't meet your criteria for obscenity.   And you
> probably wouldn't want to, since that would require authorizing
> them to open and read all of your mail.  But it can be an
> effective way to prevent a particular sender for sending you
> specific kinds of materials, since the penalties for sending
> obscene materials through the mails are quite severe.
>
> If it is addressed to you, by name and matching address, they
> are, as Stephen indicated, legally required to deliver it
> (unless it falls under the prohibitions of (2) above).  So,
> oddly, you can opt out of "untargeted" mailings, but not out of
> "targeted" ones.
>
> john

I checked 39USC and 39CFR955 I guess the postal service maintains a list if
you want to not receive mailing for sexually oriented materials,
sweepstakes, and pandering solicitations. But that's about it. As far as the
USPS goes.
>

RE: namedroppers, continued

[Gray, Eric]

Dave,

It's not all that unclear either.  The "really nasty spammers"
use anonymity in at least two ways: to avoid filtering and to avoid
being billed for wasting our time, storage capacity, bandwidth and 
other resources.  Taking anonymity away from these people would be
the long overdue end of their "free lunch" on everyone else's tab.

On top of that, some spammers are actually breaking the law.
Gotten any South African "my late  died and left me  ..."
mail lately?  Those people belong in jail...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[EMAIL PROTECTED]
508 305 7214


> ...
> 
> The general idea behind pursuing simple authentication presumes that the
> really nasty spammers would not want to be identified.  It's not clear how
> valid this presumption really would be.
> 
> d/
> --
>  Dave Crocker  
>  TribalWise 
>  t +1.408.246.8253; f +1.408.850.1850

Re: namedroppers, continued

[Bill Sommerfeld]

> I checked 39USC and 39CFR955 I guess the postal service maintains a list if
> you want to not receive mailing for sexually oriented materials,
> sweepstakes, and pandering solicitations. But that's about it. As far as the
> USPS goes.

I have not yet tried filing a form 1500, but, if you believe the folks
at junkbusters.com [1] [2], and page 13 of Postal Bulletin 21977 [3],
it's clear that the courts have ruled that porn is in the eye of the
beholder.

  "Postmasters may not refuse to accept a Form 1500 because the
   advertisement in question does not appear to be sexually
   oriented. Only the addressee may make that determination."

- Bill

[1] http://www.junkbusters.com/self.html#prohibit
[2] http://www.junkbusters.com/dmlaws.html
[3] http://www.usps.com/cpim/ftp/bulletin/1998/pb21977.pdf

Re: namedroppers, continued

[Valdis . Kletnieks]

On Tue, 10 Dec 2002 08:57:59 EST, "Gray, Eric" said:

>   On top of that, some spammers are actually breaking the law.
> Gotten any South African "my late  died and left me  ..."
> mail lately?  Those people belong in jail...

Or this:

http://ars.userfriendly.org/cartoons/?id=20021209

(OK, so it's a REALLY bad pun ;)



msg09754/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Theodore Ts'o]

For those of you who are in the Boston area, the following
presentation might be of interest, given recent discussions about
methods of compating SPAM.  It is hosted by the MIT Laboratory for
Computer Science's Applied Security Reading Group.

- Ted


ASRG TALK - in NE43-941 at 400 p.m. this THURS

Open to the Public

Date:THURSDAY, DEC 12th
Time:4:00 p.m. - 5:00 p.m.
Place:   NE43-941, 200 Tech Square
Speaker: Cynthia Dwork, Microsoft Research, Silicon Valley Campus
Title:   Fighting Spam May Be Easier Than You Think

Abstract:

In CRYPTO'92 Dwork and Naor proposed the following simple technique
for combating spam:

If I don't know you, and you want your e-mail to appear in my
inbox, then you must attach to your message an easily verified
"proof of computational effort", just for me and just for this
message.

If the proof of effort requires, say, 10 seconds to compute, then the
economics of sending spam are radically altered, as a single machine
can send only 8,000 messages per day.

The recent proliferation of spam has lead to a renewed interest in
these ideas.  This talk surveys recent work on both the choice of
functions that can be used to yield easily verifiable proofs of
computational effort, and architectures for implementing the proof of
effort approach.  Filtering and/or forcing senders to pay in other
currencies, such as human attention and money, will be covered as time
permits.

Hosted by the Applied Security Reading Group
http://pdos.lcs.mit.edu/asrg/

Re: namedroppers, continued

[Doug]

Hello everyone,

It seems to me if the mail server administrators would make the decision to
require people that send emails from their servers to log into a valid
account on that server and use the same valid account on the server as a
return address it would negate the ability of a large percentage of the
spamers to send the spam anon. This would allow easier filtering of many of
the offending messages by domain. Additionally, the sending account field
and the reply to field should be equal and clients should be required to use
an email address that is associated with the account used to log into the
server in the first place. This will need to be implemented in the beginning
by administrators who run software capable of it, and it would be
implemented later as part of the email client and/or server software using
new software releases, patches, and individual customizations of existing
software. I know that there are many people who will scream and gnash their
teeth at this suggestion as it will force them to identify themselves to
anon mailing lists but I think it would be an acceptable compromise if we
could eliminate a major portion of the spam clogging our inboxes. Clients
need to be identified by ISP based email servers using their DNS and IP
address footprints and clients attempting to send email with improper
footprints should be disregarded (making it very difficult to send email
from the server if you truly are not a valid subscriber to the service, much
like many of the current news servers do). Then to deal with the anonymous
email servers out there (hotmail, yahoo, etc...) the operators of those
services should require clients logging into those accounts to send email
from a valid IP address with no unsecured proxy services running on them
(much like many IRC servers are doing) and transmit this IP information
along with the email being sent. This would allow for pinpoint
identification of the senders of spam using IP addresses MAC addresses and
time stamped logs for the specific purposes of taking legal action against
these network abuses. I know it will be argued that this will require
cooperation between ISPs and that some systems are already implementing
these measures but if all administrators as a single body insist that
everyone adhere to these rules or be excluded from sending email to clients
of their services and enforced this through IP block and domain blocking the
stragglers would be forced to adhere to these rules. Further, if a body such
as the IETF stood behind this and perhaps drafted specifications for
administrators, and software developers to follow when making new
clients/servers and updating existing clients/servers it would hold added
weight in the market place. The extra cost associated with such actions
could be offset by saved resources, and additional revenues made as a result
of higher subscription rates justified by superior spam filtering techniques
and a greater number of subscribers to the service due to better service
quality. I would also like to suggest that the California law that requires
all unsolicited emails be appended with adv: in the subject line be expanded
to a federal law and additionally require emails that are solicited by
signing up for a service include exact information about who the sender
bought your email address from in the email.

These are just some ideas I have had on eliminating spam and should in no
way be considered a flame against anyone. I know there is no way that this
will stop all unsolicited email from being sent or received. I just thought
they might help to get some people rolling on a solution and that it would
be better than complaining about it. After all doesn't a global solution
make more sense than venting about what should be done to keep it out of
this mailing list.

Thank you for your time and attention,

Douglas Huyler
[EMAIL PROTECTED]
704-721-0212

P.S. I am sorry this email comes so long after the original post was made
but I don't read the list very often and after reading this thread from the
begining to December 6th I thought I would reply. If someone else has
brought these things up after this point I am sorry, but I haven't caught up
with the list yet.


- Original Message -
From: "Fred Baker" <[EMAIL PROTECTED]>
To: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, December 06, 2002 4:41 PM
Subject: RE: namedroppers, continued


> At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote:
> >The only way to resolve this issue properly would be to require every
> >submission to an IETF mailing list to be cryptographically signed (PGP
> >or S/MIME), to require the subscribers to register their signing key and
> >to then filter the mail sent out on the list so that only signed mail
> >gets through.
>
> I would be in favor

Re: namedroppers, continued

[Valdis . Kletnieks]

On Sun, 05 Jan 2003 19:04:41 EST, Doug said:

> It seems to me if the mail server administrators would make the decision to
> require people that send emails from their servers to log into a valid

Your proposal would fix the problem, but end up tossing a large quantity
of babies out with the bathwater.  The problem is that for the case of
a mailing list, you have *4* (at least) things to keep track of:

1) The RFC821 recipient address.  For your copy of this posting, it's "your
email address".

2) The RFC821 sender address.  It should be available in the Return-Path:
header in most well-behaved mail systems as you look at your mail.

3) The RFC822 From: address.

4) The RFC822 To: address.

Another problem is that I am (fortunately) still receiving more mail
each day that counts as "legitimate unsolicited" (problem reports about
our servers, people who have seen my name and are looking for technical
advice, etc) than I do actual spam.

It's not as easy as it looks... :)

/Valdis



msg09885/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Doug]

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Doug" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 1:23 AM
Subject: Re: namedroppers, continued


>> It seems to me if the mail server administrators would make the decision
to
>> require people that send emails from their servers to log into a valid
>
>Your proposal would fix the problem, but end up tossing a large quantity
>of babies out with the bathwater.  The problem is that for the case of
>a mailing list, you have *4* (at least) things to keep track of:

There are many comercial email servers that require the people sending email
with their server to log into the server using a valid username and pass
before
doing so. I doubt they are losing any valid emails. All it does is to keep
unauthorized users from using the server without a valid password. The
reason
to require that the sender address in the outgoing email matches the email
address refrenced in the account is to keep people from sending spam from
these email servers and using fraudulant return and/or sender address.
I fail to see how this throws out any babies. perhaps I am missing
something.

>
>1) The RFC821 recipient address.  For your copy of this posting, it's "your
>email address".

>2) The RFC821 sender address.  It should be available in the Return-Path:
>header in most well-behaved mail systems as you look at your mail.

>3) The RFC822 From: address.

>4) The RFC822 To: address.

I know what the recipient address, sender address, from address, and to
address in headers look like. The problem is that many spammers use false
information here and change it on a regular basis. This makes it impossible
to block their email at the client end. My proposal is very basically to
make
it mandatory to put valid information in these fields in order to be able to
send the email.

>Another problem is that I am (fortunately) still receiving more mail
>each day that counts as "legitimate unsolicited" (problem reports about
>our servers, people who have seen my name and are looking for technical
>advice, etc) than I do actual spam.

I also never intended for servers to be using filters on unsolicited emails
just
because they are unsolicited. My intention was to suggest that people who
were sending unwanted and unsolicited "comercial" email should be blocked.
I suggested that servers that refused to cooperate with the rest of the spam
hating world could be blocked just in case but, this may be a bit harsh.
In addition the steps I mentioned would allow for the person receiving these
emails to gather information to allow them to easily take legal action
against the
spammers that still managed to get through. IE if everyone is forced to use
valid
information in the headers to be able to send the email without using some
exploit on the server then it should be easy to track them down. If of
course
they are forced to use exploits to send their anon spam then the admins of
the
system would eventually find this and take action to block them and/or
prosecute them. Perhaps you could be scanning header information as well on
the receiving server (not the client or the sending server) to allow you to
check
for nonsense return addresses like [EMAIL PROTECTED] or fraudulant source DNS
and IP information. Another thing that could be checked for is wether the
sending account matches the reply to address.

>It's not as easy as it looks... :)

Oh no I never said it was easy and I also never said I knew it all. I am
just
making a suggestion as to a possible solution to the problem.

:)
Doug

>/Valdis

P.S. I do seriously want to know how this would stop valid email users from
getting/sending their email.

Re: namedroppers, continued

[Harald Tveit Alvestrand]

--On mandag, januar 06, 2003 02:01:27 -0500 Doug <[EMAIL PROTECTED]> 
wrote:

Your proposal would fix the problem, but end up tossing a large quantity
of babies out with the bathwater.  The problem is that for the case of
a mailing list, you have *4* (at least) things to keep track of:


There are many comercial email servers that require the people sending
email with their server to log into the server using a valid username and
pass before
doing so. I doubt they are losing any valid emails. All it does is to keep
unauthorized users from using the server without a valid password. The
reason
to require that the sender address in the outgoing email matches the email
address refrenced in the account is to keep people from sending spam from
these email servers and using fraudulant return and/or sender address.
I fail to see how this throws out any babies. perhaps I am missing
something.


wellthink about how mail from someone who is not an user of that system 
(like me) can send mail there

how does your system tell the difference between a remote mail server and a 
malicious user?

Harald

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 06 Jan 2003 02:01:27 EST, Doug said:

> There are many comercial email servers that require the people sending email
> with their server to log into the server using a valid username and pass
> before
> doing so. I doubt they are losing any valid emails. All it does is to keep
> unauthorized users from using the server without a valid password. The
> reason
> to require that the sender address in the outgoing email matches the email
> address refrenced in the account is to keep people from sending spam from
> these email servers and using fraudulant return and/or sender address.
> I fail to see how this throws out any babies. perhaps I am missing
> something.

What you're missing is that I can configure *MY* server so it will only:

1) Accept mail *TO* a local recipient.
2) Allow relaying of mail to a *remote* recipient after doing some sort of
authentication that it's one of my users.

And in fact, the last I heard, open relays were only 1% or so of the total
mailservers out there - so the above is already the usual state of affairs.

Note there's no requirement that *inbound* mail be authenticated, which is
the basic source of the spam problem.  Your mail server will probably
accept mail for your userid from anyplace without authentication.

Now let's say you *do* start requiring authentication for inbound mail.
Let's consider this piece of mail, which is being sent to both you and
the IETF list...

1) What userid/password does the IETF mailserver use to authenticate
itself to your mail server?  Remember in your answer to note that forcing
users to manually update a whitelist of mailing lists they are on is
a helpdesk nightmare, and hard to scale - our main mailserver has some
80K mailboxes/aliases on it, and I'm on a lot of lists.  However, just
because *I* am on a list hosted at some site doesn't mean that any other
users on my mail server wants to accept mail from that site.  However,
even if you decide *that* cost is toleralble, there's still:

2) What userid/password does my laptop use to authenticate itself to your
mail server?  And note that you can't just say "my laptop has to send it to
my mail server" - because then you need to get the userid/password pair to
my mail server.  Remember that your answer has to scale to 40 million .coms,
and that it has to work on a sender/recipient pair basis (otherwise, it's
like inviting a vampyre in - if they can get one person at your server to
OK the mail, then they can commence spamming all your users).  Note that
answers like the "reply to this message to prove you're not a spammer"
schemes are *NOT* a long-term solution - if any of those packages becomes
widespread enough to actually impact the spam problem, the spammers will
have a little Perl program scanning the bounces and canning the "yes I'm
not a spammer" responses.



-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09901/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Doug]

I believe the answer to your first question is you would send mail
using
your own mail server not someone else's. Although...I do see unique
issues
involved in people using mail servers that are not part of their
network
(hotmail, yahoo...) to send email if they try to authenticate you as
part of
their network before allowing you to send email. I believe the
solution to
that problem is that those commercial mail servers (free or premium)
would
not be able to authenticate you as part of their network before
allowing you
to send your email. They would then require clients logging into those
accounts (with valid user names and passwords) to send email from a
valid IP
address with no unsecured proxy services running on them (much like
many IRC
servers are doing) and transmit this IP information along with the
email
being sent. This would allow for pinpoint identification of the
sender's
using IP addresses MAC addresses and time stamped logs for the
specific
purposes of taking legal action against these network abuses.

Your second question is a bit harder for me to answer. I believe (I
may be
incorrect) that there is already a difference between a receiving mail
server's transaction with a sending or relaying mail server and a mail
client. I would never claim that it is impossible for a malicious user
to do
anything (I know better). On the other hand if we can achieve
authentication
before sending email and it becomes a requirement of the system then
it
should make the actions of a malicious user stand out in the logs of
the
server allowing for tracking, blocking, and prosecution of those users
for
the unauthorized access and (mis)use of private network resources. My
solution does NOT have a way of completely stopping spam from being
sent but
perhaps in conjunction with other actions it can stop a majority of
spam
from being sent. Additionally, my solution makes it easier for end
users and
administrators to track the actions of spammers and find their virtual
locations. I would further suggest that once this information is
gathered
and verified with the spammers ISP subpoenas, court orders, cease and
desist
orders, fines under existing laws, and criminal prosecution could do
the
rest.

I am not claiming that this will eliminate spam on it's own. I am
claiming
that it will make it harder for the offending parties to get away with
sending spam in a manner that is not compliant with TOS agreements and
the
law. This solution would require a concerted effort by the
administration
comunity as a whole and I think that is where the problem truely is.

- Original Message -
From: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]>
To: "Doug" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 10:00 AM
Subject: Re: namedroppers, continued


>
>
> --On mandag, januar 06, 2003 02:01:27 -0500 Doug
<[EMAIL PROTECTED]>
> wrote:
>
> >> Your proposal would fix the problem, but end up tossing a large
quantity
> >> of babies out with the bathwater.  The problem is that for the
case of
> >> a mailing list, you have *4* (at least) things to keep track of:
> >
> > There are many comercial email servers that require the people
sending
> > email with their server to log into the server using a valid
username
and
> > pass before
> > doing so. I doubt they are losing any valid emails. All it does is
to
keep
> > unauthorized users from using the server without a valid password.
The
> > reason
> > to require that the sender address in the outgoing email matches
the
email
> > address refrenced in the account is to keep people from sending
spam
from
> > these email servers and using fraudulant return and/or sender
address.
> > I fail to see how this throws out any babies. perhaps I am missing
> > something.
>
> wellthink about how mail from someone who is not an user of that
system
> (like me) can send mail there
>
> how does your system tell the difference between a remote mail
server and
a
> malicious user?
>
>  Harald
>

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 06 Jan 2003 14:38:09 EST, Doug <[EMAIL PROTECTED]>  said:
> I believe the answer to your first question is you would send mail
> using
> your own mail server not someone else's. Although...I do see unique
> issues
> involved in people using mail servers that are not part of their
> network
> (hotmail, yahoo...) to send email if they try to authenticate you as
> part of
> their network before allowing you to send email.
You're still missing the point.

How do you tell the difference between:

1) The IETF mail server sending for the IETF list.
2) The large SUN box across the hall that's the main vt.edu mail server.
3) My laptop.

Currently, my laptop will send directly to the destination.  The problem is
that although it would be trivial to change it so that it uses the central
Virginia Tech mail hub, that doesn't fix your problem - there's still no
authenticator for the vt.edu mail server at your mail server either

Oh, and don't even suggest chasing MX records - the MX for vt.edu points
at one set of boxes, but you will almost certainly *NOT* get a connection
from them, as our outbound servers are at different addresses.  And no, we
won't change this unless you first manage to get hotmail.com and aol.com
to not use different inbound and outbound addresses first, as they do the
same thing for the same reasons.
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09908/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[Doug]

I am apparently missing something here but I am going to give it a
shot anyway.

You can tell the difference between 1, 2, and 3 because they all have
a different DNS/IP footprint.

You can send email directly to the IETF mail server? Do you have an
account on that server?

I myself use a SMTP server to send out my email. It goes from my email
client to the SMTP server I happen to be using and it then gets
relayed through the network until it reaches the destination email
server.

The validation I have been referring to would take place between the
mail client and the originating server. The entire point would be to
verify the identity of the person sending the email or at least the
account it is being sent from.

I am not suggesting that the destination email server should ask for
authentication for every email it receives before it relays it on to
another mail server or a client. I am saying that the originating
server should ask for it before accepting it and relaying it on to the
network.

The originating server would then be able to assure correct header
information by not allowing an email to be sent unless the outgoing
email was tagged with the proper DNS/IP footprint (not that of an
unsecured proxy server or a spoofed IP) and a return/reply address
that is associated with the account that the client used to
authenticate with the server. This in effect means that you cannot use
a different return/reply address (or a fake return/reply address) that
cannot be traced back to your account on the originating server by the
recipient or an IP/DNS footprint that cannot be traced back to your
machine or a point on your network by the recipient. This is to force
the person sending the email to be accountable for the email sent.

I am not suggesting that the recipient or even the relaying server
should be allowed to connect back to the originating mail server or
the client that sent the email. That would create security risks for
networks hosting mail servers and clients sending the email.

I am suggesting that before someone drops an email onto an originating
mail server that the server should take what I consider to be
reasonable steps to authenticate the user and confirm their identity
and account status on that server. The server would then tag
information onto the email that would identify the machine on which
the email client that sent the email resides (not the information of
an unsecured proxy). In addition, the originating server should tag
information that identifies the account (on the originating
server/network) that the client used to send the email and force the
originating client to provide a valid reply address that is associated
with the account to the recipient of the email.

I am not suggest that originating servers should be tagging the exact
virtual location of an inbound or outbound server to anything or
changing MX records to reflect the correct virtual location to the
outside world. In fact, if this is not done it helps keep those
outbound email servers hidden from the outside world and helps keep
malicious users from finding them and exploiting them in some way to
send their email without authorization. I do feel that I should be
able to identify the actual network on which that server resides so I
can contact someone there to help track down someone who is sending
spam.

Does the above clear up any confusion? Is there anything I am missing
here? If so please tell me what because I would welcome the
opportunity to learn something new. There may very well be big gaps in
this plan I am just unaware of what they are so I welcome the
opportunity to learn that you or anyone may pointing them out would
bring.

Doug
[EMAIL PROTECTED]
704-721-0212

P.S. As a side note if anyone thinks this is not a proper forum for
exchanging ideas about this please do tell me. It is not my goal here
to disrupt anything. I am just trying to exchange some ideas with a
large body of professionals in the hopes of learning something and
hopefully contributing something helpful. I would also like to invite
the moderators of this forum to contribute what they think of this
line of discussion. If they think it is unproductive I would be more
than willing to drop it and never breath another word about anything
unless it falls into any guidelines they would like to set forth.
Please, anyone, do feel free to respond with anything you feel would
be helpful constructive or apropriate on this subject.



- Original Message -
From: <[EMAIL PROTECTED]>
To: "Doug" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 3:36 PM
Subject: Re: namedroppers, continued

>> I believe the answer to your first question is you would send mail
>> using
>>your own mail server not someone else's. Although...I do see unique
>> issues
>> involved in people using mail servers that are not part of their
>> network
>> (hotmail, yahoo...) t

Re: namedroppers, continued

[Melinda Shore]

In that environment, anybody can get around what you're
proposing by setting up their own first hop mail server.
Or  hop mail server, for that matter.

Melinda

Re: namedroppers, continued

[Valdis . Kletnieks]

On Mon, 06 Jan 2003 18:08:44 EST, Doug said:
> You can tell the difference between 1, 2, and 3 because they all have
> a different DNS/IP footprint.

They do? Are you sure of this?  I'll give you a hint - if you're outside
the two /16's of our network, and you get an inbound SMTP connection from us,
looking up the PTR to get the hostname will almost certainly *NOT* have
the string 'mail' in it.

And the inbound and outbound mail servers at ietf.org are called 'odin' and
'ran', respectively..  Not much info there.

And last I heard, about 30% of the PTR space is broken beyond use due to
cluenessness on the ISP's part, so you can't get a DNS name you can trust.

So what DNS/IP footprint were you planning to use?

> You can send email directly to the IETF mail server?

Yes, sometimes multiple times an hour if I'm in a verbose mood...

>   Do you have an
> account on that server?

Nope, no account there. Don't need one, works fine..

> I myself use a SMTP server to send out my email. It goes from my email
> client to the SMTP server I happen to be using and it then gets
> relayed through the network until it reaches the destination email
> server.

OK.. to be *very* pedantic, I use an SMTP server as well.  My MUA (Mail
User Agent) exmh hands the mail to the SMTP server I happen to be using,
and the SMTP server relays mail everyplace.  It just happens that my preferred
SMTP server happens to be already running on my laptop

> I am not suggesting that the destination email server should ask for
> authentication for every email it receives before it relays it on to
> another mail server or a client. I am saying that the originating
> server should ask for it before accepting it and relaying it on to the
> network.

Aha.  I see now.  What you *want* is what all properly run mail servers
*ALREADY* do.  It's amazingly useful for tracking down users that are being
silly and need a slap upside the head to clear the kloo blockage.  What
it's NOT useful for is stopping the determined spammer who doesn't use
your mail server to inject the mail into the net

The reason it doesn't stop spam is because you're missing an important
point - you seem to think that "if the sending server validates the user,
we won't have spam.."

> authenticate with the server. This in effect means that you cannot use
> a different return/reply address (or a fake return/reply address) that

Hmm.. so the mail I'm replying to wouldn't work, because I got it from the IETF server
but it has your From: address on it - therefore the IETF server must be
lying about who it is and who the sender is.

Actually, that's not quite true - there's usually 
> cannot be traced back to your account on the originating server by the
> recipient or an IP/DNS footprint that cannot be traced back to your
> machine or a point on your network by the recipient. This is to force
> the person sending the email to be accountable for the email sent.

OK.. and this is *forcing* it *how*?

Think carefully here - the receiving end is trusting what the sender
sends.

> and account status on that server. The server would then tag
> information onto the email that would identify the machine on which
> the email client that sent the email resides (not the information of
> an unsecured proxy). In addition, the originating server should tag
> information that identifies the account (on the originating
> server/network) that the client used to send the email and force the
> originating client to provide a valid reply address that is associated
> with the account to the recipient of the email.

And of *COURSE*, not even a SPAMMER would be so unrighteous as to forge
a "this mail was approved" header.

This mail has a 'X-Verified-Sender-Address:' header that identifies
the originating address.  Take a look at it, and tell me if you feel any
better about having verified the origin.  And remember that since I control
my machine, I can make a similar change to any *OTHER* header (From:, Sender:,
X-Authenticated:, or whatever).

And the spammer controls his server

/Valdis




msg09916/pgp0.pgp
Description: PGP signature

Re: namedroppers, continued

[jfcm]

At 13:05 07/01/03, Lloyd Wood wrote:

Doug has rediscovered the idea of closing open mail relays to prevent
unauthorised use by outsiders sending to outsiders. This was a big
thing in the early 90s when email became popular.

Doug has also come up with the idea of adding the IP address of the
originating client machine (not necessarily using SMTP) in a header
so that an attempt can be made to identify it - e.g. Hotmail has done
that for years.

missing mail admin experience, I think.


This remarks shows that the problem is around for more than ten years and 
that no one found a satisfactory solution in using the present system. 
Would this feed back from real world not be enough for us to understand its 
'cybernetic' (true meaning) lesson : the current mail system model is 
inadequate.

Question now is : do we have to investigate a new one? or can an 
architectural change/addition may elegantly address the case? probably a 
mix of both due to the existing e-mail system use. ie a new e-mail system 
with a retro-compatibility with the current one. Or would it also be a new 
TCP/IP design, compatible with the old one? Or/and a new IPv6 compatible 
with the old one?

May be Dick Clarke will tell us next week how much he wants to invest into 
such a Nextnet?
jfc

Re: namedroppers, continued

[Doug]

Hello Mr. Wood,

- Original Message -
From: "Lloyd Wood" <[EMAIL PROTECTED]>
To: "Doug" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, January 07, 2003 7:05 AM
Subject: Re: namedroppers, continued


> Doug has rediscovered the idea of closing open mail relays to
prevent
> unauthorised use by outsiders sending to outsiders. This was a big
> thing in the early 90s when email became popular.

This may seem to be a bit basic for some of the people who have worked
on this problem for years. My intention was not to prove that I had
the latest and greatest solution to the spam problem. It was to get
the ball rolling in an open discussion forum and present my ideas on
the topic in the hopes that someone who knew more than me on the topic
would as well.

>
> Doug has also come up with the idea of adding the IP address of the
> originating client machine (not necessarily using SMTP) in a header
> so that an attempt can be made to identify it - e.g. Hotmail has
done
> that for years.

After examining the headers of many of the spam advertisments I get
and trying to contact the administrator of the network it came from I
find that it is usually futile because the network doesn't exist and
the IP information is incorrect. I also find that most use false
sender and reply address information (in an attempt to keep recipiants
from filtering them). This makes it hard (at least for me) to do
anything about them. I have experimented with filters for subject
wording but this unfortunately hits on some of my wanted email as
well. This reduces my ability to to block them on the receiving end.
Even if I could it doesn't help the net congestion they cause or do
anything about the processing time it is using across the net. These
things leads me to propose that a more global solution needs to be
implemented. The problem here is that when you bring this up for
discussion in a professional environment like this one people don't
want to discuss it. Instead they consider it a problem that has no
solution and just want to forget about it.

>
> L.
>
> missing mail admin experience, I think.

Very true. I have never administered anything other than my http and
ftp servers. I have thought of turning on the mailserver but I do not
know enough about administering it yet and I really have no need for
it. I certainly hope that nobody thought I actually ran my own mail
server because I was not my intention to pretend that I did.

It is nice to see someone with more knowledge and/or experience on the
topic than me taking the time to think (and talk) about it.

Thanks for the input,
Doug
Asking questions, presenting possible solutions, and learning from
mistakes is how we get solutions.
---snipped previous for sake of size--

Re: namedroppers, continued

[Valdis . Kletnieks]

On Tue, 07 Jan 2003 13:33:28 EST, Doug said:

> After examining the headers of many of the spam advertisments I get
> and trying to contact the administrator of the network it came from I
> find that it is usually futile because the network doesn't exist and
> the IP information is incorrect. I also find that most use false
> sender and reply address information (in an attempt to keep recipiants
> from filtering them). This makes it hard (at least for me) to do
> anything about them.

The trick here is to remember that except for the relative few spammers that
are advocating a religious/political/philosophical viewpoint (a la "Uncertainty
Principle is Untenable!"), the spammers *WANT* you to be able to contact them
via *some* means - they can't extract money (their usual goal) from you if
you can't get back to them.

Moreover, it has to be relatively simple to find - it has to be simple enough
that even a victim who doesn't have enough kloo to stop to wonder why the
"confidential and private" Nigerian scam arrived via spammage can figure out
how to get aboard

-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg09919/pgp0.pgp
Description: PGP signature

RE: namedroppers, continued

[Tony Hain]

Doug wrote:
> ...
> After examining the headers of many of the spam advertisments 
> I get and trying to contact the administrator of the network 
> it came from I find that it is usually futile because the 
> network doesn't exist and the IP information is incorrect. I 
> also find that most use false sender and reply address 
> information (in an attempt to keep recipiants from filtering 
> them). This makes it hard (at least for me) to do anything 
> about them. I have experimented with filters for subject 
> wording but this unfortunately hits on some of my wanted 
> email as well. This reduces my ability to to block them on 
> the receiving end. Even if I could it doesn't help the net 
> congestion they cause or do anything about the processing 
> time it is using across the net. These things leads me to 
> propose that a more global solution needs to be implemented. 
> The problem here is that when you bring this up for 
> discussion in a professional environment like this one people 
> don't want to discuss it. Instead they consider it a problem 
> that has no solution and just want to forget about it.

An approach that is more effective than scanning for content is to
simply block connections from the last hop in the SMTP chain before
yours. This kills both direct spammers as well as open relays. The list
can be long (mine is ~ 256 /24's for a private little mailer), but that
is a tradeoff against how much space you want to block at a time. On
several occasions I have considered putting in 61/8, 200/6, & 210/7,
because that would remove 3/4 of the list, but that also creates a
guilt-by-association for people with no control over their address space
or those who are abusing it. 

While this approach avoids having the content traverse the wire, some of
the machines are tenacious, as yesterday's log shows. 
http://www.tndh.net/~tony/ietf/2003-01-05-log.txt

Tony

Re: namedroppers, continued

[Dr. Jeffrey Race]

On Tue, 07 Jan 2003 15:26:55 -0500, [EMAIL PROTECTED] wrote:
>The trick here is to remember that except for the relative few spammers that
>are advocating a religious/political/philosophical viewpoint (a la "Uncertainty
>Principle is Untenable!"), the spammers *WANT* you to be able to contact them
>via *some* means - they can't extract money


See 

If the contact data are invalid, report to RIR or to ICANN.  They
are obliged to correct the data.

Jeffrey Race

Re: namedroppers, continued

[Vernon Schryver]

> From: "Dr. Jeffrey Race" <[EMAIL PROTECTED]>

> ...
> If the contact data are invalid, report to RIR or to ICANN.  They
> are obliged to correct the data.

No, contrary to the common hope to extract petty vengence from spammers,
they are merely forced to provide contact data that is not obviously
bogus.  Worse, by forcing spammers to be less creative, these efforts
make them harder to recognize.  A random name and address from the
nearest phone book is not readily identifiable, unlike the false names
previously favored by many spammers.  Both sorts of domain contacts
are useless for contacting spammers.

Besides, domain contact addresses generally unrelated and are
certainly irrelevant to the contact addresses for collecting money
in almost all spam.


Vernon Schryver[EMAIL PROTECTED]

Re: namedroppers, continued

[Daniel Pelstring]

Doug,

This topic comes up quite often.  It has been discussed at length many
times.  Do not take criticism of your ideas too harshly, it is just that
most people here have seen these same solutions proposed by many people over
many years.  It gets a bit old and, patience gets a bit short.  A very quick
summary of the solutions proposed during these discussions is as follows:

A) Anybody can send mail to anybody (what we currently have.)

B) Mail servers check that the sender is authorized to send mail to the
users of its system.

C) Sending mail requires some sort of computationally expensive to compute,
easy to check, data to be sent along with messages (probably based on sender
address, receiver address and message)

Unfortunately, B requires that there be some way to authenticate users
of other systems.  The only way that has been thought of to do this is to
have some central authority to do this.  While it is certainly possible,
this is thought to be a bad idea for many reasons, the most prominent of
which is the potential for abuse.  Lacking a central authority, this can be
done on mail servers already, with no need to involve the IETF (an example
would be whilelists.).

Unfortuantely, C would have to be computable in a reasonable amount of
time in order not to be a major headache.  This means that the spammers
large cluster of powerful computers would still be able to send many
messages.  It would also wreak havoc with mailing lists.  It would also
become easier to compute as time goes on, due to the ever progressing nature
of computers.  This does not even take into account that we would be
creating a standard with the sole purpose of inefficiency, which probably
makes most engineers wince and, although that may not seem like such a
horrible idea right now, this standard could survive far into the future,
with implications yet to be known (keep in mind the scale on which these
standards will be implemented.)  If another solution is implemented in the
future, this may come back to bite us.

At the moment, it seems the IETF consensus (notice the *seem* here, this
is my personal opinion taken from reading the discourse on these lists) is
that the best solution is A.  At some point another solution may hold the
majority favor, but that time is not now.

Of course, it is possible that there is a solution that has not been
thought of, in which case it is a bad idea to discourage people from
thinking about it.  Know, however, that this list contains many extremely
arrogant (many of them justifiably so) experts in their chosen field, who
dislike their time being wasted.  I encourage you, if you have further
ideas, to do the required research to see if it would work before sending a
message and, be very thorough.  Also know that if you choose to get into a
flame war with people on this list, that some them have likely been doing
this for decades and, are probably much better at it than you are.  It is
likely to do nothing but frustrate you.  If you have another idea and, have
questions about how to check that it is at least feasable, I would be happy
to point you in the right direction.

-Daniel Pelstring


- Original Message -
From: "Doug" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Lloyd Wood" <[EMAIL PROTECTED]>
Sent: Tuesday, January 07, 2003 1:33 PM
Subject: Re: namedroppers, continued


> Hello Mr. Wood,
>
> - Original Message -
> From: "Lloyd Wood" <[EMAIL PROTECTED]>
> To: "Doug" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Tuesday, January 07, 2003 7:05 AM
> Subject: Re: namedroppers, continued
>
>
> > Doug has rediscovered the idea of closing open mail relays to
> prevent
> > unauthorised use by outsiders sending to outsiders. This was a big
> > thing in the early 90s when email became popular.
>
> This may seem to be a bit basic for some of the people who have worked
> on this problem for years. My intention was not to prove that I had
> the latest and greatest solution to the spam problem. It was to get
> the ball rolling in an open discussion forum and present my ideas on
> the topic in the hopes that someone who knew more than me on the topic
> would as well.
>
> >
> > Doug has also come up with the idea of adding the IP address of the
> > originating client machine (not necessarily using SMTP) in a header
> > so that an attempt can be made to identify it - e.g. Hotmail has
> done
> > that for years.
>
> After examining the headers of many of the spam advertisments I get
> and trying to contact the administrator of the network it came from I
> find that it is usually futile because the network doesn't exist and
> the IP information is incorrect. I also find that most use false
> sender and reply address informat

Re: email and spam (was: Re: namedroppers, continued)

[John C Klensin]

--On Tuesday, 07 January, 2003 13:33 -0500 Doug
<[EMAIL PROTECTED]> wrote:

>> Doug has rediscovered the idea of closing open mail relays to
> prevent
>> unauthorised use by outsiders sending to outsiders. This was
>> a big thing in the early 90s when email became popular.
> 
> This may seem to be a bit basic for some of the people who
> have worked on this problem for years. My intention was not to
> prove that I had the latest and greatest solution to the spam
> problem. It was to get the ball rolling in an open discussion
> forum and present my ideas on the topic in the hopes that
> someone who knew more than me on the topic would as well.
>...

Ok, Doug.  Let me take a shot at simultaneously explaining the
problem here and  why your suggested solutions are getting such
resistance.  Perhaps a different approach may succeed where
Lloyd's didn't (not his fault, I'm sure).

Almost all of the measures you have suggested have serious
side-effects or critical prerequisites.  In the last analysis,
most of us would rather put up with a little spam than pay the
prices involved.  Others are sufficiently fed up with spam that
they are willing to consider some very radical changes to how we
use email.  But, regardless of how that comes out, the decisions
have been fairly explicit: people have thought of your
suggestions, and others, and their impact, and have made fairly
explicit decisions about preferences.  My comment about X.400 of
a few weeks ago was intended to address those issues, but
apparently made a reference too far in the past, or too subtle,
for some of the people who have been participating in the
discussion.

The people who have been through it are reluctant to start the
discussion again because the dead horse has been kicked into an
unrecognizable pulp. There has been a good deal of discussion,
in many archives, that it would be good for you to read.  If you
then come up with a _new_ idea that doesn't revisit the old
problems, many of us would be enthused about listening.  It is
only the old and discredited proposals that are met with
intolerance.

Let me take a closely-related pair of examples from your note.
As I understand it, you would like ISPs (really email providers)
to take responsibility for authenticating their customers.  And
you would like IP addresses shown in mail header traces to be
reliable.  Ok.  Those two things turn out to be much more about
trust relationships than they are about protocols: one can make
major changes to protocols without changing the trust
relationships at all, and can accomplish those things without
any changes in the protocols.  But, assuming that you aren't
willing to trust anyone who can operate a mail-sending protocol,
there are only a few ways that you can trust the source and
origins of email.  

For example, we could, as a society, start licensing email
providers, require each licensed provider to accept mail only
from other licensed providers and from users they can
authenticate (with severe penalties for violating those rules).
That would make folks who would like to go back to business
models in which they charge for every item of mail very happy.
It would make many of the rest of us unhappy.  But it would
work... and, while some protocol enhancements might make it
easier to support, nothing is really required beyond SMTP as it
exists today.

Similarly, you could decide to work with an email mailbox
provider who would refuse to accept mail from any site with
which it didn't have an agreement about user authentication and
traffic and which, were relaying permitted, would insist that
any site from which it accepted a relayed message impose the
same requirements on its users.  With some prototype agreement
forms, this could be a way to build up a trust web similar to
the licensing one, using a web of bilateral agreements rather
than governmental action.  

But either of those approaches would result in less legitimate
mail getting through.  For instance, I run my own mail servers
and, as far as I know, can authenticate anyone who originates
mail here.  But I have neither the resources nor the inclination
to participate in a large collection of bilateral contractual
agreements, nor to start applying for licenses.

The issues with those bad IP addresses are similar.  Most are
spoofed.  You can trust the information in Received headers only
as far back as the last mail host you trust to report
information accurately.  If there is a spammer deliberately
deciding to deceive you, anything earlier is likely to be trash,
not because the wrong information is in the Whois tables, but
because the data in the Received fields is being made up (either
at random or in the hope of pinning the spam on someone else).
And, again, formalizing  the trust relationships through
contracts or licenses would help a great deal, and might be the
only solution, but those options carry a high price in terms of
generally accessibility and usability of email.

regards,
john

p.s.

>

Re: email and spam (was: Re: namedroppers, continued)

[jfcm]

Dear John,
I am afraid that at this stage (e-mail + 40 or so years) telling someone to 
read the archives has no meaning. And telling him to post if he has a 
_new_idea either.

Could we not think of an FPS (frequently proposed solutions) where each 
defeated "solutions" would be listed and quickly discussed. There would be 
two good reasons:

1. to provide a true list of what has been proposed. It would save time to 
all and provide a good negative check list for those with an idea. At least 
it would be new to the FPS: it would be added or used.

2. very often the roots of the true solution is something which has been 
half thought and overlooked. Or something triggered in someone's mind by 
another idea.

jfc

PS. From what you quote, you seem to consider that SPAM=spoofing? Are there 
statistics and trends about that?



On 00:22 08/01/03, John C Klensin said:

--On Tuesday, 07 January, 2003 13:33 -0500 Doug
<[EMAIL PROTECTED]> wrote:

>> Doug has rediscovered the idea of closing open mail relays to
> prevent
>> unauthorised use by outsiders sending to outsiders. This was
>> a big thing in the early 90s when email became popular.
>
> This may seem to be a bit basic for some of the people who
> have worked on this problem for years. My intention was not to
> prove that I had the latest and greatest solution to the spam
> problem. It was to get the ball rolling in an open discussion
> forum and present my ideas on the topic in the hopes that
> someone who knew more than me on the topic would as well.
>...

Ok, Doug.  Let me take a shot at simultaneously explaining the
problem here and  why your suggested solutions are getting such
resistance.  Perhaps a different approach may succeed where
Lloyd's didn't (not his fault, I'm sure).

Almost all of the measures you have suggested have serious
side-effects or critical prerequisites.  In the last analysis,
most of us would rather put up with a little spam than pay the
prices involved.  Others are sufficiently fed up with spam that
they are willing to consider some very radical changes to how we
use email.  But, regardless of how that comes out, the decisions
have been fairly explicit: people have thought of your
suggestions, and others, and their impact, and have made fairly
explicit decisions about preferences.  My comment about X.400 of
a few weeks ago was intended to address those issues, but
apparently made a reference too far in the past, or too subtle,
for some of the people who have been participating in the
discussion.

The people who have been through it are reluctant to start the
discussion again because the dead horse has been kicked into an
unrecognizable pulp. There has been a good deal of discussion,
in many archives, that it would be good for you to read.  If you
then come up with a _new_ idea that doesn't revisit the old
problems, many of us would be enthused about listening.  It is
only the old and discredited proposals that are met with
intolerance.

Let me take a closely-related pair of examples from your note.
As I understand it, you would like ISPs (really email providers)
to take responsibility for authenticating their customers.  And
you would like IP addresses shown in mail header traces to be
reliable.  Ok.  Those two things turn out to be much more about
trust relationships than they are about protocols: one can make
major changes to protocols without changing the trust
relationships at all, and can accomplish those things without
any changes in the protocols.  But, assuming that you aren't
willing to trust anyone who can operate a mail-sending protocol,
there are only a few ways that you can trust the source and
origins of email.

For example, we could, as a society, start licensing email
providers, require each licensed provider to accept mail only
from other licensed providers and from users they can
authenticate (with severe penalties for violating those rules).
That would make folks who would like to go back to business
models in which they charge for every item of mail very happy.
It would make many of the rest of us unhappy.  But it would
work... and, while some protocol enhancements might make it
easier to support, nothing is really required beyond SMTP as it
exists today.

Similarly, you could decide to work with an email mailbox
provider who would refuse to accept mail from any site with
which it didn't have an agreement about user authentication and
traffic and which, were relaying permitted, would insist that
any site from which it accepted a relayed message impose the
same requirements on its users.  With some prototype agreement
forms, this could be a way to build up a trust web similar to
the licensing one, using a web of bilateral agreements rather
than governmental action.

But either of those approaches would result in less legitimate
mail getting through.  For instance, I run my own mail servers
and, as far as I know, can authenticate anyone who originates
mail here.  But I have neither the resources nor the inclin

Re: email and spam (was: Re: namedroppers, continued)

[John C Klensin]

--On Monday, 13 January, 2003 17:23 +0100 jfcm <[EMAIL PROTECTED]>
wrote:

> Dear John,
> I am afraid that at this stage (e-mail + 40 or so years)
> telling someone to read the archives has no meaning. And
> telling him to post if he has a _new_idea either.

You are entitled to your opinion.  I was only trying to suggest
that people who come to the IETF list, and propose the same old,
failed, ideas as if they had just received a relevation from on
high are likely to get some resistance... and to explain that
resistance.

> Could we not think of an FPS (frequently proposed solutions)
> where each defeated "solutions" would be listed and quickly
> discussed. There would be two good reasons:
> 
> 1. to provide a true list of what has been proposed. It would
> save time to all and provide a good negative check list for
> those with an idea. At least it would be new to the FPS: it
> would be added or used.
> 
> 2. very often the roots of the true solution is something
> which has been half thought and overlooked. Or something
> triggered in someone's mind by another idea.

Variations on this idea have been proposed to the IESG and IAB
several times, and have not gone anywhere.  I'll leave
explanations as to why to someone else, but  at a minimum, there
has been a shortage of volunteers to maintain a "dumb ideas
archive" (I know, that isn't quite what you said) and a shortage
of entities willing to shield such volunteers from liability.

> PS. From what you quote, you seem to consider that
> SPAM=spoofing? Are there statistics and trends about that?

There is certainly non-spoofed spam, including the many
materials that claim one has subscribed to an opt-in list or and
others that claim they are conformant to some law which never
passed.  I don't have any statistics that go beyond the
anecdotal.  But, if you look at the mass e-mailing software
packages that are frequently advertised (not exclusively by
spam), most of very proud of their capabilities to hide actual
message origins and to use the facilities of others as relaying
in supposedly-undetectable ways.  Similarly, as Doug and others
have observed, spam often comes with headers that are
sufficiently spoofed to make addresses and other data useless.
I assume --but cannot prove-- that all of these symptoms are
indications that spammers know that messages that use consistent
and accurate origin information are easily filtered out and
discarded and that most ISPs have terms and conditions of
service that prohibits using their facilities to spam.

regards,
 john