On Fri, 16 Jul 2004, Douglas Otis wrote:
After reviewing the Bounce Address Tag Validation (BATV) specification
further:
http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html
At the risk of being very off-topic, I'll say that I prefer a different
syntax for signed addresses than Dave's specification. I think my version
fits in with the spirit of RFC 822 better because it uses a pre-existing
token delimiter (i.e. ".") for separating parts (atoms) of the signed
email address. The following is something I sketched out in early May.
Here "ISSA" stands for "interoperable signed sender address".
Mailbox = Local-part "@" Domain
Local-part = Dot-string / Quoted-string
Quoted-string = DQUOTE *qcontent DQUOTE
Mailbox =/ ISSA-Mailbox
ISSA-Mailbox = ISSA-Local-part "@" Domain
ISSA-Local-part = ISSA-Dot-string / ISSA-Quoted-string
ISSA-Dot-string = ISSA-Prefix Dot-string
ISSA-Quoted-string = DQUOTE ISSA-Prefix *qcontent DQOTE
The Dot-string or *qcontent of an ISSA-Mailbox are the same as the
Local-part of the unsigned Mailbox it is based on.
ISSA-Prefix = ISSA-Tag "." ISSA-Data "."
ISSA-Tag = "SSA" ISSA-Version
ISSA-Version = 1*DIGIT
ISSA-Data = Atom
It seems possible to constrain <original local part+timestamp>/sig-type/sig
where the local part and timestamp as to to validate the message. The
order of these elements could be
<localpart+timestamp>/signature/selector
where selector identifies both the algorithm and the domain key
selector.
In my syntax, the ISSA-Version number defines the both the syntax and
the verification semantics of the ISSA-Data, which includes the signature,
timestamp, and any other data required (as you suggest). ISSAs can always
be verified using an SMTP callback, but public-key ISSA-Versions may make
verification possible with just a DNS lookup. (This is where MTA
authentication ^W public key records in the DNS come in.)
This is effectively a lightweight version of DomainKeys with the
additional benefit of much better integration with already-deployed
systems. Like DomainKeys it can be extended to per-user keys (by defining
an appropriate ISSA-Version).
It could also mean if the private portion of the key were shared with
users, they could send from any domain, but that would imply the domain
was willing to trust these individuals. For this to be used from the MUA
and the MTA, the presents of a selector would need to override the MTA
operation.
Part of the point of ISSAs is to define a family of formats so that MUA
software can in principle sign addresses on behalf of a domain or a user,
if the MTA software used by the domain supports the same format as the
MUA, and if the MUA is given the right privileged information (the private
key). It's also a way of detecting that an address is (probably) an ISSA
given no prior knowledge, and a way of recovering the unsigned address
that the ISSA is based on.
I'm planning to implement this form of forgery protection for the
University of Cambridge because it fixes all the bugs in SPF and
Sender-ID:
(1) it provides protection for my users from collateral spam without any
co-operation from the recipient of the forged spam or any other site
(2) it protects against original forgeries with a null return path
(3) it does not require any modification of forwarding services
which is important for a large percentage of my users
(4) it detects forgery before the transmission of message data without any
modifications to SMTP
(5) the same mechanism allows me to eliminate forgery within the
university
The main downside is that some filters (most frequently anti-virus email
gateways) are frequently incompetently implemented and produce malformed
auto-responses which are collateral spam without a null return path and
directed at a From: or Sender header instead of the original envelope
return path; BTAV doesn't eliminate this form of junk.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
SHANNON: WESTERLY, BECOMING CYCLONIC FOR A TIME, 4 OR 5, OCCASIONALLY 6. RAIN
THEN SHOWERS. MODERATE OR GOOD.