[Asrg] a "baby steps" proposal.

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 fluxmonger(_at_)yahoo(_dot_)com(_dot_) 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 "fluxmonger(_at_)yahoo(_dot_)com" 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 
chuqui(_at_)plaidworks(_dot_)com can send email, but bin(_at_)plaidworks(_dot_)com cannot. 
Neither can fluxmonger(_at_)apple(_dot_)com(_dot_) 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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg