Ok.
Here is a scenario:
I send a signed message somewhere.
To me, it's that simple.
IMHO this-Works: (some of which flies in the face of the scope- I know -
don't care)
-One signature per message.
-Authentication happens in the SMTP process or a process that knows
everything about the message that the MTA knows about it.
- Relays must not sign messages if the messages have already been signed
unless the content has changed (that makes it a new message right?)
- Let the admins figure out what level the RSA is at. I think they know
better than we do about how to get their mail from place to place. If they
set it too high.. reject it! Why is that so hard?
- If the sig is broken, the email is broken- period. Whose bright idea was
it to forgive broken sigs?!
- SSL is what DKIM *should* be. It is the heart and soul of it.
this doesn't work:
"I sign sometimes" This seemed like a joke to me. What is the point if you
can't tell the user if your mail will be signed by you and when it will be
signed. - Will work by putting in FQDN or CIDR's in the SIG line and using
your MTA or MTA data aware process to check it against the sending IP.
"I sign always" - Unless you are draconian, this will not work for you and
you will have to use 'I sign sometimes or never' and that.... well...
currently is useless.
What did I miss?
Regards,
Damon Sauer
On 8/2/06, John L <johnl(_at_)iecc(_dot_)com> wrote:
> I think a more fundamental question is who the consumers of SSP
information
> are. I think that everybody agrees that DKIM receivers are an important
> constituent, but are they the only ones? It doesn't seem very hard to
> envision other consumers.
Usage scenarios would be very helpful. As Dave noted, if people can throw
stuff into a protocol because it might be useful for something nobody
actually plans to do, you end up with terminal bloat.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html