AccuSpam wrote:
And including the private key in the auto-response sounds a bit
daft too
AccuSpam wrote:
I agree. It should be changed to request mechanism, where the MUA
does a request over secure channel such as HTTPS. Will modify the
specification.
I wrote too quickly. On further thought, this can not be changed,
because the access to the mailbox is the only assurance of
trustSenderKeys has that the MUA is the sender's MUA.
Indeed, you wrote too quickly. It has been put to you whether you are making
things up as you go along. I would not necessarily put it that way; but
clearly you must see, from your own wording here, that you have not even
made the beginning of a serious proposal.
I read your entire document; and not to be rude or anything, but it all
sounds frightfully amateuristic. Perhaps because you have chosen to modify
the MUA side of things: an ill-begotten plan to begin with. Because users
know nothing; they have no tools, nor the skills to use them, nor even the
inclination. It already starts here:
"SenderKeysTM adds an e-mail header"
And how will users go about doing this? They will disassemble their Outlook
Express code and patch in some hooks? See? You have not even thought through
the most basic obstacles. Will others patch their MUA for them? How? It is
not like Outlook Express can just be compiled/reinstalled. And even if,
yeah, users are really in the habit of doing that stuff daily, right?
Will Microsoft do it for them? They would, if already millions of people
were using it. But nobody CAN use it, until the Microsoft patches arrive!
The ol'd chicken and the egg story. That is why SPF is so brilliant: because
it is easily deployable. No need to try and teach your grandma how to patch
her Outlook Express; just an administrator, somewhere far away from her,
changing a DNS record, and adding a milter/policy daemon of sorts.
To say that SPF is too cumbersome because you have to change DNS records now
and then, is being disingenuous at best. One administrator, at one MTA site,
making a one-time, minor change to a DNS record, far and far, and far,
outshines your convoluted plan of having all users update their MUA's (which
is something they cannot even do themselves).
But why would anyone even do so? Most MUA have built-in supports for
cryptography, and can use standards like STARTTLS to communicate with their
respective MTA's, if a secure channel is required. Why would anyone start
patching MUA's, just to accommodate your very bad idea of sending private
keys over the wire? Well, to be honest, you retracted that idea; then you
'emendated' to this:
"... where the MUA does a request over secure channel such as HTTPS"
Like in "HTTP for which you need a certificate"? Uhm, why not use SMTPS
then?? Or STARTTLS. What you are basically saying is, that you need a
regular secure channel to send your less-than-regular private keys. LOL. :)
I will stop now. I am getting too sarcastic. But you keep covering one hole,
just to open an even bigger one. You take things personally, I understand
that. If a proposal of mine were raked, I would probably be defensive too,
and quick to retort. But the best thing for you to do, IMHO, would be to say
to yourself, "Ok, I goofed; clearly I have not thought things through.
Before I swallow my entire leg, let me just go back to the drawing board,
and conjure something up for which I, myself, have already been able to
counter the most basic objections, lest I look foolish." Whether you will do
so, remains to be seen, of course. ;)
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx