Subject: [Asrg] Re: RMX Records

From: Daniel Feenberg <[email-masked]>
Date: Sun, 2 Mar 2003 19:18:05 -0500 (EST)

Since no one else has followed up, I will ask some questions. They are not
meant as complaints, but an RFC doesn't serve well as a persausive
document. 

If respected by receiving MTAs, the proposal would give the owner of the
DNS space in which a host lives control over which servers could originate
SMTP traffic. This seems a reasonable delegation of authority, but is
likely to be controversial. Alternatively, the owner of the IP address
range could be given this authority. Why pick one or the other?

Why this is superior to Adam Filip's proposal (
http://groups.google.com/groups?q=vixie+mx+records+spam&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3E18B0B3.43939A35%40Andrzej.Adam.Filip&rnum=10
)  to overload the existing MX record? That proposal would also vest
authority in the owner of the domain name. It would seem that requiring
modifications to the DNS system is a substantial additional obstacle to
adoption. Do you have reason to believe that DNS software authors/vendors
would cooperate?

Does the RMX record for relays.danisch.de include all the valid sources of
SMTP traffic for subdomain.danisch.de, or does the receiving server
recurse down to relays.subdomain.danisch.de for that list?

Would you expect operators to reject mail without a valid RMX record? I
can see subtracting a point from the spam score for a valid RMX. It would
be hard to justify to most users rejecting mail entirely. Is that what you
envision? 

feenberg at nber.org 

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

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 10:20:27 +0100

Hi,

On Sun, Mar 02, 2003 at 07:18:05PM -0500, Daniel Feenberg wrote:
> SMTP traffic.

No. To be more precise:

The proposal would give the owner of the domain which the
senders e-mail address belongs to control over which servers could originate
SMTP traffic.

The proposal quitly assumes that the owner of a domain (i. e. the
one who is able to define zone entries) is the same who is
allowed to decide who may use this domain in a senders address.

> Alternatively, the owner of the IP address
> range could be given this authority. 

No, this would give the key in the attackers hand. 

Since domains and not IP addresses are used in E-Mail addresses
(at this very moment you are reading a message from [email-masked],
not from [email-masked]), authorization (at least of the
right hand side of the address) is a matter of domain, not IP address.

The commercial spammers do have control over their own IP address
range. If authority was given to the owner of the IP address, they
could give themselves any authorization they want to have. 
E.g. they simply declare themselves as authorized to use
@hotmail.com, @yahoo.com, @nber.org...

That's the opposite of what you want to have.

> adoption. Do you have reason to believe that DNS software authors/vendors

First, MX records are not meant to be used for that. If you want
to keep the Internet working, use things in the way you are supposed
to do. Using them in the reverse way violates the definition of MX.

Second, it doesn't work and it is too much overhead, because there
is one indirection step missing. Assume that I want to authorize 
the relays of my hoster rackland and another set of relays, e.g. 
by an employer or some ISP for originating mails from danisch.de.

If I had to do this in the MX way, I had a lot of trouble figuring
out which relay machines exist and changing it every time the
providers do change it. With my proposal, the RMX record for 
danisch.de would simply give permission to "relays.rackland.de" and
"relays.employer.com", where the admins of rackland and employer
can define the APL records for these domains reasonably. If the IP
address changes or new relays are added, it just takes a single change
instead of modifications of all domains hosted. 

Third, DNS software is ready to be extended. The most important
software is bind9, and this is available as source. So I can (and I
will as soon as APL records are available) provide a patch on my
homepage and pass it to the upstream maintainer. As soon as the 
record type has become a standard, it will be incorporated into the
main distribution. Adding a new record type to a DNS server is not
a big deal. And none of the commercial software vendors wants to
live with a DNS server which doesn't support all record types. 
No, the DNS server software is not the problem. It will be more 
difficult to convince the MTA software vendors. But that's the
same problem as with the MX proposal.

> recurse down to relays.subdomain.danisch.de for that list?

Well, it should work just like normal DNS. 
There would be no RMX record for "relays.danisch.de".

There would be a RMX record for "danisch.de", which points
to relays.rackland.de, which is an APL record containing a
list of the relay machines.

For subdomain.danisch.de there must be another RMX record, as
with MX records. But since DNS supports a very simple form of 
wildcards, a single entry *.danisch.de could cover all one
level subdomains of danisch.de. 

But I agree the next question is what to do with 
sub.domain.danisch.de . Maybe it would be wise to require the
receiving MTA to climb up the domain tree until something is
found.

> Would you expect operators to reject mail without a valid RMX
> record?

I would neither expect them to reject it nor to accept it.

It's just a matter of their policy. 

If a mail comes without any RMX record at all, then this
is a statement like "We don't have a authorization policy".
It's your policy whether you accept this message or not.

If a mail comes with a large RMX record, e.g. 0.0.0.0/0,
thus authorizing the whole world, it's your decision whether
you want to have that mail or not.

If a mail comes with a good RMX record, but from an 
IP address not covered by this record, again, it depends on 
your policy whether to accept or reject that mail. 

Your policy could even depend on the recipients address.
For one recipient you prefer a more tight policy, another
recipient is more relaxed. 

Actually, with my proposal I do not want to block any e-mail.
I want to give the receiver some simple and (at least to
a certain level) reliable information, on which his individual 
decision whether to accept or deny the message can be based.

Don't understand RMX records as a message filter. It's the
domain owners statement about the domains security policy.
It's the receiver's business to block or accept a message.
You're still free to send any message you want to send, but
I become free to not take it.

regards
Hadmut

---

From: [email-masked] (Justin Mason)
Date: Mon, 03 Mar 2003 11:59:52 +0000

> allowed to decide who may use this domain in a senders address.

One issue I can see here: if I send mail from my home machine for
mydomain.org, connected using an ISP's dynamic pool of IPs for their DSL
users, then I either 

	(a) need to know that ISP's address ranges

	(b) need to update my RMX records dynamically each time I connect,
	and this needs to match my mail *at the time the recipient checks
	it* (ie potentially breaking the store-and-forward model!)

	(c) need to set up a static-IP deal with the ISP, or buy a colo
	server ;)

	(d) need to use an "allow all" 0/0 mask for mydomain.org.
	
How do we solve this?   Is there another solution?

BTW note that this, in general, does seem to be a very promising approach
(and one that's been mooted a few times before in various forms ;)

cheers,

--j.

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 3 Mar 2003 08:07:45 -0500 (EST)

> mydomain.org, connected using an ISP's dynamic pool of IPs for their DSL

[deletia]

Well, couldn't you relay through your ISP's SMTP server, and put that
server as your RMX record?  This isn't perfect -- it means all of your
ISP's customers could spoof mail from your domain, but it's better than
nothing.

Nevertheless, I do not think RMX records will fly in practice.
There are often legitimate reasons for relaying through other SMTP
servers, such as when you're on the road and using an ISP's global
roaming service.

--
David.

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 14:45:26 +0100

> mydomain.org, connected using an ISP's dynamic pool of IPs for their

That's one of the bitter pills. As long as anyone with a 
dynamic IP address is able to send mails with your address, then 
there is no difference between the authorized sender and the abusing
attacker. 

Many of the Spam messages I receive are sent from DSL accounts with
dynamically allocated IP addresses. If *you* are allowed to send
mail from jmason.org, then everybody else who can get the same
IP address a few minutes later would be allowed as well (as long as
we glue permissions to IP addresses and omit the time factor).

> 	(a) need to know that ISP's address ranges

No, that's why I used the APL records instead of directly using the
address ranges.

It would look like this:

your ISP, lets assume he has the domain isp.com, would have to 
administer some APL records.

That could be something like

    customdynrange.isp.com     covering all its dynamic address ranges 

or
    state.isp.com              if the ISP can determine which address
			       ranges belong to which state

or 
    city.isp.com	       if ranges are limited to a city.

Let's assume you're working somewhere in california with ISP1,
but sometimes you're in New York and working with ISP2.

Then your RMX record could look like this:

jmason.org    IN RMX  (california.isp1.com newyork.isp2.com)

which would still keep the door open for thousands of 
IP addresses, but would block mails from Texas, India, Nepal...

> 	it* (ie potentially breaking the store-and-forward model!)

No, you certainly could do so. Many people use dynamic DNS updates for
their regular home machine anyway. 

Let's assume you have such dynamic update for the machine 
home.jmason.org.

Then your RMX would look like this

jmason.org  IN RMX ( jmason.org )
jmason.org  IN APL ( home.jmason.org )

home.jmason.org IN A  your-dynamic-address

(or maybe the RMX recors should allow host names directly).

Since your dynamic entry home.jmason.org exists for the full time you
have a certain IP address, you will be able to send. Once you drop
the connection, the entry home.jmason.org doesn' exist anymore (or
changes), but since you have lost that certain IP address, this 
is perfectly consistent. And no, it doesn't break the
store-and-forward model, since you can't send e-mail with that
IP address after you've terminated your connection.

> 	(c) need to set up a static-IP deal with the ISP, or buy a colo

That would be the best. That's what I do. 

> 	(d) need to use an "allow all" 0/0 mask for mydomain.org.

That's also possible. That's a statement like "I don't want to 
restrict origins for my domain". If you want to do so, that's fine.
But it might be my decision to not accept mails from such a domain
anymore.

> How do we solve this?   Is there another solution?

Yup. Use Cryptography and have a PKI Infrastructure.  Use
challenge-response authentication, mail signatures, or something
alike. But that's far more complicated, has severe vulnerabilities,
and requires updates of virtually every MUA.

My proposal is not the final solution of all problems, but it is
 
- feasible
- cheap
- simple
- effective
- doesn't affect MUAs
- backwards compatible
- easy to implement
- easy to administer and debug
- allows smooth transition
- allows flexible policies

Also, my proposal doesn't claim to be an exclusive solution. 
Maybe you could have something like this:

- If the sender is authorized by the RMX record, accept the
  mail the old way. 

- If not, require authentication by password or a mail signature.

regards
Hadmut

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 14:58:08 +0100

> ISP's customers could spoof mail from your domain, but it's better than

Well, it would be the responsibility of the ISP's SMTP server to 
somehow check the authenticity of the mail. Some ISP's have SMTP 
servers which always know which customer an IP address is currently 
assigned to. So your customer might restrict usage of your domain 
as a sender address with any mechanism - password authentication, 
single sign-on, your IP address. But that's a black box from an
outside point of view.

Your RMX records could state that your mail comes from this 
certain SMTP server only. How you ensure authenticity within this
server, that's your private business and beyond the scope of the 
draft. But that's a design criteria. In contrast to PKI, I want 
to leave it the domain owner's private business whether and how 
intra-domain-authenticity is checked.

> servers, such as when you're on the road and using an ISP's global

Yes, I often heard that argument. But

- What's the technical difference between you on the road and 
  and Spammer? How will you distinguish your mail from a spammers
  mail abusing your domain?

- 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.

  And that's not too much to ask for, because you need a central 
  relay for receiving your mail anyway. How do you receive mail when 
  you're on the road? You need some service provider who receives the
  message for you and allows you to download it. It's not a bad idea
  to do the very same for sending e-mail in reverse direction.

  If you receive e-mail through a central relay, so what's the 
  problem with sending e-mail the very same way?

regards
Hadmut

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 3 Mar 2003 09:17:16 -0500 (EST)

> intra-domain-authenticity is checked.

Right.  But a lot of people don't like having to relay through
their ISP's server.  Some ISP's, for example, won't let you send
mail from any domain but theirs.  So I could not send mail from
"[email-masked]" through my ISP's server; it would
have to be from "[email-masked]" or something like that.

>   and Spammer?

None.

>   How will you distinguish your mail from a spammers

You can't.

>   machine, simply because thats easier.

Well, you are technically savvy, so you know how to set up SMTP AUTH to
make this work.  The vast majority of people don't.

[...]

>   problem with sending e-mail the very same way?

In theory, I agree, but in practice, I do not think most people will
go for it.  Also, it's very cheap to register domains and set up RMX
records, so the extra cost to spammers is small.  A spammer that charges
$500 to send out bulk e-mail can easily charge $520 instead, and register
a one-time disposable domain name for the purpose.

Where these kinds of records might help is with the large free e-mail
providers like hotmail, yahoo, etc.  But I already have rules to reject
e-mail from these domains unless the sending host name (a) resolves and
(b) ends in the same domain as the sender domain.  Hotmail and Yahoo are
pretty good about keeping their reverse-DNS records up to date, and this
is very effective.

Widespread use of RMX records would simply make spammers choose not to
fake their e-mail from "hotmail.com" or "yahoo.com".

---

From: Reinhold Jordan <[email-masked]>
Date: Mon, 03 Mar 2003 15:22:28 +0100

Hi,

> we glue permissions to IP addresses and omit the time factor).

but is this really the problem? Most spam-mails with wrong sender
use domains like hotmail or other great freemailers. And this
freemailers doesn't use dynamic IPs. A test on this domains will
reject much more than 50% of spam...

Regards, Reinhold

-- 
                       Reinhold Jordan
WWW: http://reinhold.bachrain.de    Mail: [email-masked]
"Do you pine for the nice days of minix-1.1, when men were men
and wrote their own device drivers?"                     Linus
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 15:36:30 +0100

On Mon, Mar 03, 2003 at 03:22:28PM +0100, Reinhold Jordan wrote:
> but is this really the problem?

Believe me, it is. About a year ago, some Spammers were sending
millions of mails around the world and used random addresses from
my domain as sender addresses. I received tons of complaints and
cursing threats from people who received Spam, but didn't want to 
believe that I don't have anything to do with it.

> Most spam-mails with wrong sender

Yeah, but once you start blocking splam from @hotmail, they will 
start to use any random domain.

regards
Hadmut

---

From: Roland <[email-masked]>
Date: Mon, 03 Mar 2003 14:49:28 +0000

> there is no difference between the authorized sender and the abusing

The RMX-record allows the owner of the domain to restrict abuse
of his domain by spammers and alike.
Those who want to limit the forging use the RMX (most likly Yahoo,
Hotmail and Outblaze, and all the others suffering from this).

Many people already accept mail from such often-forged freemail-
domains only from their legitimate hosts.

The real problem will be with forwarding accounts, the envelope-
sender should be replaced with the address of the forwarder.
Maybe you want to include a note about this in your proposal.

> jmason.org    IN RMX  (california.isp1.com newyork.isp2.com)

Wildcards would be nice too, and could solve the problem with
dynamically assigned hostnames.

> IP addresses, but would block mails from Texas, India, Nepal...

Its usually easy to get the abuse stopped if all parties reside
on the same provider. But the proposal should include a note
about possible forgeries of RDNS if the hostnames dont get
double-checked.

> But it might be my decision to not accept mails from such a domain

I dont think that should be a part of the proposal.
There are enough domains which will use RMX anyway, and this will
put quite some pressure on the others.
The acceptance would be much better if you not trying to force the
usage of RMX to anybody. And of course everybody is still free
to block whatever he wants on the own server.

> and requires updates of virtually every MUA.

This actually does not stop the spew at the side of the sender
since the whole message has to be received and parsed for the
cryptographic bits.

The solution probably would need an extended MAIL FROM where the
key of the sender gets appended (like the SIZE extension) to allow
rejection at the RCPT TO (per receipient) without actually receive
and parse the whole content.
The solution should probably also allow for an additional token
to be appended to the RCPT TO, for various reasons.

There is also another problem: if RMX gets widely used spammers
will use empty envelopes which can not be protected by RMX.
How could an RMX-compatible DSN be composed ?

Roland

---

From: Reinhold Jordan <[email-masked]>
Date: Mon, 03 Mar 2003 15:56:27 +0100

Hi,

> believe that I don't have anything to do with it.

ok, this is an argument. I just see, if I filter freemailers with
wrong IPs, domains without open port 25 and my own domains I get
rid of more than 95% of spam. But I know, if you all use my qmail-
patch, spamers will start new ways to send spam... :(

Regards, Reinhold

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Mar 2003 09:29:17 -0500

> reject much more than 50% of spam...

spam keeps changing.  block one way of sending spam and there will be
others.  as long as it's cheap/easy to get an Internet account, spammers
will get throwaway accounts.

that and being able to send mail from multiple accounts with the same
return address is quite useful.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Mar 2003 10:15:36 -0500

> rid of more than 95% of spam. 

right now, if I filter out mail with invalid characters in the subject
line, I get rid of more than 75% of the spam I receive.  but sooner or
later spammers will learn to encode in rfc 2047.

spammers interpret filters as damage and route around them.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 16:17:51 +0100

> Maybe you want to include a note about this in your proposal.

Yup, thanks. Same problem with some mailing list processors, which
leave the envelope sender intact.

> dynamically assigned hostnames.

At least at a first glance, wildcards don't work.

If the RMX contains *.isp.com, what are you looking for in the
next resolving step? 

You could, of course, try to match the hostname found by reverse
lookup, e.g. do a reverse lookup of address a.b.c.d , and see
if the hostname matches e.g. northpole.isp.com. But that opens
the door for spammers again, since if they have access to their
reverse DNS entry, they can give themselves any name. So you had
to doublecheck this again.

I'd rather avoid making PTR records part of the chain, since they
are a little bit vulnerable to some nonsense, and usually under
someone else's control. 

> to block whatever he wants on the own server.

Ah, sorry, my statement was misleading. With "my decision" I didn't
mean the draft, I was speaking as mail admin. I was talking about
the local policy, not a general rule. 

> since the whole message has to be received and parsed for the

I'm currently preparing another draft for a successor of SMTP 
which also addresses this issue. But this is a different story
since it is a new protocol requiring new software.

> and parse the whole content.

Yes, that's a design criterion of my draft. If this is considered
to be within the scope of this working group, I can present a
first, rough version soon.

> to be appended to the RCPT TO, for various reasons.

Yep, already contained in my draft.

> How could an RMX-compatible DSN be composed ?

That's a pretty good question. Introducing empty envelopes
was a pretty bad idea, especially in context of SMTP which presents
envelop addresses only before transmission of the message.

That's a diffent problem we'll have to discuss. Unfortunately, 
it will be difficult to disestablish empty envelopes in 
common SMTP.

regards
Hadmut

---

From: Reinhold Jordan <[email-masked]>
Date: Mon, 03 Mar 2003 16:27:36 +0100

Hi,

> later spammers will learn to encode in rfc 2047.

but there is a little dirrerence between your filter and mine.
You got the traffic and me not.

> spammers interpret filters as damage and route around them.

I see this as a "sport" - are they better or me ;)

Regards, Reinhold

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Mar 2003 10:34:18 -0500

> You got the traffic and me not.

important observation - different sites get different kinds of spam.

> I see this as a "sport" - are they better or me ;)

that's fine if you enjoy that kind of sport.

Keith

---

From: "Robert G. Ferrell" <[email-masked]>
Date: Mon, 03 Mar 2003 09:40:07 -0600

>spammers interpret filters as damage and route around them.

It seems to me that if we could get the 0.01% (or whatever the
figure is) of people who respond to spam to stop it, the problem
would go away on its own.  There has to be a cost benefit to
spamming in order for it to continue.

RGF

Robert G. Ferrell
[email-masked]

---

From: Reinhold Jordan <[email-masked]>
Date: Mon, 03 Mar 2003 16:41:03 +0100

Hi,

> important observation - different sites get different kinds of spam.

what do you mean? What I say is, I check for spam _bevor_ it is
transfered. If you check the subject, you can only do this, _after_
it is transfered.

> that's fine if you enjoy that kind of sport.

:)

Regards, Reinhold

---

From: Jens Reichmann <[email-masked]>
Date: Mon, 03 Mar 2003 16:46:37 +0100

> I see this as a "sport" - are they better or me ;)

Sorry, this is not a sport. This is a
duty to detect emails from the noice. ;(

This problem can only resolved with political
rules and technical settings over many ISP's!

Jens

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 3 Mar 2003 10:29:34 -0500 (EST)

> believe that I don't have anything to do with it.

Actually the proposal is very helpfull in this regard. Whereas now any
spammer can forge your address from any injection point, if the proposal
were widely accepted, then only the next person on your IP address could
forge your address, and I am not sure how easily he could arrange to be in
this position. He can look up your authorized smtp sending IP address
easily enough, but how easy would it be for him to get the providor to
issue that address to him? Would Radius or DHCP hand them out at random,
or could he bias the result in some way to raise his chances of getting
your old address?

Somehow it seems more practical to just buy a domain name and use it till
the spam filters catch on, although $10 is probably significant for many
spammers.

By this reasoning, the proposal could succeed at providing authentication
without actually reducing spam. Which is not a condemnation.

One thing to remember is that no single action will eliminate spam, but
some combination will. We have to ask "is this going to be part of the
combination"?

---

From: "Johan Louwers" <[email-masked]>
Date: Mon, 3 Mar 2003 17:23:44 +0100

New to the list.........
dear all, new to the list and trying to get up and running with the
discussion so i am aboute to ask some strange questions.....

What do we want to do? Find a way to eliminate or at least downsize the
number of spam messages running around on the internet. We "think" most of
the spammers will make use of "stolen" domain names. Is this so? and if
so.... are there researche papers to prove this? Are we 100% sure we are
looking at the correct problem?

Let say we are........
how to avoid people to send mail in name of a domain that they are not
permitted to? The sugestion (in very short) is to enable the recieving mail
server to check at the sending mail server that the original sending party
(the client/spammer) is allowd to send mail in name of this domain. correct?

Ok lets say, (the situation in holland) I am driving on the freeway and i
pullover at the gasstation. I get me a couple of free internet account CD's
go home install a couple of accounts get a mail adres and start sending SPAM
mail, after sending the mail i simpley delete the account an start using the
next free account...... The recieving mail server is checking with the
sending mail server of my free-ISP to look if the IP adres is allowd to send
mail in name of @freeISP.nl I am allowd to send mail ... so the spam is out
in the world and i just have bypassed the solution........

The next situation. Lets say i am the owner of www.veryhornypreteengirls.com
and i like to SPAM mail to a list of people. My @veryhornypreteengirls.com
mail server is placed someware in a third world country so i do not have to
worry aboute the law. I send out my spam mail the recieving server is
checking with my mail server and i am allowd to sendout the mail so the spam
is on the internet.

The checking part of reciecing server checking sending server is a good plan
to avoid a lot of spam mail it is only not enough. You also need a
"centralized" way to check if the sending domain is a "trusted" domain. You
must have the option to aloow or deny the mails from mail servers on this
list.

Just some of the things I was thinking aboute...... :-)

Regards,
Johan.

------------------------------------------------
There are only 10 types of people in the world:
Those who understand binary and those who don't.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 3 Mar 2003 11:35:16 -0500

> spammers interpret filters as damage and route around them. 
	Or, learn how to pierce through them...
	Others have used the sport analogy, still others refer to it as
war. In any case, spam filters that rely on analysis of messages
contents are simply not the solution -- no matter how strongly marketed
they may be and no matter how interesting the construction of filtering
systems may be to college students.

	The best we can expect from spam filters that rely on textual
analysis is an ever escalating "arms race" where email recipients deploy
ever more complex and sophisticated spam filters to defend against
spammers whose methods grow continuously more complex and sophisticated.
Even the "learning" filter systems, based on Bayesian logic, etc., which
are so greatly touted these days, cannot hope to defend effectively
against spammers who use "learning" techniques to discover what the
filters have learned. When the offense and defense both have the same
tools available to them, an arms race is the most expected result. And,
an arms race does little but cripple all involved by forcing them to
spend more and more of their resources to maintain a stable
relationship. 
	I was very pleased to see that the charter of this group focuses
on the problem of "consent-based" communication and appears to direct
attention away from filtering solutions based on textual analysis. I
must admit though that I'm somewhat worried about the discussion of
"approaches that determine the nature of a message based on its
characteristics" and sincerely hope that that this phrase does not
become a trap-door which permits endless discussions of methods by which
the useless textual analysis arms race can be furthered.
	Filters based on textual analysis cannot succeed. Let's focus on
fundamental solutions to the problem of spam -- i.e. how to build
systems for "consent-based" messaging.

		bob wyman

---

From: "Gary Feldman" <[email-masked]>
Date: Mon, 3 Mar 2003 11:37:42 -0500

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David F. Skoll
> Sent: Monday, March 03, 2003 9:17 AM

> Well, you are technically savvy, so you know how to set up 
> SMTP AUTH to make this work.  The vast majority of people don't.

Only the ISP needs to be that savvy.  The user just needs to be
able to set up the mail client the same way it's already being done
for POP3 passwords.  Conceivably some email clients don't make this
as easy, and perhaps some don't even support SMTP AUTH, but there's 
no technical reason they couldn't be just as easy as current POP3
setup.

Gary

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 17:41:53 +0100

On Mon, Mar 03, 2003 at 10:29:34AM -0500, Daniel Feenberg wrote:
> without actually reducing spam.

That's the next step of the story.

First, we have to keep in mind, that we still have no precise and
concise definition of "Spam", and I guess we'll never have.

My draft is focussed on the sender address fraud aspect of Spam, while
most people are focussed to the "mail which I don't want to have"
aspect. Unfortunately, the latter one is not easy to grab in a technical
and automated way. 

And there's another point: My approach could be seen as a "european
way". Let me explain this:

The RMX records don't stop spam. They stop e-mail fraud (i. e. using a 
foreign domain as a fake sender address), at least to a certain level.

When you receive a message, and the RMX records say "good", then
what's the use of this? You can assume that the owner of the domain 
has somehow in any way authorized the sender to do so, is somehow
responsible. It is a link between the message and the domain.
Now, what's that good for?

In Europe, especially in Germany, the whois entry of a domain usually
gives detailled information about who's responsible for a domain. This
is a link between a domain and a real human. OK, what's that good for?

You can sue the person.
You can blame the person.
You can blacklist the person (which is more effective than
  blacklisting his/her domains which can be changed like underwear). 

Effectively, you know who is molesting you. The mail suddenly turns
from an anonymous standard Spam to a plain normal, but still
unsolicited message.

There are still some problems:

- Some countries /ISPs don't keep the whois entries filled with 
  reasonable informtions, especially the far east countries.

  So teach your MTA to reject messages from domains which don't
  have  reasonable whois entry. It will force them to update
  their entries.

- Some countries (e.g. the USA) don't have that european idea
  of a human's identity. In Europe, people have identity cards, 
  you don't simply change your name or identity. Your name 
  and address can be "verified". In the USA, people insist of 
  beeing free to choose any name and address. It is very difficult
  to authenticate somebody when you lack a reliable identity.

Ok, back to the Spam problem.

We can't find a technical solution as long as we don't define Spam. 
Spam is a term for "everything annoying which can be found in a 
mailbox". Forget about it. We'll have to find real, hard criterias. 

I'll suggest those:

- Forged sender address
- Non-individual mass mail
- Lack of personal relation between sender and recipient
- recipients address found in context which was not supposed to 
  allow this certain message transfer

When we know what we are talking about, we can start to design
protection mechanisms. RMX records are designed against forged
sender addresses (domain part).

regards
Hadmut

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 3 Mar 2003 11:47:36 -0500 (EST)

On Mon, 3 Mar 2003, Bob Wyman wrote:

>Filters based on textual analysis cannot succeed.

I completely disagree.

If by "succeed", you mean "stop all spam", then you're right.  However, I
define "succeed" as "stop a large-enough proportion of spam to save
money", and by that measure, textual analysis can be very effective.

I believe that there is no solution that will totally stop spam.  What
is needed is a broad-spectrum approach consisting of:

- A legal framework to make it possible to prosecute spammers and extract
  money from them.
- Technical non-content-based means to reduce spam, such as RMX records.
- Buy-in by ISPs to take technical measures against spammers (ie,
  force subscribers to relay mail through the ISP's SMTP server.)
- Text-based analysis to detect likely spam.
- Tools to increase spammers' costs, such as tarpitting, tempfailing
  suspect messages, etc.

Like it or not, this is an arms race.  The best we can hope for is to increase
spammers' costs without hurting ourselves too much in the process.

> Let's focus on

In my business, I rely on getting e-mail from completely unknown
people.  This is a feature of e-mail I cannot do without.  Anything
that makes it harder for strangers to contact me than simply dashing
off an e-mail is a non-starter for me.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 03 Mar 2003 17:53:24 +0100

"David F. Skoll" <[email-masked]> writes:

> mail from any domain but theirs.

Use ISPs with proper values of "S".  *shrug*

I wonder whether the proposal has any chance of implementation.  Can
BIND handle those additional records today?  Is it feasible from an
operational point of view?
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 18:03:21 +0100

> discussion so i am aboute to ask some strange questions.....

Well, the list discussion just started a few hours ago. :-)

> in the world and i just have bypassed the solution........

Naw, I don't think so. 

First, it should be a disadvantage for the ISP if he allows all
customers to send mail. E.g. a receiving MTA could reject messages if
the RMX covers more than 16 hosts. Then the customers of that ISP
couldn't send mails anymore and start complaining. 

A solution would be:

The ISP has two domains,  e.g. loose.isp.com and tight.isp.com

The RMX for loose.isp.com covers all its dynamic IP addresses.
Customers are free to use it when sending mail. If the receiving
MTA is willing to accept it - fine. Just use [email-masked].

The RMX for tight.isp.com covers only the central relay. 
If the receiving MTA doesn't accept [email-masked], 
you'll have to send mail through the central relay of isp.com. 
isp.com takes responsibility to verify that you are john.doe,
and now you can send with [email-masked], which will
be accepted by the receiving MTA.

In Europe ISPs will be /are required to check a customers identity, 
so the ISP is actually able to perform the verification.

> checking with my mail server and i am allowd to sendout the mail so the spam

It still works: You are forced to use @veryhornypreteengirls.com as 
a sender address, not just [email-masked] 

My MTA can perform a whois query and find that the mail came from a
country without sufficient laws and without reliable whois
informations. The MTA could reject or maybe perform a time consuming 
text analysis. 

> "centralized" way to check if the sending domain is a "trusted" domain. You

Yup, but to do so, you first need a reliable link to the
domain. Otherwise its useless to check whether it's trustworthy.

regards
Hadmut

---

From: "Robert G. Ferrell" <[email-masked]>
Date: Mon, 03 Mar 2003 11:13:39 -0600

My contention is that spam is largely a social, not a technical, issue.
The reason spam exists is that it is cost effective for the spammers.  A 
certain small percentage of people who receive spam respond to it, and that 
response is sufficient to drive further spamming.  If we spent as much 
effort in educating the public about the pitfalls of responding to 
unsolicited commercial email as we do in thinking up ways to block it, we 
could probably make the problem go away on its own.

In effect, those few who bite at the bait spam offers are as responsible
for the spam problem as the spammers themselves.  I think an international 
campaign aimed at them would be at least as effective as all this technical 
end-running we're doing.  In the long haul, it's difficult for me to see 
how any technical solution can represent more than a temporary setback for 
the spammers.  They're getting increasingly savvy and they're driven by the 
clear economic gain they're deriving from their actions.  We can never 
successfully subvert that by filtering.  We have to attack the root of the 
problem, which is that spam pays.  Stop that payout, and you stop spam. No 
one sends out spam on the scale we're seeing just because they feel like 
it. They do it because in the end they make money off the process. They 
make money off the process because a small minority of the people who 
receive spam respond to it by sending the spammers money. If we can modify 
that behavior socially, we can reduce spam to a relative trickle that can 
be more easily handled by technical means.

At least that's how it appears to me.

RGF

Robert G. Ferrell
[email-masked]

---

From: "Mark Delany" <[email-masked]>
Date: 3 Mar 2003 17:20:31 +0000

> off an e-mail is a non-starter for me.

Which simply means that a consent-based system gives you an "accept
unsolicited email from anyone" button, doesn't it?

Regards.

---

From: [email-masked] (Justin Mason)
Date: Mon, 03 Mar 2003 17:44:41 +0000

Keith Moore said:

> - originator identification/authentication/tracing
>   (e.g. if you can reliably tell whether a message is coming from a
>   known spammer, or merely someone of unknown reputation, or someone
>   you know.  this happens at various levels of granularity - 
>   you might know the ISP that is originating the mail, or you 
>   might know what business has that IP address block, or you
>   might know the specific MTA, or you might be able to identify
>   the sender via some kind of authentication, either in the
>   message or out-of-band (say SMTP authentication).)

This is, by far, the most urgent one.   SMTP is currently forged on a
massive basis, in order to send spam.  If we can come up with a way to
successfully break mail-originator forgery, every other aspect becomes a
whole lot easier.

Regarding the whack-a-mole spamhaus issue, where they register domains
like "somegreatnewspammyoffers439.biz" in order to send authenticated spam
for each spam-run -- that's not a big problem; we'll just be back at the
mid-90s stage, when DNS blacklists *worked well*!

Bottom line: if we're in a forum to "fix SMTP", then IMO mail-originator
forgery should be top priority.

(Disclaimer: I hack on SpamAssassin, which uses message-analysis.  But
SpamAssassin's a platform for filtering these days, and I'd love to get
origination-auth so we can support it!)

--j.

---

From: "Johan Louwers" <[email-masked]>
Date: Mon, 3 Mar 2003 18:43:41 +0100

> domain. Otherwise its useless to check whether it's trustworthy.

Think aboute a way that all the domains are "trusted" if they are violating
the "we do not send spam" rule they are placed on the list with a marking of
1 very new "spam attack" is placing them up in the ranking...... If you have
a spamSendingRate of 100 you are totaly blocked.  After some time of not
violating the rule the ranking will be dropping down. To maintain this list
you should be thinking of a mechanisme like the way DNS servers are updated.

I do not think that the lookup methode alone is efficient enough and manual
setting country's, IP ranges and more like that to NOT TRUSTED in your mail
sever is enough....... if we are looking fore a close and tighter meganisme
to ban SPAM from the internet we need more then the lookup methode I
think.....

Reagrds,
Johan.

---

From: [email-masked]
Date: Mon, 3 Mar 2003 07:59:31 -0800 (PST)

PGP Signatures and in general messages signed by from accepted lists
- this probably belongs to originator identification/authentication/tracing
but should be mentioned

Filtering by target email address - i.e. some add ietf+email or whois+email,
etc. and use that to futher differentiate how filter may do the work but 
actual recepient account maybe the same. 
- not sure what category this belongs to in your list, might have to be 
on its own

Other proposed mechanisms are to require heavy computation of ciphers to 
make sender's job a lot more difficult and limit how many emails they 
would be able to do 
- this definetly should go into its own category

Some other mechanisms include sending verification email to be sent that 
contains picture with text that only person can read.
- this probably belongs to blacklist/whilelist category

And we should definetly pay more attention on combination of the techniques.
Some programs only work for combination and assign special "points" to 
each filter or its type and then if number of points is high they mark it 
as "maybe spam", "possible spam", "most likely spam", etc. or in fact 
delivery it but let recepient see the gradingand decide if he wants to 
open it and modify grading to his best preference. It can also be noted 
that this can be multiple final grade categories - i.e. like with movies, 
email can be  categorized by content as heaving "adult content", 
"language" , etc.

On Mon, 3 Mar 2003, Keith Moore wrote:

> okay, basically I agree with your thesis.  I'd state it a different way:
> spam is in the eye of the beholder.  the same message can be legitimate
> to one recipient (especially if it was solicited  - maybe the guy really
> does think he can enlarge a part of his anatomy :) and illigitimate to
> another recipient.
> 
> so trying to distinguish spam from non-spam by analysis of text, without
> knowing the recipient's preferences, is inherently of limited
> applicability.
> 
> (you might argue that there are some messages that can be determined to
> be unwanted no matter who they are sent to - say viruses - but as far as
> I can tell this is a very narrow class.  maybe I actually want to get
> that .EXE file in email.  maybe I want to receive mis-labelled content
> to see how my mail user agent will handle them.  etc.)
> 
> but I think it's too early to start arguing about *the* solution. 
> for now we should try to understand the solution space - see
> what general techniques we have at our disposal.
> 
> offhand I can think of several categories of tools:
> 
> - message analysis techniques 
>   (looking at characteristcs of messages)
> 
> - recipient-specified preferences
>   (recipient says "I don't want spam" or "I can't read Korean")
> 
> - message filtering (e.g. removal of viruses, annoying HTML, whatever)
> 
> - differential message handling by relays
>   (e.g. messages from known senders are allowed to be larger, 
>    contain a wider variety of content, be accepted for delivery more 
>    quickly; messages from unknown parties might be delayed
>    and/or restricted to size or content; messages from known
>    spammers or that are known to have viruses are bounced or
>    discarded)
> 
> - recipient feedback mechanisms (e.g. blacklists, whitelists)
> 
> these should not be considered mutually exclusive - clearly they
> can be combined, and often are.
> 
> which ones am I missing?

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Mar 2003 12:15:42 -0500

which ones am I missing?

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 3 Mar 2003 13:09:31 -0500 (EST)

> unsolicited email from anyone" button, doesn't it?

And that is different from now... how?

---

From: "Mark Delany" <[email-masked]>
Date: 3 Mar 2003 18:43:10 +0000

> And that is different from now... how?

I'm assuming a consent-based system gives each email address individual control
over their "consent" settings.

You chose to set your email address to "accept unsolicited email from anyone" because
that's important to you. It may not be important to me, so my "consent" settings are
more stringent.

Of course a "consent-based" system is entirely hypothetical right now. All I'm saying
is that there is no reason to preclude existing behaviour wrt what one accepts on
an individual basis.

If you are saying that this "feature" of email is universal and everyone will want
it and must have it, then that's another question entirely. To my mind that's
a consent-threshold question. Spam tells us that the current (and only) threshold
is too low.

Regards.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 3 Mar 2003 13:49:54 -0500

> Filtering by target email address - i.e. some 
> add ietf+email or whois+email, etc. and use 
> that to futher differentiate how filter may do the work
	The method of inserting a "digital signature" or other
distinguishing mark into an address is an effective way of creating a
"single user" email address that can be used to limit the utility of
email addresses to any other than authorized users. Creating "single
user" addresses gets around the problem we have today with addresses
which are equally useful to anyone who can discover them.
	In the most basic approach, you take a "Base" address, say:
"[email-masked]" and then add to it a sender dependent part which
creates an address whose utility is limited to a particular sender.
Thus, if I want to authorize "[email-masked]" to send mail to me, I might
generate a digital signature on the combination of sally's FROM address
and my own address that looks like "poiypoi/syK9798". I would then have
Sally use the address "bob+poiypoi/[email-masked]" when sending
mail to me. My mail server or client can then inspect incoming mail and
check to see whether or not messages to me use "authorized" addresses.
If an address isn't properly authenticated (either because it doesn't
contain a signature or because the signature is incorrect), then my
software would be able to flag the message as one that is not
authorized. 
	By using such a system, you can significantly reduce the value
of a "stolen" email address since mail that doesn't have a proper
signature in the "TO" address would be either deleted or shunted into a
"possible junk mail" folder. The system the nice feature of allowing
both "authenticated" and "unauthenticated" senders. Your "base" address
(i.e. the address with no "+" part, would be generally used by anyone
who is contacting you for the first time or who does not have an
established relationship with you. Such mails a "suspect" and would be
filed into an appropriate in-box. However, people who have a
relationship get a personal "single user" address for you that allows
them to send directly to your "trusted" email inbox. Messages with bad
authentication (i.e. wrong signatures) could be filed in a third inbox. 
	The system would relies, to a certain extent, on FROM addresses
not being forged and thus mechanisms to increase our ability to trust a
FROM address would make it stronger. However, the system is still useful
even in light of forged FROM addresses since a spammer, in order to gain
access to the "trusted" inbox, would need to know both a "single-user"
email address as well as the FROM address that goes with it. Obtaining
this pair of data is much more difficult than what is needed today --
today, you only need to have one piece of info: A valid email address.
Also, it should be noted that if one detects that a spammer *has*
obtained the pair and is sending forged messages, you now know from whom
the address was "stolen" which is very useful data. Also, you can simply
issue a new "single user" address to your correspondent (after getting
them to promise that they will take better care of their address book in
the future) and then use a "black list" to filter out messages sent
using the old authentication code.
	Adding the authentication code to TO addresses is something
which is supported today by any email system that supports the "+"
convention (i.e. text between the "+" and the "@" is ignored by the
server). Thus, sendmail servers, many IMAP servers, Verisign's mail
system, Earthlink, etc. have no problem properly handling email that
contains authentication codes and thus have "latent support" for
single-user addresses today. However, it is the case that not all
systems handle this stuff. For instance, Hotmail and a variety of other
mail providers don't... But, that could be fixed.
	This solution provides authorization of senders with fine
granularity, allows unanticipated senders to get messages to you, and
permits the "revocation" of sending rights when addresses are found to
have been compromised. Also, this method still leaves plenty of room for
folk who want to work with "spam filters" since filters can be usefully
employed as a secondary filter on messages that have been accepted into
"junk mail" folders. (You might have spam filter that focuses on
classifying "junk mail" into "really junk" in a Red folder and "not sure
if it is junk" in a Grey folder, but tell your filters not to touch
messages which have been received with trusted, single-user addresses.

		bob wyman

Note: I believe that Intel/Xircom and others have patents that cover
some applications of this technology.

---

From: [email-masked] (Justin Mason)
Date: Mon, 03 Mar 2003 19:00:40 +0000

> some applications of this technology.

If they do, and they cover the spam-filtering case, I hoped they were
filed before 1997, when "tms" was posted (see
http://www.DeepEddy.Com/tms.html ).  Nowadays, thousands of people are
using TMDA, another more popular and well-maintained implementation of the
same idea. 

So far, 2 patent applications on this technology that I know of, have had
TMDA submitted as "prior art".

Got any patent ref numbers?

--j. (bad patents are a pet peeve)
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 3 Mar 2003 13:38:51 -0500 (EST)

> could probably make the problem go away on its own.

That may be, but the IETF has to chose from among the tools that it has to
achieve its goals, just as the legislature must chose from among its
tools. There is no doubt a better way than this to solve the problem, but
that doesn't really matter, in fact it is always true. The existence of a
better solution is only an argument against this solution if this solution
precludes the better one, and if the better one would otherwise come into
existence. Neither of these is highly likely, so this group should
continue to think about "What is the most you can do with an RFC?" rather
than "What is the most someone else could do if they wanted to?".

Somewhere there is a legislature meeting about this problem, and someone
is saying that the IETF needs to solve the email forgery problem, rather
than depend upon the legislature to paper over technical inadequecies.

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Mar 2003 14:06:39 -0500

> This is, by far, the most urgent one. 

I think it's valuable, and I also think it's the one with the least
practical development so far.  But I don't think any of these will work
in isolation.  For instance, authentication isn't going to work without
some means of establishing trust in the credentials.  

I have some ideas about how to do this, but I think it's too early in
the group's lifetime to discuss specifics just yet.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 3 Mar 2003 14:09:19 -0500

>Got any patent ref numbers?
	See:
http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=6356935  
And
http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=6085321

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 3 Mar 2003 14:15:13 -0500

Justin Mason mentioned tms and TMDA

	Can you provide any discussion of the success of these systems
in blocking spam? Are the users happy with these systems? If they are
successful, why haven't they been deployed more broadly? Are there any
IPR constraints that would prevent IETF working groups from discussing
similar approaches, etc...

		bob wyman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Justin Mason
Sent: Monday, March 03, 2003 2:01 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Asrg] Single-User Addresses (a bit piece of a solution) 

If they do, and they cover the spam-filtering case, I hoped they were
filed before 1997, when "tms" was posted (see
http://www.DeepEddy.Com/tms.html ).  Nowadays, thousands of people are
using TMDA, another more popular and well-maintained implementation of
the same idea. 

So far, 2 patent applications on this technology that I know of, have
had TMDA submitted as "prior art".

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 3 Mar 2003 14:16:54 -0500 (EST)

On Mon, 3 Mar 2003, Mark Delany wrote:

> I'm assuming a consent-based system gives each email address
> individual control over their "consent" settings.

OK; but such systems are available (and being used) now.  I know that
because I occasionally run into some e-mail robot demanding that I
prove I'm a real person.  If most people I tried to correspond with
did this, I'd stop sending them e-mail.  If you could come up with a
consent-based system that didn't have some kind of challenge-response
interaction, then you'd have something good.

> If you are saying that this "feature" of email is universal and
> everyone will want it and must have it, then that's another question
> entirely. To my mind that's a consent-threshold question. Spam tells
> us that the current (and only) threshold is too low.

I think you'll find that most businesses that have a "sales@" or "info@"
address on their Web site require the ability to receive e-mail from anyone.

---

From: wayne <[email-masked]>
Date: 03 Mar 2003 13:25:50 -0600

In <[email-masked]> Hadmut Danisch <[email-masked]> writes:

> > )  to overload the existing MX record?

This proposal appears to overload A records, not MX records.

Basically, it creates a domain name specific DNS blacklist which could
use the same machinery that is already available and in use for all
the various other blacklists.  It would require no changes to the name
servers and only very minor changes to MTAs.  In the case of sendmail,
"all" it would take is hacking on the sendmail.cf file.

When IP address w.x.y.z connects and claims they are from domain
example.tld, the MTA and/or the spamfilter would do a DNSBL check on
z.y.x.w.smtp-out.example.tld in addition to checking
z.y.x.w.bl.spamcop.net and such.

> to do. Using them in the reverse way violates the definition of MX.

This proposal doesn't involve MX records and all the various DNSBLs
prove that it is practical.

> by an employer or some ISP for originating mails from danisch.de.

"All problems in Computer Science can be solved by another level of
indirection".... 

There is no more overhead than existing DNSBLs.

More importantly, I suspect that the majority of email traffic would
be sent by domains that would not need this extra level of
indirection.  I suspect that this RMX proposal would actually have
greater overhead.

If you really needed this extra level of indirection, you could hack
on bind to do the recursive lookups on other domain specific
blacklists that you are interested in.  Hacking on bind would be
required for the RMX proposal anyway, but only the domain that needs
this extra level of indirection would need to be updated.

> Third, DNS software is ready to be extended. [ ... ] As soon as the 
> a big deal.

This adds another hoop that people have to jump through.

How much software has to be changed to support this new record?  What
if a users wants to set up SpamAssassin on their local machine to
check the RMX record and doesn't have control over the nameserver they
use?  Would they still be able to do it?  (Clearly, the domain
specific blacklist would be no problem.)  Would people need to update
their resolver stub?  

> same problem as with the MX proposal.

I suspect that getting the MTA and spamfilter software vendors to
implement a domain specific blacklist would be pretty easy.

IMHO, the hard thing is to get a bunch of the larger ISPs to support
either the RMX or the domain specific blacklists.  Every time they add
a new server, they will have to remember to update the list and if
they don't, only a few people who run bleeding edge anti-spam systems
will notice.

-wayne

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Mar 2003 14:27:54 -0500

> My contention is that spam is largely a social, not a technical,

theft of tangible property is largely a social, not a technical issue.
however we employ technical means to thwart thieves and to make it
easier to track down thieves, so that we can employ social means (e.g.
prison) to deter them.  of course we also try to educate people to
make them less vulnerable to thieves.  and we purchase insurance to
manage the cost of lossage due to theft.

but we don't rely exclusively on either social or technical means to
deter thieves.  nor do we insist on having a 100% perfect solution to
the crime of theft.

offhand, I don't see why similar mechanisms can't be applied to
spammers.  and I suspect that social mechanisms to deter theft wouldn't
be very helpful by themselves - the supporting technology (locks, keys,
fences, alarms, cameras, serial numbers, fingerprints, etc.) helps a
lot to create a credible deterrent.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Mar 2003 14:34:14 -0500

> - this probably belongs to originator
> identification/authentication/tracing but should be mentioned

yup, PGP is an example of that class.

> Filtering by target email address - i.e. some add ietf+email or
> whois+email, etc. and use that to futher differentiate how filter may
> do the work but actual recepient account maybe the same. 
> - not sure what category this belongs to in your list, might have to
> be on its own

indeed, I do this myself - list traffic is filtered differently
than traffic to my mailbox. 

> Other proposed mechanisms are to require heavy computation of ciphers
> to make sender's job a lot more difficult and limit how many emails
> they would be able to do 

yup.

schemes that charge for sending email (esp. from unknown parties) have
also been proposed- I suppose there is a general class of imposing
barriers.

> Some other mechanisms include sending verification email to be sent
> that contains picture with text that only person can read.

I think that's another example of imposing a barrier.  
"here, jump through this hoop and then I'll read your mail"
the idea is to make the barrier small for those who send only a few
messages, much larger for those who send large numbers of messages.
and perhaps also to compensate the recipient :)

> And we should definetly pay more attention on combination of the

yeah, I'm fairly convinced that no single technique will suffice.

Keith

---

From: "Mark Delany" <[email-masked]>
Date: 3 Mar 2003 19:39:11 +0000

> interaction, then you'd have something good.

Indeed. The Holy Grail.

> address on their Web site require the ability to receive e-mail from anyone.

Sounds like we're in violent agreement.

Regards.

---

From: [email-masked] (Justin Mason)
Date: Mon, 03 Mar 2003 19:43:37 +0000

> similar approaches, etc...

Well, tms (apparently) became unmaintained, so TMDA was started.  That's
got a lot of users out there.

The main issue it has (I hear), is that it requires configuration and
manual whitelisting of mailing lists, e-commerce sites, etc.  Manual
intervention by the user is a big usability issue for spam filters,
since you start getting into a situation where they have to spend more
time configuring it than they would deleting the spam. ;)

--j.

---

From: Roland <[email-masked]>
Date: Mon, 03 Mar 2003 20:31:33 +0000

> This proposal appears to overload A records, not MX records.

Getting a new RR implemented into bind will likely take years,
a solution based on the existing records could be much faster.

The solution as presented in the posting of Andrzej Filip would
reject mail from the whole NU-TLD by default, and also from any
domain which has a wildcard defined:

$ dig 4.3.2.1.smtp-out.anything.nu

At least one should reject only if 127.0.0.2 gets returned, many
dnsbl-implementations already allow to distinguish by the last
octet, and there are many more mta's than sendmail.
(which should be _immediately_ updated to 8.12.8 because of a
dangerous remote root-compromise btw)

But the current scheme of dnsbl really only works for blacklists,
this application would be a whitelist by definition and the
implementation requires some more work.

One solution could be to reserve a magic (like 127.0.0.127 or maybe
better something like 255.255.255.255) for this purpose and create
some kind of standard which also may be used by other whitelists,
and can be easy integrated into the code of existing dnsbl-clients.

A-records are preferred because all dnsbl-clients (except rblsmtpd
which only queries for TXT) already know how to look them up.

Roland

---

From: Roland <[email-masked]>
Date: Mon, 03 Mar 2003 21:00:18 +0000

> Sounds like we're in violent agreement.

For addresses which only receive individual emails (like info@
and webmaster@) checksum-based distributed systems like DCC
provide nearly 100% accuracy without false positives, and even
in that case you still have a copy in the spam-folder.

But the solution sought here should prevent unsolicited mail at
the sender. You cant do this with content-scanning and it will
take at least 10 years to become usable for a sales@-address
which is too worried about loosing business from a misconfigured
or not-updated potential client.

Roland

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 3 Mar 2003 16:16:50 -0500 (EST)

> or not-updated potential client.

No, that's not true.  There's something totally obvious that many people
in the computer field overlook:

	Human brainpower

It is my contention that no technological solution will solve the spam
problem, at least not to a high degree of satisfaction.  The best we
can do is come up with tools that make people as efficient as
possible, and then leave the final decision up to a person.

Think of paper mail: Many corporations filter paper mail for their top
executive through clerical staff who perform triage.  The clerical
staff's time is comparatively cheap and it makes sense to have people
perform this duty.

Now transfer that analogy to e-mail.  A system that performs
first-pass automatic sorting gets you 90-98% of the way there,
depending on its sophistication.  It makes sense to have clerical
staff spend a few minutes a day going through the remaining
questionable e-mail.

It's (probably) no secret that my company sells anti-spam tools, and
this is our approach.  A broad-spectrum of technological approaches,
with the final decision being made by a human.  Of course, that human
can grant the automatic processes some decision-making power; there's
a risk/efficiency tradeoff that we leave up to our customers.

This scheme works really well for corporations, but, alas, not so well
for individual end-users.  Nevertheless, allowing a tradeoff between
automation and human intervention is, IMO, the best solution for the
forseeable future.

If we change e-mail protocols so that spam becomes impossible, we'll
change the whole nature of the medium that makes it so attractive in
the first place.  For every "abusive" trick performed by a spammer,
there are legitimate uses for that trick.