In <MHEGIFHMACFNNIMMBACAGEJBINAA(_dot_)sethg(_at_)GoodmanAssociates(_dot_)com>
"Seth Goodman" <sethg(_at_)GoodmanAssociates(_dot_)com> writes:
It's an answer we've discussed in the past and have more recently improved
to answer various objections/perceived problems. The protocol is called
Signed Envelope Sender (SES) and was the predecessor of BATV.
You should have seen Dave Crocker's face at the MARID interim meeting
when I asked him what the difference between his proposal and SES
was. Then I started pointing out all the holes in his idea that we
had already discussed and mostly solved in SRS/SES.
This protocol has
been worked on for a number of months on a separate list subsequent to
discussing it here early in the year.
I thought the mailing list that you were discussing this on was
sender-auth(_at_)lists(_dot_)infradead(_dot_)org, but either that list is dead,
or I
was bounced off it. Which mailing list is the SES discussion on?
Signature verification
by a DNS server is sufficiently lightweight that it is little more than a
normal DNS query, several of which occur for every message received in any
case.
Both SPF and DK are DNS cache-friendly (or about as friendly as they
can be). All messages coming from the same source within the DNS TTL
of the SPF or DK record require no new DNS lookups. (Now, for some
reasons, companies like google and AOL both have 5 minute TTLs.
*Yech*)
So, I'm doubt your claim that several DNS lookups are required per
message. Especially for larger MTAs that use local copies of DNSBLs
and such.
The major problem I see with your specialized NS server is that in
order for the forwarder problem to be solved every sender must run
one. Also, unless you either integrate the specialized code into a
standard NS or having your specialized NS act as a proxy, you need a
separate IP address for the server.
I like your idea of a SES NS server and SPF records, and it certainly
can work well for many situations. Sadly, I don't think it is a
cure-all. :-<
recipient looks up the SPF record for "domain" and finds an SES modifier in
the record, such as:
v=spf1 a mx ses=exists:{%l}._ses.{%o} -all
This modifier is evaluated like a mechanism for those parsers that
understand it, with a possible caveat.
Why use a modifier instead of just the exists: mechanism?
-wayne