On Wed, 2004-07-14 at 02:53, Tony Finch wrote:
On Tue, 13 Jul 2004, Douglas Otis wrote:
Example of a Domain of Responsibility Tag:
C: MAIL FROM:<alice(_at_)example(_dot_)com>
DOR:t:"ddddd.dddddd";x:"ddddd";a:"ttttt";
s:"tttttttt";
b:"tttttttttttttttttttttttttttttttttttt";
d:"alumni.almamater.edu";
(a:algorithm,
t:time-stamp,
x:expiry,
b:base64 signature,
s:selector,
d:domain)
Why not just get the originator's MSA to sign the original return path?
This gives end-to-end authentication of the MSA, does not require any
change to aliasing/forwarding systems or to SMTP, and works well with
callback verification.
Dave Crocker's BTAV draft is a start at a specification.
http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html
You are right, this could be used in the same manner as the BATV draft
presented at the interim meeting, if done at the entry point into the
channel, where the MUA has been authenticated by the SMTP server. This
also has the advantage of being recognizable by the recipient of the
mail, prior to bouncing if detecting fraudulent mail and discarding it,
without slogging through the dozen or so DNS text records to decide
whether the message is a member of a set. DOR (of access) works without
changing the way mail works nor does it require channel checks. :^)
I suggested down stream to use the SPF algorithm. On considering the
advantages, it would be better to do this as Dave Crocker had structured
it. I doubt DNS can scale to allow the SPF algorithm to be "closed" as
needed to abate spam and fraud. With the submitter mailbox being
assigned by the MUA, as done with the Submitter proposal, this simply
allows fraud to continue unabated with publicly published records
allowing points of access for fraud. It also allows deny-ability, as
anyone could become victim of fraud, both the recipient of the mail as
well as the records used to allow the fraudulent mail to be delivered,
because of Sender-ID allowably broad definitions.
With the DOR scheme, the bounce could be avoided where it saves
bandwidth as well as preventing fraud from otherwise reputable domains.
There would also be a verifiable domain to handle abuse where this
domain is able to associate the local account with the abusive mail.
This is much more information than that obtainable from Sender-ID which
leaves the authenticating domain indeterminate. Sender-ID would leave
open the question as to how any abuse is to be abated or how rules are
to be enforced. Sender-ID does not permit accrediting abuse from an open
list or a broadly defined region of address space. Because Sender-ID
can be so broadly defined, enforcement would be virtually impossible.
The DOR tag can close the door or else a bad accreditation results. :^)
-Doug
-Doug