Subject: [Asrg] Re: RMX Records

From: Adam Back <[email-masked]>
Date: Tue, 4 Mar 2003 00:08:07 +0000

Hadmut Danisch wrote:
> Even when I'm on the road and using a foreign ISP on the other side
> of the world, I always drop my email to the very same relay machine,
> simply because thats easier. My notebook doesn't need to bother with
> DNS queries and temporarily unavailable peers.  I drop all my
> outgoing mail to central host, and this host is doing the job.

That doesn't generally work because the mail hub will tend to reject
mail so sent because you're coming from a different ISP.  eg. sales
person uses aol.com, eartlink.net (or other international ISP) drops
of mail at mail.foo.com mail hub, and if the mail hub isn't vulnerable
to the open relay problem, it will reject the mail.

The other problem with RMX is that it relies on DNS which itself has
horrendous security vulnerabilities due to inherent limitations in the
protocol.  RMX inherits them and so is inherently easy to spoof and
bypass.  See for example: http://www.securityfocus.com/guest/17905
for a good survey paper on DNS vulnerabilities.

Also I'm not sure as another poster noted how much it even helps:
disposable ISP free accounts (AOL CD syndrome) are a major source,
with RMX the problem is not even improved.

Adam
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 4 Mar 2003 10:28:39 +0100

> to the open relay problem, it will reject the mail.

Hmm, I silently presumed that everybody is aware that we don't
have an open relay. The machine supports several kinds of
authentication through STARTTLS and SASL. You can drop mail only
if you authenticated before. 

(I don't even use SMTP to drop my mail. All mail sent from home
(DSL with dynamic IP) or when I'm on the road is exchanged with
the central Mail hub through BSMTP/UUCP over SSL. That's much 
faster, more secure and more robust than plain SMTP.)

> for a good survey paper on DNS vulnerabilities.

Agreed, but we won't get rid of DNS here, and in context of 
mail transfer we need DNS anyway. Fixing the security problems of 
DNS is the task of another IETF working group. We shouldn't try
to improve the whole world, but focus on spam.

> with RMX the problem is not even improved.

I don't see the problem. If anyone uses such a CD, she is still 
limited to the aol domain and can't send e.g. as @hotmail.com or
@danisch.de. 

Furthermore, I see the end of the AOL CD era coming for several
reasons. First is, that people are throwing their modems and 
ISDN cards away and are running to have a DSL account. Sales
of modems and ISDN cards have dramatically decreased. That's the
end of those AOL CDs.

Second is, under german - and I believe under european - law 
ISPs are required to state their customers identity. I guess
the same will come in the USA after 9/11. It will become
more and more difficult to have anonymous access to the internet.

Third, when a thing like RMX comes to fly, anonymous customers
will have to find a RMX covering the AOL addresses in order to 
send spam. There will be very few domains doing so, maybe just
aol.com. If AOL goes on with supporting spam, they will be 
blacklisted (which is effective in this case). They will have
to solve the problem.

regards
Hadmut

---

From: Roland <[email-masked]>
Date: Tue, 04 Mar 2003 10:26:00 +0000

> if you authenticated before. 

I think we can safely assume the wide availability of authenticated
ESMTP for everybody within the next years, even if its just based on
plain old pop-bevore-smtp.
It's basically the lack of authenticated ESMTP (and capable clients)
which forced ISP's to limit relaying to their own dialup-range.
Some also want the revenue generated from pay-by-call, but thats
covered in the (limited-)service-agreement.

Any company doing business via the internet should provide a secure
SSL/TLS-capable smarthost for security reasons anyway, and this will
be likely at the MSA-port 587 so port 25 blocks at the isp will have
no effect.

> to improve the whole world, but focus on spam.

Bulkers need to spew out millions of mails, they would need to poison
thausands of nameservers which is simply not feasible.
Such harmful manipulations are already covered by the laws in many
countries, and there are more secure alternatives to bind available.
 
> limited to the aol domain and can't send e.g. as @hotmail.com or

Those freemail-services (I'll include AOL here...) are not any major
source of spam, its all the open relays and the dedicated spamhauses
which _pretend_ to come from there. Thats where RMX comes into play.

And an AOL-dialup simply has not enough bandwidth to be useful via
open proxies where a copy of the spam has to be sent individually
to each targeted server.
Spamming via open relays only required 1% of the bandwidth, but they
are mostly gone or too widely blocked to be useful anymore.

Roland

---

From: Adam Back <[email-masked]>
Date: Tue, 4 Mar 2003 19:22:02 +0000

On Tue, Mar 04, 2003 at 10:26:00AM +0000, Roland wrote:
> Hadmut Danisch wrote:
> > Fixing the security problems of 

I think you are have not looked at DNS security issues.  It is far
easier to exploit and the cost can be amortized over many messages.
Read the paper I quoted:

http://www.securityfocus.com/guest/17905

It summarises a many of the known vulnerabilities and shows the
limitations to what an implementation can do without changing the
protocol.

On the risks associated with DNS security for the RMX application,
consider:

a) the sender knows when the SMTP server will make the DNS request (he
just injected the mail) so he can send a flurry of DNS UDP response
packets to arrive before the real response;

b) the sender can choose the TTL on his forged DNS response, making it
last for weeks;

c) during this time he can spam at full volume.

> countries, and there are more secure alternatives to bind available.

I don't see law being any significant barrier to spam.  There are too
many jurisdictions, too many opportunities for spammers to hide their
identities, and too much money involved for it to be a deterrent; and
anyway introducing laws into internet protocols invites hamfisted
politicians to introduces laws generally to the detriment of internet
users who are still poorly represented.

Hadmut claims this is not a problem because we can leave fixing DNS to
the IETF:

> Fixing the security problems of DNS is the task of another IETF
> working group. We shouldn't try to improve the whole world, but
> focus on spam.

but basing a supposed fix on a heavily broken protocol, with no known
solution without replacing the entire protocol, and big deployment
problems in doing that in a backwards compatible way, and a long
history of failure to deploy DNSSEC a backwards compatible and
incremental improvement introduces more problems than it fixes.

I think the deployment path is the most difficult challenge of
anti-spam measures.  Adding a dependency on another hard tech problem
with a yet unsolved deployment path doesn't solve the problem.

Adam

---

From: Adam Back <[email-masked]>
Date: Tue, 4 Mar 2003 20:00:27 +0000

On Tue, Mar 04, 2003 at 10:28:39AM +0100, Hadmut Danisch wrote:
> Adam Back wrote:

The problem is forcing everyone to jump through the hoop of having
valid RMX records does not stop spam.  

It just stops people sending mail from addresses without RMX records
delegating that they are allowed to (which incidentally breaks a lot
of existing functionality).

So already there is commonly some Received header giving the
information about who sent the mail.  That From headers may be
slightly harder to forge under RMX doesn't change the problem.

The problem is that spammers systematically abuse ISP AUPs.  The ISPs
already have AUPs, they already routinely correlate spam attacks to
given users and terminate accounts.  RMX does _nothing_ about spam
other than offer another route to tracing the ISP.  It also has the
unrelated and tangential effect of making certain types of forgeries
harder / breaking some times of existing functionality (where the
"forgery" is the functionality -- making the From address your desired
Reply-To: all mail I've sent for the last 5 years has been of this
form).

We know from long experience that laws, and after the fact enforcement
of AUPs don't solve the problem.  That is the status quo.

> more and more difficult to have anonymous access to the internet.

And this is a bad thing for end-users.  

Your approach to slowing spam is to punish end-users by stripping them
of privacy, and the convenience of trial-offer CDs from ISPs.

> Third, when a thing like RMX comes to fly, anonymous customers will
> have to find a RMX covering the AOL addresses in order to send
> spam. There will be very few domains doing so, maybe just
> blacklisted (which is effective in this case). They will have to
> solve the problem.

So how will anyonymous users who want anonymity for privacy send mail
in this world.

Adam

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 4 Mar 2003 21:24:10 +0100

> of privacy, and the convenience of trial-offer CDs from ISPs.

That's not my approach. That's my observation and guess.

> So how will anyonymous users who want anonymity for privacy send mail

Please specify what exactly you're talking about. Are you talking 
about pseudonyms, forged addresses, remailers or what?

- Being anonymous can't mean to be able to forge/adopt a foreign
  E-mail address or abuse a foreign domain. I do respect your
  wish to communicate anonymously, but I don't accept that you 
  can pretend to be [email-masked] to do so.

- You're still free to use an anonymous remailer/pseudonym server. 
  If mail comes from that server it will be something like
  [email-masked]  It's my decision to accept this or not.

- Your right to send anonymous e-mails doesn't include my 
  duty to accept it and to make my infrastructure available for 
  this on my expense.

  Your right to use anonymous communication corresponds with 
  my right to decide whether I want to participate or not.

  And I do not want to receive anonymous e-mail, at least not to 
  my normal e-mail address. 

  Freedom of anonymous communication is nice, but it can't be 
  a matter of the initiator only. The callee must agree to 
  participate in anonymous communication.

- You're still free to buy a 10$ domain  foobardomain.org and 
  to have a 0/0 RMX record, thus allowing anyone on the world
  to use [email-masked] . Maybe lots of MTAs will accept such
  mail. My one wouldn't.

regards
Hadmut

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 4 Mar 2003 13:29:53 -0700 (MST)

> From: Adam Back <[email-masked]>

> ...

No, the status quo involves lots of spam, but not from ISPs that have
strongly anti-spam AUPs and bother to really enforce them.  (A strong
anti-spam AUP is not one that says "send as much spam as you want for
a couple business days and then buy a new throw-away account."  One
that says "send spam and your financial knee-caps will be destroyed
by our lawyers" is strongly anti-spam.)

Demonstrations of how laws can work are the very successful recent
U.S. state laws against telemarking.

> ...

All of the authentication anti-spam efforts are based on the mistaken
notion that ISPs cannot know their own customers and exact a pound or
two of flesh for bad behavior.
That notion is incredibly silly if you've paid the least attention to
history.  For example, Ma Bell knew a lot less about its pay phone
customers, but nevertheless managed to keep "phone phreaking" under
better control than AT&T, MCI/UUnet, and Sprint have controlled their
own spammers.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Gary Feldman" <[email-masked]>
Date: Tue, 4 Mar 2003 16:13:50 -0500

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Adam Back
> Sent: Tuesday, March 04, 2003 3:00 PM

> The problem is forcing everyone to jump through the hoop of 
> having valid RMX records does not stop spam.  
> 
> It just stops people sending mail from addresses without RMX 
> records delegating that they are allowed to (which 
> incidentally breaks a lot of existing functionality).

Surely it is clear by now that a single technical solution
isn't going to stop spam outright, but rather will be part
of a larger picture.  It is also clear that since existing
functionality is what enables spam, it will have to change.

I no longer accept "breaks existing functionality" as a
bulletproof objection.  The stock reponse is what is the underlying
requirement, and how can that requirement be met in the context
of a spam-preventing email system?  If the requirement
can be met some other way, then the objection disappears.

Gary

> So how will anyonymous users who want anonymity for privacy 
> send mail in this world.

Currently, anonymous means "can't find a responsible party."
That is unacceptable.  The way to achieve anonymity, as
already suggested, is to work with a responsible third-party
willing to assume responsibility.

Gary

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 4 Mar 2003 15:59:51 -0700 (MST)

> From: "Gary Feldman" <[email-masked]>

> can be met some other way, then the objection disappears.

That is true only provided you still meet the design goals served by
the existing solutions.  "Solutions" that are too much work or don't
support easy mail among strangers are irrelevant.  Recall the
telemarketing (non-)solutions that would be perfect, if only you could
force all of your callers to jump through hoops such as DTMF passwords.

Even if you do find a solution that meets the design goals, you can't
force the market to accept your solution.  Your new solution must be
enough better to make people change.  That is a very high barrier.

> willing to assume responsibility.

No, almost all spam already has a responsible party that could be
found if only those responsible for keeping records would meet their
existing responsibilities.  No third parties are needed or could do
anything but make things worse.  All ISPs could know their customers.
Open relays and open proxies could be closed or have good logs.  ISPs
hosting spammers could know their customers.  Telephone companies
serving spammers that advertise only their telephone numbers know
their customers, the spammers.  Essentially no spam lacks a pointer
to the responsible party.  (Yes, I know about "joe jobs" as well as
some religious, political, and "kook" spam that lacks such pointers.)

On the other hand, no third party can guarantee anyone's identity at
a price that mail senders or recipeints could afford.  Verifying that
someone is who they say they are costs a lot more than the $350 that
Verisign charges for a certificate, as demonstrated by the Microsoft
certificate they issued.

Back on the first hand, in practice the credit card numbers used to
buy ISP services are good and sufficient proofs of identity.  If they
were not, then no Internet or any credit card commerce would be
possible, because there would be too much credit card fraud.

The only reason some (but not all!) ISPs don't know their customers
and don't exact penalities from spammers sufficent to deter almost all
spam is that it's cheaper or more profitable to support the spammers.

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 5 Mar 2003 00:34:18 +0100

On Tue, Mar 04, 2003 at 03:59:51PM -0700, Vernon Schryver wrote:
> the existing solutions. 

Insecurity and forgeability have never ever been a design goal
of SMTP. That's a disadvantage, but not a design goal. It has also 
never been a design goal of telnet to make plaintext passwords
available to eavesdroppers.

We cannot fix any security hole as long as we insist on still
fulfilling a so called "design goal" which states insecurity.

Keep in mind the SMTP as we know it was designed more than 20 years
ago (Jon Postels RFC 821 dates from August 1982). In 1982 and before, 
there were almost no security considerations in context of internet
protocols, especially for e-mail. The security business developed in
the 90's. Plain SMTP is one of the last dinosaurs of the pre-security 
era still alive. 

Security didn't play any role in the design of SMTP. Even if it did,
after more than 20 years of progress in internet protocols and
security, such an age-old design goal would require some revision. 

So that so called "design goal" is neither existing nor really relevant.

Hadmut

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 4 Mar 2003 17:08:59 -0700 (MST)

> Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23])
> 	by calcite.rhyolite.com (8.12.8/8.12.8) with ESMTP id h24NZ8im005746
> 	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL)
> 	for <[email-masked]> env-from <[email-masked]>;
> 	Tue, 4 Mar 2003 16:35:10 -0700 (MST)
> Received: from sodom (uucp@localhost)
> 	by sklave3.rackland.de (8.12.8/8.12.8/Debian-1) with BSMTP id h24NZ7i3024946;
> 	Wed, 5 Mar 2003 00:35:07 +0100
> Received: from sodom.home.danisch.de (localhost [127.0.0.1])
> 	by sodom.home.danisch.de (8.12.8/8.12.8/Debian-1) with ESMTP id h24NYIuB018298
> 	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
> 	Wed, 5 Mar 2003 00:34:18 +0100
> Received: (from hadmut@localhost)
> 	by sodom.home.danisch.de (8.12.8/8.12.8/Debian-1) id h24NYI2q018296;
> 	Wed, 5 Mar 2003 00:34:18 +0100
> From: Hadmut Danisch <[email-masked]>

> of SMTP. That's a disadvantage, but not a design goal.

That is wrong if asked and answered honestly.  Of course "insecurity"
and "forgeability" have not been design goals, but "receiving mail
from strangers" has been a goal.

Authentication is not magic pixie dust that can be sprinkled over a
protocol.  Authenticating strangers is nonsense.  A stranger is someone
you don't know, including don't know he is not a bank robber, spammer,
your long lost uncle, or all three.

Contrary to your implicit claim, sending from one IP address with a
different return IP address has always been a design goal.  Sending
from one domain name with a return address in another domain has always
been an explicit design goal at least as far as the Reply-To header
is concerned.  That the Sender header exists, suggests that differing
SMTP client reverse DNS domaon name and Mail_From values has been a
goal.  For at least 15 years allowing such mismatches have been a
practical requirement.  

Requiring that the reverse DNS domain name matches the Mail_From domain
name is as wrong aad silly as it would be to requirer that when you
send a picture postcard while on vacation you use your current hotel
as your return address.  Neither requirement would reduce fraud, spam,
or anything else that is bad.

There are reasons why large ISPs would like to impose such a requirement.
The instant messaging battle between AOL and Microsoft demonstrates
why they would like it and why reasonable people oppose it.

Whether sklave3.rackland.de authenticates mail from sodom.home.danisch.de
with a Mail_from value of [email-masked] tells no one outside
whether you are a spammer.  On the other hand, if you were a spammer,
it would be trivial to finger you by contacting the operators of
213.133.101.23 or if necessary 213.133.96.29, 213.133.96.65, or
212.114.147.1.

Since both sklave3.rackland.de and calcite.rhyolite.com are running
SMTP-TLS, your mail could have been authenticated, if only my system
had a certificate.  But that certificate would not tell me or my
system anything that I don't already know or would need to know about
whether your mail is spam.

If mail.rackland.de also runs SMTP-TLS and if you check its logs, you
will probably find that some spammers are also using SMTP-TLS.

>          That's a disadvantage, but not a design goal. 

That authentication is nonsense when receiving mail from strangers
is an unavoidable disadvantage of the design goal of receiving mail
from strangers.

>                                                        It has also 

That's irrelevant noise.

> fulfilling a so called "design goal" which states insecurity.

Stated honestly, that is true.  Indeed, we cannot fix security
holes that are implicit in the design goals without changing
the design goals.

If your design goals imply a protocol that authenticates senders, then
use SMTP-AUTH, STMP-TLS, SMIME, PGP, or others.  They are all widely
available and work fine.  However, they are also useless and irrelevant
for a general mail protocol among strangers.

> So that so called "design goal" is neither existing nor really relevant.

That is various quite wrong and entirely irrelevant.

---

From: "Gary Feldman" <[email-masked]>
Date: Tue, 4 Mar 2003 20:57:33 -0500

> Behalf Of Vernon Schryver
> Sent: Tuesday, March 04, 2003 7:09 PM

> That is wrong if asked and answered honestly.  Of course 
> "insecurity" and "forgeability" have not been design goals, 
> but "receiving mail from strangers" has been a goal.

That may have been the goal twenty years ago, but today the goal
must be reformulated, perhaps as "receiving personal email
from strangers must be possible for those who wish to receive
such mail"

> Contrary to your implicit claim, sending from one IP address 
> with a different return IP address has always been a design 
> goal.  Sending from one domain name with a return address in 
> another domain has always been an explicit design goal at 
> least as far as the Reply-To header is concerned.  That the 
> Sender header exists, suggests that differing SMTP client 
> reverse DNS domaon name and Mail_From values has been a goal. 

Ultimately, requirements translate into user requirements, not
some technical point.  Phrasing them technically as above
tends to obscure the real requirements.

So, for example, the real requirement is to be able to send
mail from one authorized address with a return address being
another authorized address, "authorized" being the operative
word.  Or it's the ability to run mailing lists with
reasonable "From" addresses, and a choice (at the list server 
level) between having the default reply go back to the sender
or to the list.

I do not believe that it was ever a requirement to have
the ability to send an email with a return address one had
no right to use, and even if it were, it is not a requirement
now.  Requirements phrased in terms of IP addresses are only
justifiable when rephrased and analyzed this way.

> Requiring that the reverse DNS domain name matches the 
> Mail_From domain name is as wrong aad silly as it would be to 
> requirer that when you send a picture postcard while on 
> vacation you use your current hotel as your return address.  
> Neither requirement would reduce fraud, spam, or anything 
> else that is bad.
 
While that's often done, the real requirement is that the 
sending computer have the authorization to send on behalf
of the purported (i.e. mail_from) domain  -- or perhaps 
it needs to be at the user level or some other granularity).

However, let me observe that a significant proportion of the
spam I receive can be rejected on the reverse DNS basis, while 
only a tiny proportion of legitimate mail would result in a false
positive.  So, while it's far from perfect, I don't agree
with your conclusion that it doesn't reduce spam, based on 
my own personal empirical evidence.

Gary

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 04 Mar 2003 16:21:35 -0500

"Gary Feldman" <[email-masked]> wrote:
> ... today the goal must be reformulated, perhaps as "receiving
> personal email from strangers must be possible for those who wish to
> receive such mail"

  I'm not sure I agree.

  If my ISP is under serious attack from spammers, then some level of
"good" mail will probably be thrown out with the spam.  The only way I
know of to guarantee that no "good" mail is thrown out, is to not
throw out *any* mail.

  This is unacceptable.

  We have to decide what level of spam we can live with, and what
level of false positives we can live with in anti-spam filters.  If
lowering the false positive rate by 2% increases the amount of spam by
10x, then that solution doesn't scale.

> now.

  I agree.

  Alan DeKok.

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 4 Mar 2003 21:46:33 -0500 (EST)

> know of to guarantee that no "good" mail is thrown out, is to not

Or to have a human sort it out.

> 10x, then that solution doesn't scale.

Yes, but the "we" in "we have to decide" should be we, the end users,
not some ISP.

Automatic filters will get you so far, maybe up to 90-98% accuracy,
depending on which filter you use and what your mail mix looks like.
But they do run out of gas, and if you can't accept false positives,
then the only solution is human sorting.  You just have to figure out
(1) how to do the human sorting as cheaply as possible, and (2) how
much you're willing to pay for human sorting.  That determines the
filter settings you use.

--
David.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 4 Mar 2003 22:05:04 -0500

>Or to have a human sort it out.

It's not clear to me that human sorting would be reliable to the 
extent you are implying.  Especially third party human sorting.  But 
I've come real close to replying to some messages that looked 
perfectly fine to me.  The information that flagged them as spam was 
not the content, but details about the path they took, how many 
people they went to, and other things that a human observer could not 
determine.  But in any case, it's not clear what this means in an ISP 
context.  Companies may find it necessary to hire a human to filter 
borderline messages that an automatic filter is unsure of, but in the 
ISP context, false positives do not have a simple 
solution--especially since an ISP is not likely to be able to afford 
(in terms of processing time and resources) the degree of end-user 
customization that an enterprise might (and I seriously doubt any of 
us want ISPs reading our email).
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 4 Mar 2003 20:46:15 -0700 (MST)

> word. ...

That use of "authorized" is more of the same but worse, because it is
involves a misuse of technical jargon.  The problem is that it
"authorized" is meaningless in this case.  This is not a mere technical
quibble.  You cannot "authorize" some but only some strangers.  It is
as impractical (and undesirable in the larger context) for an ISP in
China to check that a user is "authorized" to use a return address in
the U.S. as it is for a hotel in China to check to see if a guest is
"authorized" to use a U.S. return address on a picture postcard.

Or to get closer to home and recent headlines, for a Hotmail user to
use an AT&T return address.

> it needs to be at the user level or some other granularity).

Yes, and the trouble is that in practice that cannot be implemented
without the forcing users to use return addresses matching their
sending IP addresses.

> my own personal empirical evidence.

My own empirical evidence and the evidence of others who object
more to not receiving legitimate mail than to receiving junk is
the opposite.  However, I bet the numbers we are talking about are
the same.   I bet your "tiny proportion" is several percent.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 4 Mar 2003 20:55:18 -0700 (MST)

> From: "Alan DeKok" <[email-masked]>

> "good" mail will probably be thrown out with the spam.

That's wrong, unless mail is a mere frill or recreation for you.

>                                                         The only way I

It is also an overstatement.  My personal set of filters have a false
positive rate of much less than 0.1% or about the normal failure rate
of email.  They have a false negative rate of less than 1%.  Plenty
of spam is sent my way, because I've been exposing my current address
in public for more than 10 years.

> 10x, then that solution doesn't scale.

People whose livelihoods depend on mail cannot, will not, and do not
accept false positive rates above 1%.  That you can talk about changing
the false positive rate by 2% brands you as outside that class.
There's certainly nothing wrong with not depending on email for the
butter on your bread (or your bread), but beware of assuming that
everyone else is the same.

Note that people who do depend on email and cannot tolerate 1% false
positives are like business flyers.  They are the most profitable
customers for many ISPs.  That means that many ISPs have similar
views of false positives.  There are other ISPs, but they cater to
"home users."

---

From: "Derek J. Balling" <[email-masked]>
Date: Tue, 4 Mar 2003 22:56:32 -0500

> use an AT&T return address.

I think it's perfectly fair, though, for $DOMAIN_HOLDER to be able to 
say "if it's coming from $HERE, we're willing to vouch that it's 
someone who at least has some moderate claim to be from $DOMAIN.

Think of it more as "designating" IPs as "belonging to this domain", or 
"vouching for them" rather than authorization.

> without the forcing users to use return addresses matching their

Not at all. It requires them to use IP addresses which their 
domain-holder has vouched for.

Nothing would stop me from using my rr.com host to send megacity.org 
mail, so long as the admin of megacity.org was willing to say "if it's 
coming from $THERE, it's ok".

D

---

From: Troy Rollo <[email-masked]>
Date: Wed, 05 Mar 2003 15:10:44 +1100

At 10:56 PM 03/04/2003 -0500, Derek J. Balling wrote:
>Nothing would stop me from using my rr.com host to send megacity.org mail, 
>so long as the admin of megacity.org was willing to say "if it's coming 
>from $THERE, it's ok".

This breaks automated forwarding.

--
Troy Rollo			Chairmain, CAUBE.AU
[email-masked]		Executive Director, iCAUCE

---

From: "Derek J. Balling" <[email-masked]>
Date: Tue, 4 Mar 2003 23:15:22 -0500

On Tuesday, March 4, 2003, at 11:10 PM, Troy Rollo wrote:

>> mail, so long as the admin of megacity.org was willing to say "if 
>> it's coming from $THERE, it's ok".
>

Couple solutions to that, most of which are documented pretty well in 
Gordon's proposal ( 
http://www.pan-am.ca/draft-ietf-asrg-dsprotocol-00.txt ).

And it only breaks it if the recipient rejects it. It could just as 
easily use that as part of a scoring system like SpamAssassin, etc.

D

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 4 Mar 2003 21:31:12 -0700 (MST)

> From: "Derek J. Balling" <[email-masked]>

> "vouching for them" rather than authorization.

If the "IP address here" refers to Hotmail's IP addresses in that
example, then there's no sense in worrying whether Hotmail has authorized
the Hotmail user to send the message.  If the "here" is some IP address
associated with the AT&T domain name that used by the Hotmail user as
a return address, then it is between nonsensical and impractical.

It will never be practical for Hotmail to ask AT&T "is my user who
I think is John Doe living at [refused] in [refused] USA authorized
to use [email-masked]?"

Even if John buys the premium Hotmail service and gives Microsoft
his credit card number as well as his address, date of birth,
mother's madian name, and his favorite pet's name, he would not want
Microsoft to send enough of that to AT&T to identify him to AT&T so
that AT&T could say "yes, he is authorzed use [email-masked]."

Yes, there are cryptographic protocols that in theory could resolve
that, but in practice they are unworkable for various reasons.
An important reason is that they require either an absolutely
intolerable central identity authority for all all of us, or they require
more shuffling of individual public keys than people can or will tolerate.

A more important reason is that it solves a minor problem.  Most
spammers use return addresses that they are authorized to use.  Only
a little spam uses envelope or header From addresses that can honestly
be called "forged."

> coming from $THERE, it's ok".

That handwaving and designing wishful thinking that cannot be made
concrete except in uninteresting special cases, no matter how often
it is repeated in news.admin.net-abuse.email.

---

From: Troy Rollo <[email-masked]>
Date: Wed, 05 Mar 2003 15:34:37 +1100

At 11:15 PM 03/04/2003 -0500, Derek J. Balling wrote:

>Gordon's proposal ( http://www.pan-am.ca/draft-ietf-asrg-dsprotocol-00.txt ).

Actually it says "Another document will identify similar problems and 
solutions, including mail forwarding services and the Null Sender envelope 
(MAIL FROM:<>)."

The problem is that this approach assumes that the only significant reason 
mail with a given domain can come from a location not in a pre-authorised 
set is that it's spam. I would submit that there are many more common 
reasons for mail coming from an unexpected source - forwarding just being 
an immediately obvious one.

Even for forwarding, authorising the re-sending host at the receiving end 
requires at its best that the user provide this information (perhaps by 
means of some web based form) to the receiving ISP, and assumes that:

         (1) The user can get it right.
         (2) The user has access to all of the relevant information.
         (3) That the user knows within a reasonably short period (
             or preferably in advance) when the information changes.

None of these is a particularly good assumption.
--
Troy Rollo			Chairmain, CAUBE.AU
[email-masked]		Executive Director, iCAUCE

---

From: "Gordon Fecyk - Home" <[email-masked]>
Date: Tue, 4 Mar 2003 23:15:21 -0600

> solutions, including mail forwarding services and the Null Sender envelope

It was strongly suggested to deal with that in another document to avoid
clouding the problem that draft tries to tackle.  The above doc deals with
secondary MXes only because they're the most popular thing that DS is going
to break.

> set is that it's spam.

Actually, it assumes the only reason mail with a given domain is not from an
authorized location, is that it's simply not authorized.  Wether it's spam
or not isn't immediately relevant, aside from the indirect fact that a good
chunk of spam has fake envelopes.  This protocol could also break e-mail
worms since the majority of those fake the sender envelope.

Mail forwarding is going to break no matter what proposal is adopted to
prevent domain spoofing.  I wanted to write another document to address that
very problem, but here's a preview.

Mail forwarders could modify or augment the sender envelope such as
(simplistic example):
	sender(at)[email-masked]

Or, it could replace (or encapsulate) the sender envelope entirely:
	(hash-of-sender-envelope)@forwardingservice.foo.bar

I can hear you all cringing at that.

Null Sender (MAIL FROM:<>) envelopes could be checked further, to ensure
that they come from an actual MTA running on a host, and not from a person,
by checking all kinds of stuff: forward DNS, rDNS, a RMX or DS record, and
whatnot.

I think spoofing's become so much of a problem that mail forwarders will
have to redesign mail forwarding.  I think that's why I've been told not to
tackle the problem in the DS document - because forwarders could come up
with their own ways to deal with it.

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email-masked]>
What's a PGP Key?  See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 5 Mar 2003 08:49:19 -0500 (EST)

On Tue, 4 Mar 2003, Kee Hinckley wrote:

> Companies may find it necessary to hire a human to filter
> solution--

Oh, clearly this is not an appropriate solution for an ISP.  I was intending
it only for a corporate setting.

Spam does not really cost ISP's anything except bandwidth and storage.
They don't care (nor should they) if their end-users are less productive;
that's a worry only for companies.

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 5 Mar 2003 14:26:06 +0000 (GMT)

> that's a worry only for companies.

I hope only someone who has never worked at an ISP would ever say this. 

Spam costs ISPs a lot in admin time, and there are lots of hidden costs 
of spam at an ISP that are very tricky to account for.

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 5 Mar 2003 09:21:49 -0500 (EST)

On Wed, 5 Mar 2003, Matt Sergeant wrote:

> Spam costs ISPs a lot in admin time,

Ah, forgot about that... I guess you have to handle complaints.  Sorry.

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 5 Mar 2003 14:56:17 +0000 (GMT)

> Ah, forgot about that... I guess you have to handle complaints.  Sorry.

Not just complaints. When your queues fill up due to massive spam runs and 
you can't even get your legitimate mail out because it's swamped by all 
the spam, then someone has to go in and manually free up the queues.

This happens a *lot* to us.

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 05 Mar 2003 10:13:56 -0500

Vernon Schryver wrote:

> accept false positive rates above 1%.

We have to remember, however, that the "true" false positive rate isn't 
determined _solely_ by how much legitimate email your filters block, but 
by the amount of legitimate email that doesn't get through.

They may seem to be the same, but it isn't.

A full bore TMDA (all first time email carries a "click this link to let 
the email through") has a 100% false positive rate in the filters first 
go-round. But if the senders follow the instructions, it's 100% delivery 
in the end.  [Presuming it works as it's supposed to, and you don't have 
senders with broken mailers that can't see/display the returns.]

Discussions of false positives has to take into account what you do with 
a reject, and the practises you follow to rectify problems.

Yes, my management would draw and quarter me if our false positive rate 
got above even .01%. It is.  False positive handling is part of the 
insurance to make sure that we eventually do deliver all legitimate email.

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 05 Mar 2003 08:29:43 -0500

> That's wrong, unless mail is a mere frill or recreation for you.

  It's also reality.  The cost of getting 100% accuracy is
prohibitive.

> My personal set of filters have a false positive rate of much less
> than 0.1% or about the normal failure rate of email.

  I thought that's what I was saying...

> the false positive rate by 2% brands you as outside that class.

  I agree completely.  My false positive rate is zero.  As is my false
negative.  As is the total amount of mail I receive at some domains.

  Filtering is a complete waste of time for some domains.  It's
simpler to give up, and walk away from the domain.  If you can live
with filtering, that's nice for you.  But you should also realize that
by some standards, you're not receiving any appreciable amount of
spam.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 05 Mar 2003 08:22:31 -0500

> depending on which filter you use and what your mail mix looks like.

  Automatic filters only work if you're not receiving any significant
amount of spam.

  If you're receiving 100K+ spams a day, then the machines to run the
filters cost a fair amount of money.  Not everyone can afford to spend
$10K on a mailer instead of $2K, just to get legitimate mail through.

  With the spam volume Chris Lewis is saying Nortel gets, I'd be
surprised if their infrastructure costs were less than $100K.
Large companies can afford that.  Small ones can't.

  Alan DeKok.

---

From: "Peter A. Friend" <[email-masked]>
Date: 05 Mar 2003 10:38:13 -0800

> that's a worry only for companies.

Not quite:

1. SA fight spammers literally ALL DAY LONG. Null routes sometimes are
the only thing that will shut a spammer up for a while.
2. The bulk of incoming MX hardware is there because of the massive
cycles that merely accepting connections from spammers incurs.
3. Spammers can potentially delay delivery of valid mail my tying up all
MX resources until the server detects them and spanks them, or an SA
detects them and spanks them.
4. Spam takes up a lot of disk space. One may think that disk space is
cheap, and it is. But, depending on what kind of network attached
storage you use, and how you store your mail, having the spam just
sitting on those disks reduces performance for valid mail.
5. Customer complaints
6. Customer churn (I get too much spam at this ISP)
7. Development resources tied up adding new ways to fight spammers
instead of adding new features.
8. Good SAs that sit there and fight spam all day cost a lot of money.

I could probably go on for days... ;-)

Peter

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 05 Mar 2003 14:42:24 -0500

> by some standards, you're not receiving any appreciable amount of

Alan knows of what he speaks.

See http://striker.ottawa.on.ca

Our spamtrap domains are about as bad:

DATE                    PASS   BLOCK    FILT SPAMTRP     CPT
20030226              297092   33250   16817  970828     191
20030227              316610   31600   11376  820258     211
20030228              262716   33066    8282  825232     190
20030301               83534   24279    6285  709274      56
20030302               88370   22862    5684  923656      86
20030303              282078   34845    9663  822272     374
20030304              297998   27606    9590  866320     149
20030305                   0       0       0  568238     120

PASS = email getting thru (production email)
BLOCK = IP-based blocking (DNSBL and local, production email)
FILT = content filtering (production email)
SPAMTRP = spamtrap domains.
CPT = end-user complaints on what got thru (production email). We 
average one or two complaints per hundred spams that get thru.

The last day only shows complaints and spamtrap so far today.  Don't get 
other three numbers til tomorrow.

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 5 Mar 2003 14:52:19 -0500 (EST)

>   Automatic filters only work if you're not receiving any significant

Delegation is the key.  You delegate spam handling down to the level
that minimizes your cost.  It's not cost-effective for a few people to
handle 100K spams.  It's not cost effective for 20,000 end-users to
handle 50 spams each.  It's probably cheapest for 1000 department-level
clerical people to deal with 1,000 spams each.

Note that you cannot eliminate the cost of dealing with spam.  But
you can minimize it.

> filters cost a fair amount of money.

Nah.  If you're receiving that kind of mail volume, you have big
machines with under-utilized CPUs anyway.  Content-scanning just uses
up CPU cycles that would be wasted.  Nik Clayton says he filters
2 million messages/day with SpamAssassin; I'd be amazed if fewer
than 100K of those are spam.

> Large companies can afford that.  Small ones can't.

Small companies don't get 100K spams/day.

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 5 Mar 2003 14:56:10 -0500 (EST)

> See http://striker.ottawa.on.ca

I have a hard time believing that's typical, except for large
companies and ISP's.

---

From: "Terry Carmen" <[email-masked]>
Date: Wed, 5 Mar 2003 16:25:21 -0500 (EST)

> machines with under-utilized CPUs anyway.  Content-scanning just uses up
> CPU cycles that would be wasted.  Nik Clayton says he filters
> Small companies don't get 100K spams/day.network

Small companies routinely get several hundred, up to several thousand
spams/day.

I found the biggest improvement by blacklisting Korea and China. Mail from
IPs within their netblocks is simply refused. There are a few
South-American countries that I may add next. Using an RBL in-progress
spam attacks and another for open relays has reduced the spam that makes
it through from thousands to only a dozen or so per day.

Unfortunately, this still wastes my bandwidth. Server utilization isn't
really an issue, since even a slow box by today's standards can handle a
huge amount of rejected connections.

Blacklists (fixed and dynamic) are the technological equivilant of
"shunning", and seem to be quite effective if practiced on a widespread
basis. It can range from "If you break our social contract, we will ignore
you", to "we will ignore your network", or even "we will ignore your
region of the earth" if the spam continues.

The trick is to make spamming painful for the network owners, so THEY will
control the spammers. Networks are expensive and nobody wants to own one
that can't talk to anybody else.

At some point in the world of spam, there is a network operator who has
allowed a spammer a connection. This may be an ISP, Network Provider or
simply an open relay. It really doesn't matter. The place where the mail
enters the netwok should feel pain for polluting our space.

Once this happens, spam will again become only a minor annoyance.

Terry

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 5 Mar 2003 17:01:06 -0500 (EST)

> Small companies routinely get several hundred, up to several thousand

That's manageable, and a couple of orders of magnitude less than what
Alan gets.

> I found the biggest improvement by blacklisting Korea and China.

Yes, that works pretty well.  Nigeria and Brazil too.

> Unfortunately, this still wastes my bandwidth.

To the point where you actually have to pay more money?

> enters the netwok should feel pain for polluting our space.

Right; I agree.  And there are ways to do that even now:

- Tempfail suspected spam until it is accepted or rejected by a
person.  This works well for small organizations with spare bandwidth.
It won't work for large organizations, unfortunately, but if enough
small people do it, the open-relay or spam server will feel the pain.
Each recipient will pay for a little bit more bandwidth; the relay will
pay for a lot more bandwidth plus clogged queues.

- Litigate.  The US is lawsuit-happy; even the threat of being sued
would probably make an ISP crack down on spammers or an open relay
mend its ways.

- Blacklist.  If ISP's refuse to play ball, blacklist them.

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 07 Mar 2003 00:42:32 -0500

> it only for a corporate setting.

Eeek!  I don't want to read 50,000 spams per day!

False positives have a very simple solution.  Treat it as the first step 
in a "do something else to get this thru".  Just like confirming a 
mailing list subscription with per-transaction keywords.  Or, "click 
here" to get it through.

In our case, we simply arrange to have the bounces say "if you think 
this was in error, forward this bounce to <x@x>".  Where <x@x> is a 
whitelisted address with people who'll forward/fix mistunings.  It's 
relatively safe - spammers tend not to do that.  And I'm a suspicious 
SOB ;-)

If your filters are good, the FP rate is low.  Our false positive 
handling address averages less than 5 per day.

---

From: "Eric S. Johansson" <[email-masked]>
Date: Sat, 08 Mar 2003 10:53:27 -0500

> Eeek!  I don't want to read 50,000 spams per day!

not to mention that it is a horrible human factors problem.  You want to keep 
users out of the spam trap because the whole point of antispam filter is to keep 
you from seeing spam.

> mailing list subscription with per-transaction keywords.  Or, "click 

classic challenge response systems have a serious problem if the center of the 
message is a robot.  For example, you purchase something on the net, you get an 
invoice from a robot confirming the order and the robot is given a challenge 
message.  You never see the invoice and never will unless you go to your spam 
trap and root around in all the garbage.

As have pointed out elsewhere on the list, I believe a more reasonable solution 
will be a combination of postage stamp plus white list plus spam filter as 
discriminator.  If mail doesn't have a postage stamp, it is passed to the 
discriminator which evaluates the message as spam/unknown/good mail.  Only 
unknown messages are given a postage due or challenge response.  You minimize 
false positives and minimize challenge messages outbound to reduce potential 
annoyance of challenge/postage due messages.

I'm almost done with some reference code on the receive filter.  I'm hoping to 
finish the discriminator integration this weekend.

> handling address averages less than 5 per day.

unfortunately, that's a moving target.  Spam is an economic problem with 
biological characteristics.  Filters create evolutionary pressures and I'm 
noticing spam is evolving to be more and more indistinguishable from real mail. 
  The end result is an increasing false positive rate because the difference 
between good and bad mail will get smaller and smaller.

I believe that most of the techniques people have outlined on this list will 
send us down the same rathole as the virus/antivirus community.  Evolutionary 
pressures creating change which requires yet another revision of the software or 
techniques.  It's a great revenue stream for the anti-<blah> manufacturers but 
it's hell for everyone else.

This is why I believe that we need to hit the spammers in the pocketbook through 
technical solutions.  From what I see, tools like connection grabbers, postage 
stamps, and legitimizing narrow forms of e-mail marketing will have a far 
greater impact than anything proposed so far.

it's a fundamental axiom of animal training that rewarding good behavior 
extremely quickly produces much more rapid change than punishing.  See: "don't 
shoot the dog" by Karen Pryor.  If we can give a legitimate outlet for e-mail 
advertising, a lot of the incentive to spam will be reduced.  Those that remain 
can be punished through negative reinforcement techniques like connection 
grabbing and postage stamps.

---eric

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Mar 2003 11:37:29 -0500

> I have a hard time believing that's typical, except for large

Nobody's suggesting it's typical.  It's just where we're all headed if
we don't put on the brakes.

There are plenty of reports of in-the-ballpark-comparable experiences
with much smaller organizations.

Striker is, admittedly, a far out case, where it looks like a single
spammer malfunction has led to a continuous and unstoppable DDOS.

On the other hand, our spamtrap metrics are what a, say,
long-existing[+] 100,000[*] user company looks like after 18+ months of
turning off the deliverability of the domain. Imagine if it was an ISP
with considerably higher turnover and similarly long life.  100,000
users is a _small_ provider in comparison to moderate to large ISPs...
AOL blocks three and a half orders of magnitude more spam than our
spamtrap represents...

[*] for reasons I won't go into here, what was a 10,000 employee company
probably looked like a 100,000-seat ISP on the Internet in terms of
proliferation of email addresses.  Thank god we got rid of that mess.

[+] long-existing?  Consider: the domain behind that spamtrap was in the
game early enough to get a class A with no questions asked.

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Mar 2003 11:36:53 -0500

Eric S. Johansson wrote:

 >> False positives have a very simple solution.  Treat it as the first
 >> step in a "do something else to get this thru".  Just like confirming
 >> a mailing list subscription with per-transaction keywords.  Or, "click
 >> here" to get it through.

 > classic challenge response systems have a serious problem if the center
 > of the message is a robot.  For example, you purchase something on the
 > net, you get an invoice from a robot confirming the order and the robot
 > is given a challenge message.  You never see the invoice and never will
 > unless you go to your spam trap and root around in all the garbage.

Who said anything about "you" (the recipient)?

Let's say that you purchase something on the web, the robot generates
the invoice, and the robot sees a challenge (or a reject).

What would intelligent engineering of a system that deals with money
suggest?  What would due diligence suggest in the face of the user
typing their email address wrong? Or the recipient mail server being
offline for a bit too long?

Email isn't 100% reliable, entirely aside from spam filtering misfires.
Properly designed systems (ie: those ones that don't get sued for
negligence in handling financial transactions) make allowances for them.

That's right, the reject gets dropped in someone's mailbox on the
sending side, and a human being figures out what to do.  Or something
analogous.

It works.  We get FP reports regarding robots, mailing lists, "trial
software registration systems" and the like all the time.

The "robot" factor is not an issue with properly designed systems. If
they're not properly designed to handle ordinary exceptions, I'd suggest
that doing business with them at all is a bad idea, entirely aside from
whether they can get thru your spam filters.

 > extremely quickly produces much more rapid change than punishing.  See:
 > "don't shoot the dog" by Karen Pryor.  If we can give a legitimate
 > outlet for e-mail advertising, a lot of the incentive to spam will be
 > reduced.  Those that remain can be punished through negative
 > reinforcement techniques like connection grabbing and postage stamps.

This only works when having the dog behave good is the desirable
outcome. I would suggest that, with Stubberfield [*] for example, the
only desirable outcome is an "ex-dog" in Monty Python terminology ;-).

The only way to make Ralsky "behave" is to _promise_ to deliver what he
sends.  Do we really want that?  I don't think so.

[*] Stubberfield is the unstoppable spammer of "teenage girl with horse"
sex videos - seems to relish spamming children with this crap. Or,
consider the guy who spams animated gifs of dogs and um, you know.

---

From: Kee Hinckley <[email-masked]>
Date: Sat, 8 Mar 2003 14:23:51 -0500

At 10:53 AM -0500 3/8/03, Eric S. Johansson wrote:
>classic challenge response systems have a serious problem if the 
>center of the message is a robot.  For example, you purchase 
>something on the net, you get

They also have another problem I haven't seen addressed.  People are 
talking about Turing-test type challenges to prove you are human.  So 
far all the ones I've seen proposed require that you can see.  They 
will not pass federal requirements in the U.S. as they currently 
stand.  And if they get widely deployed outside of the federal arena 
you are certain to see accessibility lawsuits.  Solveable perhaps by 
including both visual and audio prompts, but someone should start 
thinking about it now.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: abuse <[email-masked]>
Date: Sat, 8 Mar 2003 18:38:33 -0800 (PST)

on "3-8-2003" "Kee Hinckley" writ:

: the ones I've seen proposed require that you can see.
: They will not pass federal requirements in the U.S. as they currently
: stand.  And if they get widely deployed outside of the federal arena
: you are certain to see accessibility lawsuits.  Solveable perhaps by
: including both visual and audio prompts, but someone should start
: thinking about it now.

... i lay claim to being the "guy that's blind in one eye, and can't see
out the other".

    what, exactly, are the "fed's" requirements with regard to 'americans
with disabilities' vis-a-vis 'software'.  is that an implication, or a
requirement of the statute.

    the 'threat' of lawsuits in the us is a given, so that something of a
moot point.

    i am at a loss in 'seeing' (sorry) how a 'visual prompt' helpful to
those blind enough to warrent its use ...
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 9 Mar 2003 13:27:47 -0500

>requirement of the statute.

Section 508 "requires all Federal agencies to make electronic
and information technology accessible to people with disabilities".

A number of the challenge/response protocols proposed here (as well 
as those currently in use at Yahoo and other webmail sites, as well 
as at search engines like Google) contain tests whereby you look at 
an image containing non-ocr'able text (typically it's either 
distressed in some way, or has a weird background) and type in the 
text of the word you see.  This assures the sender/presenter that you 
are a human and not a robot trying to spam.  Those won't work if you 
are blind.  As a result I would assert that any challenge/response 
system that uses such a test will not be acceptable to the U.S. 
Government for use in government funded mail software.

I don't know if providing both visual and aural tests would be sufficient.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: abuse <[email-masked]>
Date: Sun, 9 Mar 2003 15:08:57 -0800 (PST)

on "3-9-2003" "Kee Hinckley" writ:

: acceptable to the U.S. Government for use in government funded mail
: software.

... well, that's just too bad.  the way i got it figured, imposing
standards of the government, to solving a problem, the government itself
not serious about solving, counterproductive.

    given the DCMA, 'the patriot act', and the dod's information
gathering activities, government involvement is the last thing i want to
see ...

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 10 Mar 2003 00:58:50 -0500

>not serious about solving, counterproductive.

I'd argue that the problem isn't with the government in this 
particular case (and that's not an argument I usually make), but with 
a challenge-response system that assumes that "human == can-see".

---

From: abuse <[email-masked]>
Date: Mon, 10 Mar 2003 00:32:53 -0800 (PST)

on "3-10-2003" "Kee Hinckley" writ:

: a challenge-response system that assumes that "human == can-see".

... that, is a secondary assumption.  the primary, is one in which the
ability to 'read' made.

    that sounds perposterous (sp et al), howeever, it offers a
fundamental premise.  a certain level of 'experience' is required to use
the offerings of the internet.  those of us with visual 'handicaps' do
what has to be done, to get done, what needs doing.  others of us, may
not have the 'abiilty' or 'willingness' to do that.
    now, 'mandating' a standards 'change' for the benefit of a miniscule
population, who may not even benefit from it, is not a prudent design
decision.  in my opinion, any change in standards is going to offer
minimal long term benefits ...

---

From: "Eric S. Johansson" <[email-masked]>
Date: Tue, 11 Mar 2003 12:40:15 -0500

> the invoice, and the robot sees a challenge (or a reject).

first off, the robot would generate a stamp when it sent the invoice.  That 
would prevent it from getting a challenge.

> offline for a bit too long?

good question.  I would talk to some of my financial cryptography contacts on 
this topic.  My gut senses that if you are using a stamp that is equivalent to 
cash, the money is lost.  Any future communication would require new stamps. 
This is why I like CPU cycles stamps.

As for the other items, you would not get a postage do or challenge message. 
You would get the classic "mail failed" message.  Now it would be nice if we 
could make these messages more understandable by robots so they can handle 
errors better but that is a whole different conversation.

> sends.  Do we really want that?  I don't think so.

those are wonderful examples.  However, they aren't the people we're trying to 
reach.  They are the people we're trying to stop.  I do get lots of "legitimate 
advertising" that I am interested in sometimes.  I just want to manage it 
better.  Those of the people we want to reach and I believe those of the people 
we can influence.  If we raise the various high enough, a bunch of the spammers 
will go away.  The truly hard-core ones will remain and can be targeted because 
the field will be smaller and less noisy.

It's my opinion, it's worth what you pay for it.  ;-)

---eric

---

From: Wilson Roberto Afonso <[email-masked]>
Date: Thu, 13 Mar 2003 22:17:02 -0300

On Sat, 8 Mar 2003 14:23:51 -0500

> including both visual and audio prompts, but someone should start 

I'm a lagging behind on the traffic of this list, but I thought I'd
comment on this.  A while ago I implemented a system like this for a
website where we had a problem with software robots.  It was your usual
"fuzzy image with text" system (we had to play with it a little bit to
make it OCR-resistent without making it unreadable).  We did get a few
complaints from blind users who were being shut out of the site, so I
did the sensible thing: I added a link saying "click here to listen to
the challenge" an generated a "fuzzy" sound file with the same
information that is in the image.  It was not particularly hard to do, I
just had to research a little bit on sound file formats.

So, it is not an intractable problem.  It just has to be done right.

-Wilson
-- 
Wilson Roberto Afonso                           [email-masked]
http://www.netwhatever.com
GCS d- s: a C++ UBL++++$ P++ L++++ W++ N+(++) o+ K++ w !E !O M V- PS++ PE++
Y+ PGP++ t 5? X+ R tv+ b++++ DI++++ D- G+ e++ h-- r+++ y+