Wietse,
One other thing about the different, DKIM is not really a "ECHO/PUBLIC"
concept. Its more direct mail with a complexity of mailing list as well.
Its funny that you bring this up. I don't know if others remember
Planet Connect (http://www.planetc.com) but in the early 90s' it was one
the first commercially viable satellite based broadcasting "Mail and
File" distribution systems. It was one the first ways before PPP
connectivity was broadly viable to offer high bandwidth distribution of
both internet and fidonet data.
It broadcasted:
Usenet newgroups
Fidonet Echo Mail (MAIL BONE)
Fidonet Echo File (FILE BONE)
I can't recall the subscription model, but its receiver box including
some "key" concept that control the subscription process and what data
is dechipered. If I recall, it was only unidirectional as with all
early satellite broadcasting system and who used a phone line for any
feedback requirement.
At the user end, typically a Mail Hub with its own subscribers using
UUCP/SLIP or FTP or FIDONET, it only collected the data of group
interest, discarding the rest. If a member subscribed to a newsgroup or
fido echo, it included the item for the collection.
Now, it could it been used to send direct mail? or a mailing list
broadcast using a DKIM data encryption system?
Well, on the creation side. I will need an outbound wire (SMTP) to the
PC site who would broadcast it. As part of the broadcast, it could
encrypt the email with the subscriber PC key.
Putting aside security issues, it is theoretically possible for my
receiver box will see this email packets and will automatically decrypt
only those DKIM emails belonging only to this box.
In this case, the PC service will do all the DKIM validation and SSP
checking before the PC subscriber encryption and broadcast takes place.
Of cause today, the encryption part is not required because the ISP site
(SMTP receivers) will direct/hold mail for MUA subscriber pick up. No
broadcasting concept.
The SMTP receivers can do the DKIM/SSP checking and the end-users don't
have to worry about it.
--
HLS
Hector Santos wrote:
Wietse Venema wrote:
Perhaps an analogy from a different but familiar world will help.
Consider DKIM or SSP as broadcast radio transmissions (or TV if
you must). The point is that it is a UNIDIRECTIONAL thing. The
sender doesn't know if anyone is receiving the signal, and they
certainly can't force anyone to listen (or watch their TV program).
Likewise, the sender of DKIM-enabled email doesn't know if the
receiver implements DKIM or SSP, and they certainly can't force
them to implement unenforceable statements that say "deny".
DKIM and SSP have no more "enforcement" power than broadcast radio.
You don't know who "receives" the signal and you certainy can't
force them to do anything with it.
With the DKIM and SSP broadcast model, you can define the format
of the signal and its meaning. That's all. If you want to control
the receiver and "deny" mail, then you need a fundamentally different
model.
Yes Wietse.
Thank you for highlighting the simple broadcaster/receiver model. It was
very appropiate.
If I may fine tune (excuse the TV pun) the model....
The new "technology" added to the electronic broadcast are with the new
XYZ (DKIM) markings in the bit, byte or packet streams (analog or digital).
Only new compliant receiver boxes are capable of deciphering or making
any use of the XYZ markings in the stream or piggybacking on the stream.
Now, what is the purpose of the new XYZ markings in the broadcast signals?
That depends on who is doing it and way:
- Is this an Information based marking?
- Is this a new control-based marking?
If we step aside a second using a real model, the TV satellite and cable
industry also faced both design questions.
- Informational - improved receivers gives you fancier menu, it
addressed the ergonomics of the user experience.
- Controls - improved receivers allow the vendors to leverage new
subscription models, including helping them to secure
against pirating. This migh also include logic that
leverages new BI-DIRECTIONAL communications hardware.
So who will want this?
Well, the vendors (senders) will be tickled pink if they can get
everyone to purchase or license a new receiver box. That way the vendor
profit margins are improved in the name of improving the quality of the
user experience/service. New feedback information will help in direct
marketing ideas.
How about users?
Well, I will venture to say only the users who don't want the additional
controls will be those with illegal subscriptions. So they will stay
away from any new receiver boxes if they don't have to. But they might
desire the neat new GUI boxes because it now allows them to do all kinds
of other stuff, i.e. PVR. Vendors know the power of marketing, so they
will entire these users and also migh offer some amnesty (Upgrade) program.
So yes, indeed, the model is very appropriate for DKIM.
However, the differences are these:
The new XYZ/DKIM markings is a standard and not proprietary. That means
other broadcasting vendors, including broadcasting sniffing pirates can
do the same thing and might be able to use to this to exploit
"something" about this new XYY/DKIM markings and know logic it is know
to allow or offer.
So how we resolve this?
Policy and authorization (SSP) concepts.
Within the XYZ/DKIM broadcasting markings is a FEEDBACK bit that tells
the receiver how/where to double check the originality of the XYZ
packet. This will require a BI-DIRECTIONAL concept and usually it back
to the original holder.
Now my new receiver box is getting true signals from the vendor I am
paying money too and I don't have to worry about getting fraudulent
broadcasting that might try to do something harmful to my system or my
interrupt my watching (reading) entertainment. I will get silly marque
messages on the TV screen trying to sell me something.
Here's the irony:
Everyone is doing this in the telecommunications world
including broadcasting, DSL, Cable, Mobil market with
new bi-directional feedback capabilities now possible.
Its about time we catch up with it in the EMAIL world too.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html