Hi people,
Before I make a gigantic fool of myself, I'm going to lay these ideas
before the IETF so I can have the usual disperse range of comments before
pushing this toward the ASRG/draft/similar. I know of only one distinct
and important catch in this proposal, that being a modification to all
MUAs and MTAs to allow the acceptance and carrying of a password token
which should persist throughout the entire mail delivery, which may or may
not somehow get itself encoded into the envelope sender (using a hack in
source routing, perhaps) if persistence can't otherwise be guaranteed due
to lack of ESMTP implementations and/or other problem with this
assumption. In other respects, though, I think you'll find complete
backward-compatibility and all round niceness. There may also be this
issue with new network traffic generation, which we'll try and address
later. Note as well that this isn't the full story since we deliberately
leave out a big part of this spec to your own imaginations - the token
server, DNS record format and said source routing hacking. More later.
It goes without saying that if you have any questions, you should feel
free to ask!
Okay then, here we go:
My proposal is a scheme for anti-forgery, which makes use of a non-blank
token, or password, which can be verified by a recipient system as
matching against a password submitted by a sender and against a list of
passwords held at a fixed location by the sender domain's designated query
resource, before accepting mail from the sender. This means that the
whole bother about listing domain names and IP addresses should be
completely alleviated, even when a user makes use of spoofing and
autoforwarding for good reasons and provided the envelope is properly
preserved for the true sender; only the password should determine whether
the recipient gets the mail and/or considers it likely spam, and it's the
sender's responsibility to ensure it gets sent either directly or by the
forwarder. The need for rewrites may or may not be necessary, that's open
for you lot to discuss. In short, it's like SPF, but without the
heartache inherent in the good and sensible among us resulting from such
strong dependence on the aspects of connecting hosts, but with the added
inconvenience of additional network traffic (more later) and the token
transfer. Here's the outline:
1. Sender MUA submits message through some host X, indicating token to X
using the stok extension to be defined in SMTP as an extention to its
"mail from:" command:
mail from:<someone(_at_)example(_dot_)org> stok=blorb
If the server doesn't support the extension or ESMTP, the client will
proceed normally, and the authentication simply won't work, with or
without fatal results.
2. X stashes away token, and does the usual lookup in DNS to figure out
where the mail is going. It may use one or more relays, in which case it
should submit the mail envelope in precisely the same way as in step 1,
above, inclusive of token as parameter to stok. The point here is that
the password *must* be submitted down the whole chain as in the
preservation of the envelope, else the whole thing breaks. Still, it does
so in a friendly and hopefully short-lived way.
3. Assuming X uses one of example.org's MXs and delivers straight to it,
X will listen out for the advertisement of the stok keyword, and make the
final mail transaction, beginning with the "mail from:" and including the
stok=blorb as above. At this point, policy at the MX determines how mail
from unauthenticated submitters is to be handled; it might refuse outright
if no token is given, it might flag it with a header - whatever takes its
fancy. Anyway, here comes the bad bit.
4. MX begins a password query. It must connect to some kind of password
query resource. The MX may connect to a designated MTA for a domain and
use the stok keyword to query for a password (>>"stok blorb" <<"250 Token
is tasty!") or some other simplified database query. No publically
accessible list may be used, since spammers can just as easily use those
(my original thought before it bombed on me), unless they are accessed by
verifying that the MX is somehow in authority to do so, provided no other
host can (I can't think of such a way that can't somehow easily be
circumvented by someone with a DNS server handy). Anyway, whatever way
this query works, we publish the resource type and location in DNS (or
just the location if only a single type of query is used) for sender
domain in a TXT record of that sender domain.
5. Authenticated submitters are welcome, unauthenticated submitters
aren't, policy-dependent. All done! Expectations will naturally be that
admins start gentle and get more and more aggressive.
Sidenotes:
1. Implement caching in password requests, similar to DNS, to assist in
keeping traffic minimal and/or use a very minimal password protocol and
daemon?
2. Sender designates stok (Submittal Token) upon creating his/her account
with his/her ISP. MUA of user must add a submittal password field in its
configuration. User must be permitted to change stok whenever he wants
with his provider, perhaps using a provided protocol/service as in POP3PW.
3. Security depends on the protection and unguessability (sophistication)
of passwords. Those tokens will contain no whitespace characters but may
contain legally permitted characters in SMTP transactions. If a spammer
gets hold of someone's password, we're back on square one. Thing is, the
password tells us, without a doubt, who the abusing (or abused victim of
identity theft) was. ISP disables that password, all is good again, and
we can also trace abused/abuser with much greater ease. Naturally, we
don't want to put the password out to the public.
4. MX policy decides whether stok is sufficient enough both to
accept/reject/tag/whatever mail, and also whether it is now safe to lower
open relay or other barriers. However, I personally advise caution -
unless you can be sure that spam from other than forged domain envelopes
will not in big part emerge through your server, perhaps because you
bother to do the A-RR check and also check the existence of a given
domain, don't do it. The short is that this is intended to be forgery
protection to go hand in hand with other means of spam detection and help
alleviate the awful blockage of loads of innocent hosts, and maintain your
freedom to use any relay in your power, not to encourage open relays; I
just hope one day the usefullness of such a system will make it plausible
in the future to do so again.
5. A password query was picked rather than a password list because it
does away with both too much complexity and the whole issue of how to keep
the list away from one pair of eyes and available to another.
6. The insentive to move to this type of standard would be that final MXs
will start refusing, or marking as spam, any unauthenticated submittals.
7. The use of the envelope is yet to be dreamed up by enthusiastic minds;
needless to say we want an audience here and may not be able to depend
easily on ESMTP (though this seems unlikely).
8. This won't stop all spam. If a spammer sets up shop, we're all in
for, especially since standard domain name checks by most modern MTas
won't work neither. Still, tracing these virmin suddenly becomes a bit
easier.
Right, I think that's everything. Any questions? What do you reckon?
Cheers,
Sabahattin
--
Thought for the day:
Bagpipes (n): an octopus wearing a kilt.
Latest PGP Public key blocks? Send any mail to:
<PGPPublicKey(_at_)sabahattin-gucukoglu(_dot_)com>
Sabahattin Gucukoglu
Phone: +44 (0)20 7,502-1615
Mobile: +44 (0)7986 053399
http://www.sabahattin-gucukoglu.com/
Email/MSN: <mail(_at_)Sabahattin-Gucukoglu(_dot_)com>