On Tue, 1 Apr 2003 09:12:00 -0800 (PST)
william <william(_at_)elan(_dot_)net> wrote:
This would be my preferred approach. Very similar to draft proposal I
was/am going to write.
Cool. It doesn't solve the problem of course, it just adds path audits
(which is a not-inconsequential value).
The other aspect I've been noodling is using a form of plus addressing
to encode sender-address-specific consent tokens obtained via a
challenge response handshake. It has horrible human usability
features of course. Basic idea:
Bubba writes an email to Boffo.
Bubba's MUA looks for a locally stored consent token from Boffo and
fails to find one. This is done at the MUA level as definitions are
contextual, subjective, etc.
Bubba's MUA emails Boffo for a consent token. This could also happen
via LDAP or SMTP extension ala VRFY or or or... I use SMTP as the
transport as it allows for disconnected operation (eg third world
behind UUCP, dialup, etc).
ObNote: Grammar and typing could be encoded into the consent token
request to allow requesters to describe what type of mail they want
to send to the stranger, thus allowing some forms of policy to be
stated -- but that's a feature for Good Guys, not spammers.
Boffo's MUA auto-replies with a token (which is really a dated source
address).
Bubba's MUA receives the token, stores the token for future use
(policy encoded in the consent reply), and sends Bubba's mail
appropriately.
Boffo, on receiving a SPAM can revoke the token, all tokens for that
sender, etc.
List servers and legit marketing groups the like can auto-establish
the token arrangement at subscribe time, and auto-renew as tokens
expire.
Loosely its a way of encoding killfiles and sender-expense into the
protocol, which is mostly a really stupid idea, but it keeps nagging at
me in that there-is-meat-here way. Most of the benefit seems to be that
it makes the mail transaction more expensive (this is also its critical
flaw). For a spammer to email successfully it would have to accumulate
hordes of consent tokens in a time consumptive process (which would also
be readily visible recipient-server side due to the floods of consent
requests). More particularly they would have to do this fairly quickly
as if not the tokens will expire, and they'll have to do it for every
source address they use... Equally however it trebles the overhead
required for a transaction to three message exchanges for the default
unrelated case, which is not happy news.
<shrug> Just more wet noodles.
Regarding sendmail, its problems are not related to email or dns RFCs,
its just security problems in the programming & design of the program.
<nod, shrug> I tend to be an Exim and Postfix fan. However, OT.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(_at_)kanga(_dot_)nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg