Subject: [Asrg] a "baby steps" proposal.

From: Chuq Von Rospach <[email-masked]>
Date: Mon, 24 Mar 2003 23:31:39 -0800

In and around today's various crises, I found myself pondering ways to 
maybe build a solution to part of the spam problem. Without pretending 
this is a formal proposal, or even fully fleshed out, here is an 
approach that came to me -- consider it a talking point to get things 
started.

I was thinking of ways to try to slow down or block the issue of stolen 
domains and forged return addresses, and looked ways to allow domains 
to "take back" their domains. And came up with, conceptually, a new 
flavor of the ident server.

Okay, you get a piece of email from [email-masked]. Should you 
accept it? right now, there's no way to query yahoo and ask, not 
reasonably.

To avoid making changes to existing protocols, instead of modifying DNS 
for new fields, I thought I'd do it using a well-known host name (which 
also allows a large site to scale with load balancers or perhaps round 
robins, while allowing small sites to simply virtual host it to their 
machine). Call it, say, hostauth.yahoo.com (if mail is from 
lists.apple.com, say, the authorizer is hostauth.lists.apple.com; 
through aliasing, it can all be tied to single server or single 
administration if you want). for sake of simplicity, I'll assign it 
port 5555.

As the site trying to decide on accepting, you can query that server 
two questions: is "[email-masked]" authorized to send e-mail from 
your domain? and "is this IP address authorized to send e-mail for your 
domain"?

Participation is optional; lack of a server means you don't have the 
information to work with (I assume some users will choose to make lack 
of a server a deciding action; maybe some day). It allows a site to 
explicitly deny mail from non-existant/forged accounts. It allows sites 
to start restricting mail sent from non-local locations (the issue of 
the remote user using an accessible SMTP host is an issue, as are 
backup MXes, among things I've thought of).

For instance, if you query hostauth.plaidworks.com, it'll tell you that 
[email-masked] can send email, but [email-masked] cannot. 
Neither can [email-masked]. Since I send email as plaidworks via 
my work's SMTP while I'm at work, it'd not only tell you that 
64.81.78.180 can send e-mail as plaidworks.com, but so can 
17.254.0.152. If you got email from 216.139.12.17, my server would tell 
you no. the IP ranges are probably tri-state: there will be addresses 
whitelisted by that server, addresses potentially in the "no opinion 
state", and addresses blacklisted (things that admin has found to be 
sources of spam forged with that domain's addresses, or perhaps 
generated out of rbls). If I were sending mail using my 
@employers.domain address using y home SMTP server, whether that'd be 
in the "no opinion" or "blacklist" would be based on the policy of that 
domain owner, which I think is fair, even if it might inconvenience me 
at times.

Data can be cached for some period of time. Once you know my auth 
server approves that address and/or IP address, you don't need to query 
every time you see it; it's safe to assume it's going to stay okay. 
rejections are more problematic, maybe a shorter cache for them.

What's in it for a domain? The ability to better control who's using 
that domain, especially those trying to use it without permission. The 
reduced problems with bounces from forged headers, time spent by admins 
dealing with misdirected abuse mail, etc, etc -- all can help offset 
the cost of creating and maintaining this auth server. It requires no 
new protocols, no massive outlays of engineering or "stuff", no massive 
re-engineering of the universe; it's effectively an RBL built and 
maintained by a domain, about that domain, advertised via a known 
host/known port mechanism.

On the client side: it can be built into anti-spam tools similar to 
existing RBLs; adding support isn't a major issue. Decisions on how to 
use the data can be administered how a domain wants them to be, it's a 
local decision.

A nice side aspect of this is that bogus auth servers can be 
blacklisted. If you catch one lying to you, the receiving side can 
simply flag all mail being authed through that server as bogus, so once 
a server is found to be spam friendly, it gives you a way to deal with 
all of the spam authed by that server. spammers can work around that, 
of course, but it's one more thing for them to have to deal with, and 
the auth server has to be in DNS, so it's harder to hide than using 
open relays or open proxies. It's another tool to force a spammer to 
stand still long enough to find where he is, not where his mail is 
coming from.

basically, it's something that's both an ident server (on a domain 
basis) and an RBL. It'd have a very simple protocol, and should be 
quite fast. for most sites, a flat file configuration ought to suffice; 
for larger organizations, it'll be more complex to keep all of the data 
straight, but it's all engineering, not imagineering).

risks/issues:

any server that does a yes/no on "is this a good address" risks leaking 
those good addresses to spammers.

the 'accept/reject' decision effectively has to happen where the mail 
enters your MX relays, or you risk losing that IP address. the legal 
user part can be done anywhere.

For organizations with lots of sub-domains that send mail, it adds some 
complexity to their DNS administration. I don't consider that a huge 
issue.

to me, at first glance, it seems like it's easily implementable, 
doesn't require re-engineering (beyond tweaking sendmail.cf or 
equivalent), and the only significant risk I see is the exposure risk 
above, but it can be engineered to a tolerable level fairly easily 
through fallback delays or whatever. If seems to give domains better 
control (not perfect, better -- the issue of "this is a legal address 
on our domain, BUT THAT ISN'T HIM isn't resolved at all, unless you can 
nail it with the IP lookup). Basically, it solves one small problem, 
without (I think) creating newer ones of any great size.

Thoughts?

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

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 25 Mar 2003 07:27:15 -0500 (EST)

> administration if you want). for sake of simplicity, I'll assign it 

This moves responsibility for authorizing mail from the connecting host to
the owner of the hostname of the connecting host. Currently the host
itself must prevent relay, and needs to use SMTP AUTH or POPAUTH for
roving users. Under this proposal that would be unecessary because the
receiving host would query the authorizer for authorization. Now the
authorizer is the one that decides if mail is legitimate or not.

What is missing is an argument for why this is better, or is better in
combination. Is there a large group of MTAs who would do this but would
not do SMTP AUTH? Is SMTP AUTH to hard? But a whole new authorization
protocol is not likely to be easier. Are there particular problems with
SMTP AUTH that are insoluble?

Furthermore, the authoriser has less information than the sending host. It
doesn't know the actual sending address, or if the actual sender knows the
login id and password for his account, or anything about the message
content.

I would have guessed that most mail originates from servers that are
controlled by the same entity that controls the DNS server of the host
name, and that therefore this proposal does not shift responsibility in
most cases. However many MTAs are on DSL lines where the ISP has effective
control over DNS but the customer controls the machine itself. In these
cases I would guess there was much less liklihood of this proposal being
effected correctly.

Daniel Feenberg

---

From: "Mark Delany" <[email-masked]>
Date: 25 Mar 2003 13:42:23 +0000

> those good addresses to spammers.

eRBL is a variant on this that I've discussed in other forums. The
idea is to reverse the question to be "is this a known bad address".

As the owner of the domain, you get to know about bad addresses
because you get the bounces. In effect, hostauth becomes a cache of
recent bounces to bogus addresses, for some value of recent.

The advantage of this approach is that it doesn't leak addresses and
cannot be used to list-wash.

Using your example, if someone is trying to send mail using
[email-masked], in very short order you'll start getting bounces
to that address because spammer lists are rarely perfect. As soon as
you get the bounce and the local delivery/forward fails, the address
gets added into your eRBL.

A query for any other email address returns NXDOMAIN regardless of
whether it's valid or not.

Regards.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 25 Mar 2003 10:02:55 -0500

>recent bounces to bogus addresses, for some value of recent.

There are an infinitely number of bad addresses and a finite number 
of good ones.  Given that you only know about the bad ones *after* 
the spammer has used them, and given that they can generate a unique 
one in every N messages, I don't see this is a big win.

I bounced over 40,000 different addresses last year.  I have less 
than 40 good addresses.  Extreme yes, but managing good addresses is 
a lot easier.

And of course, it only works if the spammers send to bad addresses 
that bounce.  But if people implement eRBL, then the spammers have an 
easy way to avoid sending to bad addresses.
-- 
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: [email-masked]
Date: Tue, 25 Mar 2003 10:18:02 -0500

> than 40 good addresses.  Extreme yes, but managing good addresses is 

A good point.. and then you said...

> easy way to avoid sending to bad addresses.

You say that like it's a bad thing... ;)

Sites go to incredible lengths to keep usernames secret.. and they they
get dictionary-attacked, which is probably even worse from the mail system
point of view.